Introducing CodingBooth: Reproducible Dev Environments, One Command Away

#devops #docker #devtools #productivity

Production is containerized. CI is containerized. The dev loop — where we actually spend our hours — usually isn't. CodingBooth is the missing piece.

The three pains

If you hop between projects, you've probably collected all three:

Project residue. Every project installs something — a JDK, a Go toolchain, a DB client, an SDK. After a few months the host is a graveyard of half-configured runtimes, and two unrelated projects end up fighting over a broken global.
Legacy projects punish you. The bigger and older the project, the harder it is to set up the same way as the rest of the team. The onboarding doc is stale, the setup script worked on someone's 2019 laptop, and the "just works" build tool version isn't published anywhere obvious.
AI-assisted drift. Coding assistants happily suggest brew install this or go install that@latest while solving something small. Unless someone is watching closely, those land on your host permanently. A year of pair-programming with an assistant later, the environment has mutated in ways nobody documented.

All three add up to the same thing: development becomes less repeatable — and the breakage is subtle enough that it doesn't surface until someone else tries to run your code.

Enter CodingBooth

A booth is an isolated, reproducible dev environment, declared in the repo, brought up with a single command, and torn down without residue.

The model:

Drop a .booth/ folder into your project. Declare the environment there (a Boothfile, or a plain Dockerfile if you'd rather).
Run ./booth. A container starts with your host UID/GID mapped through, your project mounted in, and your chosen front-end open.
Edit, build, test inside the booth. Files you create are owned by you on the host — no chown dance, no root-owned artifacts.

Installing CodingBooth itself is one command:

curl -fsSL https://codingbooth.io/install.sh | bash

Same booth for you and your teammate. Same image, same tools, same versions. Host stays clean.

It's not just a terminal

The thing that surprises people first time they see this: they assume "booth = browser terminal." That's one variant. There are several, and they all share the same underlying environment:

base / terminal — minimal shell, in-browser or in your host terminal
notebook — Jupyter Lab with multi-language kernels
codeserver — full browser-based VS Code, extensions and all
desktop-xfce / desktop-kde — a complete Linux desktop in your browser

Open today's project in browser VS Code, re-open tomorrow as a notebook when you want to plot something, switch to a full desktop when you need a GUI tool — same toolchain underneath the whole time.

This blog runs in a booth

The entire .booth/Boothfile for this Svelte + Firebase blog is two lines:

# .booth/Boothfile
# syntax=codingbooth/boothfile:1
# Configured by: booth config --no-tui --overwrite --variant codeserver --port 13579 --expose 5173 --select firebase+credential/claude-code+auto-accept+credential+settings-cache

setup claude-code
setup firebase

That's it. Two setup lines and the whole dev environment is declared. Each line maps to a curated install script — no FROM wrangling, no ARG ceremony. The # Configured by: comment is the exact booth config invocation that produced the file, so anyone can regenerate it from scratch.

Runtime concerns (variant, port mappings, credential mounts) live in a small config.toml next to it.

Try it in 30 seconds

booth example list
booth example try snake-zig my-snake
cd my-snake
booth

The snake example builds with Zig — a toolchain you almost certainly don't have on your host. Inside the booth you edit, compile, and the resulting binary lands on the host side ready to run. Nothing installed. Nothing to clean up. That's the whole pitch in miniature.

There's a longer write-up — the Config TUI (130+ templates), who benefits most, more on each pain — over on the full post: