Docker Kanvas: Bridging Compose and Kubernetes

Docker launched Kanvas, a new platform designed to close the gap between local development with Docker Compose and production deployment on Kubernetes. The core feature is automated conversion of docker-compose.yml files into Kubernetes manifests, integrated into the Docker Desktop workflow. This puts Docker in direct competition with Helm and Kustomize in the cluster deployment management space.

The Problem Kanvas Addresses

Teams that use Docker Compose locally and Kubernetes in production regularly hit the same friction point: keeping the two definitions in sync. Every time a service is added or a configuration changes in Compose, the Kubernetes manifests need to be updated manually — or through a conversion tool like kompose that requires re-running and re-adjusting outputs on each change.

Kanvas aims to make this conversion continuous and automatic, keeping Compose as the authoritative source while generating Kubernetes artifacts alongside it.

What the Conversion Looks Like

Given a typical Compose file:

# docker-compose.yml
services:
  api:
    image: my-api:latest
    ports:
      - "8080:8080"
    environment:
      DATABASE_URL: postgresql://db:5432/app
    depends_on:
      - db
  db:
    image: postgres:16
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
 
volumes:
  db-data:

Kanvas generates the corresponding Kubernetes resources — Deployments, Services, PersistentVolumeClaims, and ConfigMaps for environment variables. The generated manifests are minimal and correct, covering the direct translation of what Compose expresses.

What they don't cover by default: resource limits, liveness/readiness probes, HorizontalPodAutoscaler configurations, or environment-specific overrides. These remain your responsibility to add.

Comparison with Helm and Kustomize

Kanvas lowers the entry barrier for Compose-native teams moving to Kubernetes. Helm's chart ecosystem and Kustomize's overlay approach offer significantly more flexibility for complex deployments, but require learning Kubernetes-native tooling from the start.

Where Kanvas Fits

Good fit:

• Small projects or proof-of-concept deployments
• Teams migrating from Compose to Kubernetes for the first time
• Teams already centered on Docker Desktop as their dev tooling

Stick with existing tools:

• Complex multi-environment deployments (staging/prod/preview)
• Projects already using Helm charts from the ecosystem
• Teams with established Helm or Kustomize workflows

What's Missing

For Kanvas to compete seriously with Helm or Kustomize in production scenarios, it needs to address:

1. Secret management: Integration with Kubernetes Secrets, Sealed Secrets, or External Secrets Operator
2. Multi-environment configuration: Environment-specific overrides without duplicating the base Compose file
3. GitOps integration: Clean patterns for ArgoCD or Flux to consume Kanvas-generated manifests

None of these are blockers for experimentation, but they're table stakes for production adoption at scale.

Practical Takeaway

If your team is running Docker Compose in development and hasn't migrated to Kubernetes yet, Kanvas is worth experimenting with — it lowers the conceptual overhead of that transition. If you're already running Helm or Kustomize in production, the switching cost doesn't make sense right now.

Watch this tool as it matures. Docker has the developer mindshare and Desktop distribution to make Kanvas a genuine on-ramp to Kubernetes for a large segment of the developer community.