Do not run Kubernetes for a client project that fits on one server, has no autoscaling requirement, and is maintained by fewer than three people who touch infrastructure. A single Docker Compose host running behind a reverse proxy handles the majority of small agency workloads, and it costs you exactly two things: minutes of downtime during reboots, and a manual path back from hardware failure. Kubernetes does not remove those costs, it converts them into a control plane you now have to keep alive. Pick the failure mode you can actually staff.
TL;DR by reader profile:
- Agency running 12 client sites on one provider (WordPress, Node APIs, a few static builds): one Compose host per client tier, because per client blast radius matters more to you than scheduling, and your real risk is a botched deploy, not capacity.
- Two person team with one revenue critical app (SaaS, single Postgres, 24/7 traffic): Compose plus a warm standby and tested restores, because a second machine you can promote beats a cluster nobody on the team can debug at 3am.
- Team of six with a genuine multi service platform (8 or more services, several deploys a day): Kubernetes starts paying for itself here, because rolling deploys, health gating and per service resource limits stop being manual work.
- Contractor handing infrastructure back to the client at the end of the engagement: Compose, because a docker-compose.yml plus a README is a deliverable the client can actually run, and a cluster is a dependency on you.
- Anyone under a contractual uptime commitment with penalties (SLA with credits attached): you need redundancy of some kind, and that is the one case where the orchestration question becomes a real engineering decision rather than a preference.
- Solo developer hosting side projects and one paying client: Compose on a single host, because every hour spent on cluster maintenance is an hour not billed.
The central tradeoff: Kubernetes buys you automatic recovery and rolling deploys at the price of a permanent operational surface you must keep patched, while Compose buys you a system one person can hold in their head at the price of doing recovery yourself.
Table of contents
When should you not run Kubernetes?
Skip Kubernetes when the cluster would exist to solve a problem you do not have yet. Four conditions, and if three of them describe your project, stop.
Your workload fits on one machine: the whole stack, application, database, cache and reverse proxy, runs inside the RAM and CPU of a single server you can afford. If you are not resource constrained, the scheduler has nothing to schedule.
Traffic is predictable: you know roughly what next Tuesday looks like because it looks like last Tuesday. Horizontal Pod Autoscaler is worth real money when load swings by an order of magnitude within an hour. It is worth nothing when your peak is 3x your trough and both fit on the same box.
Nobody on the team owns infrastructure full time: Kubernetes is a system that needs a person. Version skew between control plane and nodes, CNI upgrades, cert rotation, ingress controller changes and deprecated API versions all arrive whether or not anyone is assigned to them.
The client will eventually own this: you are building something you hand over. A cluster is a hiring requirement disguised as a deployment target.
| Condition | Points to Compose | Points to Kubernetes |
|---|---|---|
| Capacity | Everything fits on one host | You are already sharding across machines |
| Traffic shape | Predictable, within 3x daily swing | Spiky, unpredictable, event driven |
| Team | Under 3 people touching infra | A named platform owner or team |
| Deploy frequency | A few times a week | Several times a day across services |
| Handover | Client inherits the stack | You operate it indefinitely |
| Uptime terms | Best effort, informal | Contractual SLA with penalties |
The inverse is also true, and worth saying plainly so this does not read as a hit piece. If you run 8 or more services that deploy independently, if two teams need to ship without coordinating, or if your uptime commitment survives a single machine failing, Kubernetes is the correct answer and Compose will hurt you.
Top comments (0)