WSLCC: docker compose, but for WSL Containers

Heads up — this is a work in progress. WSLCC is young, and so is the platform it's built on (WSL containers are in public preview). Expect rough edges, breaking changes, and the occasional "well, that's embarrassing." If any of the ideas below sound useful, come kick the tires and help shape where it goes: github.com/arepetti/wslcc.

The one-line pitch

WSLCC (short for WSL Containers Compose) gives you a docker compose–style workflow on top of Microsoft's WSL containers. You write the same Compose YAML you already know, run a familiar command, and your services come up — no Docker Desktop required.

Wait, what are "WSL containers"?

If you've been on Windows for a while, you know WSL (the Windows Subsystem for Linux) as the thing that gives you a real Linux environment without a VM to babysit. More recently, Microsoft has been building a native container story right into WSL: a way to pull images and run Linux containers on Windows using the OS's own plumbing, driven by a CLI called wslc.

It's a genuinely exciting direction. Containers, on Windows, without a heavyweight extra runtime layer sitting in the middle. But there's a catch.

The gap: there's no compose

Here's the thing about real-world container work: almost nobody runs a single container. You've got a web app and a cache and a database and a message queue. The tool that made all of that pleasant was docker compose: one YAML file, one up, and your whole local stack springs to life.

wslc can start containers. What it doesn't (yet) have is a compose verb. So the moment you want to describe a multi-service app declaratively (the way every Compose file on the planet already does) you're back to running things by hand and wiring them together yourself.

That's the gap WSLCC fills.

What WSLCC actually does

WSLCC reads the exact same Compose files you already have. Take a bog-standard docker-compose.yml:

name: web-redis



services:

  web:

    image: nginx:1.27

    ports:

      - "8080:80"

    depends_on:

      - redis

    restart: unless-stopped



  redis:

    image: redis:7

    restart: unless-stopped

…and bring it up with a command that should feel like muscle memory:

wslcc compose up

wslcc compose ps

wslcc compose down

The commands mirror docker compose on purpose. The whole point is that you don't have to relearn anything. If you know Compose, you already know WSLCC.

One interface, two backends

Here's a design decision worth calling out: WSLCC isn't hard-wired to a single runtime. Under the hood it talks to providers, and it ships with two:

• 
  WSL containers (wslc): the native Windows path, and the reason this project exists.


• 
  Docker Compose (docker): because plenty of us still have Docker around, and having one tool that speaks to both is genuinely handy.

Why does that matter? Because it means WSLCC can be your single, unified front door. Testing something against Docker today and WSL containers tomorrow? Same YAML, same commands, just point it at a different provider. No mental context-switch, no second toolchain.

# Start/stop it manually or make it a Windows service

wslcc daemon start # "--provider docker" to use Docker

wslcc compose up

A tiny daemon, and a reason for it

WSLCC has two moving parts:

• 
  wslcc — the CLI you type at.


• 
  wslccd — a small background daemon it talks to over gRPC (a named pipe locally, or HTTP when you want it).

That split might look like over-engineering for a "just run my containers" tool, but it buys two real things. First, it keeps a warm, long-lived process around to manage state instead of paying cold-start costs on every command. Second (and this is the fun part) because the CLI and daemon are decoupled, the daemon can live somewhere else. The long game is managing containers on a remote machine the same way you manage them locally, and a graphical companion app down the road, both talking to the same daemon.

Why build this at all?

Honestly? Because the pieces are almost there. WSL containers give Windows a native, lightweight way to run Linux workloads. Compose gave the whole industry a lovely way to describe multi-service apps. WSLCC is the connective tissue: it lets a decade of existing Compose files and Compose muscle memory work against this new, native Windows backend — while still playing nicely with Docker for everyone who lives in both worlds.

If you've ever thought "I wish I could just compose up against WSL containers," that's the entire motivation in one sentence.

Give it a spin

The project is open source (MIT) and lives here:

github.com/arepetti/wslcc

It's early, it's evolving, and feedback is gold at this stage. Try it against a Compose file you already have, tell me what breaks, and if the vision resonates...issues and PRs are very welcome.

Happy composing.