If you are a small team shipping a web app, you almost certainly do not need Kubernetes yet. A single container image deployed to a managed platform, or a couple of VMs behind a load balancer, will carry you further than most engineers expect — often to seven figures of revenue. Kubernetes solves problems you get after product-market fit; adopting it before then mostly buys you a second full-time job maintaining the cluster.
I've run both setups. This post is the argument I wish someone had handed me before I spent a weekend debugging a CrashLoopBackOff that turned out to be a missing environment variable — a bug that would have been a one-line log entry on a boring stack.
What does Kubernetes actually give you, and what does it cost?
Kubernetes is a container orchestrator. Its real value shows up when you have many services, many nodes, and a need to schedule, restart, scale, and roll them out without a human in the loop. Self-healing pods, horizontal autoscaling, rolling deploys, service discovery, and declarative config are genuinely good features.
The cost is that every one of those features is a system you now operate. The cluster control plane, the ingress controller, the CNI network plugin, cert rotation, node upgrades, RBAC, secrets management, and a YAML surface area large enough to hide subtle mistakes for days. Managed control planes (EKS, GKE, AKS) remove some of that, but you still own the worker nodes, the networking, and the deploy pipeline.
The trap is that the value scales with your number of services while the cost is mostly fixed and paid up front. For a three-person team with one app and one background worker, you pay nearly the full operational tax to solve a coordination problem you don't have.
Kubernetes' benefits scale with the size of your fleet; its costs land on day one regardless of your fleet size.
When is a boring stack the right call?
A "boring stack" here means: one container (or a small handful), a managed runtime that handles restarts and TLS for you, a managed Postgres, and deploys triggered from git. No cluster to babysit.
For most early-stage products this is not a compromise — it's the correct engineering decision. It gives you the two things that actually matter early: fast iteration and few moving parts to debug at 2am. When your app is a monolith plus a worker, "the platform restarts it if it dies and gives me a URL" is 90% of what you'd have reached for Kubernetes to get.
If you want the managed version of "just run my container with health checks, TLS, and zero-downtime deploys," Render is the platform that handles restarts, rollouts, and certificates without asking you to think about nodes. If you want your app running close to users in multiple regions with a real edge network and you're comfortable with a bit more infrastructure literacy, Fly.io is the one that gives you global deployment without standing up a cluster. If you want the fastest possible path from git push to a live URL with a database attached and are fine trading fine-grained control for speed, Railway is the one optimized for that first-hour experience.
None of these are perfect. Managed platforms cost more per compute unit than raw VMs, you inherit their outages, and you can hit ceilings on custom networking or GPU workloads. But "I occasionally pay a premium and can't tune the kernel" is a far cheaper problem than "my team spends 20% of its time operating a cluster."
The right question isn't "can Kubernetes do this?" — it can do almost anything — it's "is running the cluster cheaper than the problem it solves for me?"
How do the options actually compare?
Here's how I'd weigh the common choices for a small team, as of mid-2026:
| Option | Ops burden | Best fit | Main drawback |
|---|---|---|---|
| Managed PaaS (Render, Railway, Fly.io) | Very low | 1–10 services, small team, no dedicated ops | Higher per-unit cost, platform lock-in |
| Single VM + Docker Compose | Low | Side projects, internal tools, MVPs | Manual scaling, single point of failure |
| VM + systemd (no containers) | Low–medium | Long-lived monoliths, predictable load | You manage the OS and deploy scripting |
| Kamal / Docker over a few VMs | Medium | Rails/Node monoliths wanting zero-downtime deploys | You own the servers and networking |
| ECS / Fargate | Medium | AWS-committed teams, moderate service count | AWS-specific config, IAM complexity |
| Kubernetes (managed) | High | Many services, real autoscaling needs, platform team | Steep operational tax, large config surface |
| Kubernetes (self-hosted) | Very high | Specific compliance/hardware needs | You are now an infrastructure company |
The pattern: complexity and cost rise together as you move down the table, and you should only move down when a concrete problem pushes you there — not because a conference talk made Kubernetes sound inevitable.
Adopt orchestration the way you'd adopt any dependency: when the pain of not having it exceeds the pain of running it.
What are the real signals you've outgrown the boring stack?
Boring stacks do run out of road. The mistake is switching too early or ignoring the signals when they genuinely arrive. Real triggers I trust:
- You have more than roughly 8–12 independently deployed services and coordinating their configs, networking, and rollouts by hand has become error-prone.
- You need bin-packing across many nodes for cost reasons — lots of heterogeneous workloads that a scheduler would place far more efficiently than you can by hand.
- You need genuine autoscaling tied to metrics, not just "add a bigger VM," and traffic is spiky enough that manual scaling loses you money or uptime.
- You have a dedicated platform/infra person or team whose job is to run this. Kubernetes without an owner rots.
- Multiple teams need self-service deploys with isolation and a shared, declarative substrate is genuinely the cleanest way to give it to them.
Notice what's not on this list: "we might scale someday," "investors expect it," or "it's what serious companies use." Those are aspirations, not load. A useful middle step before full Kubernetes is a lighter tool — Kamal for pushing containers to a few servers with zero-downtime deploys, or HashiCorp Nomad if you want scheduling without the full Kubernetes ecosystem; Nomad is the orchestrator to reach for when you want multi-node scheduling but not the operational surface of a Kubernetes cluster.
If you can't name the specific service-count or scaling problem Kubernetes solves for you this quarter, you're buying insurance against a fire you don't have.
FAQ
Do I need Kubernetes to scale a web app?
No. You can scale a single containerized app a very long way by running more instances of it behind a load balancer on a managed platform. Kubernetes helps coordinate many services across many machines; it is not a prerequisite for handling traffic.
Is Docker the same as Kubernetes?
No. Docker packages and runs individual containers; Kubernetes orchestrates many containers across a cluster of machines. You can use Docker (and Docker Compose) with zero Kubernetes, and for most small teams that's the right starting point.
When should a startup actually move to Kubernetes?
When you have many independently deployed services, a real need for scheduler-driven autoscaling or bin-packing, and someone whose job is to operate the cluster. If you can't check all three, a managed platform or a lighter orchestrator will serve you better.
Bottom line
If you're a small team, start boring: one container image, a managed runtime, a managed database, deploys from git. Reach for a lighter orchestrator like Kamal or Nomad when you have several servers and want zero-downtime deploys without a cluster. Move to Kubernetes only when your service count, autoscaling needs, and a dedicated owner all point there at once. The goal is to spend your scarce early engineering time on the product, not on the platform underneath it.
