Ditch dev containers, switch to Devbox

You add a dev container to your project. Build takes 10 minutes. You change one dependency. Rebuild. Another 10 minutes. Your disk fills up with layers. Your filesystem is slow because everything goes through Docker mounts

A teammate can’t run it because their Docker daemon crashed. Someone else can’t access their SSH keys because they’re outside the container. You spend 2 hours debugging volume mounts

Devbox gives you isolated environments in seconds. No containers. No builds. No mounts. Your tools are there when you cd into the project

Dev containers are expensive overhead

I’ve watched teams waste hours on dev container issues

The container won’t build because a base image changed. The volume mount is slow so tests take 3x longer. You can’t access your dotfiles without copying them in. Your Git config doesn’t work because it’s on the host

Every team member needs the same Docker version. The same settings. The same mounts configured. Miss one detail and things break differently for them

Then someone updates the Dockerfile. Everyone rebuilds. 15 minutes each. That’s the whole team blocked

Oh, and if you use IntelliJ? Dev containers require an Ultimate subscription. VS Code gets it free. JetBrains charges $169/year for the privilege of using a dev container. That’s $169 to make your IDE slower

The fundamental problem: dev containers enforce an arbitrary environment defined imperatively in a Dockerfile. You have to build it, launch it, wait. Sometimes it fails halfway through

What Devbox does differently

Devbox creates isolated shells using Nix packages. No virtualization. No container runtime. Just a shell with your tools

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

# In your project
devbox init
devbox add go@1.21 nodejs@20 postgresql@15
devbox shell

You get a shell with Go 1.21, Node 20, and Postgres 15. Isolated from your system. Same versions for everyone

The config is 10 lines:

{
  'packages': [
    'go@1.21',
    'nodejs@20',
    'postgresql@15'
  ],
  'shell': {
    'init_hook': [
      'echo 'Dev environment ready''
    ]
  }
}

No Dockerfile. No build step. No image layers. Nix downloads the exact packages you need and puts them in your PATH

It’s automatic with direnv

Add a .envrc file:

eval '$(devbox generate direnv)'

Run direnv allow. Now when you cd into the project, your shell automatically loads the right tools

cd ~/project
# Environment loaded automatically
go version  # 1.21
node --version  # 20

cd ~/other-project
# Different environment
go version  # 1.20 (or not installed)

No devbox shell command. No activation. Just cd and your tools are there

Combined with shell hooks, you can auto-start services:

{
  'packages': ['postgresql@15', 'redis@7'],
  'shell': {
    'init_hook': [
      'pg_ctl start -D .devbox/postgres',
      'redis-server --daemonize yes'
    ]
  }
}

Services start when you enter the directory. Stop when you leave. Completely automatic

No container means no container problems

Your filesystem is your filesystem

No mounts. No volume drivers. No permission issues. Your editor sees the real files. Your tools run at native speed

Your configs work

Git uses your .gitconfig. SSH uses your keys. Your shell history persists. Your aliases work. Everything’s normal

No builds

Change a dependency? Add it to devbox.json. Run devbox shell. It downloads in seconds. No rebuilding a 2GB image

Reproducible without the pain

Nix pins exact package versions. Your teammate runs devbox shell and gets identical tools. No ‘works on my machine’

A client had a Django app in a dev container. Building took 12 minutes. Docker Desktop used 8GB RAM. Half the team disabled it to save battery

Switched to Devbox. Same Python version, same Postgres, same Redis. Load time: 3 seconds. RAM: normal system usage. Everyone’s battery life improved

When you still need containers

Devbox isn’t for running your app in production. It’s for development

For deployment, Devbox can generate Dockerfiles:

devbox generate dockerfile

Creates a minimal container with your exact dependencies. Build it once for deployment

Use Devbox locally. Fast, native, no overhead. Build containers for production when you need them

Devbox works with everything you have

Already using Docker Compose for databases? Keep it:

{
  'packages': ['nodejs@20', 'python@3.11'],
  'shell': {
    'init_hook': ['docker-compose up -d']
  }
}

Your app runs natively with Devbox tools. Databases run in Compose. Best of both

Need the exact dev container spec for CI? Devbox generates that too:

devbox generate devcontainer

Creates a .devcontainer folder. VS Code users who want containers can use it. Everyone else uses Devbox

Getting started

Install Devbox:

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

In your project:

devbox init
devbox add python@3.11 nodejs@20
devbox shell

You’re in an isolated shell. Python 3.11 and Node 20 available. Exit and they’re gone from your PATH

Add direnv for automatic activation:

devbox generate direnv > .envrc
direnv allow

Now just cd into the project. Tools load automatically

Your team clones the repo, runs devbox shell. They get the same environment. No Docker. No build wait. No troubleshooting mounts

Dev containers solve the wrong problem. They containerize the environment when you just need consistent tools. Devbox gives you consistent tools without the container tax

Your laptop stays fast. Your filesystem stays normal. Your tools load in seconds. That’s how dev environments should work