# Devbox: Nix-Powered Isolated Dev Shells Without Virtual Machines

> Devbox is a CLI tool by Jetify that creates isolated, reproducible development environments by wrapping Nix, giving teams a simple package-manager-style interface to over 400,000 versioned OS packages. It requires no virtual machine and exports to a devcontainer or Dockerfile when you are ready to ship.

**jetify-com/devbox** — Instant, easy, and predictable development environments

- Repository: https://github.com/jetify-com/devbox
- Website: https://www.jetify.com/devbox/
- Stars: 12,378 · Forks: 358
- Language: Go
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/jetify-com-devbox

## Isolated Dev Shells Without Virtual Machines

Managing tool versions across projects is a common friction point. A project that requires Python 3.10 conflicts with another that requires Python 3.12, and installing both on the same machine through brew or apt-get typically means manual switching. Devbox addresses this by creating an isolated shell for each project, where the tools are available only inside that shell.

The isolation does not rely on a virtual machine or a Docker container. Devbox operates directly on the host file system and processes, so there is no filesystem virtualization overhead and no container daemon to manage. The README describes it as working similarly to a package manager like yarn, but operating at the operating-system level rather than the language level.

The target user is a developer or team that works across multiple projects with different version requirements, or someone who wants to try a tool without permanently installing it on the host machine. The README gives a specific example: a development environment with Python 3.10 and Go 1.18 available in the shell even when those versions are not installed on the underlying machine. The project is written in Go, licensed under Apache 2.0, and maintained by Jetify. The last push to the repository was on 28 September 2026, with version 0.18.4 released three days earlier.

## How Nix Provides the Isolation

Devbox is internally powered by Nix, the functional package manager and build system. The README acknowledges this directly: Nix provides the isolated shells, while Devbox provides a simpler interface to them.

Nix stores packages in an immutable directory, and each package version occupies its own path. Two projects can use different versions of the same binary without conflict because each binary lives at a separate path and is only placed on the PATH inside the shell that requested it. This design is what lets Devbox guarantee that each project's environment is deterministic: the same devbox.json on two machines produces the same set of binaries.

The interface Devbox exposes does not require learning the Nix language or writing Nix expressions. You declare packages by name and version using a short syntax, run one command to enter the shell, and Nix handles the resolution and caching. Packages are drawn from the Nix Package Registry, where the README states over 400,000 package versions are available via nixhub.io.

This design choice has a trade-off: Nix must be present on the machine. The Devbox install script handles this dependency, but teams running in constrained environments where software installation requires approval must account for the Nix layer, not just Devbox itself.

## Installing Devbox and Starting Your First Shell

The README provides one install command:

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

After installation, create a new directory, move into it, and initialise a Devbox configuration:

```bash
devbox init
```

This writes a `devbox.json` file in the current directory. The README recommends committing this file to source control. Add a package by name and version:

```bash
devbox add python@3.10
```

Search for available packages and their pinnable versions at nixhub.io. After adding a package, the `devbox.json` records it:

```json
{
  "packages": [
    "python@3.10"
  ]
}
```

Enter the shell:

```bash
devbox shell
```

The README notes that the shell prompt changes to indicate you are inside a Devbox shell rather than the regular terminal. Verify the package is available:

```bash
python --version
```

Regular tools and environment variables from the host, such as git configuration, remain accessible inside the Devbox shell:

```bash
git config --get user.name
```

Exit the Devbox shell and return to the regular terminal with:

```bash
exit
```

Commands can also be run directly without entering an interactive shell: `devbox run` executes a command in the Devbox environment and exits. The full list of available commands is in the CLI reference at the Devbox documentation site.

## The devbox.json File and Version Pinning

The `devbox.json` file is the single source of truth for a project's development environment. It lists the packages and their pinned versions. Because Nix stores packages by version, the same file on two machines with the same architecture produces identical tool versions, without a separate lock file for each dependency.

The version syntax uses an `@` separator: `python@3.10`, `go@1.18`. Packages without a version specifier resolve to the default version in the registry. The README's quickstart shows a minimal file with a single package, but teams running a full backend stack can add databases, runtimes, and build tools in the same list.

Environment variables and init hooks are additional fields the devbox.json supports according to the repository's structure, though the README focuses on the package declaration. The go.mod file shows the project uses `github.com/joho/godotenv` for .env parsing, which points to environment variable support in the tool.

The file should go into source control alongside application code. A new team member clones the repository, runs `devbox shell`, and gets the same versions of every tool without reading a setup guide.

## Exporting to devcontainer and Dockerfile

Devbox can translate the devbox.json environment into formats that other tools understand. The README lists three export targets: a devcontainer for use with VS Code, a Dockerfile for building a production image, and a remote development environment in the cloud.

The devcontainer export lets VS Code's Remote Containers extension open the project inside a container that matches the local Devbox shell, which helps teams where some members prefer an IDE-integrated workflow while others prefer the terminal. The Dockerfile export produces an image that uses the same tool versions as the development shell, reducing the difference between what developers run locally and what runs in CI or production.

The README describes these exports as using the same single definition. The practical benefit is that the devbox.json becomes the canonical environment declaration: you write it once for local development and derive the container and remote environment from it, rather than maintaining a separate Dockerfile and a separate devcontainer.json.

The repository's `examples/` directory contains subdirectories for cloud development, data science, databases, servers, and stacks, which shows the range of configurations the team uses to test the tool.

## Where Devbox Falls Short

Devbox operates on Linux and macOS because Nix runs on those platforms. The search data shows demand for Windows installation, but the README does not document a Windows-native path. Users on Windows need to verify the current state of Windows support in the official documentation before committing to the tool.

The Nix dependency is both the source of Devbox's reliability and a constraint on adoption. Organisations that lock down which software can be installed, or that run build agents where Nix is not present, must treat Nix itself as a prerequisite to approve. The Devbox install script handles this automatically in permissive environments, but not everywhere.

Devbox creates isolated dev shells, not isolated network environments or filesystems. A process running inside a Devbox shell has access to the host network and the host filesystem by default. Teams that need network isolation or a fully sandboxed build environment need a container or VM approach instead.

The tool does not manage application dependencies at the language level. npm packages, pip packages, or Go modules are not handled by devbox.json; those dependency managers run inside the Devbox shell, still governed by their own lock files. Devbox manages the OS-level tools, not the libraries those tools operate on.

## Devbox Compared to Docker Dev Containers and Bare Nix

The closest alternative for reproducible dev environments is a Docker-based approach, either through docker-compose or VS Code Dev Containers. Docker containers give stronger isolation: separate filesystem, separate network namespace, and a clean process tree. The trade-off is overhead: Docker requires a container daemon, and file I/O between the container and the host is slower than native access. Devbox runs on the host directly, so there is no filesystem indirection.

Bare Nix provides the same isolation mechanism as Devbox but requires writing Nix expressions and understanding the Nix derivation model. The README positions Devbox as a simpler interface to Nix. The nix shell and nix develop commands from the Nix project serve a similar purpose but with a steeper learning curve. Devbox hides the Nix language behind a JSON configuration and a familiar CLI.

The portability exports in Devbox give it an advantage for teams that need both local development and containerized CI: the same devbox.json drives both without maintaining two separate environment definitions. A pure Docker workflow typically requires a Dockerfile for CI and a devcontainer.json for local development, and keeping them in sync is manual.

## Conclusion

Devbox suits teams who manage several projects with conflicting tool versions and want an approach lighter than Docker containers. The tool installs in one curl command and the devbox.json file can go straight into source control. Anyone who needs a Windows-native installation path should check the official docs first: the README does not address Windows-native setups. The Apache 2.0 licence places no restrictions on commercial use.

## FAQ

### What is Devbox?

Devbox is a CLI tool by Jetify that creates isolated development shells using Nix as its underlying package manager. You define the OS-level tools your project needs in a devbox.json file, run devbox shell, and get an environment with those exact tool versions, without installing them permanently on your machine.

### What does Devbox do?

Devbox creates per-project isolated shells with specific versions of OS tools like Python, Go, or Node, drawn from over 400,000 package versions in the Nix Package Registry. It also exports those environments to a devcontainer or Dockerfile for use in CI or cloud development.

### How do I install Devbox?

Run the install script with curl -fsSL https://get.jetify.com/devbox | bash. The script installs Devbox and the Nix dependency it relies on. After installation, run devbox init in any project directory to create the devbox.json configuration file.

### How do I use Devbox?

Run devbox init to create devbox.json, then devbox add to specify packages such as python@3.10, and finally devbox shell to enter the isolated environment. Run devbox run to execute a single command inside the environment without starting an interactive shell.

### What is the devbox.json file?

devbox.json is the configuration file Devbox creates when you run devbox init. It records the list of OS-level packages and their versions that make up the project's development environment. The README recommends committing it to source control so every team member gets the same tools.

## Sources

- [jetify-com/devbox on GitHub](https://github.com/jetify-com/devbox)
- [License: Apache-2.0](https://github.com/jetify-com/devbox/blob/main/LICENSE)
- [Project website](https://www.jetify.com/devbox/)
- [README](https://github.com/jetify-com/devbox/blob/main/README.md)
- [Releases](https://github.com/jetify-com/devbox/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jetify-com-devbox