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.

thinslice CLI multiplexing agent worktrees

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 5433 connects directly
  • State as a plain directory you can cd into, pg_dump, rsync, or snapshot — not opaque volume internals
  • Cold start as a process fork — no image pulls, no docker compose up wait, 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-search

slice 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.

thinsliceDocktree
LicenseSource available (community license)Open source (MIT)
PlatformsmacOS, Linux, WindowsAnywhere Docker runs
InterfaceCLICLI
Services run asNative processesDocker containers
Edit the tool with your coding agentYes (shell scripts)
Docker daemon requiredNoYes
VM on macOSNoYes
Git worktreesYesYes
Per-worktree PostgresYesYes
Per-worktree RedisYesYes
Per-worktree port allocationYesYes
State as a plain directoryYes— (Docker volumes)
Cold startProcess forkdocker compose up
Clone state to new worktreeYes (--from current)
Detach / reattach stateYes
Throwaway agent worktreesYes (slice tmp)
Reuse existing Compose filesYes (generates overrides)