Kubernetes vs Docker: one server or a cluster?

Docker builds a container image and runs it on one machine. Kubernetes takes those same images and runs them across a cluster of servers, restarting or moving them when something fails. They aren't rivals. For a small team the real choice is Docker Compose on one server or a Kubernetes cluster, and you should pick by what your app needs, not by which one sounds more impressive.

Stay on one server until you have a problem only a second server fixes. When you do, the servers aren't the expensive part. On our rate card a 4 vCPU, 8 GB server is $91.80 a month billed by the hour, and a managed cluster with one worker that size is $94.35. High availability costs more, and so does the Kubernetes knowledge your team needs.

What's the difference between Docker and Kubernetes?

Docker is a platform for building, shipping and running applications. You build an image, which is a read-only template, and every container is a running instance of it. Kubernetes is an open source platform that runs those containerized workloads on a cluster of nodes and handles service discovery and load balancing, rollouts and rollbacks, and self-healing for you.

In practice you use both. You build an image with Docker, push it to a registry, and Kubernetes pulls it and runs it on whichever node has room.

Is Kubernetes replacing Docker?

No. Kubernetes stopped using Docker Engine as its runtime when version 1.24 removed the dockershim on May 3, 2022, and nodes now run containers through a runtime such as containerd. That changed nothing for your images. The Kubernetes project's dockershim FAQ says images built with docker build "will work with all CRI implementations", and Docker on your own machine works as before.

Docker is still the more common tool by a wide margin. In the Stack Overflow 2025 Developer Survey, 71.1% of respondents had done extensive work with Docker in the past year and 28.5% with Kubernetes. Among container users, Kubernetes is the norm in production: CNCF's 2025 survey found 82% of them run it there.

Docker Compose vs Kubernetes

Docker's own production guide starts where most small teams should: "The easiest way to deploy an application is to run it on a single server, similar to how you would run your development environment." One VM, one compose.yaml, docker compose up -d. That file gets you a restart policy such as unless-stopped to bring a crashed container back, more copies of a service with docker compose up --scale web=3, and your database, cache and app side by side on one private network.

What one server can't give you is a second server. Named volumes live on that VM's disk, so the data is tied to that machine. When the machine goes down, so does the app, and nothing reschedules it somewhere else. Shipping a change has a gap too: Docker's guide says redeploying a service "stops, destroys, and recreates" its container, so a single copy is briefly offline.

Kubernetes closes both gaps: a failed node's Pods start on another node, and a Deployment swaps old Pods for new ones a few at a time.

Kubernetes vs Docker Swarm, and the steps in between

Swarm mode is still built into Docker Engine and runs a service across several machines, replacing copies when a machine fails. Docker's production guide names it as the next step: "If you want to scale up your application, you can run Compose apps on a Swarm cluster." Kubernetes goes further: a HorizontalPodAutoscaler adds Pods when load rises.

You may not need either. Zero-downtime deploys alone aren't a reason to build a cluster. Tines ran them for its web containers on Docker Compose with nginx and a short script, "in production for over 6 months without issue". docker-rollout is a Docker CLI plugin that "updates Docker Compose services without downtime". Kamal, from 37signals, deploys Docker containers to a list of servers with zero-downtime deploys and rolling restarts. Our Heroku alternatives post covers Kamal for Rails.

So the realistic middle step is two servers behind a load balancer, deployed with Kamal or a rollout script.

Docker vs Kubernetes: what each costs to run

Here's each setup on American Cloud at list prices on October 21, 2026: Standard (Intel) hosts, billed by the hour for a full month.

The first control node is free, a load balancer is a flat $12, and each worker comes with a 200 GB disk to the server's 160 GB. On a monthly term the server drops to $90; Kubernetes nodes bill by the hour only.

A control plane that survives losing a node needs three control nodes, and each one past the first bills as a full node at the worker size. Smaller workers shrink the bill: three 2 vCPU, 4 GB workers, three control nodes and a load balancer come to $263.81. No line has a charge for traffic out: we don't charge egress on VMs, Kubernetes nodes or load balancers. Block storage volumes and extra public IPs aren't included.

What EKS, GKE and AKS charge for a cluster is in our Kubernetes hosting cost comparison.

Kubernetes vs Docker: which one do you need?

Move to Kubernetes when the app has to keep running after a server dies, when you run several services that need to scale separately, when load swings enough that you want nodes and Pods added on their own, or when your team already works in Kubernetes manifests and so do the people you hire. Until then, one server running Compose, or two with Kamal, is less to run and less to reason about. "We might grow" isn't a reason.

Companies do quit Kubernetes. 37signals moved to Google's managed Kubernetes and pulled back after outages in its network control plane, then tried vendor-supported Kubernetes on its own hardware, which "turned out to be a very expensive and operationally complicated idea". It built Kamal instead. A managed control plane takes etcd and the API server off your hands. It doesn't write your manifests, ingress or storage setup.

Docker Compose to Kubernetes on American Cloud

Staying on one server? If it runs with docker compose up on your laptop, it can run on a server. Our Docker Compose guide puts it on an Ubuntu VM with your domain and HTTPS.

When you need a cluster, create a managed Kubernetes cluster, download its kubeconfig and point kubectl at it (getting started). Kompose, an official Kubernetes project, converts the same compose.yaml into manifests. Its own site says the conversion is "not always 1-1", so read what it produces for volumes and ports before you apply it:

# Kompose v1.38.0, https://kompose.io/
kompose convert -f compose.yaml
kubectl apply -f .

Worker nodes can autoscale between a minimum and maximum you set, and version upgrades are one action from the cluster's Manage menu. When a manifest fights you, a person answers: chat and support tickets come with every account, and our median support response time is under two minutes. To size your own cluster or server, use the pricing calculator.