Devbox vs Devenv: Nix Without the Pain

Your Dev Environment Is a Disaster and You Know It

You’ve got Node 18 pinned globally because one project refuses to die, Python 3.9 fighting Python 3.12 in a $PATH cage match, and a .tool-versions file that’s aspirational at best. You’ve heard Nix solves this. You’ve also heard Nix requires a philosophy degree and three weekends to understand.

Here’s the thing: you’re not wrong on either count. Nix is genuinely good at reproducible environments. It’s also genuinely painful to learn from scratch. The Nix language is its own beast, nixpkgs has ~100,000 packages but finding the right one feels like guessing, and flakes are the “modern” way except half the docs haven’t caught up.

That’s where Devbox and devenv come in. Both are tools that wrap Nix to give you reproducible per-project dev environments without forcing you to write Nix yourself. They’re different tools with different philosophies, and picking the wrong one means you’ll be fighting the abstraction layer instead of shipping code.

Let’s break them down.

What They Both Do (and Why That Matters)

Before getting into the differences, the shared pitch: both tools let you declare a set of packages and services for a project, and spin that environment up without polluting your global system or requiring Docker.

# The promise: this works the same on your laptop, your teammate's laptop, and CI
devbox shell   # or: devenv shell

No apt install, no Homebrew disasters, no “works on my machine.” The packages come from nixpkgs, which is enormous and reasonably up to date. Both tools isolate dependencies per-project. Both generate a lockfile. Neither requires you to know Nix to get started.

That’s where the similarity ends.

Devbox: Nix for People Who Just Want It to Work

Devbox is made by Jetify (formerly Jetpack.io). It’s been around since 2022 and has stabilized considerably. The pitch is brutally simple: “like Homebrew or apt, but per-project and reproducible.”

Getting Started

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

Devbox installs Nix under the hood if you don’t have it, manages the whole thing, and you never have to think about it. Then in your project:

cd my-project
devbox init
devbox add nodejs@20 postgresql@16 [email protected]
devbox shell

That’s it. You’re in a shell with those exact tools available. Your global system is untouched.

The config lives in devbox.json:

{
  "$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.13.1/.schema/devbox.schema.json",
  "packages": [
    "nodejs@20",
    "postgresql@16",
    "[email protected]"
  ],
  "shell": {
    "init_hook": [
      "echo 'Welcome to the project shell'"
    ],
    "scripts": {
      "start": "node server.js",
      "test": "pytest tests/"
    }
  }
}

It’s JSON. No Nix. No functional programming. No head-scratching. You search packages at search.nixhub.io (Jetify’s frontend), pick a version, add it. Done.

Services

Devbox can run background services too. PostgreSQL, Redis, MySQL — it wraps process-compose to manage them:

devbox add postgresql@16
devbox services start postgresql
devbox services ls

Services stop when you’re done, don’t interfere with each other across projects, and don’t require Docker. This is genuinely useful.

Devbox Generate

One killer feature: Devbox can generate a Dockerfile and a GitHub Actions workflow from your devbox.json. You define your environment once, it handles the rest.

devbox generate dockerfile
devbox generate github-workflow

The generated Dockerfile uses jetify-com/devbox as the base. Not everyone loves vendor lock-in on the container layer, but for hobby projects and small teams it’s handy.

What Devbox Is Not Great At

Devbox abstracts Nix away almost completely. That’s a feature, but it’s also a ceiling. You can’t configure nixpkgs overlays, you can’t pin to a specific nixpkgs commit easily, and you can’t access the full power of the Nix ecosystem. If you need a package that’s only available via a Nix flake or requires custom build options, you’ll hit a wall.

Also, devbox.json doesn’t support shell environment variables in a first-class way. You’d reach for .env files for that, which is fine but slightly incoherent when you’re trying to make everything declarative.

Devenv: Nix for People Who Want to Learn Nix (Eventually)

devenv is made by Cachix. It’s been around since early 2022 as well, but it leans into Nix more aggressively. The config is a Nix file. You write Nix modules. You’re expected to read docs. In exchange, you get the full power of the Nix ecosystem and a genuinely rich set of built-in options.

Getting Started

# Requires Nix with flakes enabled first
sh <(curl -L https://nixos.org/nix/install) --no-daemon
echo "experimental-features = nix-command flakes" >> ~/.config/nix/nix.conf

# Then install devenv
nix-env -iA devenv -f https://github.com/cachix/devenv/tarball/latest

Slightly more setup. Then in your project:

devenv init
devenv shell

This creates devenv.nix and devenv.yaml. The .nix file is where you live:

{ pkgs, ... }:

{
  packages = with pkgs; [
    nodejs_20
    python312
    postgresql_16
  ];

  languages.python = {
    enable = true;
    version = "3.12";
  };

  services.postgres = {
    enable = true;
    initialScript = ''
      CREATE DATABASE myapp;
      CREATE USER myuser WITH PASSWORD 'secret';
    '';
  };

  enterShell = ''
    echo "Dev environment ready"
    echo "Node: $(node --version)"
  '';
}

Yes, that’s Nix. No, it’s not that bad once you squint at it for ten minutes. It’s mostly attribute sets and strings. The module system means you’re not writing raw Nix expressions — you’re filling in options that devenv defines.

Language Integrations

This is where devenv pulls ahead hard. It has first-class language support for over 30 languages:

{ pkgs, ... }:

{
  languages.rust = {
    enable = true;
    channel = "stable";
  };

  languages.go = {
    enable = true;
    package = pkgs.go_1_22;
  };

  languages.python = {
    enable = true;
    poetry.enable = true;
  };

  languages.javascript = {
    enable = true;
    npm.enable = true;
  };
}

Enabling a language doesn’t just add the binary — it sets up the whole toolchain. Python gets a virtualenv. Rust gets the right linker flags. Go gets GOPATH sorted. This is the kind of glue code you’d normally write yourself in shell scripts and then forget about when onboarding someone six months later.

Services That Actually Work

devenv’s service support is more extensive than Devbox’s. PostgreSQL, MySQL, Redis, Elasticsearch, Kafka, RabbitMQ, Nginx, Caddy — all configurable in your .nix file:

{
  services.postgres = {
    enable = true;
    port = 5433;
    listen_addresses = "127.0.0.1";
  };

  services.redis = {
    enable = true;
    port = 6379;
  };
}

Run them with:

devenv up

This starts all services in the foreground using process-compose. Ctrl-C stops everything cleanly. It’s closer to a full docker compose up than what Devbox offers, without the Docker overhead.

Pre-commit Hooks Built In

devenv has first-class support for git pre-commit hooks via the pre-commit attribute:

{
  pre-commit.hooks = {
    nixfmt.enable = true;
    prettier.enable = true;
    eslint.enable = true;
    ruff.enable = true;
  };
}

Run devenv shell and the hooks are installed automatically. No separate pre-commit install step, no requirements-dev.txt to maintain. This is a legitimately good integration.

The Cost

devenv expects you to engage with Nix. The devenv.nix file is a Nix module, and when something goes wrong you’ll see Nix error messages. They’re better than they used to be, but they’re still Nix error messages. You’ll Google things like “infinite recursion encountered” and end up in a GitHub issue thread from 2021.

The documentation is solid but assumes you’re willing to read it. The devenv.sh site has a complete options reference, which you’ll need. Devbox’s simpler model means less to learn; devenv’s richer model means more to understand.

Head-to-Head: The Practical Stuff

Setup Friction

If you’re onboarding a team that has zero Nix exposure, Devbox wins this round.

Package Selection

Both use nixpkgs. Devbox uses nixhub.io for version search; devenv uses standard Nix package names (pkgs.nodejs_20 not nodejs@20). Devbox’s versioning is friendlier (nodejs@20, [email protected]). Devenv requires knowing the Nix attribute name, which is sometimes obvious and sometimes not.

# Devbox: search and add
devbox search ripgrep
devbox add ripgrep

# devenv: look up in nixpkgs, add to devenv.nix
# pkgs.ripgrep — happens to be obvious, but not always

Lockfiles

Both generate lockfiles. Devbox has devbox.lock. Devenv uses devenv.lock alongside flake inputs. Commit both. They work roughly the same way for reproducibility.

CI Integration

Devbox has a dead-simple GitHub Actions integration:

- name: Install devbox
  uses: jetify-com/[email protected]
  with:
    enable-cache: true

- name: Run tests
  run: devbox run test

devenv’s CI story involves Nix flakes and the cachix/install-nix-action. More setup, but more powerful — you get the full Nix binary cache ecosystem, and Cachix (devenv’s maker) provides free caching for open source projects.

Team Onboarding

Devbox: “Install devbox, run devbox shell.” Your team lead sends one Slack message and it works.

devenv: “Install Nix, enable flakes, install devenv, run devenv shell.” Someone will have a non-standard setup and you’ll spend 20 minutes debugging their /etc/nix/nix.conf. Not the end of the world, but it happens.

Which One Should You Actually Use?

Here’s the honest answer:

Use Devbox if:

• You want reproducible environments with zero Nix knowledge required
• Your team is polyglot (different language backgrounds, not all familiar with Nix)
• You’re primarily adding packages, not customizing build behavior
• You want the devbox generate dockerfile shortcut
• You just want it to work on a Tuesday afternoon without a deep dive

Use devenv if:

• You’re already comfortable with Nix or want to learn it properly
• You need rich language toolchain setup (Rust, Go, Python with Poetry, etc.)
• You want built-in pre-commit hooks without a separate config file
• You’re running multiple services locally and want them orchestrated in one place
• You’re on NixOS or manage a Nix-heavy infrastructure

The honest middle ground: Devbox gets you 80% of the benefit with 20% of the learning. devenv gets you to 95% of the benefit but the last 15% requires you to understand what you’re doing. If you’re just trying to stop the “it works on my machine” conversation, Devbox is the faster path. If you find yourself constantly hitting Devbox’s ceiling, devenv is where you’re headed anyway.

One more thing worth noting: neither tool locks you out of the other. You can start with Devbox today, and if six months from now you need richer Nix integration, migrating to devenv is annoying but not catastrophic. The package names change; the concepts don’t.

A Real-World Setup: Full-Stack Project

Here’s what a practical setup looks like for a Node + Python + PostgreSQL project in each tool.

Devbox:

{
  "$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.13.1/.schema/devbox.schema.json",
  "packages": [
    "[email protected]",
    "[email protected]",
    "postgresql@16",
    "[email protected]"
  ],
  "shell": {
    "init_hook": [
      "pip install -r requirements.txt --quiet",
      "npm install --silent"
    ],
    "scripts": {
      "dev": "node server.js & python worker.py",
      "test": "pytest && npm test"
    }
  }
}

devenv:

{ pkgs, ... }:

{
  packages = with pkgs; [ git curl ];

  languages.javascript = {
    enable = true;
    npm.enable = true;
  };

  languages.python = {
    enable = true;
    version = "3.12";
    pip.enable = true;
  };

  services.postgres = {
    enable = true;
    port = 5432;
    initialScript = ''
      CREATE DATABASE myapp;
    '';
  };

  services.redis = {
    enable = true;
    port = 6379;
  };

  pre-commit.hooks = {
    prettier.enable = true;
    ruff.enable = true;
  };

  enterShell = ''
    echo "Stack: Node $(node --version), Python $(python --version | cut -d' ' -f2)"
  '';
}

The devenv version is longer, but notice what you don’t have in init_hook: no pip install, because the Python language integration handles the virtualenv. No manual hook setup. That’s the trade-off in practice: more config upfront, less glue code scattered around.

Should You Bother?

Yes, with caveats.

Both tools are stable enough to use in production workflows as of mid-2026. nixpkgs is well-maintained and the Nix ecosystem has matured considerably. The days of Nix being a fringe academic project are behind us.

If you’re still using nvm, pyenv, rbenv, and a .tool-versions file to manage your environment, you’re doing unnecessary work. Pick one of these tools, spend an afternoon on it, and stop context-switching into version manager hell when you switch projects.

Devbox is the lower-commitment entry point. devenv is where you go when you want Nix to actually be a superpower instead of just a package manager with extra steps.

Either way: commit the config file, delete the “required: install X first” section from your README, and get back to the actual work.

Related Reading

• Atuin: Shell History That Actually Works Across Machines
• btop vs htop vs bottom: Top Replacements
• Carapace: Universal Shell Completions
• Difftastic: Structural Diff That Makes Sense
• fd vs find: Rust Speed vs POSIX Power