Install

curl -fsSL https://get.jetify.com/devbox | bash

# Or
brew install jetify-com/jetify/devbox

# Verify
devbox version

The installer also installs Nix if it's missing — with the multi-user daemon mode. On a fresh machine, takes a few minutes to bootstrap.

Initialize a project

cd my-project
devbox init

# Creates devbox.json:
# {
#   "packages": [],
#   "shell": { ... }
# }

Add packages

# Find a package
devbox search nodejs
# nodejs                  20.x, 22.x, ...
# nodejs_22@22.6.0
# bun, npm-check-updates, pnpm

# Add to the project
devbox add nodejs@22
devbox add python@3.13 postgresql@16 ripgrep fd bat

# devbox.json now lists those packages with pinned versions
# devbox.lock has the exact Nix store hashes

Commit both devbox.json and devbox.lock to Git. Every developer running devbox shell in the project gets exactly the same versions.

Enter the dev shell

devbox shell

# Inside the shell, the requested packages are on PATH
which node     # /nix/store/.../bin/node
node --version # v22.x.y

# Exit
exit

The host shell is unmodified outside the devbox. Different projects can require different Node versions; there's no global conflict.

Direnv integration: auto-enter on cd

# Install direnv (or use mise; see /tutorials/mise-polyglot-runtime-versions.html)
sudo apt install direnv
echo 'eval "$(direnv hook bash)"' >> ~/.bashrc

# Inside the project, generate the .envrc
devbox generate direnv
direnv allow

Now cd-ing into the project auto-activates the devbox shell; cd-ing out deactivates it. No explicit devbox shell needed.

Init hooks

devbox.json can declare commands to run when the shell starts:

{
  "packages": ["nodejs@22", "postgresql@16"],
  "shell": {
    "init_hook": [
      "echo 'Project shell activated.'",
      "[ -d node_modules ] || npm install"
    ]
  }
}

Useful for "install deps if missing," "set up the local Postgres data directory on first activation," "run a one-time codegen."

Scripts: like npm scripts but cross-language

{
  "packages": ["nodejs@22", "postgresql@16"],
  "shell": {
    "scripts": {
      "dev":       "npm run dev",
      "db-start":  "pg_ctl -D ./data start",
      "db-stop":   "pg_ctl -D ./data stop",
      "db-init":   "initdb -D ./data --auth=trust"
    }
  }
}
devbox run db-init     # initialize the local Postgres data dir
devbox run db-start    # start the local Postgres
devbox run dev         # run the app

Bundled services

For "give me a local Postgres + Redis + nats in this project" without docker-compose, devbox has process-management built in:

{
  "packages": ["postgresql@16", "redis@7", "nats-server@2"],
  "services": {
    "postgresql": {
      "command": "pg_ctl -D ./data -l postgres.log start",
      "is_daemon": true,
      "shutdown": "pg_ctl -D ./data stop"
    },
    "redis": {
      "command": "redis-server --port 6380"
    }
  }
}
devbox services up         # start all
devbox services down       # stop all
devbox services start postgresql
devbox services stop redis
devbox services attach     # tmux-style view of all services' logs

For projects where the dev environment really wants a local database + cache running, this beats docker-compose's overhead.

Cloud sync via devbox cloud

Jetify's optional service: identical dev environment in a remote VM, accessible via SSH or VS Code Remote. Same devbox.json; reproducibility carries to the cloud. Useful for heavy build envs that don't fit on a laptop.

devbox vs alternatives

  • mise (see that tutorial) — lighter; per-project runtime versions without the Nix backing. No system-level packages (postgres, ripgrep, etc.). For "just runtime versions," mise is simpler.
  • devenv.sh (Cachix) — same idea, more Nix-native. If your team is OK with Nix syntax, devenv.sh exposes more power; devbox is the more accessible default.
  • nix flakes directly — the most flexible; steepest learning curve. devbox is the JSON wrapper that gets 80% of the value without needing to write Nix.
  • Docker dev containers (VS Code Dev Containers, GitHub Codespaces) — container-based, OS-isolated. Heavier ops; useful when you specifically need OS-level isolation. devbox gives you per-project tooling without paying the container tax.
  • asdf (the older polyglot version manager) — predecessor of mise; less polished. Mise is the modern replacement.

When devbox isn't the right tool

  • For Windows-without-WSL hosts, devbox doesn't run (Nix on native Windows isn't a thing). Use mise or a container.
  • For projects where the only requirement is "Node X" and nothing else, mise has less overhead.
  • For deeply Nix-committed teams, plain flakes are more flexible.

For "I want my team's dev environments to be the same across Linux + macOS, without anyone needing to learn Nix," devbox is the right size in 2026.