Comparison • Container orchestration
Every alternative to Kubernetes worth considering, what each one gives up, and the question that decides between them. Written by people who run Kubernetes in production and still think most teams should not.
Most articles on this query assume the answer is no. It is not always no. Here is the split we would actually defend.
You run dozens of services across a fleet and need a scheduler to place them. You have hard multi-tenancy, per-namespace RBAC or network policy requirements. You depend on operators — Postgres, Kafka, cert-manager — that only exist as Kubernetes controllers. You have people whose job includes the cluster. Any of these and Kubernetes is earning its complexity.
Under ten services, under five machines, one team, no regulatory isolation requirement. At this size Kubernetes replaces problems you do not have with a control plane you now have to keep alive. The honest version of "we might need to scale" is that you can migrate later, and the migration is smaller than three years of cluster upgrades.
Not "will we grow". Ask: what is painful right now that Kubernetes would fix? If you cannot name a specific failure — a deploy that takes the site down, a machine that fills up, a service nobody can place — then you are buying a solution ahead of the problem, and the bill arrives every week in attention.
Ordered roughly by how much machinery you end up operating. Checked September 2026.
| Option | Multi-node | You operate | Learning curve | Best for |
|---|---|---|---|---|
| Docker Compose | No | One server, Docker, a reverse proxy | Hours | Everything that fits on one machine |
| Kamal | Yes, over SSH | The servers, and the deploys | A day | Rails-shaped apps on your own boxes |
| Docker Swarm | Yes | The Swarm cluster | A weekend | Multi-node with Compose syntax you know |
| HashiCorp Nomad | Yes | Nomad, usually plus Consul and Vault | Weeks | Mixed container and non-container workloads |
| AWS ECS + Fargate | Yes | AWS configuration, not servers | Weeks | Teams already committed to AWS |
| k3s / lightweight Kubernetes | Yes | A Kubernetes cluster, smaller | Months | You want Kubernetes with less installation |
| Managed container platform | Yes, hidden | Nothing | Minutes | Shipping an app rather than running a platform |
The column that matters is "you operate". Every option above can run your containers. They differ almost entirely in what breaks at 3am and who is expected to fix it.
The closest like-for-like swap, and the one people ask about most.
Swarm ships inside the Docker engine. docker swarm init, join your other nodes, and docker stack deploy a Compose file — you have multi-node scheduling, an overlay network, service discovery, rolling updates, secrets and health checks. There is no separate control plane to install and no new file format to learn. For a three-node setup this is genuinely an afternoon.
Kubernetes gives you what Swarm does not: custom resources and operators, real RBAC, horizontal pod autoscaling, network policies, an ecosystem where every vendor ships a Helm chart. It asks for a control plane, a CNI choice, an ingress controller, and an upgrade cadence that does not stop.
The honest caveat on Swarm is momentum. Development has been quiet for years, and it is maintained rather than advanced. It still ships in Docker and it still works, but you are choosing a stable backwater over a busy highway. That is a reasonable trade for a small team and a bad one if you expect to hire people who already know your stack.
Not really a comparison — they answer different questions — but it is the one people are asking, so here is the answer.
Compose describes containers on one machine. Kubernetes reconciles a declared state across many. Compose has no scheduler, so it cannot place a container on a different node when one dies; it has no rolling update primitive, so a docker compose up restarts things; and it has no concept of a node at all. Every one of those omissions is why it is comprehensible in an afternoon.
The widespread claim that Compose is "not production ready" is mostly wrong. A Compose file with restart: unless-stopped, health checks, resource limits and a reverse proxy in front runs a real business perfectly well, and has for years. What it does not survive is the machine itself failing. If a single server going down is an acceptable incident for you — and for a large number of B2B applications it is — Compose is a complete answer.
Where this gets interesting: you can keep the Compose file and stop owning the machine. Hostim.dev takes a docker-compose.yml directly and runs the services on a Kubernetes cluster it operates, so you keep the file you already understand and lose the server you did not want.
# the file you already have
services:
web:
build: .
ports: ["8000:8000"]
environment:
DATABASE_URL: ${DATABASE_URL}
worker:
build: .
command: ["python", "worker.py"]Paste that into Hostim and both services deploy, with a managed PostgreSQL behind DATABASE_URL. No manifests, no Helm chart, no cluster.
The serious alternative if you want a scheduler but not a platform.
Nomad is one Go binary that acts as both server and client. It schedules Docker containers, but also raw executables, Java applications and batch jobs, on the same cluster — a genuine capability Kubernetes does not have and a real reason some organisations choose it. Operating it is markedly less work: fewer moving parts, a simpler upgrade story, and a configuration language most people find readable.
The cost is everything around it. Service discovery means running Consul. Secrets means running Vault. Ingress, certificates and storage are integrations you assemble rather than defaults you inherit. And the ecosystem gap is real: when a vendor ships one integration, it is a Helm chart. Nomad suits a team that has operations people and wants them working on fewer, simpler things. It does not suit a team that wanted to stop thinking about infrastructure.
Two bills. Only one of them arrives as an invoice. Prices checked September 2026 — confirm on the provider's own page.
| Line item | Typical monthly cost | Note |
|---|---|---|
| Managed control plane (EKS / AKS / GKE standard) | ~$70–75 | Per cluster, before a single workload runs |
| Worker nodes | $60–200+ | Two or three nodes, sized for headroom you rarely use |
| Load balancer | $20–30 | One per ingress, more if you are not careful |
| Egress | Metered | The line that turns a spike into an invoice |
| Engineer time | The real number | Upgrades, CNI and ingress compatibility, certificates, node pools, on-call |
A self-managed cluster removes the control plane fee and adds the control plane to your job description. For a team of one to five people, the cash line is noise and the time line is the entire decision.
Hostim.dev is Kubernetes. You just never touch it.
Hostim runs Kubernetes on bare metal in Falkenstein, Germany, with a purpose-built operator that turns a project, an app, a database or a volume into the Kubernetes resources underneath. That is why the behaviour you would expect from a cluster is there: containers get a rolling update rather than a restart, a readiness probe checks every 10 seconds and takes a container out after 3 consecutive failures, and a shutting-down container gets 60 seconds to finish what it was doing before it is killed.
What is absent is the part you were trying to avoid. No control plane to upgrade. No CNI to choose. No ingress controller to keep compatible. No certificate rotation. You push a Docker image, connect a Git repository, or paste a Compose file, and the platform schedules it.
New version goes up, old one drains, traffic moves when the new container is ready. The Deployment exists — you did not have to write it.
Provisioned and backed up, included in the plan price. On a cluster of your own, each of these is an operator you install and then own.
Storage that survives a redeploy, attached per app. The same primitive as a PVC, without the storage class decision.
Certificates issued and renewed automatically. No cert-manager to debug at renewal time.
Live logs and graphs out of the box, plus a bastion into the running container. No Prometheus stack to deploy.
From €2.50/month for reserved CPU, RAM and storage. No control plane fee, no per-request charge, no egress meter.
The argument here is not that Kubernetes is bad. It is that operating one is a job, and most teams already have a job.
Comparisons
Side by side against the platform you are moving from, or a round-up covering several at once.
It depends on what you are replacing. For one machine, Docker Compose with a restart policy is the alternative and it is usually enough. For several machines with no cluster team, Docker Swarm or HashiCorp Nomad are the closest like-for-like orchestrators. If you do not want to operate any orchestrator, a managed container platform such as Hostim.dev, Render, Railway or Fly.io runs Kubernetes on your behalf and gives you a deploy command instead of a control plane.
Probably not, if you are running fewer than about ten services on fewer than about five machines, with one team and no hard multi-tenancy requirement. Kubernetes solves scheduling across a fleet, declarative rollout of many services, and self-healing at a scale where a human cannot keep up. Below that scale it mostly adds a control plane you now have to keep alive. The test is not how big you plan to be — it is whether anything is currently painful that Kubernetes would fix.
Docker Compose runs a set of containers on one machine from a single YAML file. Kubernetes schedules containers across many machines and continuously reconciles what is running against what you declared. Compose is a tool you run; Kubernetes is a system that runs. Compose has no scheduler, no rolling update primitive and no notion of a node failing, which is exactly why it is simpler. If your whole application fits on one server, Compose is the correct choice and Kubernetes is a tax.
Swarm is built into the Docker engine, takes about ten minutes to set up, and uses Compose file syntax you already know. It gives you multi-node scheduling, service discovery, rolling updates and secrets. Kubernetes gives you far more — custom resources, an operator ecosystem, fine-grained RBAC, autoscaling, a real network policy model — and costs far more attention. Swarm development has been quiet for years, which is a genuine risk to weigh, but it still ships in Docker and still works. Pick Swarm if you want multi-node with a weekend of learning; pick Kubernetes if you need the ecosystem.
Nomad is a single Go binary that schedules containers, plain binaries, Java applications and batch jobs on the same cluster. It is markedly simpler to operate than Kubernetes and handles non-container workloads that Kubernetes does not. The trade is ecosystem: you add Consul for service discovery and Vault for secrets, where Kubernetes has answers in the box, and far fewer vendors ship a Nomad integration. Nomad suits an operations team that wants a scheduler and not a platform.
A managed control plane is roughly 70 to 75 US dollars a month on EKS, AKS or GKE standard, plus the worker nodes, plus a load balancer, plus egress. The cash cost is rarely the problem. The real cost is the engineer time: cluster upgrades every few months, CNI and ingress controller compatibility, certificate rotation, node pool management, and the on-call load of a control plane that can fail in ways an application cannot. For a small team that is comfortably the most expensive thing on the bill.
It is an alternative to operating Kubernetes, not to Kubernetes itself — most managed container platforms run it underneath. That distinction matters more than it sounds. You still get rolling deploys, restarts, health checks and persistent volumes, because those are Kubernetes features. What you do not get is the cluster, the upgrades, or the pager. If your objection to Kubernetes is the operational load rather than the runtime model, this is the option that actually addresses it.
k3s is Kubernetes, packaged as a single binary under 100 MB with the legacy cloud provider code and some alpha features stripped out. The API is the same, so your manifests port unchanged. It removes the installation pain and a lot of the resource overhead, and it does not remove the concepts — you still learn pods, services, ingress and RBAC. It is the right choice if you want Kubernetes and less of the setup, and the wrong choice if you wanted to not think about Kubernetes.
Yes. Hostim runs Kubernetes on bare metal in Falkenstein, Germany, with a purpose-built operator that turns a project, an app, a database or a volume into the underlying Kubernetes resources. You never see it. You push a Docker image, a Git repository or a Compose file, and the platform handles scheduling, restarts, rolling updates, HTTPS and persistent storage. That is deliberate: the argument on this page is not that Kubernetes is bad, it is that most teams should be renting it rather than running it.
Start now
Open the dashboard and deploy a Docker image, a Git repo or a template. The 5-day trial project needs no card.