The failure modes were not subtle. Docker layer cache invalidation across hundreds of WordPress sites with slightly different plugin sets means storage cost grows non-linearly. Cold-start latency on a previously-unseen site was 300–900ms — fine for a serverless function, catastrophic for a publisher's homepage. And the kernel work to keep each container's network namespace isolated was, in the end, work we were paying for twice.

The primitive we actually wanted was already in the kernel: cgroups v2, exposed cleanly by systemd 'slice' units. Each site gets a slice that caps CPU, memory, and IO. A Linux user, a PHP-FPM pool, an Nginx server block. The site cannot escape the cgroup. The PHP-FPM pool is named after the user. The user owns nothing but its own document root. We get hard isolation, near-zero overhead, and a deploy step that is mv followed by systemctl reload php-fpm.

Docker was not wrong; it just was not the right tool for this shape of workload. The lesson, again: Linux has spent thirty years on multi-tenancy. Use it.

The site under test is a clean WordPress install with WooCommerce, 25 products, a Storefront theme, no caching plugin. Identical export imported to four hosts plus CubitRace. Each host's largest 'small business' plan, billed monthly. Probes from a single k6 worker in fra1, hitting origin (no CDN). 30-minute warmup followed by 60 minutes at three load profiles: 50 / 200 / 500 concurrent users.

The numbers, the k6 scripts, the raw stage outputs, and the post-run analysis are all in our public benchmarks repo. We are happy to re-run any host on request. If you find a methodological problem, open an issue — we will fix it.

Caddy's on-demand TLS solves this with a simple ask-before-issue handshake. When the first TLS request for an unknown hostname arrives, Caddy pauses, asks our control plane 'is this a real customer domain?', and only on a yes does it kick off the ACME flow. The 'ask' endpoint is an internal API that consults the same domains table the dashboard writes to. Bad guesses, scanners, and stale DNS records get a polite no — and never touch the rate-limit budget.

We layered two extra safeguards. First, a redis-backed circuit breaker that backs off if we hit transient ACME errors. Second, ALPN-01 + HTTP-01 fallback so a single broken DNS record on a customer domain does not block the rest of the issuance pipeline. The result: 99.97% of new domains have a working cert within 15 seconds of DNS propagation, and we have never been rate-limited.