How does Docker Compose differ from Kubernetes, and when would you outgrow it?

The core scope difference: one host vs. a cluster

Docker Compose fundamentally orchestrates containers on one Docker host — every service defined in a compose file runs on the single machine where docker compose up was executed. Kubernetes (see that stack) orchestrates containers across a cluster of potentially many machines. A scheduler decides which node each workload actually runs on, entirely independent of where you happen to be running kubectl from.

Compose: docker compose up  -> everything runs on THIS one machine

Kubernetes: kubectl apply -f deployment.yaml -> the SCHEDULER decides which of
            potentially dozens/hundreds of cluster nodes each Pod actually runs on

What Compose fundamentally cannot do, by design

• No automatic rescheduling on machine failure — if the single host running your Compose application goes down, everything goes down with it. There is no other machine for anything to fail over to, since Compose has no concept of "other machines" at all.
• No horizontal scaling across hosts — docker compose up --scale api=5 can run 5 instances of the api service, but all 5 still run on that same single host, sharing its finite CPU, memory, and disk. There is no way to spread replicas across multiple machines the way Kubernetes naturally does.
• No sophisticated rolling updates — Compose can restart services with an updated image, but it lacks Kubernetes's fine-grained rolling update controls: maxUnavailable/maxSurge, readiness-probe-gated progression, and automatic rollback on failure (see that stack's Deployment question).
• No built-in self-healing beyond simple restart policies — Compose respects restart: policies per service, identical to plain Docker's (see the lifecycle topic). But it has nothing comparable to Kubernetes's continuous reconciliation loops, which actively work to keep desired and actual cluster-wide state in sync.

Where Compose genuinely excels, and remains the right tool

• Local development — spinning up an entire application's dependencies (databases, caches, message queues, the application itself) with one command, identically for every developer on a team, is Compose's strongest and most enduring use case.
• CI test environments — bringing up a full integration-testing stack for the duration of a CI job, then tearing it down, is a natural fit for Compose's single-host, ephemeral-by-design model.
• Simple, single-server production deployments — a small application that genuinely doesn't need multi-host scale or sophisticated availability guarantees can legitimately run in production via Compose on a single well-maintained server. Not every application needs Kubernetes's complexity (see that stack's "how do you decide whether a project needs Kubernetes" question for the fuller version of this judgment call).

The signals that indicate you've outgrown Compose

• You need the application to survive a single machine failing entirely, not just a single container crashing.
• You need to scale beyond what one machine's resources can provide.
• You need genuinely sophisticated, safe rollout strategies (canary, blue-green — see the Kubernetes stack) with automatic health-gated progression and rollback.
• You're running enough distinct services/teams that you need the richer scheduling, resource-quota, and multi-tenancy primitives a real orchestrator provides (see that stack's topics).

Why this isn't a value judgment against Compose

Compose solving a narrower problem than Kubernetes isn't a shortcoming. It is a deliberate, appropriate scope. Using Compose for local development, even when production runs on Kubernetes, is extremely common and sensible. Many teams use Compose specifically to closely approximate their production container images and configuration locally, without needing a full local Kubernetes cluster like minikube or kind for everyday development work. The judgment call is about matching the tool's actual scope to the actual problem. Reaching for Kubernetes's cluster-wide orchestration complexity before you have a genuine multi-host, high-availability, or sophisticated-rollout requirement is over-engineering — exactly as covered in the Kubernetes stack's own judgment question on this topic.