wslcontainers
Free tool · runs in your browser

docker-compose → wslc migration analyser

wslc has no Compose runtime. Paste your docker-compose.yml to see which fields map cleanly, which need changing, and which have no equivalent at all — then export a wslc startup script for the whole stack.

Load an example

Generated wslc startup script

This replaces docker compose up -d. It creates the named volumes and networks first, then starts each service in dependency order derived from depends_on. Unsupported fields are preserved as comments so nothing silently disappears. 

# Paste a Compose file to generate a wslc startup script
Analysis runs locally. Your Compose file is never uploaded.

Read the script before running it. The sleep 2 calls are placeholders standing in for depends_on, not real readiness checks. For anything beyond local development, replace them with a proper probe — pg_isready, a curl retry loop, or your own health endpoint poll.

What the statuses mean

StatusMeaningWhat to do
Supported The field maps onto a wslc run flag with the same behaviour. Nothing. It is handled in the generated script.
Needs care It works, but semantics differ — path translation, bridge-only networking, or only part of the field applies. Read the note and verify the generated command matches your intent.
Not supported No equivalent exists in the wslc preview. The field is dropped. Replace the behaviour yourself, or keep Docker for this stack.

Why there is no wslc compose

Compose is a declarative orchestrator: it holds a dependency graph, restarts failed containers, and waits on health checks. wslc is a daemonless single-container runtime — there is no long-running process to watch containers and restart them, so the orchestration half of Compose has nowhere to live. That is also why Testcontainers cannot attach to wslc: no daemon means no Docker socket and no Engine API.

The practical consequence is that migrating a stack is a translation job, not a configuration change. For the field-by-field reasoning behind this tool, see the Compose migration guide. For single commands rather than whole stacks, use the command converter.

Same analysis in your terminal and your editor

This page shares its rule table with the open-source docker2wslc packages, so you get identical results from the CLI: 

# check a whole repository, exit code 2 means something cannot migrate
npx docker2wslc lint .

# or via pip
pip install 'docker2wslc[yaml]'
docker2wslc compose docker-compose.yml

Also available as an MCP server for Claude Code and Cursor, and on GitHub.

Frequently asked questions

Can wslc run docker-compose.yml directly?
No. The wslc public preview ships no Compose runtime and no wslc compose subcommand. A Compose file is a declarative description of a stack; wslc only has imperative single-container commands. To move a stack across you translate each service into a wslc run invocation and handle ordering, restarts and health checks yourself, which is what this tool generates.
What happens to depends_on when I migrate?
It disappears. wslc has no dependency graph, so nothing waits for anything. This analyser still reads depends_on and topologically sorts your services so the generated script starts dependencies first, but the sleep calls it inserts are placeholders — replace them with real readiness probes such as pg_isready or a curl retry loop before relying on the script.
Which Compose fields are unsupported by wslc?
Eight of the common ones have no equivalent in the current preview: depends_on, healthcheck, restart, platform and extends, plus the Swarm-only parts of deploy. Four more work with caveats: volumes, networks, deploy resource limits and profiles. The remaining fifteen fields in this analyser map straight onto wslc run flags.
Is my Compose file uploaded anywhere?
No. Parsing, analysis and script generation all run in your browser as plain JavaScript. There is no backend call and no telemetry on this page. You can verify it by opening DevTools and watching the network tab, or read the script at /compose-tool.js.