DEV Community: Jan van Dorth

Testing Microservice Changes from Git Worktrees End to End Without the Terminal Tab Explosion

Jan van Dorth — Sat, 28 Feb 2026 10:45:09 +0000

TLDR: made a visual cli-tool called Recomposable to tackle this issue.

If you use Claude Code with git worktrees, you probably have multiple branches of the same repository checked out simultaneously. Claude works in one worktree, you review in another. This works well for single-service projects, but it breaks down when you run microservices.

The problem: you need to verify that the changes Claude made to one service still work with the rest of your stack. This means rebuilding that one service from the worktree's code while keeping everything else on main, and Docker Compose has no concept of worktrees, it only knows about files on disk, so you're on your own. I have solved this for myself with the cli-tool Recomposable, which I will discuss further down the page.

What you have to do today

Say Claude Code is working on your auth-service in a worktree, and you want to test its changes against the rest of your stack. Here's the manual workflow:

Step 1: Find the worktree path.

Claude Code creates worktrees in .claude/worktrees/ with generated names, so you need to find it first.

git worktree list
# /Users/you/project                   abc1234 [main]
# /Users/you/project/.claude/worktrees/jan-abc123  def5678 [fix-oauth]

Step 2: Build the service from the worktree.

You need to combine the worktree path with the compose file path, specify the service, and build:

docker compose -f /Users/you/project/.claude/worktrees/jan-abc123/docker-compose.yml build auth-service

Step 3: Start it.

docker compose -f /Users/you/project/.claude/worktrees/jan-abc123/docker-compose.yml up -d auth-service

Step 4: Verify.

Open another tab, tail the logs, check the other services, maybe rebuild if it failed.

Step 5: Switch back.

When you're done testing, repeat steps 2-3 but pointing back at the original compose file.

Every step requires you to remember or paste the worktree path, and if you have multiple compose files you also need the correct file name. There's no overview of which services are running code from which branch - you just have to remember.

You can script this with aliases or a Makefile target, but you still lack a way to see at a glance which service is running from which worktree, and every new worktree means updating your aliases.

What recomposable does instead

recomposable is a Docker Compose TUI I built for development workflows, and version 1.1.4 adds worktree switching as a first-class feature.

Press t on any service, and a picker shows all available git worktrees. Select one with j/k and Enter, and the service is stopped, rebuilt from the target worktree's compose file, and started. That's it.

When services run from different branches, a WORKTREE column appears automatically with non-main branches highlighted in yellow, so you see at a glance which service runs from which branch.

SERVICE              STATUS    BUILT     PORTS          WORKTREE
auth-service         running   2m ago    5001           fix-oauth
api-gateway          running   1h ago    8080           main
web-app              running   3d ago    3000           main

No paths to remember, no compose file flags, no switching terminals to check which branch a container was built from.

How it works

When you press t, recomposable runs git worktree list --porcelain from the compose file's directory to discover all worktrees, and the picker shows each worktree's branch name and path.

On selection, it maps the compose file path to the equivalent path in the target worktree. If your compose file is at infra/docker-compose.yml relative to the git root, it looks for the same relative path in the target worktree and shows an error if the file doesn't exist or the service isn't defined in the target compose file.

The override is stored per service, and all subsequent operations — rebuild, restart, logs, exec, watch, dependency-aware cascade rebuild — automatically use the overridden compose file. Switching back is the same action: press t and select the original worktree.

The Claude Code workflow

This is the workflow I built the feature for:

Start recomposable in your project directory, with your full stack running on main.
Open Claude Code and tell it to work on auth-service in a worktree.
Claude makes its changes, and you want to verify them end-to-end.
In recomposable, navigate to auth-service, press t, and select the worktree Claude is working in.
The service rebuilds from Claude's branch while the rest of the stack stays on main.
Check logs, run requests, and verify — if something is wrong, check the logs right there in the TUI.
When done, press t again and switch back to main.

No terminal tabs, no path juggling, no guessing which branch is running.

This scales to any number of services. Claude working on three services across two worktrees? Switch all three, and the WORKTREE column shows you exactly what's running where.

Future work

The worktree feature covers the core workflow, but there are gaps worth addressing for teams that use this pattern heavily:

Auto-detect worktree changes. Currently you manually press t to switch, but recomposable could watch for new worktrees appearing (e.g., Claude Code just created one) and prompt you to switch the affected service, removing the "go check if Claude is done, then switch" polling loop.

Worktree-aware cascading rebuilds. The dependency-aware rebuild (d) already restarts transitive dependents, but if auth-service is switched to a worktree and api-gateway depends on it, the cascade doesn't switch api-gateway too. For tightly coupled services that should be tested from the same branch, a "cascade switch" would reduce manual steps.

Diff preview before switching. Before rebuilding from a worktree, showing a summary of what changed (files modified, services affected) would help you decide whether the switch is worth the rebuild time, especially when Claude has been working for a while and you're not sure what exactly changed.

Branch status indicators. Showing whether a worktree's branch is ahead/behind main, or has uncommitted changes, would help you decide which worktree to test — a branch that's 30 commits ahead is a different risk profile than one that changed a single config file.

Multi-service worktree switch. A single action to switch all services from one compose file to the same worktree, because when Claude works on changes that span multiple services in the same repo, switching them one by one is unnecessary friction.

Install

npm install -g recomposable

Navigate to a directory with a docker-compose.yml, create a recomposable.json pointing to your compose files, and run recomposable. The worktree feature works out of the box with any git repository that has multiple worktrees.

GitHub | npm

Every Docker Compose TUI I Could Find (And Why I Built My Own)

Jan van Dorth — Thu, 26 Feb 2026 14:50:20 +0000

If you run more than a couple of containers locally, you know the hassle. Countless terminal tabs, just to be able to rebuild your services and inspect the logs.

I built recomposable to fix this for my own workflow.

Before building it, I searched for existing tools to see if one would fit my needs. Below is a feature comparison of every Docker TUI I could find which I deemed relevant for my development workflow.

Here's what I found:

The Tools

See the table below for a quick comparison. The table is followed by a short summary of which features each package has or doesn't have. The comparison is biased, as Recomposable ticks almost all the boxes, but that's because i've made it to solve my own specific docker development hassles.

How They Compare

	lazydocker	DockTUI	oxker	Cruise	DockMate	DockedUp	Pocker	dry	ctop	dcv	recomposable
Language	Go	Python	Rust	Go	Go	Python	Python	Go	Go	Rust	Node.js
Compose-first	No	Yes	No	No	Partial	Yes	No	No	No	Yes	Yes
Rebuild	No	Limited	No	No	No	No	No	No	No	No	Yes
No-cache rebuild toggle	No	No	No	No	No	No	No	No	No	No	Yes
Dep-aware rebuild	No	No	No	No	No	No	No	No	No	No	Yes
Compose Watch	No	No	No	No	No	No	No	No	No	No	Yes
Log pattern scanning	No	No	No	No	No	No	No	No	No	No	Yes
Log search	No	Clipboard	No	No	No	No	Keyword filter	No	No	No	Yes (`/`, `n`/`N`)
CPU/Memory	ASCII graphs	Yes	Yes	No	Yes	Yes	Yes	No	Yes	No	Yes (color thresholds)
Port display	Yes	Yes	Yes	Yes	No	No	No	No	No	No	Yes
Vim keybindings	Partial	No	Custom	No	No	No	No	No	No	No	Full (`j`/`k`/`gg`/`G`)
Container exec	Yes	No	Yes	Yes	Yes	Yes	No	No	No	No	Yes (in-TUI)
Image/volume mgmt	Yes	No	No	Yes	No	No	Images	Yes	No	No	No
Zero dependencies	Single binary	Docker container	Single binary	Single binary	Single binary	pip	pipx	Single binary	Single binary	Single binary	Node.js (already on your machine)

lazydocker

github.com/jesseduffield/lazydocker

40k+ GitHub stars. Written in Go. It's a general-purpose Docker manager: containers, images, volumes, networks. Has live logs, ASCII metric graphs, exec into containers, bulk commands. Docker Compose is supported but it's not the focus.

DockTUI

github.com/dialmaster/DockTUI

Actually built for Docker Compose specifically. Real-time CPU/memory dashboard, grouped by compose stacks. Interesting choice: it runs as a Docker container itself. Clipboard integration for copying log snippets. The downside is that it can't monitor remote daemons.

oxker

github.com/mrjackwills/oxker

Rust + ratatui. Clean single-screen layout showing containers, logs, CPU, memory, and ports all at once. Customizable keymaps and color schemes. Sortable columns. About 900 stars. Doesn't try to do too much, but does it quite good.

Cruise

github.com/NucleoFusion/cruise

Go + Bubbletea. Containers, images, volumes, networks, logs, from one screen. Looks good too.

DockMate

github.com/shubh-io/DockMate

Calls itself "htop for Docker". Go-based, zero-config. Single-keystroke actions: s to start, x to stop, r to restart, d to remove. Also supports Podman. Has compose lifecycle management.

DockedUp

github.com/anilrajrimal1/dockedup

Focused on monitoring. Auto-groups containers by docker-compose project. Color-coded status, health, CPU, and memory. Hotkeys for logs, restarts, shell access.

Pocker

github.com/pommee/Pocker

Python + Textual. View containers and images, manage status, browse logs/env/stats. Has log keyword filtering. Install via pipx. If your stack is Python-heavy you might prefer this.

dry

github.com/moncho/dry

One of the older tools in this space. Go-based. Covers Docker and Docker Swarm. Gives you inspect, history, logs, and the usual start/stop/remove. More of a Docker CLI replacement with a visual layer on top than a monitoring dashboard.

ctop

github.com/bcicen/ctop

Does one thing: real-time container resource metrics. Think top but for containers. CPU, memory, network, I/O. No compose awareness, log viewing nor container management. Good for when you just need a quick glance at resource usage.

dcv

github.com/tokuhirom/dcv

Minimal TUI viewer for docker-compose. Rust-based. Lightweight by design.

Where Recomposable Fits

Most of these tools are general Docker managers that happen to support compose. They're built for people who manage Docker infrastructure.

Recomposable is built for the developer workflow: you have one or more docker-compose.yml files, and you spend your day rebuilding services, restarting them and checking logs for errors. You occasionally look for port numbers and want to make sure your services don't take up too much CPU and memory. If this sounds recognizable, Recomposable will help you out.

Things it does that no package in the list does:

Rebuild with no-cache toggle. Press b to rebuild. Press n to toggle --no-cache --force-recreate on and off. Other tools only support restart. When your Dockerfile changes or a dependency breaks, restart doesn't help you. You need a clean rebuild.

Dependency-aware rebuild. Press d to rebuild a service and automatically restart everything that depends on it, in topological order. No more manually restarting five services because you changed a shared library.

Docker Compose Watch integration. Press w to toggle docker compose watch per service. Watch output streams to the bottom log panel. The service list shows a cyan W indicator next to watched services.

Log pattern scanning. It continuously scans logs across all your services and counts matches for configurable patterns (warnings, errors, whatever you care about). You see the counts right in the service list without opening any log view.

Full log view with search. Scrollable, full-screen, with / to search, n/N to jump between matches, and live auto-scroll when you're at the bottom.

In-TUI container exec. Press e to open an inline exec panel in the bottom of the list view, or x for a full-screen command runner. cd works and the working directory is tracked across commands. Type commands, see output, navigate history with Up/Down. No need to leave the TUI or open another terminal.

What it for now doesn't do: manage images, volumes, networks, Swarm and Podman support. You can find the current issues in the repo. If you want to contribute by building this or any other feature, just submit a PR! Thanks in advance :)

Install

npm install -g recomposable

Then cd into a directory with a docker-compose.yml and run recomposable. Done.

GitHub | npm