Uses

What I build with, and how two machines share the work. Checked October 2026.

Two machines, one workspace

I edit everything on a MacBook Air with 8 GB of memory. The heavy work runs on a Windows PC next to it: Docker, test suites, GPU runs, Rust builds. The code never lives in two places. The Mac is the only place I edit; the other machine gets disposable copies.

MacBook Air (M2, 8 GB): code, editor, browser
  │  Tailscale (WireGuard), direct over the home network
  ▼
Windows PC (Ryzen 7 5800H, 16 GB, RTX 3060 6 GB)
  └─ WSL2: Ubuntu 24.04, 14 CPUs, 12 GB — "devbox"
       ├─ its own Tailscale address
       ├─ Docker Engine and Compose (no Docker Desktop)
       ├─ NVIDIA GPU passthrough
       └─ ~/mirror/<project>: throwaway copies for heavy runs

Tailscale

Both the Windows host and the Linux server inside it join my Tailnet as separate devices. SSH to the server is key-only. Ports that containers publish are reachable from the Mac by name, as devbox:<port>, and from nowhere else: WSL2 sits behind Windows' NAT, so only my Tailscale devices can reach them.

Docker on the other machine

The Mac has a Docker context that points at the server, so plain docker and docker compose run there:

docker context use devbox

Quitting Docker Desktop on the Mac frees about 4 GB of memory, which on an 8 GB machine is half the point. Two things change from local Docker: bind mounts refer to folders on the server, so I use named volumes; and docker build sends its context over the network.

Run next to the database, not across the network

Moving only Docker to the server makes a chatty program slower. I measured it on a service that makes 40 to 55 database round trips per write:

Where things runOne database round tripOne write
Code and Docker on the Mac0.64 ms95 ms
Code on the Mac, Docker on the server5.36 ms313 ms
Code and Docker both on the server0.17 ms12 ms

So heavy runs go to the server too. A small devbox command syncs the working tree to a mirror with rsync and runs the command there, next to the databases:

devbox run "uv sync --frozen && .venv/bin/python -m pytest tests -q"

That suite, 518 tests on 10 workers, takes about 3 minutes 40 seconds there. On the loaded Mac it was 13% done after an hour. Long-lived servers run in tmux on the server, so they survive the Mac going to sleep.

Two architectures as a test rig

For Taco, the two machines are also the test: the Mac is ARM and the server is x86. scripts/dx <lane> <command> runs a command on the server in its own build directory, so parallel jobs never wait on one cargo lock. scripts/xcheck folds every test file on the Mac and unfolds it on the server, then the other way round, and fails unless both machines restore every byte and write identical .taco files.

Editors

  • VS Code, Zed and Neovim.
  • Xcode and Android Studio for mobile apps.

Terminal

  • Ghostty and iTerm, with zsh.

Languages and runtimes

  • TypeScript on Node.js and Bun, with pnpm.
  • Rust, for Taco and networking experiments.
  • Python with uv, for measurement tools.

Tools

  • Docker, Postman, DBeaver and the GitHub CLI.
  • Claude and Claude Code.

Browsers

  • Arc and Chrome.