Devvm.dev: One VM for every project

Free and open source

An isolated sandbox with your project’s toolchain, ready for you or a coding agent to start coding.

Quick start #

brew trust --formula devvmhq/tap/devvm
brew install devvmhq/tap/devvm

The install script in the Linux tab also works on macOS, and Installing lists its options.

1. Go to your project

Open a terminal and cd into any project folder.

2. Run devvm

devvm shows what the new VM gets. Confirm to make it, or customize it.

3. Start your agent

devvm opens a shell in the VM, whose prompt starts with (devvm), so start your agent there.

Claude Code needs your Claude login before its first start, which devvm agent login claude makes from the VM and keeps on your machine (your first VM). The next time you run devvm in the folder, it opens the same VM, and devvm tools adds an agent to a VM you already have.

What’s supported #

Toolchains

devvm chooses the toolchains your project’s files call for, and you can choose more when you customize a new VM or name them with --tools (toolchains).

Coding agents

Claude Code, Codex and opencode run in the VM. Choose one when you customize a new VM, or choose them for every new VM in devvm setup (coding agents).

Layers

devvm ships the docker, nix and desktop layers, which you choose when you customize a new VM, and devvm layer new creates your own custom layers you can apply to any of your VMs (layers).

Why use devvm? #

• Developers face attacks every day, such as supply chain attacks , leaked secrets,prompt injections and rogue agents.
• A sandbox limits the blast radius of an attack to what’s inside it.
• You know you should run your code and agents in a sandbox, but most tools need configuration and setup that’s hard to get right.
• devvm ships with sensible defaults so you can start coding in a sandbox with a single command.

Developer ready, zero config #

• The base image comes with optional extras that you choose, such as oh-my-bash, fzf, zoxide (z ), tree and tldr.
• Every VM gets your git name and email, so the commits made in it are authored by you or your agent.
• Ports forward on their own, so a dev server on :5173 in the VM opens atlocalhost:5173 on your machine (ports ).
• devvm code opens the VM in VS Code over Remote-SSH (devvm code ).

Isolated sandbox #

• The VM mounts your project folder at the same path. Apart from your agents’ settings from devvm’s own store, which it gets read-only, it sees nothing else in your home folder (what a VM can reach ).
• New VMs get the allowlist network tier by default, so they reach only an allowlist of hosts, through a proxy on your machine. You can choose a looser tier, internet or open, or a stricter one, none.
• On macOS, devvm locks.git ’s hooks and config, so the VM can’t change what git runs on your machine (.git protection ).
• With --clone , the VM works on a clone of the repo of its own instead of your folder, so nothing in it can touch your working tree or.git , and its work reaches your repo only when you fetch it.
• No sandbox closes every gap, so attack vectors lists what’s left open, andstaying safe lists the habits that close most of it.

Ready in seconds #

• The first VM builds a base image, and every later VM is a copy of it that starts in seconds (images ).
• devvm builds each version of a toolchain once and shares it read-only, so all VMs use the same copy (shared tools ).

Made for coding agents #

• The agent runs in the VM, so an attack on it stays in the sandbox. It gets your settings, skills and MCP servers but never your history (coding agents ).
• On every network tier, their secrets, such as your Claude Code token and your Codex login, stay on your machine, because the VM gets placeholders and devvm’s proxy puts the real ones into its requests on the way out.

Make it yours #

• Your own layers are setup scripts that devvm builds into an image:devvm layer new mailpit starts one, anddevvm --layers mailpit makes a VM with it (your own layers ).
• devvm setup --layers gives every new VM the layers you choose, so your shell setup, aliases or dotfiles can go in a layer of your own that each VM gets unless you leave it out (extras of your own ).
• --from starts the base image from a container image instead of Ubuntu’s, such asnode:24 or your team’s own (starting from a container image ).
• When the project has a devcontainer.json ,devvm sets up its VM from the file’s container image, ports, environment and commands (devcontainer.json ).

FAQ #

What does it run on?

devvm runs on macOS and on Linux, on arm64 or x86_64. It needs Lima, which runs the VMs with Apple’s Virtualization framework on macOS and QEMU on Linux (backends). Homebrew installs Lima along with devvm, and on Linux, Lima also needs QEMU and access to /dev/kvm. Installing lists every requirement, and known limits lists what Linux hosts lack, such as .git protection.

Does the agent run on my machine?

No. You start the agent in the VM’s shell, so it runs in the VM, and you never install it on your machine. There it sees only what the VM can reach.

Is it free?

Yes. devvm is open source under the MIT license.

Start coding in a sandbox #

Install devvm, then run devvm in any project folder.