Flox 1.0 – Nixを活用したオープンソース開発環境のコード化

 (github.com/flox)
3 ポイント 投稿者 GN⁺ 2024-03-14 | 1件のコメント | WhatsAppで共有
  • Floxはエンジニアリングチーム向けのソフトウェア環境プラットフォームで、開発者のノートPCからCI、本番環境まで同一に再現される環境を1つのマニフェストで管理する
  • 基盤はNixだがNixの知識は必須ではなく、宣言的マニフェストと暗号学的に固定されたコンテンツハッシュ入力により環境ドリフトを減らす構造となっている
  • macOS、Linux、Windows WSL2で動作し、Nixpkgsの12万以上のパッケージを検索・インストールでき、自社ソフトウェアを再現可能なパッケージとしてビルド・公開することもできる
  • flox init、flox install、flox activateの流れでプロジェクトごとの分離環境を作成し、有効化するとツールが現れ、抜けると消えるため、システムをクリーンに保てる
  • FloxHubでの共有、OCIイメージ生成、サービス実行、SBOM・CVEパッチ・SCA、AIコーディングエージェント向けの決定論的実行環境まで含み、組織単位での環境ライフサイクル管理に重点を置いている

Floxが解決しようとしている問題

  • Floxは開発環境を1つのファイルで定義し、開発者のノートPC・CI・本番環境で同じ環境を実行できるようにするプラットフォームである
  • 従来のパッケージマネージャーが単一マシンへのパッケージ導入に重点を置くのに対し、Floxは組織全体のパッケージと環境のライフサイクルを管理する
  • 中核となる特性は3つある
    • 宣言的: プロジェクトに必要なツール、環境変数、サービスを1つのファイルで記述する
    • 再現可能: 同じ定義から、対応するシステムであればどこでも同じ環境を生成できる
    • 合成可能: プロジェクト・チーム・パイプラインごとに環境を階層化できる

対象ユーザーと利用環境

  • Platform・DevXチームは、組織全体のツールチェーンを標準化し、Nixの学習を強制せずに基準環境を拡張できる
  • Security・AppSecチームは、SBOM、迅速なCVE対応、依存関係の出所、再現可能ビルドを扱える
  • 開発者は、macOS、Linux、Windows WSL2でプロジェクトごとの再現可能な環境を使え、コンテナやVMよりも仮想環境に近い方式で動作する
  • AIコーディングエージェントは、毎回同じ方法で生成コードをビルド・実行できる決定論的な環境を得られる
    • 対象例はClaude Code、Cursor、Copilot、Codex

再現性とサプライチェーンセキュリティ

  • Flox環境は宣言的マニフェストで定義され、暗号学的に固定されたコンテンツハッシュ入力にロックされる
  • 同じlockfileは対応する各システムで同じパッケージに解決されるため、マシン間で環境の一貫性が保たれる
  • 1つの環境定義を開発者のノートPC、AIエージェントのサンドボックス、CI、本番環境で使える
  • Nixpkgsの12万以上のパッケージを利用できる
  • 自社ソフトウェアをソースからビルドして再現可能なパッケージにし、チーム全体で使えるよう公開できる
  • 再現可能性を基盤として、SBOM生成、ソフトウェア構成分析（SCA）、自動脆弱性・CVEパッチ、依存関係の出所確認、監査可能なビルドを扱いやすくしている

インストールと基本ワークフロー

  • Flox CLIはmacOS、Linux、Windows WSL2にネイティブ方式でインストールできる
    • macOS: brew install flox または .pkg インストーラー
    • Linux: Debian/Ubuntu向け .deb、Fedora/RHEL向け .rpm
    • Windows: WSL2上でLinuxパッケージを使用
  • 基本的な利用フローは、プロジェクト内に環境を作成し、必要なパッケージを導入してから環境を有効化する形である
    • flox init: プロジェクトに環境を作成
    • flox install python3 nodejs: 環境にパッケージをインストール
    • flox activate: 環境に入る
  • READMEの例では、有効化された環境内で python3 --version は Python 3.13.13、node --version は v24.15.0 として動作する
  • 環境を抜けるとインストールされたツールは見えなくなり、プロジェクト間の衝突を防ぎつつシステムをクリーンに保てる

主な機能

  • Create: flox init でコードの隣に宣言的な環境を作成し、自動有効化できる
  • Search: flox search でNixpkgsの12万以上のパッケージを探せる
  • Share: flox push / flox pull により、FloxHub上の単一の基準環境をチーム全員が同じように取得できる
  • Containerize: flox containerize により、DockerfileなしでFlox環境をOCIイメージ化できる
  • Build & publish: flox build / flox publish で自社ソフトウェアを再現可能なパッケージとしてビルドし、チームに公開できる
  • Services: flox services start でデータベース、キュー、バックグラウンドプロセスを環境の一部として実行でき、有効化時に開始し終了時に停止する
  • Configure: manifest.toml に環境変数、シェルフック、有効化スクリプトを宣言的に定義する
  • AI-ready: flox-agentic を通じて、AIコーディングエージェントが毎回同じ依存関係でビルド・実行できるよう支援する

DockerとNixユーザーにとっての位置づけ

  • Floxはコンテナ技術ではなく、Dockerの代替でもない
  • Dockerではパッケージングとコンテナ分離が混在しがちだが、Floxはソフトウェアパッケージングと選択した分離方式を分けるべきだという立場を取る
  • Flox環境はベアメタル、VM、コンテナのいずれでも同じように動作する
  • flox containerize はソフトウェア環境を含むOCIイメージを作成し、Docker、Kubernetes、その他のコンテナランタイムと併用できる
  • NixユーザーにとってFloxは代替ではなく追加ツールである
    • コラボレーション環境とパッケージ共有のための中央サービスFloxHubを提供する
    • 有効化フック、サービス、シェルプロファイルを1つの宣言的TOMLファイルにまとめる

出典とサポート資源

  • FloxはD.E. Shaw groupの大規模エンタープライズNix展開から生まれ、大規模なエンジニアリング組織でNixを利用しやすくするために使われてきた
  • 関連リソース
  • セキュリティに関する問い合わせは security@flox.dev で受け付けている
  • Flox CLIのライセンスはGPLv2である

関連記事

1件のコメント

 
GN⁺ 2024-03-14
Hacker News のコメント

  • Ron、リリースおめでとう。気になるのは収益モデルがどうなっているのかという点
    CEO と会社、従業員がいて、Crunchbase を見ると2,400万ドルの資金調達を受けているように見えるのに、ランディングページやドキュメントで価格情報が見つからない
    GitHub プロフィールで FloxHub にログインしても支払いオプションが見えないが、どんな計画なのか気になる

    • 指摘ありがとう。今日公開した無料・オープンソースという形は、Flox を始めた大きな理由であり、今後さらに多くのものを入れていく予定
      今日公開したオープンソースクライアントと環境共有用の FloxHub サービスは永続的に無料で提供される
      その後は、基本の Flox Catalog の上に重ねる、より強力な非公開ソフトウェアカタログを提供しようとしている
      自社の成果物を配布したり、Flox の中で修正済みのオープンソースパッケージ版が必要だったりするなら、常に無料の Flox Catalog を補完する自社カタログを簡単に作れるようにする計画
      長期的には、企業が広く断片化したソフトウェアサプライチェーンをより適切に管理できるよう、サブスクリプションとサービスの形でエンタープライズ向けソリューションを販売したいと考えており、企業向けカスタムツール開発の費用を企業が一緒に負担するのは合理的だと思う
    • 2,400万ドルも調達したとは驚き。ここから24億ドルのエグジットに至る道筋はあまり見えないが、幸運を祈る

  • README の「Nix を新規ユーザーにとってより簡単にする」式の文言や似た表現を見るたびに引っかかる
    自分はかなり有能なほうだと思っているが、Nix を使っていて「これは簡単だった」と感じたことは一度もない
    Nix の概念は本当に好きだが、ユーザー体験はひどい。このツールがそれを解決するものなのかもしれないが、そこに到達するまでにはドキュメントがほとんどなく、すでに廃止されたやり方の中を迷いながら設定を延々といじる必要があり、かなりフラストレーションがたまる
    いずれにせよ、Nix 関連の何かを見るたびに「これが簡単になる日が待ち遠しい」と思ってしまう

    • 「Flox は D. E. Shaw グループで Nix を導入していた中で始まり、Nix を新規ユーザーにとってより簡単にして、すぐに価値が証明された」という文のことを言っているなら、元の解釈とは逆に聞こえる
    • その文は Nix が新規ユーザーにとって簡単だという意味ではなく、Flox が Nix を簡単にするという意味に読める
    • まったく同じ経験。NixOS をかなり長く触ってみたが、.nix や flakes に慣れることはできなかった
      基本概念がすぐ頭から抜けてしまい、新しく何かを設定するたびにまた調べ直さなければならず、結局は手順に頼ることになった
      問題のデバッグも難しく、何が間違っているのかを知るには、非常に特定のコマンドと地獄のようなファイルシステムを掘り回さなければならない
      概念は好きだが、実際には邪魔が多すぎるという感じ
    • Nix は好きで、nix リポジトリにもかなりパッケージをコントリビュートしてきたが、決して簡単だとは言えない
      Haskell のバックグラウンドがあるのでより馴染みやすく感じる面はあるが、構文そのものも新規ユーザーに直感的ではない
    • 強く同意。利点は見えるが、初期の学習曲線がとてつもなく急
      Rust を学ぶときに似ていて、面白くもある

  • 「学習曲線なしに Nix の力を提供する」系の製品の核心的な問題は、裏側には依然として Nix と /nix/store があり、Nix は意図的にこれを自動で整理しないという点
    ユーザーが Nix を隠したツールを使っていると、結局ディスクがいっぱいになるが、ストレージを減らす方法を知らないので、ユーザーフレンドリーとは言いにくい
    ユーザーが Nix をインストールすることを理解し、学習過程を経れば、/nix/store が何で、どう管理すべきかについてメンタルモデルを作れるという点で違う
    こうした下層の複雑さをどう扱う計画なのか気になる

    • ロールバックと履歴をサポートすれば、ディスクがいっぱいになるのは避けられない。Nix では通常、複数のGC ルートがプロファイルとパッケージを指していて、整理できないため
      Flox の環境は単なるシンボリックリンクではなく宣言的な形式で、内部的には flakes を持っているため、削除でき、必要なら再現することもできる
      そのため nix-env/nix profile を使う場合よりガベージコレクションの破壊性が低く、古い世代をより積極的に整理できる
      戦略は、整理したものを復元できる宣言的・再現可能な方法を常に保証したうえで、空き容量、経過時間、最近未使用、使用頻度の低さといったヒューリスティックでディスクがいっぱいになるのを避けること
    • Docker や Bazel と比べるとどうなのかと思う
      逆に Nix ではこの問題を経験したことがない。ごみ掃除の方法を明確に教えてくれるし、何が残っていて、なぜ残っているのかも簡単に調査できる
      デフォルトで有効化されていない理由は、ほかのガベージコレクタと同じく邪魔になることがあり、全員に合うポリシーはないから
      結局、GC ルートが多すぎれば判断を下す必要がある
    • Nix はガベージコレクションをサポートしている
      コンピュータを使うたびに、裏では信じられないほど複雑なことが何千も起きているのに、Nix を抽象化することだけが特別扱いされる理由がよく分からない
    • 職場でもBazelで同じ問題がある。数か月経つと開発マシンのディスク容量が足りなくなる
    • Nix のガベージコレクションを30分ごとに走らせるよう設定すればいい

  • リリースおめでとう。Nix は本当に好きだけど、オンボーディング体験は控えめに言っても悪く、最悪の場合はひどいものだということも認める
    だから、もっと近づきやすくしようとする試みは歓迎したい。命令型 CLI は、多くの人が期待し、気楽に感じるやり方にはるかに近いので、良い方向だと思う
    ほかの場所の環境を使うプロセスを単純化する点にも大いに共感する
    ただ、重要そうなのに見えていないのは IDE 統合だ。環境内からコマンドラインで IDE を起動するのは多くの同僚にとって直感的ではなく、実際の問題の根本原因として何度も診断したこともある
    必要なときに「本物の Nix」へ降りていく話はどうなるのか気になる。たとえば Rust のクロスコンパイル用ツールチェーンを設定するような少し複雑な環境では、崖から落ちるようなことにならないか心配だ
    Rust 開発の例として、Rust-Analyzer が正しく動くように flake に長い shellHook を入れる必要があったのだが、こうした設定を Flox ではどうできるのか気になる
    こういう部分を抽象化しようとしているのか、そうでないなら Nix を知らないユーザーがどうやって見つけ出せるのかも気になる
    絶対に不可能だと言いたいわけではなく、本当にうまくいってほしいと思っているが、まだ方法がよく見えていない

    • 必要なときに「本物の Nix」へ降りる部分についてはすでに議論しており、追加の力が必要な場合には Nix 自体を使えるようにする計画だ
      現在考えているのは、特定のフィールドで flake 参照を許可するか、Nix スタイルのエントリーポイントを用意する方式だ
      まだ公開も文書化もされていないので、待ってもらえるとありがたい
      複雑さを隠すことと能力を露出することの間には本当に微妙な線がある、という点には全面的に同意する

  • 通常の nix-shell や nix develop の代わりに Flox を使う利点が何なのか気になる

    • Flox の社員です。Nix ツールとの関係から言うと、目標はより ユーザーフレンドリーになることだ
      Nix 式言語を学んだり、Nix の内部構造を理解したりしなくても成功できるようにすることを目指している
      また、ある程度の方向性と磨き込みも加えている。たとえば命令型/宣言型の混合インターフェースがあり、flox install && flox list を実行すると変更内容が TOML に反映される。一方 nix develop では Nix 式を編集する必要がある
      nix develop は bash シェルに入るが、flox activate は bash や zsh シェルに入ることができ、fish 対応も追加する予定だ
      Git で環境を管理することは Nix ツールと同様にサポートしつつ、flox push/flox pull/flox activate -r のように、それらのツールではできない形での環境共有も追加している
      アカウントを作成すれば https://hub.flox.dev/mkenigs/default で私の環境のパッケージを見られ、CLI があれば flox list -r mkenigs/default で確認したうえで flox activate -r mkenigs/default で使える
      Nix 式言語を知らない人に flake.nix をリンクするより、ずっと受け入れやすいと思う
    • 別の言い方をすれば、個々のエンジニアは基盤技術とそれに付随するツールを学んだほうがよいと思う
      Flox や devenv のようなツールが寿命を迎えたり、nixpkgs にきちんと追随できなかったり、ソフトウェアが腐るさまざまな形のどれかを経験したりする可能性は十分にある
      一方で nix develop は Nix Flakes が続く限り残るだろうし、次の方式へ移行するマイグレーション経路を提供する動機もある
      さらに重要なのは、あらゆる抽象化は漏れるということだ。Flox CLI がよりきれいに見えるとしても、結局効果的に使うには Nix を学ぶ必要があるだろう
      必要以上に倍のことを学ぶ理由があるのかと思う
    • あるいは https://devenv.sh もある

  • 既存の Devbox プロジェクト（https://www.jetpack.io/devbox）とどう比較されるのか気になる
    Flox にも任意で使える クラウドソリューションがあるのか、特定バージョンの Nix パッケージをインストールできるのか、OS ごとの依存関係をどう扱うのかも知りたい
    こうしたツールを 5 年間使ってきたが、Flox が既存のものに比べて何を新たにもたらすのか気になる

  • なぜ通常の Nix の代わりにこれを使うべきなのか本当に理解できないのだが、説明してもらえるだろうか

    • プロジェクトごとに クリーンで再現可能な環境だけが欲しい。Nix には何度か入門しようとしたが、Nix がやることがあまりに多岐にわたるので毎回圧倒された
      これは自分にとって 100 倍は単純に見える
    • Nix が多くの問題を解決することは理解しているし、実際にその能力に賭けた。だから Nix 自体にも多くの労力を注いできた
      しかし Nix は第一原理から積み上げて非常に汎用的に作られているため、学習曲線はかなり急だ
      Flox は問題範囲を狭め、特化した抽象化とインターフェースを提供することで、初日から Nix の専門家にならなくても Nix の力を活用できるよう単純化しようとするツールだ
    • 同僚に Nix を納得させるより、flox や devenv を納得させるほうがはるかに簡単だ

  • 再現可能な開発環境に非常に関心があり、職場でも開発コンテナを何年も順調に使っている
    約 1 年前に Nix のことを聞き、最初はその約束が素晴らしくてとても期待したが、オンボーディング過程は自分にはひどいものだった
    作りたい開発環境は明確なのに、アプローチのどこかをいつも見落としているように感じる
    全体の体験を改善しようとする新しいツールが出てきてうれしいし、試し続けていればいつか感覚がつかめることを願っている
    あなたにとっては、どの瞬間に Nix が「しっくりきた」のか気になる

    • 質問ありがとう。これは Bay Area に来たらビールを飲みながら深く話したいテーマだ
      Microservices の動画を見たことはある？ https://www.youtube.com/watch?v=y8OnoxKotPQ
      当時 Facebook で開発者プロダクトチームを率いていて、ローカル開発にリモート機能を注入するプロジェクトを始めた
      何千人もの開発者がコールドビルドに 45 分ずつ待っていた
      初期段階の一つが、ソフトウェア開発ライフサイクル全体を描き出すことで、どのツールチェーン部分を作り直す必要があるのかを把握するためだった
      動画の終盤にあるホワイトボードを見れば思い出すように、私たちがどれほど複雑に作ってしまっていたのかを可視化した瞬間、「これが私たちの働き方であるはずがない」という考えに至った

  • 最後に Nix を使ったときは、flakes をめぐってかなり混乱がありました。
    あるチュートリアルでは使うように言い、別のところではまだ開発中だと言っていて、状況が良くなったのか気になります。

    • 良くなったと思います。ここに挙がっているほぼすべて、あるいは全部のソリューションが内部的に flakes を使っているようです: https://news.ycombinator.com/item?id=39696038
      flakes の問題は 2 つに由来すると思います。
      1 つは、ほぼ 5 年近く experimental ラベルが付いているため新規ユーザーを混乱させる一方で、実際にはほとんどどこでも一般的に使われているという点です。
      もう 1 つは、https://determinate.systems/ と古くからの Nix ユーザー・開発者の間に感情的なしこりがあるように見える点です。Determinate Systems が Nix を自社の利益のために使いながら、貢献を還元していないと批判されているようです。
      私の理解では、Determinate Systems が flakes を導入したため、一部の人が反発しているようです。
      結論としては、ほぼ全員が flakes を採用しており、使っていないガイドはたいてい古い可能性が高いです。
      関連リンク: https://discourse.nixos.org/t/introducing-flakehub/32044
    • 最近 flakes を使うなと勧める人は知らないです。
      “experimental” ラベルは、完成度やバグというより API の安定性 に関する意味合いに近いです。
      特定の状況では性能問題があるかもしれませんが、回避策があり、恒久的な解決策も作業中です。
      それでも自宅と職場で flakes をかなり使っています。
    • 参考: 新しい CLI と Flakes を段階的に安定化するための計画 https://github.com/NixOS/rfcs/pull/136

  • 昨夜 macOS で Flox を試してみたところ、Nix-Darwin が /run/current-system/sw/bin で管理している Nix とは別に、デフォルトプロファイルへ Nix をインストールし、そのコピーを /usr/local/bin にシンボリックリンクしているのを見ました。
    既存の Nix ユーザー、つまり NixOS ユーザーや、すでに Nix をインストールしているものの Flox が対応するディストリビューションのパッケージ形式がない別ディストリビューションのユーザー向けの案内もありませんでした。
    Flox が Nix のサードパーティ製プロファイルマネージャーなので、不安定な Nix profile manifest 形式のようなものに依存しているからなのか、それとも実際にはさまざまな Nix バージョンと併用可能だがテストされていないだけなのか気になります。
    Nix ベースの Flox インストールを将来的に対応する機能として考えているのかも知りたいです。
    また fish 対応が来るとのことでしたが、activate サブコマンドの シェル統合 が実際に Flox のソースや設定のどこにあるのか教えてもらえますか。
    公式の fish 対応を待つ間、fenv のようなもので暫定的につなぎ込もうとしたのですが、インストール済みのものとソースを見て回っても、差し込めそうな場所がなかなか見つかりませんでした。

    • https://flox.dev/docs/install-flox/ の Nix/Generic と Nix/NixOS タブを見落としているようです。それがあなたの言う 併用 ケースを満たすのか気になります。
      現時点で fish を使う最善の方法は FLOX_SHELL=zsh flox activate -- fish だと思います。エイリアスはサポートしませんが、ほとんどは動作するはずです。
      実際にソースをハックしようとしているのか、それとも回避策を作るために構造を理解しようとしているのかも気になります。
      bash や zsh 以外のシェルでは、このあたりでエラーを出します: https://github.com/flox/flox/blob/9e18a3ceaa185006bae95a4827...
      自分で直してみたいなら、背景説明をもっと喜んでします。