Navigation

DevOps devops orchestration 6 min read

Do You Actually Need Kubernetes?

Kubernetes (often shortened to “K8s”) is the tool everyone talks about, so it is tempting to assume every serious project needs it. It does not. Kubernetes is a system for running containers across many machines, and it shines when you genuinely have that problem. For most small and medium apps, it adds cost, moving parts, and a steep learning curve you do not need. This page is an honest decision framework so you reach for K8s only when it actually pays off.

The real cost of Kubernetes

Before deciding, be clear-eyed about what Kubernetes asks of you. It is not just “run my container.” You take on a control plane (the brain that schedules and watches your containers), its own networking model, its own storage model, and a large vocabulary of objects — Pods, Deployments, Services, Ingress, ConfigMaps, Secrets, and more.

That complexity buys you real things: self-healing, automatic scaling, and zero-downtime rolling updates across a fleet of machines. But you pay for it every day in operational overhead. Someone on the team must understand it, patch it, debug it at 2am, and keep the YAML in order. If your problem is small, you are paying a large tax for benefits you will never use.

Gotcha: Kubernetes does not make a single small app faster or more reliable. For one container on one server it adds risk, not value. The point of K8s is managing many containers across many machines — reach for it when that count becomes the bottleneck, not before.

A simple decision framework

Ask yourself these questions honestly. The more you answer “yes,” the more Kubernetes earns its place.

Question	If “no” lean simpler	If “yes” lean K8s
Do you run many services that must scale independently?	One or two apps → Compose/PaaS	Yes → K8s fits
Do you span multiple servers today?	One box is plenty	A real fleet
Do you need zero-downtime rolling deploys across machines?	Brief restarts are fine	Yes
Do you have someone who knows (or will learn) K8s ops?	No ops capacity	Dedicated platform owner
Is traffic spiky enough to need autoscaling across nodes?	Steady, predictable load	Bursty, unpredictable

A useful rule of thumb: if you cannot fill a whiteboard with at least five or six distinct services that each have their own scaling and deployment needs, you probably do not need Kubernetes yet.

The simpler options, in order

There is a whole ladder of options below Kubernetes. Climb it one rung at a time. Most teams never need the top rung.

A single VPS with Docker Compose

A VPS (Virtual Private Server — a rented Linux machine in the cloud) running Docker Compose handles a surprising amount. Compose lets you describe several containers in one file and start them together.

sudo apt update
sudo apt install -y docker.io docker-compose-plugin
sudo systemctl enable --now docker
docker compose version

Output:

Docker Compose version v2.29.7

A minimal stack in docker-compose.yml:

services:
  web:
    image: myorg/web:1.4.0
    restart: always
    ports:
      - "80:8080"
  db:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_PASSWORD: changeme
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

Then bring it up and check it:

docker compose up -d
docker compose ps

Output:

NAME        IMAGE             STATUS         PORTS
app-web-1   myorg/web:1.4.0   Up 4 seconds   0.0.0.0:80->8080/tcp
app-db-1    postgres:16       Up 4 seconds   5432/tcp

The restart: always policy gives you basic self-healing — Docker restarts a crashed container. Pair it with ufw (Ubuntu’s firewall) to lock down the box:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw enable

When to use this: one server, a handful of containers, a small team. When not to: when one machine can no longer hold your traffic, or you need rolling deploys across several machines.

A PaaS (Platform as a Service)

A PaaS (a hosted platform that runs your app from source or a container, hiding the servers entirely) like Render, Railway, Fly.io, or Heroku is the fastest path for an MVP. You push code; the platform builds, deploys, scales, and gives you HTTPS. You write almost no infrastructure config.

When to use this: hobby projects, MVPs, small startups that want to ship features, not run servers. When not to: when per-instance pricing gets expensive at scale, or you need control the platform does not expose.

Docker Swarm

Docker Swarm is Docker’s own clustering tool. It turns several Docker machines into one pool using almost the same commands and Compose files you already know. It gives you multi-machine scheduling, rolling updates, and built-in load balancing — a large slice of what K8s does, at a fraction of the complexity.

sudo docker swarm init
sudo docker stack deploy -c docker-compose.yml myapp

When to use this: you have outgrown one server and want clustering without the K8s learning curve. When not to: if you need the huge ecosystem (Helm, operators, service meshes) or your cloud provider’s managed tooling — those center on Kubernetes.

Managed containers

Cloud “serverless container” services — AWS App Runner / ECS Fargate, Google Cloud Run, Azure Container Apps — run your container and autoscale it, with no servers and no Kubernetes to operate. They sit neatly between PaaS and full K8s.

When to use this: you have a container and want autoscaling without running a cluster. When not to: when you need fine-grained control over networking, scheduling, or stateful workloads.

Side-by-side comparison

Option	Operational effort	Multi-machine	Good for
VPS + Compose	Low	No	One server, few services
PaaS	Very low	Hidden	MVPs, small teams
Managed containers	Low	Hidden	Autoscaling a single service
Docker Swarm	Medium	Yes	Simple clustering
Kubernetes	High	Yes	Many services, real scale

So, do you need it?

You need Kubernetes when several of these are true at once: you run many services, they must scale independently, you span multiple machines, you require zero-downtime deploys, and you have the people to operate it. If only one is true, a simpler rung handles it for far less effort. It is also completely fine to start simple and migrate to Kubernetes later — that is the normal, healthy path. Adopting K8s “to look modern” is the most common and most expensive mistake in DevOps.

Best Practices

Start on the lowest rung that solves today’s problem; climb only when you hit a real wall.
Count your independently-scaling services honestly — fewer than five rarely justifies Kubernetes.
Never adopt K8s without someone who owns it; an unmaintained cluster is worse than no cluster.
Prefer a PaaS or managed containers for MVPs so you ship features instead of operating servers.
Use Docker Swarm as a gentle middle step when you outgrow one machine but not yet the ecosystem.
If you do move to Kubernetes, use a managed service (EKS, GKE, AKS) so the cloud runs the control plane.
Keep your migration path open: containerize early so moving between rungs is cheap.