AWS Cloud9
Cloud IDE to write, run, and debug code in the browser
Devbox
Create instant, isolated, reproducible development shells with a single command
Devbox lets you define OS‑level packages in a devbox.json file and spin up isolated, reproducible shells instantly, avoiding version conflicts and keeping your laptop clean.
Overview
Overview
Devbox is a command‑line tool that creates isolated development shells based on a devbox.json manifest. By listing the required OS‑level packages—drawn from the Nix Package Registry with over 400 k versions—developers can spin up a deterministic environment with a single devbox shell command. The shell runs directly on the host machine, avoiding the overhead of virtual machines while keeping the installed tools separate from the rest of the system.
How it works
When you run devbox init a manifest is generated and committed to source control. Adding packages (e.g., devbox add python@3.10) updates the manifest, and the next devbox shell resolves the exact versions and builds an isolated environment. The same definition can be exported as a VS Code devcontainer, a Dockerfile, or a cloud‑ready environment, ensuring that development, testing, and production use identical toolchains.
Highlights
OS‑level package management via Nix registry (400k+ versions)
Instant isolated shells without VM overhead
Portable definitions usable as devcontainer, Dockerfile, or cloud env
Deterministic environments shared via devbox.json
Pros
- Ensures identical toolchains across team members
- No system pollution; easy to add or remove tools
- Fast environment creation on local machine
- Seamless export to containers or remote development environments
Considerations
- Relies on Nix ecosystem, which may have a learning curve
- Initial setup requires curl script and Nix installation
- Limited to packages available in the Nix registry
- Performance may vary on non‑Linux platforms
Managed products teams compare with
When teams consider Devbox, these hosted platforms usually appear on the same shortlist.
Looking for a hosted option? These are the services engineering teams benchmark against before choosing open source.
Fit guide
Great for
- Teams needing reproducible dev environments across diverse OSes
- Developers experimenting with new language versions without affecting host
- Projects that ship containers built from the same toolchain used in development
- Remote or cloud development workflows that require environment parity
Not ideal when
- Users unfamiliar with Nix and unwilling to adopt its concepts
- Projects that depend on proprietary binaries not in Nix
- Environments requiring heavy GUI applications not supported in headless shells
- Teams that prefer heavyweight VM‑based isolation
How teams use it
Onboard new developers quickly
They run `devbox shell` and get the exact same tool versions as the rest of the team, eliminating setup friction.
Test multiple language versions
Spin up separate shells with Python 3.9, 3.10, or Go 1.17, 1.18 to verify compatibility without global installs.
Build production Docker images
Generate a Dockerfile from the devbox definition, ensuring the container uses identical binaries as the development shell.
Remote cloud development
Launch a cloud VM that mirrors the local devbox environment, providing seamless transition from local to remote work.
Tech snapshot
Go96%
TypeScript2%
Nix1%
Shell1%
Dockerfile1%
HTML1%
Frequently asked questions
How does Devbox differ from using Nix directly?
Devbox provides a simplified CLI and JSON manifest that abstracts Nix commands, making OS‑level package management approachable while still leveraging Nix under the hood.
Do I need Docker to use Devbox?
No. Devbox creates isolated shells locally without containers; Docker is only needed if you export the environment as a Dockerfile.
Can I share the devbox.json with my team?
Yes. Commit the file to source control; any teammate can run `devbox shell` to reproduce the same environment.
What platforms are supported?
Devbox runs on macOS and Linux where Nix is available; Windows support is limited to WSL2.
How are updates to packages handled?
Run `devbox add <package>@<version>` or edit devbox.json; Devbox will fetch the specified version from the Nix registry on the next `devbox shell`.
Project at a glance
Active- Stars
- 11,170
- Watchers
- 11,170
- Forks
- 291
LicenseApache-2.0
Repo age3 years old
Last commit3 days ago
Primary languageGo
Last synced yesterday