Kubernetes for small teams: pragmatic setups that hold up

Kubernetes has a reputation for crushing small teams under complexity. In practice, even a three-person team can run it reliably — if you know which shortcuts to take.

“Kubernetes for three developers? Aren’t you way too small for that?” — I hear this objection often, and it isn’t groundless. Running k8s “properly” is a lot of work: logging, monitoring, secrets, ingress, backups, upgrades, network policies, RBAC. Build all of that yourself and you have a full-time platform team.

And yet I run Kubernetes clusters for several small teams and would do so again without hesitation. The trick: don’t build everything yourself.

The genuinely necessary list

In my experience, these are the building blocks a small team actually needs:

  1. A managed cluster (DigitalOcean, Hetzner Cloud Managed K8s, or a stock GKE instance). Self-hosting the control plane is the most expensive optimization you can make.
  2. An ingress with automated TLS — usually ingress-nginx plus cert-manager. Set up once, then forget.
  3. A GitOps tool like Argo CD or Flux. It forces you to describe everything declaratively, and it turns rollbacks into a one-liner.
  4. A simple monitoring setup (kube-prometheus-stack, or a hosted backend like Grafana Cloud).
  5. Logs in a central system. Loki, Datadog, or even just an S3 bucket — anything that’s reviewable later.

That’s it. Service meshes, operator frameworks, multi-cluster federation — those are things you can add when a concrete problem demands them. Not before.

The most common mistake

The most common mistake small teams make isn’t under-automation. It’s over-automation — at a platform layer that no second application will ever consume. A six-level Helm-chart hierarchy for one Node.js app is busywork.

My advice: write raw YAML for your first applications. When the same block appears three times, that’s when it becomes a Helm template or a Kustomize overlay. Not before.

When it’s worth it

Kubernetes is worth it for a small team when

  • multiple services need to run side by side,
  • the infrastructure should be describable as code,
  • or you want the option to scale later without rebuilding the whole deployment pipeline.

If you only have a single web application, a platform like Fly.io or Railway is often the better choice. There’s no shame in that — only fewer pages at three in the morning.

Outside help

If you’re weighing whether your own cluster makes sense for your team, or if you want to simplify an existing one: I help teams through exactly these decisions, from the first architecture sketch to a productive handover. Get in touch.