We do not have client logos to show yet, so here is the system we know best: our own. The Cloudverg team builds and runs a fleet of production websites, from mutual-aid and family tools to an AI debate platform and an online store. Everything below was read from the servers on November 5, 2026.
The fleet at a glance
| What | Count | Notes |
|---|---|---|
| Public production sites | 12 | Each answers on its own domain, plus an admin portal and a single sign-on hub |
| Virtual machines | 5 | One 8 vCPU / 24 GB machine, three 4 vCPU / 8 GB machines and one 4 vCPU machine for this website, from two hosting providers |
| Postgres servers | 12 | Postgres 17 everywhere: nine on the busiest machine, two on the data machine (one of them Supabase), one on the web machine |
| Containers | 62 | Docker, with per-container log rotation |
| DNS zones on Cloudflare | 12 | Bot Fight Mode on, with verified crawlers and AI agents allowed |
| Mail servers | 1 | One self-hosted Stalwart server handles mail for all 12 domains. DMARC is set to quarantine on 11 of the 12. |
How it is put together
- Private network. The machines talk over a WireGuard mesh (Tailscale clients, self-hosted Headscale control server), so databases and internal services never listen on the public internet.
- One sign-on. Users sign in once through a shared OpenID Connect hub used by the sites.
- Deploys. Every site deploys the commit that was pushed, from a clean checkout, into a new release folder, then switches a symlink. Rolling back is one command. A deploy refuses to run if the live release is not part of what is being shipped, so two people cannot overwrite each other.
- Monitoring. Prometheus on the busiest machine scrapes all nodes. A health service collects browser errors and failed requests from every site.
- Patching. All five machines were fully patched on November 5, 2026, with Docker live-restore so containers kept running during the engine upgrade.
One tuning pass, measured
On October 30, 2026 the busiest machine was running out of headroom. We did not buy a bigger one. We moved batch work to machines that had spare CPU and tuned what stayed, checking that every output came out identical before switching:
| Change | Before | After |
|---|---|---|
| Kafka broker: health check without starting a JVM, 768 MB heap | 13% of a CPU core | About 4% |
| Avatar image rendering moved to the batch machine, in its own idle-priority slice | On the busiest machine, competing with web traffic | On the batch machine, about 7 minutes per image including queue time, pixel-identical output |
| Product photo background removal moved to the data machine, started only on demand | On the busiest machine | Capped at 3 threads and 2.4 GB, identical masks |
| Postgres planner settings for SSD storage | Defaults for spinning disks | Tuned on 6 databases, plus foreign-key indexes on the largest app |
One lesson worth sharing: “nice” and idle scheduling only rank processes inside their own control group. A busy service in another slice can still starve your batch jobs, so background work needs its own top-level slice with idle CPU weight.
What this means for your cloud
The same habits pay off at any size. Measure per service before you resize anything, move batch work off the machines that serve users, keep databases on a private network, and make every deploy reversible in one step. If your bill or your incident list is growing faster than your traffic, these are the first places we look in a cloud cost audit.
Talk it through
Book a 90-minute session and bring your own diagram, bill or incident. You get a written summary of what to change first. If you then book the cost audit, the session fee is credited against it.