Docker Compose to Kubernetes
Paste a docker-compose.yml and get Kubernetes manifests, with clear warnings where the two models differ.
From docker-compose.yml to Kubernetes manifests
Docker Compose is the easiest way to run a multi-container application on one machine, and many projects start there. When they outgrow a single host, the next step is usually Kubernetes, whose manifests are far more verbose: a Compose service becomes a Deployment, often a Service, a ConfigMap and a PersistentVolumeClaim. Writing those by hand for ten services is tedious and error prone.
Paste a Compose file and this tool generates the manifests: a Deployment per service (image, command, ports, replicas, resource limits, working directory, a liveness probe from the healthcheck), a Service for exposed ports, a ConfigMap for environment variables, a Secret for anything that looks sensitive, and PersistentVolumeClaims for named volumes. The Compose entrypoint becomes the container command and the Compose command becomes args, which matches how the two systems define them.
What you must still decide
- Images. Kubernetes cannot build; services with
build:need an image pushed to a registry first. - Storage. Named volumes become claims with the size you choose and the cluster's default storage class; bind mounts become hostPath volumes, which pin a Pod to a node and are rarely what you want.
- Exposure. Decide between ClusterIP plus Ingress, NodePort and LoadBalancer.
- Readiness and rollout. Add a readiness probe and resource requests before production.
The converter reads your YAML in the browser and never uploads it. For a one-off migration it saves hours; for a long-lived system consider Helm or Kustomize on top of the generated files.
Frequently asked questions
Is the conversion exact?
No. Compose and Kubernetes model things differently, so the output is a starting point. Every construct that has no direct equivalent (build, depends_on, networks, restart policies, bind mounts) produces a warning explaining what to do instead.
How are Compose ports mapped?
Each service with ports gets a Deployment (container ports) and a Service. Published ports become Service ports. By default the Service is ClusterIP, reachable inside the cluster; choose NodePort or LoadBalancer, or add an Ingress, for outside access.
Where do environment variables go?
Plain values go into a ConfigMap referenced with envFrom, or inline if you prefer. Names that look like secrets (password, token, key) go into a Secret with the value as a placeholder to replace.
What replaces depends_on?
Nothing directly. Kubernetes starts Pods independently, so applications should retry their connections, and you can add readiness probes or init containers to wait for dependencies.