TryNix、ブラウザのタブで任意のNixパッケージを実行

nixpkgsの全履歴にある任意のパッケージを、何もインストールせずに実行できるようになりました。Farid Zakaria氏が2026年9月4日にTryNixを公開しました。WebAssemblyにコンパイルしたLinuxカーネルをブラウザのタブ内で起動し、指定したパッケージを実行します。

「You can browse the complete history of nixpkgs, over 310,083 package versions, and run any of them in a Linux machine that boots in your tab」とZakaria氏は書いています。

nixpkgsは、NixとNixOSを支えるパッケージ集です。公開されたすべてのバージョンが参照可能なまま残るという性質が、こうした主張を成り立たせています。

実際の仕組み

部品はどれも既存の技術で、組み合わせ方が珍しいだけです。

QEMU-WASMを通じてWebAssemblyにコンパイルしたLinuxカーネルがマシンを提供します。ターミナルエミュレータのGhosttyが画面を提供します。メモリ上のNixストアがパッケージのクロージャ、つまりパッケージとその依存関係一式を保持します。

パッケージ自体は、Nixのバイナリキャッシュから素のHTTPで届きます。ここには条件が1つあり、Zakaria氏はそれをはっきり書いています。「The only requirement is that the cache is served with access-control-allow-origin: *」

このヘッダーが仕掛けのすべてです。Nixのキャッシュはもともと公開のHTTPファイルサーバなので、クロスオリジンのヘッダーが緩ければ、ブラウザは間にサーバを置かずに直接取得できます。

起動にかかる時間

コールドスタートは分ではなく秒です。

パッケージ	初回	再訪
hello	4.2秒	1.5秒
ripgrep	4.3秒	1.7秒
python3	7.5秒	3.5秒

2つの列の差は、ブラウザのキャッシュが働いた結果です。同じパッケージの2回目は、ダウンロードの大部分を省けます。

制約は現実的

使えるかどうかを決める制約が3つあります。

クロージャのサイズは約1.5GBが上限で、WebAssemblyの厳密な上限である4GBに対する数字です。大きなツールチェーンや、重い言語ランタイムを引き込むものは入りません。

リポジトリにあるとおり、あるのはシリアルコンソールだけです。GUIアプリケーションも、ウィンドウ管理も、ブラウザの中のブラウザもありません。

そしてすべてが実行時にx86-64からWebAssemblyへ翻訳されるため、遅延が乗ります。ここは道具を試す場所であって、性能を測る場所ではありません。

これが開発者にとって意味すること

すぐに効く用途は再現です。Zakaria氏の言い回しは借りる価値があります。「Works on my machine」is a URL now for reproduction. 該当のパッケージバージョンがそのまま起動するリンク付きのバグ報告は、バージョン文字列だけの報告とは質が違います。

ドキュメントや教材のリポジトリを保守しているなら、あらゆる入門記事で最悪の一歩が消えます。「まずNixを入れてください」は読者を失います。リンクは失いません。

自分のパッケージでこれを使いたいなら、自分のバイナリキャッシュのヘッダーを確認してください。条件はクロスオリジンのヘッダーであり、たいていの私設キャッシュでは設定されていません。変更は1行ですが、キャッシュをあらゆるオリジンに開くことになるため、意識して決めるべきセキュリティ上の判断です。

重い作業をこれに寄せる計画は立てないでください。1.5GBのクロージャ上限と翻訳のオーバーヘッドを考えれば、これは実演の場であって開発環境ではありません。Nixの周辺はここ数か月厳しい話が続きました。Nixpkgsのコアチームが解散し、stripを通じてNixOSのブートストラップにバックドアを仕込む論文も出ました。Nixの良い部分を見せやすくするプロジェクトは、時期として歓迎できます。