Docker Kanvas Turns docker-compose.yml Into Kubernetes Manifests — Here's Exactly Where It Stops

Docker spent a decade telling developers not to touch Kubernetes YAML directly, and on January 6, 2026, it finally shipped a tool that makes good on that promise: Kanvas, built with Layer5, converts a docker-compose.yml a developer already has into deployable Kubernetes manifests, Helm charts, Kustomize configs, or Terraform/Pulumi — no hand-written YAML required. It's explicitly pitched against Helm and Kustomize, and it's free, Apache-2.0, and self-hostable.

That's a genuinely useful tool, and the honest verdict up front: Kanvas closes the "translate my compose file into something a cluster understands" gap cleanly, but it stops at the manifest. It never builds an image, never pushes to a registry, and never decides which node in a fleet a workload lands on — which means every git-push PaaS still owns the harder half of the pipeline, Kanvas or not. For a platform like Bex.co, whose tenants overwhelmingly write a docker-compose.yml for local dev long before they ever touch a Dockerfile, that's not a footnote — it's the actual shape of the buy-vs-build decision on the compile step.

What Kanvas Actually Does​

Kanvas ships as a Docker Desktop extension and a hosted app at kanvas.new, built on Meshery — Layer5's CNCF-hosted infrastructure-management engine — and it works in two modes.

Designer mode is the import-and-model layer. Point it at an existing docker-compose.yml, a Helm chart, a raw Kubernetes manifest, or a Kustomize overlay, and it renders the whole thing as a visual topology: services, volumes, ports, and the dependency edges between them. Kanvas then re-evaluates that topology continuously — add a Service, and it proposes the matching port mapping on the Deployment behind it — using Meshery's relationship-evaluation engine rather than one-shot templating. From there it exports Kubernetes manifests, Helm charts, Kustomize configs, or Terraform/Pulumi IaC, plus access to a catalog of pre-built reference architectures (Docker's own numbers put it at 1,000+ versioned Kubernetes resources and 50-60+ components apiece for AWS, Azure, and GCP).

Operator mode is the live-cluster console: an in-browser terminal and log stream so a developer never has to leave the UI for kubectl, a built-in load generator, and Prometheus/Grafana overlays for CPU, memory, and latency — connecting to GKE, EKS, or any cluster a token can reach.

Licensing and access matter for the buy-vs-build question later: Kanvas is Apache 2.0, the extension and core logic live in a public GitHub repo, and Layer5 offers both a hosted SaaS tier (with a free plan) and a self-hosted deployment for teams that want the designs and cluster access to stay internal.

Kanvas vs. Kompose vs. Helm vs. Kustomize​

None of "convert Compose to Kubernetes" is new — Kompose has done a literal file-format translation since 2016, as an official Kubernetes project. What's new is doing it as a maintained, visual, continuously-revalidated product instead of a one-shot CLI pass.

The InfoQ writeup on Kanvas's launch put the honest framing on the incumbents: Helm, Kustomize, and adjacent tools like Okteto and Garden "provide high levels of customisation but often come with a steeper learning curve." Kanvas's bet is that most teams don't want that customization surface at all — they want their Compose file to become a working deployment with the fewest possible YAML decisions in between. It's explicitly not trying to out-template Helm; Docker's own materials frame it as a developer-experience layer that exports to Helm and Kustomize when a team needs that deeper control, not a low-level replacement for either.

The Scope Boundary: What a Git-Push PaaS Still Owns​

This is the part that actually matters for a platform whose whole pitch is "push a git repo, get a running HTTPS service" — because Kanvas covers exactly one step in that pipeline, and it's not the hardest one.

Read straight down that list: Kanvas earns two of nine rows outright, and both are the rows every Compose-to-K8s tool since Kompose has covered in some form. The five rows that make a self-hosted PaaS actually a platform — build from source, push to a registry, place the workload on a fleet, isolate it from its neighbors, and route a domain to it with TLS — sit entirely outside what Docker shipped. A team that reads "Docker challenges Helm and Kustomize" and concludes the build-to-deploy problem got smaller for their own platform is reading the headline, not the scope.

That gap is exactly why the Compose-first detail matters. Most tenant repos that show up at a git-push PaaS's door already have a docker-compose.yml from local development — Docker's own 2025 State of Application Development survey found Docker usage among IT professionals had climbed to 92%, and Compose is the default way most of those teams describe a multi-service app locally, long before (if ever) they write a production Dockerfile. Kanvas turning that already-common artifact into a valid deployment target is a real onboarding win. It just doesn't change how many of the other eight rows in that table a platform still has to build.

The Buy-vs-Build Calculus for a Self-Hosted PaaS​

Because Kanvas is Apache-2.0 and self-hostable rather than a closed SaaS, the decision for bex isn't the usual binary "pay a vendor or write it yourself." There's a real third option: embed Meshery's open-source conversion engine as the Compose-import step of bex's own build pipeline, instead of writing a bespoke Compose parser from scratch.

The case for embedding it: Compose's spec has enough edge cases (multi-stage build contexts, named volumes, depends_on conditions, healthchecks, network aliases) that a hand-rolled parser either reimplements a meaningful chunk of Meshery's relationship-evaluation logic or ships a narrower subset and silently drops fields tenants rely on. Kompose has run into exactly that version-coupling problem for a decade — its conversions aren't always 1:1, and it breaks when the Compose spec moves out from under it. Reaching for a maintained, CNCF-adjacent engine avoids re-litigating that same maintenance burden in-house.

The case against: Meshery and Kanvas are built to be a general-purpose, multi-cloud infrastructure-design product — AI-assisted relationship suggestions, a policy engine with a "modulation slider" for how aggressively it auto-patches your design, drag-and-drop AWS/Azure/GCP components a single-cloud-fleet platform will never use. Pulling in that whole engine to solve one narrow problem (Compose services → the manifest shape bex's Cluster-API reconciler already expects) means adopting a dependency several times larger than the feature it's serving. And the limitation critics have already flagged against Kanvas's own "auto-convert" promise cuts the same way for an embedded version of it: Compose syntax has no native representation for StatefulSets, CustomResourceDefinitions, or Operators, so anything beyond a straightforward multi-service web app — a tenant running their own Postgres operator, say — still needs a human (or bex's own detection layer) to fill the gap the conversion can't infer.

The honest middle path: treat Kanvas/Meshery's output contract (what a converted Compose file looks like as Kubernetes objects) as a spec worth matching, without taking on the whole product as a runtime dependency. A platform that already owns buildpack detection, registry push, and Cluster-API placement is better served writing a narrowly-scoped Compose importer that feeds directly into infrastructure it controls end-to-end, than embedding a general-purpose design tool's policy engine for one conversion step it happens to also do well.

What This Actually Changes​

Docker shipping a first-party, well-funded Compose-to-Kubernetes bridge is a real signal — it validates that "developers don't want to hand-write Kubernetes YAML" is now a mainstream-enough problem for Docker itself to build a product around, not just a gap independent tools like Kompose have quietly filled for years. But it changes the buy-vs-build calculus for exactly one step of a git-push PaaS's pipeline, not the pipeline. The build-from-source step, the registry push, the fleet-placement decision, the tenant isolation, and the TLS routing were never Kanvas's problem to solve, and Docker's own materials don't claim otherwise.

For bex, the practical takeaway is narrow and concrete: accept docker-compose.yml as a first-class input alongside buildpack detection and a Dockerfile, use Kanvas/Meshery's manifest shape as a reference for what "correctly converted" looks like, and keep the five rows that actually make it a platform — build, push, place, isolate, route — owned end-to-end on infrastructure it controls.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, whether that repo ships a Dockerfile, a docker-compose.yml, or neither. Star the repo on GitHub or deploy your first app today.

Sources​

• Docker: Compose to Kubernetes to Cloud With Kanvas
• InfoQ: Docker Kanvas Challenges Helm and Kustomize for Kubernetes Dominance
• Layer5: Docker Kanvas Challenges Helm and Kustomize for Kubernetes Dominance
• Layer5 Kanvas Documentation
• Kubernetes: Translate a Docker Compose File to Kubernetes Resources (Kompose)
• Kompose.io
• Docker: 2025 State of Application Development Report
• GitHub: layer5io/kanvas-docker-extension