Kubernetes has a reputation problem. Ask around and you'll hear the same thing: too complex, too much overhead for a handful of client sites.
Here's the part nobody says out loud. Plain VPS hosting has a maintenance problem that's worse. It's just quieter, because you only notice it when a Debian upgrade breaks something at 11pm.
I run FluxCD and OpenTofu on a cluster with real sites on it, and I ran VPS plus Ansible for years before that. The Kubernetes setup isn't easier because it does less. It's easier because the boundary of what you actually have to worry about gets a lot smaller.
The old way: one VPS per client
Provisioning a VPS per client works. I've automated that whole flow with Ansible before: spin up the box, harden it, install the runtime, deploy the app. It's a solid approach and I'd defend it to anyone who says otherwise.
But the OS is yours to maintain, forever, on every box. Security patches. Dependency updates. And the one that actually hurts: upgrading from one Debian version to the next and hoping nothing on that server quietly breaks.
Now multiply that by every site you host, and they're rarely built the same way. One's still on PHP 7.4 because rewriting it isn't worth it. Another's Python with a dependency pin that fights the new OS package versions. You're not maintaining one server. You're maintaining several, each with its own slightly different way of breaking when you touch it.
Docker on a VPS isn't orchestration
Containers move the boundary. Whatever language or runtime a site needs lives inside its own container, not on the host OS. Upgrade the host, and the app doesn't care what PHP or Python version it's running, because it brought its own.
That's not the same as "just run Docker on a VPS," and it's worth being direct about that. Docker or Podman gets you containers, not orchestration. Nothing schedules where things run, nothing notices when a container dies at 3am and restarts it, nothing rolls out updates without you scripting it yourself, and nothing isolates resources between tenants sharing the same box.
Kubernetes' orchestration layer is the actual product of years of work by people solving exactly this problem at a scale way bigger than any of us need. Believe me on this one: docker-compose on a VPS is not in the same category as a real scheduler.
What's left to maintain on the Kubernetes side is just narrower. Mostly: does kubelet still come up healthy after this upgrade. That's a much smaller thing to worry about than "does every dependency on every client's site still work after this OS bump."
What it actually costs
Here's what it costs to run right now: €136 a month, total, for 4 sites on the cluster.
€62 of that is the managed, production-grade HA control plane, and that's the part worth questioning if you're running this at small scale. Worth being precise about what that HA covers: just the control plane. Your actual workloads, the sites themselves, stay just as available either way, since that comes down to how you set up your worker nodes, not which control plane tier you're paying for. UpCloud also offers a development-mode control plane that's free and still supports up to 30 worker nodes. If you don't need control-plane HA yet, you can cut that €62 out entirely.
The maintenance load per site doesn't really change whether you're adding the 5th site or the 15th. That's the actual point. The VPS-per-client approach gets linearly worse with every site you add. This doesn't.
This is a small setup, not some 500-client platform. I'm building it in public, on real traffic, and I'll keep saying so as it grows.
If this is useful, tell me
I'm turning this exact stack, the same OpenTofu and FluxCD setup running these sites right now, into a course and template repo, not a "learn Kubernetes in 30 days" bootcamp. It's the actual repo I use, sanitized, plus the client onboarding and offboarding runbooks that come with it.
I haven't built the full thing yet. I want to know if this is actually useful to people before I spend months on it.
If you're maintaining client sites the hard way right now, or you're planning to build your own agency that hosts apps or websites for clients, drop your email here. You'll be first to know when it's ready, and you'll get a say in what it actually covers.