Belov Cloud: Managed Hosting That Heals Itself

Every minute, the monitor pulls node metrics and probes each managed site, classifying it as healthy, slow, 5xx, TLS-broken, or down. When something fails, autopilot runs a reversible remedy and then verifies the result: reissue the TLS certificate, flush the object and page cache, restart the container, or — for a PHP fatal — parse the error, identify the offending plugin, and deactivate it via WP-CLI. It never deletes anything.

The guardrails matter more than the remedies. A second confirmation probe a few seconds later means one blip never restarts a healthy site. A three-minute cooldown and an hourly flapping budget mean a genuinely broken site gets escalated to a human instead of being restarted forever. Certificates are backed up before reissue and restored if the new fetch fails. An AI triage step picks the first remedy to try — but only from the set that is valid for that symptom, and any unexpected answer or API error falls straight back to the deterministic default. The AI can improve the outcome; it cannot invent a destructive one.

Every detection, heal and verification is written to a per-account activity feed in plain English, so the customer sees what happened and when — including the times nothing was wrong.

Migration is where most hosting promises quietly break. Belov Cloud exports the source database mysqldump-first, byte-exact, which sidesteps a well-known WordPress corruption mode where placeholder escapes get rewritten during a naive export. On hosts with no dump binary or a disabled exec, it falls back to a resumable pure-PHP row streamer. A truncated dump is never restored: the attempt is bounded and accepted only if it carries a completion marker.

The migrated site then lands on the source host’s own PHP version, clamped to a supported range, so nothing that worked on the old host breaks on the new one. Multisite networks are detected up front and routed to a white-glove path instead of being silently flattened. Sites arrive on a staging domain that is blocked from indexing at the edge, get verified, and only then go live with a proper search-replace against the host the site was actually installed at.

Three cache layers, each verified on the node. OPcache removes PHP recompile cost on every request. A per-site Redis object cache — one prefix per tenant, fail-open by construction — caches database query results. And a Souin full-page cache inside Caddy serves anonymous HTML straight from the proxy without touching PHP at all.

Measured TTFB on the node: 5.4 ms for a cached anonymous hit, 3.5 ms for static assets, roughly 60 ms for a fully dynamic, logged-in render. The golden WordPress image was rebuilt from Apache/mod_php to Caddy + php-fpm with on-demand workers, which dropped idle memory from around 570 MiB per site to about 88 MiB — the difference between a node that hosts a handful of sites and one that hosts many.

Cache coherency is handled by an always-on must-use plugin baked into the image: on any content change it sends per-URL purges to the edge, so edits go live instantly instead of waiting out a TTL — and because purges are per-URL and per-tenant, one site’s purge can never touch another’s cache. Logged-in visitors, carts, checkouts, REST and admin paths bypass the cache entirely.

One deliberate omission is worth naming: PHP JIT is force-disabled, and the image build refuses to produce an artifact with it on. It was segfaulting php-fpm and producing intermittent 502s that the monitor could not see. Chasing a benchmark number was not worth an invisible failure mode on live sites.

Per-tenant managed WAF is an enterprise-only product at the big CDNs, so we built ours. The edge Caddy image is compiled with Coraza and the embedded OWASP Core Rule Set, running in blocking mode with WordPress-specific exclusions — SQLi, XSS, traversal and scanner traffic get a 403 while legitimate admin, REST and UTM-tagged traffic passes untouched. Per-path and per-field exclusions let a site declare the specific endpoints and form fields that must not be inspected, which is what makes running CRS in blocking mode survivable on real WordPress.

CrowdSec adds behavioural IP-level defense on top, parsing per-site access logs and SSH journals and pushing bans into a firewall ipset. Cloudflare for SaaS gives every customer domain edge TLS and DDoS protection through a single CNAME, with no Cloudflare account of their own and no exposed origin.

Tenancy isolation is enforced structurally rather than by convention: container, database, database user, volume and cache prefix are all derived from an opaque internal ID, the agent returns the authoritative names on provision, and the control plane stores and replays them instead of ever re-deriving a name from a customer-supplied domain.

HTTP checks tell you a site responded. They do not tell you the homepage now renders as a blank white column. Every ten minutes a worker screenshots each managed site with headless Chrome, diffs it against a stored baseline with pixelmatch, and when the difference exceeds threshold, asks a vision model one question: is this a real regression, or an intended change the owner just published?

Only regressions raise an alert; intended changes are recorded and acknowledged. If the judge is unavailable, the system alerts anyway — the safe default is a false alarm, never a missed outage.