Devboxとは？Nixで開発環境を再現する使い方とインストール手順【0.18.4対応】

Devboxは、パッケージマネージャNixを裏側で動かし、devbox.jsonとdevbox.lockの2ファイルでプロジェクトごとの開発環境を再現するオープンソースのCLIです。開発元はJetify（旧Jetpack）で、ライセンスはApache 2.0。Nixの言語を書かずに、devbox add nodejs@22のようなコマンドだけでNode.jsやPostgreSQLの版をチームで揃えられます。

名前が似ているMicrosoft Dev Box（Azureのクラウド開発PCサービス）とは別の製品です。この記事では、2026年10月25日時点の最新安定版0.18.4を公式Dockerイメージで動かした結果をもとに、仕組み・インストール・基本操作・0.18.0で消えた機能・他ツールとの使い分けを整理します。

まとめ：Devboxの要点

• 仕組み：パッケージ本体はNixの/nix/storeに入り、プロジェクトの.devbox/nix/profileから参照される。コンテナは使わない。
• 再現性：devbox.lockにNixpkgsのコミットとOS・CPU別のstore pathが記録される。別のコンテナでdevbox installしても、Node.js v22.23.3・Python 3.12.15が同じ版で入り、lockのハッシュも変わらなかった。
• 導入：curl -fsSL https://get.jetify.com/devbox | bashの1行。Nixが無ければ最初のコマンド実行時に自動で入る。WindowsはWSL2上で同じ手順。
• 最新の変更：0.18.0（2026年8月16日）でJetify Cloud機能を削除。devbox cache・devbox secrets・devbox authは使えない。
• 向き不向き：Nixを書けるのが一部の人だけのチームに向く。本番まで同じイメージで運ぶならDocker、ランタイムの版切り替えだけならmiseで足りる。

以下、仕組みから順に、実際のコマンド出力を添えて説明します。

DevboxとNixの関係：パッケージが置かれる場所

DevboxとNixの関係は、役割の分担で整理できます。Devboxは検索サービスを使ってパッケージ名と版をNixpkgsのコミットへ解決し（0.18.4から既定の検索先はwww.nixsearch.com）、取得・ビルド・格納はNixが担います。その上でDevboxはdevbox.jsonの管理とシェルの環境変数づくりを受け持ちます。Devbox独自のパッケージ形式は無く、通常のパッケージ検索ではNixpkgsを利用します。Nix flakeを指定すれば、独自パッケージや上書きしたパッケージも追加できます。Nixpkgs自体の構造はNixpkgsとは？Nixとの関係・パッケージの探し方とinstall・flake.nixでの使い方で詳しく扱っています。

/nix/store と .devbox/nix/profile の実体

0.18.4でdevbox add nodejs@22を実行し、nodeの場所をたどると次のようになりました。

$ devbox run -- which node
/home/devbox/proj/.devbox/nix/profile/default/bin/node
$ readlink -f /home/devbox/proj/.devbox/nix/profile/default/bin/node
/nix/store/y11g9g1pmig70hhb4ryfl0j0w0q1q35q-nodejs-slim-22.23.3/bin/node

プロジェクト側にあるのはシンボリックリンクだけで、実体はハッシュ付きのディレクトリとして/nix/storeに置かれます。同じNixストア内で同じstore pathを参照するプロジェクト間では、パッケージの実体を共有します。同じ版番号でも依存関係やビルド条件が異なれば、別のstore pathになります。devbox shellに入るとこのprofileがPATHの先頭に入り、exitで抜ければ元のPATHに戻ります。.devboxディレクトリには中身が*と.*だけの.gitignoreが自動で置かれるため、自分で除外設定を書かなくてもGitには入りません。

Nix単体・devenvとの違い

同じことはshell.nixとnix-shell、またはflakeとnix developでもできます。違いは設定の書き方です。Nix単体やdevenv（設定はdevenv.nix）はNix言語で書くのに対し、DevboxはJSONとCLIで完結します。加えて、スクリプト実行（devbox run）、process-composeによるサービス起動、Dockerfileやdevcontainer.jsonの生成といった開発向けの機能を持ちます。

判断は単純で、チーム全員がNix言語を書けるならdevenvや素のflakeのほうが制約が少なく、書けない人が混じるならDevboxが合います。逆に、OS全体の構成までNixで管理したいNixOS的な使い方では、Devboxのラッパーは遠回りになります。

Devboxのインストール：macOS・Linux・WSL2

Devbox本体はGoで書かれた単一のバイナリで、Nixは後から自動で入ります。公式のインストール手順は、非rootユーザーで次の1行を実行する方法です。

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

Nixの自動インストール：権限と取得先

Nixが入っていない状態でdevbox addなどを実行すると、「Nix is not installed. Devbox will attempt to install it.」と表示され、Enterで続行するとsudoのパスワードを求められます。公式ドキュメントは、LinuxとWSL2ではシングルユーザー、macOSではマルチユーザーの構成でNixを入れると説明しています。

取得するインストーラは版によって違います。0.16系まではDeterminate Systemsのインストーラでしたが、2025年9月16日のコミット「change builtin installer to upstream nix experimental」（nix/install.go）により、0.17.0以降はartifacts.nixos.orgで配布されるNix公式の実験版インストーラを取得します。systemdの無いLinux（コンテナなど）では--init noneを付けて実行します。nix-installerのREADMEによれば、この構成でNixを使えるのはrootかsudoできるユーザーに限られます。Nixを自分で先に入れたい場合、公式ドキュメントは引き続きDeterminate Nix Installerを推奨しています。

Nix flakeでの導入と版の固定

Nixに慣れているならnix profile install github:jetify-com/devbox/latestでも入ります。版を指定する書き方は0.13.2以降で使えます。Nixpkgs版のnixpkgs#devboxもありますが、Nixpkgs側の更新を待つため新版の反映が遅れます。公式ドキュメントが案内する導入方法は、インストールスクリプト・Nixpkgs・Nix flakeの3つです。

スクリプトで導入した本体の更新はdevbox version updateです。Nix経由で導入した場合は、導入方式に応じてNixのプロファイルや構成定義を更新します。チームで版を揃えたいときは環境変数DEVBOX_USE_VERSIONに版番号を設定すると、新しい版が入っていても指定した版で動きます（公式FAQの例はexport DEVBOX_USE_VERSION=0.8.0）。この環境変数による切り替えはランチャー経由の導入が対象で、Nix経由の導入ではプロファイルやNixの構成定義で版を固定します。0.18.0のような破壊的変更を含む版が出る製品なので、CIでは固定しておくのが安全です。

Windows（WSL2）での導入

WindowsネイティブではNixもDevboxも動きません。管理者権限のPowerShellでwsl --installを実行してUbuntuを入れ、そのシェルの中で上の1行を実行します。WSL2の仕組みや前提条件はWSL2とは？WSL1との違い・仕組み・インストール手順【WSL 3.0対応・2026年10月】を参照してください。

devbox initからshellまでの基本操作

以下は2026年10月25日に、Docker Hubの公式イメージjetpackio/devbox（Devbox 0.18.4・Nix 2.35.2、x86_64）で実行した結果です。

init・add・shell・runの流れ

mkdir my-app && cd my-app
devbox init                    # 空のdevbox.jsonを作る
devbox add nodejs@22 jq        # 版を省いたjqは jq@latest として記録される
devbox shell                   # 追加したツールにPATHが通ったシェルに入る
exit                           # 元のシェルへ戻ってから次のコマンドを実行
devbox run -- node --version   # シェルに入らず1コマンドだけ実行（v22.23.3）

devbox add nodejs@22 jqはバイナリキャッシュ（cache.nixos.org）から取得するだけで済み、10.2秒で終わりました。devbox initが作るdevbox.jsonには、packagesの空配列と、shell.init_hook・shell.scriptsの雛形が入ります。scriptsに登録したコマンドはdevbox run testのように名前で呼べるため、ビルドやテストの手順を環境定義と一緒にリポジトリへ置けます。

devbox.lockに記録される内容と再現の確認

devbox addを実行するとdevbox.lockが自動で作られます。jqの記録は次のとおりです（抜粋）。

"jq@latest": {
  "last_modified": "2026-10-20T14:23:57Z",
  "resolved": "github:NixOS/nixpkgs/5adc50831c259f87faeb09ddf930d43597197473#jq",
  "source": "devbox-search",
  "version": "1.8.2",
  "systems": {
    "aarch64-darwin": { "outputs": [ ... ], "store_path": "/nix/store/vvp6grz676r5...-jq-1.8.2-bin" },
    "aarch64-linux":  { ... },
    "x86_64-linux":   { ... }

resolvedがNixpkgsのコミットを指し、systemsにOS・CPUごとのstore pathが入るため、MacとLinuxが混ざったチームでも同じ版を指せます。devbox.jsonとdevbox.lockをGitに入れ、.devboxは入れない、が基本の運用です。

再現性を確かめるため、nodejs@22と[email protected]を追加したプロジェクトからdevbox.jsonとdevbox.lockだけを新しいコンテナへ持ち込み、devbox installを実行しました。入った版はNode.js v22.23.3・Python 3.12.15で元と同じ、devbox.lockのSHA-256も一致しました。所要時間は2分39秒で、大半はNixpkgsの該当コミットを取得してGitキャッシュに展開する初回処理でした。CIで毎回この時間がかかるなら、devbox-install-action（最新はv0.15.0）のenable-cacheを有効にする価値があります。

プラットフォーム別のパッケージと出力の指定

Linuxだけで使うツールや、ヘッダファイルが必要なライブラリは、オプション付きで追加します。

devbox add ripgrep --exclude-platform aarch64-darwin   # Apple Siliconでは入れない
devbox add busybox --platform x86_64-linux,aarch64-linux
devbox add openssl --outputs=dev                     # ヘッダ等の dev 出力を選ぶ

オプションを付けるとdevbox.jsonのpackagesは配列からオブジェクトに書き換わり、"openssl": { "version": "latest", "outputs": ["dev"] }のような形になります。旧来の記事にある--output devは誤りで、0.18.4のフラグ名は--outputs（短縮形-o）です。

パッケージと版の探し方

入れられる版はdevbox searchで確認します。devbox search postgresqlは「Found 50+ results」と返し、postgresqlに18.6や17.10、postgresql_14に14.24などが並びました。省略された版は--show-allで全件出ます。版を省いて追加すると@latestになり、devbox info nodejsはその時点で26.12.0を示しました。チームで使うツールはnodejs@22のように版を書いて追加してください。公式サイトは、8万パッケージ・40万を超える版を検索できると説明しています。

servicesによるDB起動とglobalによる共通ツール管理

devbox servicesによるPostgreSQLの起動

devbox add postgresql@17を実行すると、プラグインが.devbox/virtenv/postgresql/process-compose.yamlを作り、PGDATAとPGHOSTをプロジェクト配下に設定します。ホストの/var/libなどには書き込みません。

devbox add postgresql@17
devbox run -- initdb
devbox services up -b     # バックグラウンドで process-compose を起動
devbox services ls        # postgresql  Running  Ready
devbox run -- 'psql -d postgres -tAc "select version()"'
devbox services stop

実行すると「PostgreSQL 17.10 on x86_64-pc-linux-gnu」が返りました。devbox servicesは内部でprocess-compose（今回取得されたのは1.116.0）を使い、start・stop・restart・attachなどのサブコマンドを持ちます。psqlにホストを指定しなくてもつながるのは、PGHOSTがソケットのディレクトリを指しているためです。

devbox globalによる全プロジェクト共通のツール管理

gitやエディタのように全プロジェクトで使うツールはdevbox global addで入れ、eval "$(devbox global shellenv --init-hook)"を~/.zshrcや~/.bashrcに書くと常に使えます。設定の共有に使うdevbox global push・pullは、0.18.0から引数が必須になりました。pushにはGitリポジトリを指定し、pullにはGitリポジトリ、HTTP(S)アーカイブ、devbox.jsonのURL、またはローカルパスを指定します。

0.18.0で削除されたJetify Cloud機能

2026年8月16日公開のDevbox 0.18.0は、「Remove jetify cloud functionality from devbox」としてJetifyのクラウド連携を外しました。2025年以前に書かれた解説記事の多くはこの変更を反映していないため、次のコマンドを勧める記事は古いと判断できます。

影響が大きいのは、Jetify CacheでCIのビルド時間を短縮していたプロジェクトと、devbox.jsonのenv_fromでJetify Cloudのシークレットを読んでいたプロジェクトです。後者はエラーで止まらず警告だけで起動するため、環境変数が空のまま動いて気づくのが遅れます。0.17系以前から上げる場合は、env_fromの有無を先に確認してください。Devbox本体とdevbox generate・devbox servicesなどのローカル機能は今回の削除の対象外です。

Docker・Dev Container・miseとの使い分け

Dockerとの違いは、隔離の深さと速さの交換です。DockerはOSのライブラリまで含めて隔離でき、そのまま本番へ運べますが、macOSでは通常Linux仮想マシンを使い、ファイル共有方式や処理内容によって性能が変わります。Devbox自体は仮想マシンを必要としませんが、カーネルやシステム設定は隔離しません。コンテナの仕組みはDockerの仕組みを図解｜コンテナ隔離・アーキテクチャ・VMとの違いを実機コマンドで確認で確認できます。

devbox generateで作られるDockerfileとdevcontainer.json

devbox generateにはdockerfile・devcontainer・direnv・alias・readmeの5つのサブコマンドがあります。devbox generate dockerfileが出力したDockerfileは次の内容でした。

FROM docker.io/jetpackio/devbox:latest
WORKDIR /code
USER root:root
RUN mkdir -p /code && chown ${DEVBOX_USER}:${DEVBOX_USER} /code
USER ${DEVBOX_USER}:${DEVBOX_USER}
COPY --chown=${DEVBOX_USER}:${DEVBOX_USER} devbox.json devbox.json
COPY --chown=${DEVBOX_USER}:${DEVBOX_USER} devbox.lock devbox.lock
RUN devbox run -- echo "Installed Packages." && nix-store --gc
CMD ["devbox", "shell"]

ベースイメージがlatestタグなので、本番用にはベースイメージを固定し、アプリのコピー・依存関係の導入・必要なビルド処理に加えて、CMDまたはENTRYPOINTをアプリの起動コマンドへ変更する必要があります。Dockerfileの命令ごとの意味はDockerfileとは｜書き方・主要命令・ベストプラクティスを解説【2026年版】を参照してください。devbox generate devcontainerは.devcontainer/にDockerfileとdevcontainer.jsonを作り、拡張機能jetpack-io.devboxとremoteUser: devboxを設定します。「nix devcontainer」で探している場合は、この生成機能を使えばNixの定義をそのままDev Containerへ持ち込めます。Dev Container側の書き方はDev Container（devcontainer）のメリットとは｜devcontainer.jsonの書き方・lockfile・Compose連携【2026年版】にまとめています。

mise・asdfとの違い

miseやasdfが扱うのは主に言語ランタイムの版で、Devboxはそれに加えてOpenSSLやPostgreSQLのようなシステムライブラリ・サーバーまで版を固定できます。Node.jsとPythonの版を揃えるだけならNixを入れずに済むmiseのほうが軽く、詳しくはmiseとは？mise.tomlでツール・環境変数・タスクを束ねる導入手順【2026年版】で比較できます。両方を同じマシンで使う場合は、次の章のPATH競合に注意してください。

導入時のつまずきと対処

多いのは、Devbox以外のツールとのPATHの取り合いと、Nix由来の問題です。

devbox shellでのnode・goのPATH競合

Devboxはシェル起動時に自分のprofileをPATHの先頭へ入れます。検証では、ダミーのnodeを置いたディレクトリをPATHの先頭に足してからdevbox shellに入っても、Devbox側のv22.23.3が使われました。それでもmiseやasdfの版が使われる場合、原因は.zshrcなどに書いたmise activateがシェル起動後にPATHを書き換えていることです。対処は2つあります。

• devbox shell --pureで起動し、HOME・USER・DISPLAYなど少数を除いて既存の環境変数を引き継がない
• グローバルに入れたmiseの版を外し、そのツールはDevbox側だけで管理する

--pureは継承する環境変数を減らせますが、devbox.jsonに入れていないコマンドは使えなくなります。検証ではwhichすら「command not found」になりました。常用するなら、2つ目の整理のほうが現実的です。

開発用ヘッダの不足とNixストア容量への対処

openssl/ssl.h: No such file or directoryのようなビルドエラーは、Nixpkgsのパッケージが実行ファイルとヘッダを別の出力に分けているために起きます。前述のdevbox add openssl --outputs=devで解消します。

版を試すたびに/nix/storeは大きくなり、検証用のコンテナでは3.5GBに達しました。不要になったパッケージはnix-store --gcで回収でき、jqだけを入れた環境で実行すると773パス・378MiBが消えました。nix store gcは環境によっては「experimental Nix feature ‘nix-command’ is disabled」で止まるため、devbox generate dockerfileの出力と同じnix-store --gcを使うのが確実です。

direnvによるディレクトリ移動時の環境切り替え

devbox generate direnvを実行すると、eval "$(devbox generate direnv --print-envrc)"の1行を含む.envrcが作られます。direnv allowすれば、ディレクトリに入るだけでDevboxの環境が有効になります。direnv自体の設定はdirenvとは？.envrcでディレクトリ単位に環境変数を切り替える手順と運用を参照してください。利用状況の送信を止めたい場合は、0.18.0のリリースノートでも扱いが変わっていないDO_NOT_TRACK環境変数を設定します。

Devboxをアンインストールする手順

公式FAQにあるスクリプト導入版の手順は、次の3つを削除するものです。Nix経由で導入した場合は、導入時に使ったプロファイルやNixの構成定義からDevboxを削除します。

rm /usr/local/bin/devbox          # ランチャー
rm -rf ~/.cache/devbox            # Devboxのバイナリ
rm -rf ~/.local/share/devbox      # グローバル設定

この手順ではNixは残ります。Nixも消す場合は、Nixを入れたインストーラのアンインストール手順に従ってください。各プロジェクトの.devboxディレクトリは個別に削除します。

Devboxを採用すべき場面・避けるべき場面

採用が効くのは、MacとLinuxが混ざったチームで「ローカルでは通るがCIで落ちる」が起きているとき、新しく入った人の環境構築に毎回時間を取られているとき、そしてプロジェクトごとにPostgreSQLやRedisの版が違うときです。devbox.lockがOS・CPU別にstore pathを持つので、Apple SiliconのMacとx86_64のCIで同じ版を指せます。チームの開発環境とCIを揃える仕組みづくりから相談したい場合は、DevOps・CI/CD導入支援でも対応しています。

一方、次の条件に当てはまるならDevboxは選びません。本番まで同じコンテナイメージで運ぶ前提なら、Dockerで最初から書くほうが二重管理になりません。WSL2を導入できないWindows環境では動きません。全員がNix言語を書けるならdevenvやflakeで足ります。そして、Nixの導入にroot権限が要るため、管理者権限を持てない社用PCでは最初の一歩で止まります。導入前に、チームの端末でsudoが使えるかを確認してください。

よくある質問

Devboxとは何ですか？

Jetifyが開発するオープンソースのCLIで、Nixを裏側で使い、devbox.jsonに書いたパッケージからプロジェクト専用の開発環境を作ります。Nix言語を書く必要はなく、devbox addとdevbox shellで使えます。

DevboxとMicrosoft Dev Boxは同じものですか？

別の製品です。Microsoft Dev BoxはAzure上に開発用のWindows PCを用意するクラウドサービスで、JetifyのDevboxは手元のmacOS・Linux・WSL2で動くコマンドラインツールです。

Devboxは無料ですか？

Devbox本体はApache 2.0ライセンスで無料です。Nixと、Nixpkgsのバイナリキャッシュであるcache.nixos.orgも無料で使えます。Jetify Cacheなどのクラウド連携は0.18.0でDevboxから削除されました。

devbox.lockはGitにコミットすべきですか？

コミットしてください。devbox.lockにNixpkgsのコミットとstore pathが入っているため、他の人やCIがdevbox installしたときに同じ版が入ります。.devboxディレクトリは自動で除外されます。

Devboxをアンインストールするには？

/usr/local/bin/devbox、~/.cache/devbox、~/.local/share/devboxの3つを削除します。Nixは残るので、不要ならNixのアンインストール手順を別に実行します。

関連記事

• Nixpkgsとは？Nixとの関係・パッケージの探し方とinstall・flake.nixでの使い方
• miseとは？mise.tomlでツール・環境変数・タスクを束ねる導入手順【2026年版】
• Dev Container（devcontainer）のメリットとは｜devcontainer.jsonの書き方・lockfile・Compose連携【2026年版】
• direnvとは？.envrcでディレクトリ単位に環境変数を切り替える手順と運用
• WSL2とは？WSL1との違い・仕組み・インストール手順【WSL 3.0対応・2026年10月】