devvm gives each project a VM and leaves your other files outside

Your coding project needs a terminal. Your SSH keys don’t need a front-row seat. devvm separates those two invitations by giving each project a Lima-backed virtual machine, with the selected folder mounted inside and the rest of your home directory outside that mount.

That includes the other projects, documents and credentials that tend to share a computer with whatever you’re trying today. The maker’s site calls devvm “open source” under the MIT license. There’s no subscription tier to unlock the privilege of keeping your own files to yourself (how generous).

The ordinary setup still gives the VM a writable project folder. That’s useful when you want edits to appear immediately in your editor, and it’s a very specific limit on the protection. A command inside the VM can change the thing you deliberately handed it. A sandbox with your working tree in it still has your working tree in it.

The attack-vectors guide names the host programs that can run a changed file. A changed editor task or project configuration can run later on the host. A secret already sitting in the project folder is reachable inside the VM. The guide warns that allowed network destinations can accept data, too; allowing a repository host doesn’t make every account on that host trustworthy.

The network proxy therefore belongs in the decision along with the mount. It limits destinations on the allowlist tier, but the documented open tier reaches what the host can reach. That setting deserves more attention than the cheerful word “sandbox” on anyone’s product page.

Clone mode moves the working repository onto the VM’s disk. Local branches go across, while uncommitted changes and ignored or untracked files stay behind. That conveniently leaves the usual untracked .env behind, although credentials already committed to a branch remain part of the material you’re sending.

The return trip uses git fetch devvm. Your host receives Git objects and remote-tracking branches, and you review the commits before merging or running their contents. The docs describe this as “Fetching runs nothing from the VM” on the host. Fetching is a separate event from trusting what came back, a distinction Git users already have the machinery to handle.

Installation has a real hardware bill, even when the software is free: the first VM needs 8 GiB of free disk space. The guide recommends 8 GiB of memory and four CPUs, supports macOS and Linux on arm64 or x86_64, and says Intel Macs haven’t yet been tested. devvm doctor checks missing requirements before the first VM starts.

Project isolation could become easier to live with when creating a fresh guest is routine and returning work uses an existing review habit. The remaining question is how your actual build behaves inside those limits. Its clone workflow also carries a wonderfully literal operational catch: a stopped VM has no SSH entry, so fetching fails until it’s running again.

Even the remote needs to wake up.