Stackie supports a neat feature you may find useful. If you currently use a docker-compose.yml to run the services your app needs, it’s actually possible to keep using that workflow with Stackie without starting over — same compose file, same Docker CLI, same VS Code Container Tools panel. It does come with a few caveats that may or may not impact your usage, depending on what’s in your stack, and the rest of this post walks through them.

Under the hood, Stackie ships a Docker Engine API compatibility layer. Redirect your existing tools to Stackie’s socket and they’ll query, drive, and inspect Stackie the same way they query Docker — while in the background, your services come up as native OS processes with all the benefits that come with running natively.

If you have a docker-compose.yml file that contains services from our supported blocks list, you can point your tools at the Stackie socket and run those definitions as you usually do. Stackie speaks to your tools over the Docker Engine API, while remapping your image bindings to native block definitions in the background. Your tools still see a container runtime, images, and running containers — under the hood, Stackie is managing your stack’s lifecycle as a series of native processes on each platform.

How it works

When a Docker tool issues a request — docker pull postgres:16, docker compose up, docker ps, anything — it sends an HTTP request to the Docker daemon socket. By default that socket is owned by Docker Desktop. With Stackie installed, you point the tool at Stackie’s socket instead (the DOCKER_HOST environment variable) and the same request lands on stackied.

Inside stackied, the compatibility layer:

1. Parses the Docker request — containers, images, networks, volumes, system endpoints, and compose labels are all recognised in their native Docker JSON shape.
2. Resolves the image to a block. Our compatibility layer maps common Docker image tags to the corresponding block definitions within Stackie. Postgres’ block, for example, claims postgres, library/postgres, and docker.io/library/postgres. A postgres:16 pull is matched against this registry, the version is extracted from the tag, and the request is rewritten as “install the postgres block at version 16.”
3. Forwards to Stackie’s native runtime. From here, it’s a normal Stackie sandbox: the binary is fetched (from supercache or a native package manager), permissions are applied, and the service starts as an OS process.
4. Responds in the correct format. The response goes back to the caller in the JSON shape Docker tools expect — same field names, same status codes, same streaming format for logs and events.

The result is that your tools never know they’re not talking to Docker. From their perspective, an image was pulled, a container was created, a service is running.

Running an existing docker-compose.yml

If your compose file references services that map onto supported blocks, the workflow is:

# Point the Docker CLI at the Stackie socket
export DOCKER_HOST=unix:///<your-home>/.stackie/stackied.sock

# Run your existing compose file as usual
docker compose up

On Windows, the equivalent is:

$env:DOCKER_HOST = "npipe:////./pipe/stackie_daemon"
docker compose up

Stackie tracks the standard compose labels (com.docker.compose.project, com.docker.compose.service, com.docker.compose.container-number) so docker compose down, docker compose ps, and docker compose logs all behave the way you expect — they target the same project you brought up, not unrelated services that happened to start at the same time.

It works in both directions

The interesting consequence of presenting a real Docker Engine API is that you don’t have to start with a compose file at all. Any tool that speaks the Docker API — and there are a lot of them — works against Stackie unchanged.

If you bring up a stack with stackie up, the services appear in your existing tools as you’d expect:

• Stackie blocks show as Docker images.
• Running Stackie services show as Docker containers.
• Logs, exec, stats, inspect, and the rest of the Docker API work the way they do against Docker Desktop.

VS Code is the easiest case to picture. Open the Containers panel in VS Code Container Tools with DOCKER_HOST pointed at the Stackie socket, and the panel populates with whatever Stackie is currently running — the same expandable tree of containers, the same right-click menu, the same logs view. The only thing that’s changed is that everything underneath is a native OS process instead of a containerised one. Just without the overhead.

Screenshot placeholder — VS Code Containers panel on macOS, populated by the Stackie socket. To be added prior to publication.

The right tool for the job

A compatibility layer that’s honest about its limits is more useful than one that pretends to be Docker. The current edges:

• Supported-block coverage. A compose file that references a service Stackie has a block for (postgres, redis, mailpit, nginx, and the rest of the catalog) should run. A compose file that references an arbitrary image with no block equivalent won’t, because there’s nothing native to substitute. The blocks list is growing — if a service you need isn’t there, raise an issue on our GitHub. We prioritise new blocks based on upvotes, and plan to open the catalog to outside contributions when the specification is settled.
• Dockerfile builds are not supported. docker build and build: directives in compose files won’t work, and this is unlikely to change — Dockerfile builds depend on a Linux kernel and filesystem that doesn’t fit the Stackie model. If your use case is bringing your team’s own applications and services into the stack definition, Stackie supports that natively, and has great support for serverless applications. You may want to migrate your docker-compose.yml file to a Stack definition using our conversion tool.
• Stackie is not a container runtime. It looks like one through the API, and that’s enough for most developer workflows, but anything that depends on actual container internals — privileged containers, custom kernel modules, raw cgroup tweaks — isn’t going to find what it expects.
• Production parity is not the goal. The compatibility layer exists so your local tools and IDE panels keep working. If your production workflow needs self-built containers, keep deploying containers. You may still find value in migrating to Stackie anyway - the trade-offs are discussed in this post.

Follow along on GitHub or subscribe to the RSS feed for what comes next.