Should Small Teams Even Bother with Kubernetes?
Most small teams hit the same question at some point: should we move to Kubernetes? The honest answer for the majority of them is no, but that answer alone is not very helpful. So here is the longer version, with real prices and a clear line where the answer flips to yes.
What Kubernetes gives you
Underneath the marketing, Kubernetes is four practical things:
- Declarative scheduling – you describe the desired state and a controller keeps the cluster in that state
- Self-healing – crashed pods restart, dead nodes are drained, replicas come back automatically
- Bin-packing – many workloads share the same nodes with CPU and memory limits
- A standard API – Deployments, Services, Ingress, Jobs, Secrets, all the same on any cluster
These are real benefits. The catch is that you pay for them in money, time, or both.
What it actually costs
A realistic small-team setup looks like this: 3 services (API, worker, frontend), one Postgres, one Redis, around 50GB of storage. Here is what the same workload costs in three common shapes, all in eu-central-1 / Frankfurt.
Managed Kubernetes (AWS EKS)
- EKS control plane, 0.10 USD per hour: ~67 €/mo
- 3× t3.medium nodes (2 vCPU / 4GB): ~92 €/mo
- RDS Postgres
db.t3.small, Single-AZ: ~27 €/mo - ElastiCache Redis
cache.t3.micro: ~13 €/mo - ALB base plus LCU: ~15 €/mo
- 50GB EBS gp3 plus ~200GB egress: ~14 €/mo
Total: around 228 €/mo, before backups, observability, or any of your time.
GKE used to give you the first cluster for free. That is gone now: control plane is 0.10 USD per hour, and you get a 74.40 USD monthly billing-account credit that offsets one zonal cluster. Regional clusters pay full price.
Single Hetzner box + Docker Compose
- AX42 dedicated (8-core Ryzen 7 PRO, 64GB DDR5, NVMe): from 57 €/mo (April 2026 pricing)
- Postgres, Redis, app – all containers on the same machine, isolated by Compose
- nginx and Let's Encrypt for HTTPS
- Storage Box BX11 (1TB) for backups: ~4 €/mo
Total: around 61 €/mo. That box has enough headroom to run several more projects beside the main one.
Self-hosted Kubernetes (k3s on Hetzner Cloud)
- 3× CCX13 (2 dedicated vCPU / 8GB / 80GB SSD): ~48 €/mo
- You run the control plane, etcd, ingress controller, cert-manager, backups and monitoring yourself
Compute is around 48 €/mo, but the real cost is the hours you put into the cluster every week.
The ops cost nobody prices in
Hosting is the cheap part. Kubernetes adds work that simply does not exist with Compose:
- Cluster upgrades. A new minor lands every four months. If you skip a few, the upgrade path becomes painful.
- Ingress and cert-manager. Works fine until cert-manager hits a CRD migration or your ingress controller deprecates an annotation you depend on.
- CNI debugging. A misbehaving Calico or Cilium pod can take half a day to track down.
- RBAC and ServiceAccounts. Required even for trivial things like letting one pod read one secret.
- PVCs and storage classes. A reboot at the wrong moment can leave a volume stuck in
Terminatingand you reading the controller logs. - etcd. Quiet most of the time, then your cluster is suddenly read-only at 2am and you are restoring from a snapshot.
Realistic estimate: 2 to 5 hours a week of cluster maintenance for a self-hosted setup. Managed clusters cost less time but more money, as the table above shows. For a 3-person team, 2-5 hours a week is 5-12% of one engineer's time spent on infrastructure that does not ship features.
When Kubernetes is the right call
There are real cases where the cost is justified:
- You run more than 20 services that need consistent deploys, secrets and networking
- Multi-region or multi-tenant with hard isolation per customer
- Compliance work (SOC 2, HIPAA) where audited RBAC and NetworkPolicies save weeks of paperwork
- Your team already knows Kubernetes well and Compose would slow them down
- Bursty workloads that genuinely benefit from horizontal autoscaling on shared nodes
- You are building a platform where the Kubernetes API itself is the product (operators, CRDs)
If two or more of those apply, Kubernetes earns its keep. If none do, you are paying for capabilities you will not use.
When it is not
Most small teams have a workload that looks like this:
- 1 to 5 services
- One Postgres, maybe a Redis
- A single region
- Fewer than 5 deploys a day
This fits comfortably on one Hetzner box with Docker Compose, or on a PaaS. No Kubernetes needed, much less money spent, and far less time on ops.
The "we will need it eventually" argument is mostly survivorship bias. Most projects never reach the scale where Kubernetes is actually the cheapest option, and migrating later is easier than people claim. A docker-compose.yml maps almost line-for-line to Deployments and Services when the day comes.
Quick decision table
| Situation | Use |
|---|---|
| Solo dev, 1-3 services | Docker Compose on a VPS |
| Small team, up to ~10 services, one region | PaaS or Compose + Ansible |
| Multi-tenant SaaS with isolation needs | Kubernetes (managed) |
| Compliance-heavy, audited infrastructure | Kubernetes (managed) |
| Building a platform or operator | Kubernetes |
| "Everyone else uses it" | Not a real reason |
The middle ground
A PaaS exists exactly for this gap. You get the useful parts of Kubernetes – self-healing, declarative deploys, automatic HTTPS, isolated namespaces – without running the cluster yourself.
Hostim.dev runs Kubernetes underneath, on bare metal in Germany, so you do not have to. You paste a docker-compose.yml and get a deployed app with HTTPS, Postgres, Redis, volumes, metrics and logs.
The same stack priced on Hostim:
- 3× shared App (2 vCPU / 2GB): 13.50 €
- Postgres (10GB): 10 €
- Redis (2.5GB): 5 €
- 50GB volume: 10 €
Total: 38.50 €/mo, with HTTPS, metrics, logs and backups included.
If you actually need Kubernetes, run Kubernetes. If you are reaching for it because it is the default answer, a PaaS or a single Hetzner box will probably serve you better, for less money and less weekend work.