← Writing
Field note 3 min read

Moving development onto my devbox

The migration took two attempts. Keeping a working copy on each machine was where I went wrong.

Linux/Developer tools/Git/Infrastructure

I had an unused laptop and wanted somewhere for coding agents to keep running after I closed my MacBook. I installed Linux on it, called it devbox, and connected over SSH. Getting a shell was straightforward. Deciding where to keep the code took longer.

At first, I kept developing on the Mac and treated the devbox as a second place to run the project. I added an rsync wrapper to copy files over. Then I had a checkout on each machine, on different branches, with uncommitted changes in both.

I was also forwarding services onto different local ports so the two development stacks could coexist. That made the remote app accessible, but every change still came with a question: which copy was I editing?

Moving it twice

I moved the project to the devbox, changed my mind and went back to using the Mac copy, then moved it again. The final decision was to do the development directly on the devbox through Orca. I removed the Mac checkout and the sync wrapper.

The project now has its main checkout and task worktrees on the same machine. Other projects still live on my Mac. I choose where each project lives rather than maintaining a matching copy on both.

MacBookOrca client
devbox
~/Workspace/<project>/
    main checkout

~/orca/workspaces/<project>/ task-a/ task-b/

The directory layout on the remote machine. Project and task names are placeholders.

Getting the tools onto the right machine

Orca’s remote server runs the terminals and agents on the devbox. The Mac app connects to it. I can close the client and come back to the remote session later.

Moving the repository did not move the rest of the environment. The remote machine needed its own runtime, dependencies, Git access, and CLI logins. For the first project, cloning over HTTPS failed because the remote shell had no credential helper configured. Cloning over SSH worked with the key already on that machine.

Browser logins were another job. A CLI running remotely could ask to open a URL, but the machine had no desktop browser handler. Fixing that led to the xdg-open problem described in A headless devbox still needs a browser.

The setup I use now has fewer moving parts than the one I started with: Orca connects to the devbox, the project runs there, and I open its remote worktree to continue. There is no copy step before running a command and no sync step when I finish.

For the Linux, SSH, and power configuration, I kept the commands in How to turn an idle laptop into a Linux devbox.

PreviousA headless devbox still needs a browser