Dev Environment Kamu Rusak Lagi?
Kamu pasti pernah ngalamin ini: clone repo baru, ikutin README, terus terminal muntah error karena versi Node-nya beda. Atau lebih parah — kamu update Python buat satu project, eh project lain langsung ancur.
Solusi klasiknya? Docker. Tapi Docker buat dev environment itu berat. Image harus di-build, volume mount lambat di Mac, dan kalau kamu solo engineer yang kerja di beberapa project sekaligus, context switch-nya nyiksa.
Ada alternatif yang lebih ringan: Devbox. Bukan Docker, bukan VM. Devbox bikin isolated shell per project menggunakan Nix di balik layar — tapi kamu nggak perlu ngerti Nix sama sekali.
Artikel ini bakal ngajarin kamu setup Devbox dari nol, buat dev environment yang reproducible, dan integrasi dengan direnv supaya environment-nya auto-aktif tiap masuk folder project.
Apa Itu Devbox dan Kenapa Bukan Docker?
Devbox adalah CLI tool dari Jetpack.io. Cara kerjanya: tiap project punya file devbox.json yang mendefinisikan tools apa yang dibutuhkan — Node versi berapa, Python versi berapa, PostgreSQL, Redis, apapun. Waktu kamu jalankan devbox shell, kamu masuk ke isolated shell yang punya tools itu, dan keluar dari shell, tools-nya hilang dari PATH.
Bedanya sama Docker:
- Nggak ada container overhead — prosesnya jalan langsung di OS kamu, bukan di dalam container
- Cold start jauh lebih cepat — masuk shell butuh detik, bukan menit
- Nggak perlu Dockerfile — satu file JSON cukup
- Binary-nya native — performa sama kayak install langsung
Kekurangannya? Kalau kamu butuh isolasi OS-level (misal: test di Ubuntu sementara kamu pakai Mac), tetap butuh Docker atau VM. Devbox bukan pengganti Docker buat production deployment — ini murni buat dev environment.
Install Devbox
Install-nya satu command:
curl -fsSL https://get.jetpack.io/devbox | bash
Script ini akan install Nix dulu kalau belum ada, terus install Devbox di atasnya. Di Mac, kamu mungkin diminta approve beberapa hal di System Settings karena Nix butuh volume terpisah.
Verifikasi:
devbox version
# Output: 0.10.x atau lebih baru
Gotcha pertama: Di Ubuntu/Debian dengan systemd, installer Nix kadang gagal karena konflik dengan /etc/profile.d. Kalau kamu kena ini, coba install Nix dulu secara manual dengan flag --daemon, baru install Devbox:
sh <(curl -L https://nixos.org/nix/install) --daemon
# Restart terminal, baru:
curl -fsSL https://get.jetpack.io/devbox | bash
Setup Project Pertama
Misal kamu lagi bikin REST API dengan Node.js 20 dan butuh Redis buat caching. Tanpa Devbox, kamu harus install Node 20 (sambil jaga-jaga Node versi lain nggak kelobak), install Redis, dan doain semua itu nggak konflik sama project lain.
Dengan Devbox:
mkdir my-api && cd my-api
devbox init
Ini bikin file devbox.json kosong. Sekarang tambah packages:
devbox add nodejs@20 redis
Lihat isi devbox.json sekarang:
{
"$schema": "https://raw.githubusercontent.com/jetpack-io/devbox/0.10.0/.schema/devbox.schema.json",
"packages": [
"nodejs@20",
"redis"
],
"shell": {
"init_hook": [],
"scripts": {}
}
}
Masuk ke dev shell:
devbox shell
Cek versi:
node --version
# v20.x.x
redis-server --version
# Redis server v=7.x.x
Keluar dari shell dengan exit, dan node balik ke versi global kamu (atau nggak ada kalau memang belum install global).
Tambah Scripts dan Services
Devbox punya fitur scripts — kayak npm scripts tapi buat environment kamu, dan services buat jalankan background process.
Edit devbox.json:
{
"packages": [
"nodejs@20",
"redis"
],
"shell": {
"init_hook": [
"echo 'Dev environment ready. Run: devbox services start'"
],
"scripts": {
"dev": "node server.js",
"test": "node --test"
}
},
"services": {
"redis": {
"command": "redis-server --port 6379"
}
}
}
Sekarang kamu bisa:
# Jalankan Redis di background
devbox services start redis
# Cek status services
devbox services ls
# Jalankan script
devbox run dev
Services di Devbox dikelola oleh process-compose — semua log-nya agregat di satu tempat, dan mati otomatis waktu kamu exit dari shell.
Gotcha kedua: devbox services butuh kamu sudah di dalam devbox shell. Kalau kamu coba jalankan dari shell biasa, bakal error. Solusinya: pakai devbox run yang otomatis masuk ke environment dulu sebelum jalankan command:
# Ini jalan dari shell biasa sekalipun:
devbox run dev
Integrasi direnv: Auto-Aktif Tanpa devbox shell
Masuk ke devbox shell tiap kali mau kerja itu lumayan ganggu. Solusinya: integrasi dengan direnv, supaya environment-nya auto-aktif waktu kamu cd ke folder project.
Install direnv:
# Mac
brew install direnv
# Ubuntu/Debian
apt install direnv
Tambah hook ke shell config kamu. Untuk bash (~/.bashrc), zsh (~/.zshrc), atau fish (~/.config/fish/config.fish):
# Untuk bash/zsh:
eval "$(direnv hook bash)"
# atau
eval "$(direnv hook zsh)"
Sekarang generate .envrc untuk project kamu:
cd my-api
devbox generate direnv --print-script > .envrc
direnv allow .
Sekarang tiap kamu cd my-api, tools dari Devbox langsung masuk ke PATH. Keluar dari folder, hilang lagi. Nggak perlu devbox shell manual.
Lihat isi .envrc yang di-generate:
watch_file devbox.json
if command -v devbox &>/dev/null; then
eval "$(devbox generate direnv --print-script)"
fi
Sederhana — tiap .envrc di-evaluate, dia minta Devbox generate environment variables dan PATH yang tepat.
Gotcha ketiga: Kalau kamu commit .envrc ke Git, teammate yang belum install Devbox bakal kena error waktu cd ke folder. Tambah ke .gitignore kalau tim kamu belum semua pakai Devbox, atau edukasi mereka dulu. Untuk solo project, aman di-commit.
Contoh Nyata: Python Project dengan PostgreSQL
Buat gambaran lebih konkret, ini setup lengkap untuk project Django dengan PostgreSQL:
mkdir django-app && cd django-app
devbox init
devbox add python@3.11 postgresql_15
Edit devbox.json:
{
"packages": [
"python@3.11",
"postgresql_15"
],
"env": {
"DATABASE_URL": "postgresql://postgres:postgres@localhost:5432/devdb",
"PGDATA": "$PWD/.devbox/pgdata"
},
"shell": {
"init_hook": [
"pip install -r requirements.txt --quiet 2>/dev/null || true"
],
"scripts": {
"db:init": "initdb -D $PGDATA && echo 'PostgreSQL initialized'",
"db:start": "pg_ctl -D $PGDATA -l $PWD/.devbox/postgres.log start",
"db:stop": "pg_ctl -D $PGDATA stop",
"db:create": "createdb devdb",
"dev": "python manage.py runserver",
"migrate": "python manage.py migrate"
}
}
}
First-time setup:
devbox shell
devbox run db:init
devbox run db:start
devbox run db:create
devbox run migrate
devbox run dev
Next time? Tinggal:
cd django-app # direnv auto-aktif environment
devbox run db:start
devbox run dev
Data PostgreSQL tersimpan di .devbox/pgdata — folder-nya project-spesifik, nggak campur sama PostgreSQL global. Tambah .devbox/pgdata ke .gitignore.
Bagikan Environment ke Tim (atau Diri Sendiri di Laptop Baru)
Ini bagian yang paling gue suka dari Devbox. Commit devbox.json ke repo:
git add devbox.json devbox.lock
git commit -m "chore: add devbox environment"
File devbox.lock menyimpan hash exact dari setiap package — jadi kalau kamu atau teammate pull repo ini 6 bulan lagi, dapat versi yang sama persis. Bukan "Node 20" yang bisa berubah, tapi Node 20.11.0 yang di-pin ke Nix hash tertentu.
Di laptop baru atau CI:
git clone <repo>
cd <repo>
devbox shell # otomatis download semua packages
Untuk GitHub Actions, ada official action:
# .github/workflows/test.yml
name: Test
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: jetpack-io/devbox-install-action@v0.11
- run: devbox run test
CI environment-nya identik sama dev environment lokal kamu. Nggak ada lagi "works on my machine".
Yang Gue Lakuin Sekarang
Semua project gue sekarang punya devbox.json. Setup awalnya mungkin 10 menit lebih lama dari install manual, tapi investasi itu balik modal waktu pertama kali gue ganti laptop dan tinggal git clone + devbox shell — selesai.
Beberapa hal yang bisa kamu lakuin selanjutnya:
- Cari packages yang tersedia di search.nixos.org — hampir semua dev tool ada di sana
- Setup
devbox generate dockerfilekalau kamu butuh Dockerfile dari environment yang sama - Integrasi dengan VS Code — install extension "Devbox" supaya terminal di VS Code otomatis pakai devbox shell
- Coba
devbox globalbuat install tools global (kayakjq,gh,fzf) yang tetap isolated dari package manager sistem
Devbox bukan solusi sempurna — kalau project kamu butuh kernel-level stuff atau cross-platform testing yang ketat, Docker tetap lebih tepat. Tapi buat 90% kasus solo dev atau small team, Devbox jauh lebih ringan dan reproducible dibanding setup manual yang rawan error.
Coba di satu project dulu. Kalau cocok, kamu bakal ngerti kenapa gue nggak mau balik ke cara lama.