Docker Compose vs Kubernetes: 17 Workloads We Moved Back

We migrated 50 workloads from Docker Compose to Kubernetes over the last two years. Seventeen of them we ended up moving back.

That number surprises people. The standard story is one-way: you start with Docker Compose, you outgrow it, you graduate to Kubernetes, you never look back. Most of the “Docker Compose vs Kubernetes” comparisons you read are written by people pitching the K8s path because that is what their product or services depend on.

This post is the honest version. When Kubernetes pays off, when Compose still wins in 2026, what Kubernetes actually costs you in real money and hours, and why we send certain workloads back to Compose with no shame.

The 60-second verdict

Question	Answer
Running on one host, traffic predictable, fewer than 5 services?	Stay on Compose.
Need multi-host, auto-scaling, zero-downtime deploys, or 99.9%+ uptime SLOs?	Move to Kubernetes.
Team smaller than 6-7 engineers, no dedicated platform person?	Probably Compose, with K3s as the next step.
Stateful workloads like Postgres or Kafka in production?	Managed service, not either tool.
Regulated industry with audit requirements?	Kubernetes, almost certainly.

That is the whole framework. The rest of this post is the reasoning, the numbers, and the things competitors leave out.

What Docker Compose actually is in 2026

Docker Compose is a YAML-driven way to define and run multi-container applications on a single host. You write a docker-compose.yml that declares your services, networks, and volumes, then docker compose up and they run.

Compose v2 (the current GA version, written in Go and shipped as a Docker CLI plugin) added features that closed real gaps:

• Profiles for environment-specific service selection
• compose watch for live file syncing during development
• depends_on with conditions (service_healthy, service_completed_successfully) instead of the v1 brittle ordering
• Better resource controls through deploy.resources even outside of Swarm mode

What it still cannot do:

• Run across multiple physical hosts (without Swarm, which is essentially deprecated - more on that below)
• Self-heal failed nodes
• Roll deployments with zero downtime
• Auto-scale based on metrics
• Provide proper RBAC, network policies, or pod-level security boundaries

Compose is excellent at what it was built for. The trap is when teams stretch it past that point.

What Kubernetes actually is in 2026

Kubernetes is a distributed container orchestration platform that manages workloads across multiple machines. You declare what should be running through Deployments, StatefulSets, DaemonSets, and Services. The control plane reconciles actual state toward desired state, continuously.

What Kubernetes gives you that Compose cannot:

• Horizontal scaling across many nodes
• Automatic pod rescheduling when nodes fail
• Rolling deployments with health-check-gated rollouts
• Autoscaling: pod-level (HPA), node-level (Cluster Autoscaler / Karpenter), and resource-level (VPA)
• Real RBAC with Pod Security Standards
• A massive ecosystem (CNCF tracks over 200 graduated and incubating projects)

What it costs you to get this:

• A learning curve measured in months, not weeks
• A control plane that consumes resources even when idle
• A platform engineering function (or a managed service that does it for you)
• An observability stack that is itself nontrivial to operate (we wrote about this in our Kubernetes observability service)

The honest comparison

Dimension	Docker Compose	Kubernetes
Hosts supported	1 (single Docker engine)	Many (cluster of nodes)
Auto-scaling	No	Yes (HPA, VPA, KEDA, Cluster Autoscaler)
Self-healing	Container restart only	Yes (pod, node, controller-level)
Rolling deploys	No (manual recreate)	Yes (gated by readiness probes)
Networking	Bridge + user-defined networks	Service mesh, CNI, NetworkPolicies
Storage	Local volumes, named volumes	PVs, PVCs, StorageClasses, CSI drivers
Secrets	Env vars or mounted files	Secrets API + external secret operators
RBAC	None	Built-in, fine-grained
Configuration tooling	docker compose CLI	kubectl, Helm, Kustomize, ArgoCD, Flux
Idle resource cost	~50 MB RAM	2-4 GB RAM control plane minimum
Learning curve (engineer hours to production-ready)	8-20 hours	200-500 hours
Suitable team size	1-6 engineers	6+ engineers, or managed service

Most comparisons stop here. The interesting part starts now.

The cost math nobody publishes

Let’s price a hypothetical: a small SaaS running 5 backend services, a Postgres database, a Redis cache, and a worker queue. Moderate traffic, mostly business hours.

Docker Compose option

Single t3.large EC2 instance (or equivalent on Azure/GCP):

• Compute: $60-70/month (on-demand) or $40/month (1-year reserved)
• EBS storage: $10-15/month for 100 GB
• Backup snapshots: $5/month
• Load balancer (if you want one): $20/month
• DNS, monitoring (basic CloudWatch): $10/month

Total infrastructure: ~$100-125/month

Operational overhead: 4-8 hours/month from one engineer for patches, deploys, ad-hoc fixes. Call it $400-800 in fully-loaded engineer time at typical rates.

Effective monthly run cost: $500-925.

Kubernetes option (managed)

A minimal production setup on EKS, AKS, or GKE:

• Managed control plane: $73/month per cluster (EKS) or comparable on Azure/GCP
• 3 worker nodes (t3.large equivalent): $180-210/month
• EBS / persistent volumes: $15-25/month
• Load balancer: $25-30/month
• Container registry storage and pulls: $5-15/month
• Observability stack (Prometheus + Grafana + Loki, self-hosted)**: $30-50/month in extra compute and storage
• Backups, logging retention, alerting: $20-40/month

Total infrastructure: ~$350-450/month (3-4x the Compose number)

Operational overhead: 30-60 hours/month from a platform-fluent engineer for cluster ops, upgrades (Kubernetes minor versions every 4 months), security patches, certificate rotation, CRD upgrades, ingress controller maintenance. Realistic fully-loaded cost: $3,000-6,000.

Effective monthly run cost: $3,400-6,500.

That is roughly 7x the Compose cost for the same 5 services. The difference is justified the moment you genuinely need any of the things Kubernetes gives you (auto-scaling, zero-downtime, multi-host failover, regulatory controls). It is wasted spend if you do not.

This is the conversation most comparison posts skip because the answer hurts whichever side they are selling.

Kompose: what it actually produces

Every Kubernetes guide mentions Kompose as the “easy” way to convert your Compose file. Run kompose convert, get Kubernetes manifests, done.

The output is not production-ready. Take a real Compose service:

services:
  api:
    image: myorg/api:1.2.3
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgres://db:5432/app
    depends_on:
      db:
        condition: service_healthy

What Kompose generates: a basic Deployment, a Service, that is more or less it.

What is missing for production use, every time:

1. Readiness and liveness probes - without these, traffic flows to pods that are not actually ready
2. Resource requests and limits - without these, the scheduler cannot plan node capacity and you risk noisy-neighbor failures
3. Pod Security Standards labels - the namespace needs pod-security.kubernetes.io/enforce: restricted (or baseline) and the pod spec needs runAsNonRoot, readOnlyRootFilesystem, dropped capabilities
4. Secrets - Kompose puts your DATABASE_URL directly in the Deployment as an env var; needs to be a Secret reference
5. NetworkPolicy - default-deny baseline plus explicit allows
6. PodDisruptionBudget - so cluster upgrades and drains do not kill all your replicas at once
7. HorizontalPodAutoscaler - if you wanted autoscaling
8. Ingress or Gateway API resource - Compose ports become a Service of type LoadBalancer or NodePort, which is rarely what you actually want
9. ServiceAccount with the right RBAC - not default, which Kompose does not change
10. Image pull policy, image pinning, and signature verification - the Compose tag becomes a Kubernetes image string with no provenance controls

That is 10 things you have to add manually for every service. For a 5-service application, you are looking at 50 manual additions to make the Kompose output actually fit for production. This is why “just run Kompose” is misleading advice.

If you want this done correctly without the manual work, that is exactly what our Production Kubernetes Cluster Setup is for. Fixed price, 1 week.

The 2026 platform context

A few things have shifted that older comparison posts do not reflect:

Docker Swarm is effectively dead. Mirantis maintains it but no major cloud offers managed Swarm, and the contributor activity has collapsed. The “Compose to Swarm to Kubernetes” path that older articles suggest is no longer practical advice. Stop thinking of Swarm as a real option.

K3s and MicroK8s are the new “lightweight orchestrator” middle ground. If you have outgrown Compose but Kubernetes feels like too much, K3s is a credible answer. Single-binary, low resource footprint, full Kubernetes API. We run K3s in production for clients who want the K8s API without the operational weight of EKS or AKS.

Ingress NGINX is being retired upstream in March 2026. Production Kubernetes setups now lean toward Gateway API or alternative ingress controllers (Traefik, HAProxy, cloud-managed). If you migrate to Kubernetes in 2026, do not adopt Ingress NGINX as your default - it is end-of-life on a deadline you can plan around.

Pod Security Policies have been fully replaced by Pod Security Standards. Older Kompose-style guides reference PSP. They are gone. Use PSS labels at the namespace level instead.

Sidecar containers are GA. Workloads that needed sidecar patterns (service mesh proxies, log shippers, secret rotators) now have first-class lifecycle support, which matters when you compare to Compose’s straightforward multi-container patterns.

Stateful workloads: a decision tree

Most “Docker Compose vs Kubernetes” articles assume your workloads are stateless web apps. Real systems have databases and queues. Here is the honest take per workload:

PostgreSQL

• Compose: Fine for dev, fine for small production with regular backups. Stays this way longer than people think.
• Kubernetes with operator: Use CloudNativePG or Zalando Postgres Operator. Real production patterns exist.
• Managed service: Almost always the right answer. RDS, Cloud SQL, Azure Database. Skip both Compose and Kubernetes for the database.

Redis

• Compose: Great for ephemeral caches. If you lose it, who cares.
• Kubernetes: Redis Operator works. Sentinel and cluster modes are well-supported.
• Managed service: ElastiCache, Memorystore, Azure Cache. Same conclusion as Postgres.

Kafka

• Compose: No. Single-broker Kafka in production is not a production setup.
• Kubernetes with operator: Strimzi is genuinely good. We have deployed this many times.
• Managed service: MSK, Confluent Cloud, Azure Event Hubs. Often easier.

ClickHouse

• Compose: Possible for single-node analytical workloads up to moderate scale.
• Kubernetes: ClickHouse Operator handles cluster mode well.
• Managed: ClickHouse Cloud or our Managed ClickHouse service.

Notice the pattern: for stateful workloads at any meaningful scale, the question “Compose or Kubernetes” is the wrong question. The right answer is usually “managed service, regardless of what is running your stateless tier.”

The 7-question decision framework

If you are deciding right now, answer these:

1. Do you have more than one host? If no, Compose. Kubernetes on a single node is just complexity for no benefit.
2. Do you need true zero-downtime deploys? If yes, Kubernetes. Compose’s down/up cycle is not zero-downtime.
3. Are you running stateless web services that need to scale with traffic? If yes, Kubernetes with HPA. If your traffic is flat, Compose is fine.
4. Do you have a platform-fluent engineer (or budget for managed K8s services)? If no, stay on Compose. Kubernetes without ops budget will hurt you.
5. Are you in a regulated industry (PIPEDA, UK GDPR, PDPL, HIPAA, NESA)? If yes, Kubernetes makes the audit story much easier. We covered this on our data residency observability page.
6. Are your workloads stateful and important? If yes, the answer is managed service, then a stateless tier on either Compose or K8s.
7. Is your team size 6+ engineers? Below 6, the operational tax of K8s is usually more expensive than the platform itself.

Score yes/no honestly. If you have 3 or more “Kubernetes” answers, migrate. If you have 2 or fewer, stay on Compose, and consider K3s if you need a middle step.

The 17 we moved back

Here is the breakdown of the 50 workloads we migrated, and the 17 we returned to Compose:

Workload type	Migrated to K8s	Stayed on K8s	Moved back to Compose
Stateless web APIs (high traffic)	22	22	0
Stateless web APIs (low traffic, predictable)	8	1	7
Cron-style batch jobs	6	3	3
Internal admin tools	5	0	5
Marketing/landing sites	4	2	2
Worker queues (low volume)	5	5	0

The 17 that moved back share a profile: low traffic, predictable, low criticality, no autoscaling benefit, no compliance requirement. For these, the operational tax of Kubernetes outweighed the technical benefits. They run on a single beefy host with Compose, on a private network, with simple nightly backups. Nobody calls us at 2 AM about them.

The other 33 absolutely needed Kubernetes: heavy autoscaling, multi-region replication, regulatory audit trails, mixed-tenant isolation, real on-call requirements.

The lesson is that “graduate everything to Kubernetes” is the wrong default. Workloads are not equal. Pick the platform that fits the workload’s actual operational profile.

When to migrate (and when not to)

Migrate to Kubernetes when:

• You need multi-host or multi-region deployment
• Traffic is variable and you need autoscaling
• You require zero-downtime deploys with rollback
• You have 6+ engineers and a platform-fluent person
• You are in a regulated industry where audit logs and RBAC are non-negotiable
• You operate enough services that orchestration overhead becomes negligible

Do not migrate to Kubernetes when:

• You run fewer than 5 services with predictable traffic
• Your team is small and you do not have platform engineering capacity
• Your workloads are mostly internal tools or low-criticality public services
• Your stateful workloads are the hard part - solve that with a managed service first
• You are migrating because “Kubernetes is the standard” rather than because you need what it provides

If you are unsure, our Kubernetes Production Readiness Audit ($495, 2 weeks) gives you a third-party assessment of whether your specific environment justifies the move. We tell people to stay on Compose more often than you might think.

Frequently asked questions

Is Docker Compose still used in 2026? Yes. Widely. Compose v2 is a healthy, well-maintained project and the right tool for single-host workloads and local development. The “Compose is obsolete” framing is wrong.

Can Docker Compose replace Kubernetes? For workloads that fit a single host, yes. For multi-host, autoscaling, or zero-downtime requirements, no. There is no shame in either answer.

Is Kubernetes overkill for small projects? Almost always, yes. Below 5-10 services and 6+ engineers, the operational overhead exceeds the value. K3s or Compose are usually better.

Can I run Docker Compose on multiple servers? Not natively. You can deploy Compose to multiple servers with tooling like Ansible, but you lose the orchestration benefits. At that point, K3s or full Kubernetes makes more sense.

Does Docker Compose support auto-scaling? No. You can scale services horizontally with docker compose up --scale, but it is manual. Autoscaling needs Kubernetes (or a managed PaaS like Cloud Run / Container Apps / App Runner).

How many containers can Docker Compose handle? As many as fit on your host. Practical ceiling is usually 30-50 containers per host before complexity becomes painful.

What replaced Docker Swarm? Effectively, nothing - because Kubernetes captured the multi-host orchestration market. K3s is the lightweight middle ground for teams that want the Kubernetes API without the operational weight of managed K8s services.

---

Get help with the decision

If you are weighing this for your own environment and want a third-party read, two productized services to look at:

• Kubernetes Production Readiness Audit ($495, 2 weeks): a senior engineer scores your existing cluster (or evaluates whether you need one) across 47 production-readiness checks. Honest output - we recommend staying on Compose for the workloads that should.
• Production Kubernetes Cluster Setup ($2,995, 1 week): if you have decided to migrate, this delivers a production-ready EKS, AKS, or GKE cluster with Terraform IaC, RBAC, networking, and runbooks. Fixed price, fixed scope, no procurement runaround.

Already decided to migrate? Our companion post on the Docker Compose to Kubernetes migration process covers the step-by-step move.

Want to self-assess for free first? The Kubernetes Production Readiness Checklist is the same 47-point checklist we use in the paid audit, published in full and ungated.