thinslice vs Docktree
Docktree runs Docker Compose across git worktrees. It generates a Compose override for each worktree with a unique project name, container names, and volumes, and auto-allocates ports from a managed pool. Open source under the MIT license.
thinslice binds each git worktree to its own bag of runtime state — dedicated Postgres, Redis, ports, and config — as native processes. No Docker, no VM. Postgres is a real process on a real port. Works with any agent, on macOS, Linux, and Windows.
Same concept: containers vs native processes
thinslice and Docktree solve the same problem: one isolated dev environment per git worktree, so parallel agents never collide on ports, databases, or caches. The difference is how the services run. Docktree runs your stack in containers. thinslice runs the same stack as native processes.
Docktree wraps docker compose. It needs a Docker daemon. On macOS the daemon runs inside a Linux VM (Docker Desktop, OrbStack, or Colima), so every container, port, and volume sits behind the VM boundary. thinslice has no daemon and no VM. Postgres is a process you own directly.
Why pick thinslice
Both tools give each worktree its own Postgres, Redis, and ports. Pick thinslice if you want:
- No Docker daemon and no VM — Postgres runs as a native process, so
psql -h localhost -p 5433connects directly - State as a plain directory you can
cdinto,pg_dump,rsync, or snapshot — not opaque volume internals - Cold start as a process fork — no image pulls, no
docker compose upwait, no VM boot - Clone the current state into a fresh throwaway worktree and hand it to any agent
- Detach and reattach state across sessions
- A tool you can change — the installed commands are shell scripts that your coding agent can edit
- Free, offline, on macOS, Linux, and Windows
Architecture
thinslice runs as a CLI on your machine. Each slice new or slice tmp creates a git worktree and provisions an isolated state bag — its own Postgres cluster, Redis instance, and port range — that travels with that worktree. Every service is a native process. Nothing runs inside a container or a VM.
Docktree runs the same isolation model on Docker Compose. It generates a Compose override per worktree with a unique project name, container names, and volumes, and hands the stack to the Docker daemon. The daemon is the host for every service.
State you can inspect
A thinslice state bag is a named directory on your filesystem. The Postgres data directory, the Redis dump, and the config are files you can read with any tool. To back up a slice, rsync the directory. To dump a database, run pg_dump against the port. To copy an environment to a new worktree, clone the directory.
Docktree keeps state in Docker volumes. Volume contents live inside the daemon, not on your host filesystem. To reach the data you go through docker commands or docker exec into a container.
Runtime isolation
thinslice provisions each worktree with its own Postgres cluster, Redis instance, and port range. Two agents can run migrations, seed data, or start dev servers at the same time. They do not interfere. The state bag is persistent: detach it when the agent is done, and reattach it later to resume where you left off.
Docktree isolates the same services in per-worktree Compose projects with unique ports, container names, and volumes. The isolation is real. The services live in containers behind the daemon.
Cold start
A thinslice slice starts by forking processes. There is no image to pull and no VM to boot. Handing a fresh, seeded environment to an agent is near instant.
A Docktree stack starts with docker compose up. The first run pulls images. On macOS the Docker VM must be running. The wait is the container and VM startup path, not the code.
CLI
thinslice is a CLI first:
# Create a worktree with its own db, redis, and ports
slice new feature/add-search
# Spawn a throwaway worktree cloned from the current slice, hand it to Claude Code
slice tmp --from current claude -p "add full-text search to the products table"
# List all slices and their state
slice ls
# Attach to an existing slice
slice attach feature/add-searchslice tmp --from current clones the current state bag into a fresh worktree so the agent starts with real data and a working dev environment. When the agent exits, thinslice discards the throwaway.
thinslice sets environment variables — database URL, port, config path — that any CLI agent reads. Use Claude Code, Codex, or any other tool. Docktree is also a CLI wrapper around Compose. It ships skills for Claude Code, Cursor, Codex, and other agents.
Change the tool itself
thinslice ships as a collection of shell scripts. The files that run are the files you installed. There is no compiled binary and no build step between you and the tool.
If you want a command to work differently, ask your coding agent to edit the installed scripts. The change is live on the next run. Most tools stop you at this point: fork the repository, install the toolchain, build, and then test. thinslice also includes a built-in path to send your change upstream.
A note on worktree-compose
worktree-compose is a lighter tool in the same lane. It sets a unique COMPOSE_PROJECT_NAME per worktree and injects port overrides, then starts a Docker Compose stack. It needs Docker too. The dividing line is the same: containers and volumes on one side, native processes and plain directories on the other.
Platforms
thinslice runs on macOS, Linux, and Windows as native processes. Docktree runs anywhere a Docker daemon runs. On macOS and Windows that daemon runs inside a Linux VM.
Comparison
Facts about Docktree are current as of August 2026.
| thinslice | Docktree | |
|---|---|---|
| License | Source available (community license) | Open source (MIT) |
| Platforms | macOS, Linux, Windows | Anywhere Docker runs |
| Interface | CLI | CLI |
| Services run as | Native processes | Docker containers |
| Edit the tool with your coding agent | Yes (shell scripts) | — |
| Docker daemon required | No | Yes |
| VM on macOS | No | Yes |
| Git worktrees | Yes | Yes |
| Per-worktree Postgres | Yes | Yes |
| Per-worktree Redis | Yes | Yes |
| Per-worktree port allocation | Yes | Yes |
| State as a plain directory | Yes | — (Docker volumes) |
| Cold start | Process fork | docker compose up |
| Clone state to new worktree | Yes (--from current) | — |
| Detach / reattach state | Yes | — |
| Throwaway agent worktrees | Yes (slice tmp) | — |
| Reuse existing Compose files | — | Yes (generates overrides) |