8000 GitHub - cxz/devvm: One VM for every project. An isolated sandbox with your project’s toolchain, ready for you or a coding agent to start coding · GitHub
[go: up one dir, main page]

Skip to content
cxzPublic
forked from devvmhq/devvm

About

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

Resources

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

 
 

Latest commit

 

History

604 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

devvm

One VM for every project

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

Install · Read the docs · Staying safe

Install

On macOS, install devvm with Homebrew, which also installs Lima:

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

On Linux, install it with the install script, which also works on macOS and asks before it installs Lima, QEMU or access to /dev/kvm:

curl -fsSL https://github.com/devvmhq/devvm/releases/latest/download/install.sh | bash

Then run devvm doctor, which checks what devvm needs on your machine and says how to get anything that's missing.

Each release is signed with devvm's minisign key, RWSjzFsn7ETaijKJ2y7F4DtZobXmyv+LmdclJwZP/KmAkLUwOCzWF/2b, and Checking the install script shows how to check the script with it before you run it.

  • Requirements: macOS 13 or newer, or Linux, on arm64 or x86_64, with Lima 2.2 or newer (Lima's requirements).
  • Tested on Apple silicon Macs and on Linux on arm64 and x86_64, but not yet on Intel Macs.
  • Installing has the full list of requirements and the install script's options, and Upgrading and uninstalling covers what comes later.

Quick start

cd ~/some-project
devvm
  1. Go to your project. Open a terminal and cd into any project folder.
  2. Run devvm. It shows what this folder's new VM gets, with the toolchains your project's files call for. Confirm to make the VM, or customize it to choose its toolchains, coding agents, layers, network tier and size.
  3. Start your agent. devvm opens a shell in the VM, at the same path as on your machine, and its prompt starts with (devvm), so run claude there.
  • Running devvm in the folder again opens the same VM.
  • Your first VM has the rest.

Note

The first run starts with a few questions that set devvm's defaults for every new VM and its base image: the size and coding agents new VMs get, and the base image's optional extras. It builds the base image once, in a few minutes. Later VMs start in seconds.

Tip

Claude Code needs your Claude login before its first start, which devvm agent login claude makes from the VM and keeps on your machine (Claude Code's login).

What's supported

  • Toolchains: devvm detects them from the project's files, so a folder with package.json gets node (toolchains).
  • Coding agents: Claude Code, Codex and opencode run in the VM, with your settings, skills and MCP servers. devvm keeps their settings and logins in a store of its own, and devvm agent import copies them in from an agent you already use on your machine (coding agents).
  • Layers: the built-in docker, nix and desktop layers, and your own from devvm layer new (layers).
  • Backend: devvm runs its VMs on Lima (backends).

Why use devvm?

  • Isolated: each project folder gets a VM of its own, which mounts only the project folder, at the same path as on your machine (what a VM can reach).
  • Network tiers: new VMs get the allowlist tier by default, so they reach only the hosts you allow (network tiers).
  • Secrets stay home: on every tier, your secrets, such as your GitHub token and Claude Code token, stay on your machine.
  • Agents in the sandbox: you start the agent in the VM's shell, so you never install it on your machine.
  • Ready in seconds: every VM is a copy of a base image, and toolchains are shared read-only between VMs (images).
  • No sandbox closes every gap: a few habits close most of what devvm can't close on its own, so read Staying safe before you trust a VM with a project.

Working on a clone

By default, the VM mounts your project folder, so the VM and your editor share the same files. With devvm --clone, the VM gets a clone of the repo of its own, so nothing in it can touch your working tree or .git, and its work reaches your repo only when you fetch it:

devvm --clone                 # make the VM with its own clone, and open a shell in it
git fetch devvm               # later, on this machine, fetch the VM's work as devvm/<branch>
git log -p main..devvm/main   # review it before you merge it

Working on a clone has the details.

Docs

The docs are at devvm.dev, and their source is in docs/.

  • Getting started: installing devvm, your first VM and the commands you use most.
  • Using devvm: images and tools, clones, links between VMs, ports and size, coding agents, SSH and editors, and troubleshooting.
  • Staying safe: the habits that keep you safe, network tiers, .git protection and attack vectors.
  • Backends: Lima, which runs the VMs, and what it gives them.
  • CLI reference: every command, with its arguments and flags.
  • How it works: how devvm does what it does, for checking a claim or reviewing its security.
  • Contributing: building, testing and writing docs.

Security and contributing

License

MIT

About

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

Resources

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages

0