Docker Compose vs Kubernetes for self-hosted infrastructure.

There's a version of this question that sounds like a tech debate but is actually a question about your team's operational capacity. Docker Compose and Kubernetes both run containers. The difference is everything else: what happens when a container crashes, how you roll out updates, how you handle secrets, how you scale, and critically — how much cognitive overhead you're willing to carry.

We've deployed infrastructure for Studio clients at both ends of this spectrum: small teams on a single VPS running Compose stacks, and multi-node Kubernetes clusters for organisations with dedicated ops capacity. The answer isn't "Kubernetes is better" — it's "Kubernetes is appropriate when the operational complexity it introduces is less than the operational complexity it solves." That threshold is higher than most people assume.

What Compose is actually good at

Docker Compose gets dismissed as "not production-ready" by people who've never had to debug a Kubernetes misconfiguration at 2am. For the right deployment profile, Compose is excellent:

• Single-node deployments. If your workload fits on one machine — and most small-team self-hosted stacks do — Compose is the right tool. You get process isolation, network namespacing, volume management, and environment-specific config through .env files. That's most of what you need.
• Human-readable configuration. A docker-compose.yml is legible to any engineer who's spent a day with Docker. You can hand it to a new team member and they can understand the deployment in an hour. The equivalent Kubernetes manifests for the same stack are three to five times longer and require familiarity with a dozen resource types.
• Fast iteration. docker compose up -d --build service-name is one command. No image push to a registry, no pod rollout to wait for, no rolling update strategy to configure.
• Low dependency surface. Compose has one runtime dependency: Docker. Kubernetes has etcd, the API server, the scheduler, the controller manager, kubelet, kube-proxy, a CNI plugin, and usually a cloud provider integration or bare-metal load balancer. Every dependency is a failure mode.

The 47Network Studio deploys the Keycloak, Vault, and Matrix stacks for smaller clients on Compose with a systemd service for restart-on-failure and a daily backup cron. It's boring, it works, and operations staff who've never used Kubernetes can maintain it.

When Compose starts to strain

Compose has genuine limitations that become pain points as deployments grow:

• Multi-node workloads. Compose doesn't orchestrate across multiple hosts. Docker Swarm does, but Swarm's development has effectively stalled. If your workload needs to span machines for capacity or redundancy, you need a real orchestrator.
• Zero-downtime deployments. Compose's rolling update story is weak. Recreating a container means a brief downtime. You can work around this with blue-green deployments and a Nginx/Caddy reload, but it's manual and fragile at scale.
• Health-based scheduling. Compose will restart a crashed container, but it won't move it to a different host if the host is degraded, and it won't make sophisticated scheduling decisions based on resource availability.
• Secret management at scale. Compose reads secrets from environment variables or files. For a few services this is manageable; for twenty services across multiple stacks it becomes a configuration sprawl problem. Kubernetes Secrets (with external secrets operators) are more structured, and the Vault integration is better.

What Kubernetes actually gives you

Kubernetes gives you a declarative control plane, automatic bin-packing, self-healing (restart, reschedule, replace failed pods), horizontal pod autoscaling, rolling deployments with configurable strategies, and a rich ecosystem of operators for databases, certificates, secrets, and more. These are real capabilities. The question is whether your operational context requires them.

The hidden cost people underestimate is ongoing cognitive load. A Kubernetes cluster requires someone to understand the networking model (CNI, Services, Ingress, NetworkPolicy), the storage model (PV, PVC, StorageClass), the scheduling model (Nodes, Taints, Tolerations, Resource Requests/Limits), the security model (RBAC, ServiceAccounts, PodSecurityAdmission), and the upgrade path. This knowledge has to live somewhere in your team. If it lives in one person's head, you have a bus factor problem. If it lives in nobody's head, you have an incident waiting to happen.

The Compose production checklist

If you decide Compose is right for your deployment, these are the gaps you need to fill that Kubernetes would have handled automatically:

• Process supervision: Wrap your docker compose up -d in a systemd service with Restart=always and RestartSec=10. This ensures the stack comes back after a reboot or an unexpected Docker daemon restart.
• Health checks: Define healthcheck blocks in your Compose file for every service. Without them, Docker considers a container "healthy" as soon as it starts — even if the process inside is still initialising or has crashed into a retry loop.
• Secrets hygiene: Use Docker secrets or a bind-mounted secrets directory rather than plain environment variables in the Compose file. Env vars in Compose files end up in process listings and are visible to any process in the container.
• Backup automation: Kubernetes doesn't back up your data either, but operators make it easier to think about. In Compose land, write an explicit backup script for every persistent volume and test the restore procedure. Daily. Tested monthly.
• Log aggregation: Container logs go to Docker's JSON logging driver by default, which has no rotation by default. Configure log rotation (max-size, max-file) or ship logs to a central store (Loki, Elasticsearch) before the disk fills up.
• Image pinning: Pin image tags. postgres:latest in production is a disaster waiting to happen when a major version update breaks your schema migrations silently.

A practical decision table

How 47Network ships both

Every 47Network product ships with both a Docker Compose file and Helm charts. This isn't fence-sitting — it's an honest acknowledgment that different clients have different operational contexts. A 12-person NGO self-hosting Matrix should use the Compose file. A 200-person company with a platform team running Argo CD should use the Helm chart with GitOps.

Both deployment paths are first-class. The Compose files are tested in CI. The Helm charts are tested in CI. If a bug only reproduces on one of them, that's a bug we fix. Self-hosting support means both options actually work, not just the one we find more interesting to build.

When Studio clients ask which to use, we start with their team size, ops capacity, and whether they have — or want — a dedicated platform engineer. The answer follows from those constraints, not from what's technically more impressive to deploy.