Docker Kanvas: Automating the Compose-to-Kubernetes Migration

Docker announced Kanvas, a platform that converts Docker Compose files into Kubernetes manifests automatically. It's a direct challenge to the workflows that Helm and Kustomize currently own, aimed at teams who know Compose well but find the gap to production Kubernetes frustrating.

The Gap Between Local and Production

The typical pattern looks like this:

# docker-compose.yml (local dev)
services:
  app:
    image: myapp:latest
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://localhost/dev
    depends_on:
      - db
  db:
    image: postgres:16
    volumes:
      - db-data:/var/lib/postgresql/data

Moving this to Kubernetes means writing separate Deployment, Service, ConfigMap, PersistentVolumeClaim, and Secret resources. Even a small two-service setup expands to hundreds of lines of YAML. Inconsistencies between the local and production definitions become a quiet source of bugs.

Kanvas targets this exact problem: keep the Compose file as the source of truth and auto-generate the Kubernetes equivalent.

What Kanvas Converts

The mapping Kanvas handles covers the most common Compose constructs:

Beyond mechanical conversion, Kanvas also suggests resource limits and replaces depends_on with Kubernetes-native health checks, which is a meaningful improvement over a straight one-to-one translation.

How It Compares to Helm and Kustomize

Helm is a package manager with a templating engine. High reusability, but steep learning curve and frustrating template debugging.

Kustomize uses overlay-based patching. Simple for straightforward cases but limited for complex transformations.

Kanvas takes a different entry point — "start from your Compose file" — which means developers who already have a working Compose setup can get a viable Kubernetes configuration without needing to learn either Helm or Kustomize first.

The trade-off: Kanvas-generated manifests are a starting point. Production-grade additions (HPA, PodDisruptionBudget, NetworkPolicy, RBAC) still require manual work.

Workflow Example

# Convert existing Compose file
docker kanvas compose --file docker-compose.yml --output k8s/

The output is designed to be deployable with kubectl apply -k k8s/. GitOps integration (ArgoCD, Flux) is on the roadmap.

Watch Out for Secrets

Any plaintext credentials in your Compose environment variables will be output as base64-encoded Kubernetes Secrets. Base64 is encoding, not encryption — do not commit this output to source control as-is:

# Generated output — do not commit
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
data:
  POSTGRES_PASSWORD: c2VjcmV0  # just base64("secret")

Before deploying to a real environment, replace generated secrets with references to a proper secrets management system (AWS Secrets Manager, HashiCorp Vault, External Secrets Operator).

Who Should Use It

Good fit:

• Small to mid-size teams developing with Compose who want to move to Kubernetes without a full DevOps hire
• Projects that need to get something running in Kubernetes quickly and refine later
• Teams evaluating whether Kubernetes is worth adopting for their workload

Not a good fit:

• Teams that already have well-maintained Helm charts — migration costs likely outweigh the benefits
• Complex setups using Compose's build context, advanced networking, or multi-stage configurations that Kanvas doesn't yet handle
• Organizations where Kubernetes expertise is already in-house and opinionated configuration is preferred

Takeaways

• Docker Kanvas converts Compose files to Kubernetes manifests and fills a real gap in the tooling ecosystem
• It offers a different entry point than Helm or Kustomize, lowering the initial Kubernetes adoption barrier
• Generated manifests are functional starting points, not production-ready configurations
• Most useful for teams moving from Compose-based local development to a Kubernetes production environment