Nixからの移行理由

2025年6月7日原文(blog.railway.com)

概要

Railwayが新たなビルダー Railpack をリリース。 Nixpacksの課題を解決し、 より高速・柔軟なビルド を実現。 イメージサイズ削減 やキャッシュ最適化によりデプロイ効率向上。主要言語・フレームワークを幅広くサポート。 Railpackはオープンソース で、今すぐ利用可能。

Railpackリリース概要

Railwayが新ビルダー Railpack を発表
14M以上のアプリ開発経験を活かした設計
Nixpacksの課題を踏まえ、 ゼロから再構築
Beta版 として本日より利用可能
railway.comやCentral Stationで既に運用中

Nixpacksの課題

バージョン管理の柔軟性不足
- Nixは コミットベースのバージョン管理 のみ対応
- パッチバージョンごとの指定や管理が困難
- 例：NodeやPythonは最新メジャーのみ対応
イメージサイズの肥大化
- 依存パッケージ全てを1レイヤーで管理
- 分割不可 なため、サイズ削減困難
キャッシュ制御の難しさ
- レイヤーキャッシュの 無効化が頻発
- 環境変数の注入でキャッシュヒット率低下
ユーザー体験の不統一
- デフォルトバージョン更新時に ビルド失敗リスク
- Nix独自仕様の理解が必要

Railpackの主な特徴

パッケージの細かなバージョン指定
- major.minor.patch 単位で管理
イメージサイズの大幅削減
- Nodeで 38%減、Pythonで 77%減
BuildKitによる高度なキャッシュ制御
- 環境横断のキャッシュ共有 に対応
依存関係のロック
- デフォルトバージョン更新時も 既存ビルドの安定性維持
シークレット管理の強化
- BuildKitシークレットで 環境変数の漏洩防止
Go言語ベースの新アーキテクチャ
- BuildKitとの親和性向上
Miseによるバージョン解決・パッケージインストール
- 他ソースにも将来的に対応予定

Railpackの動作フロー

Analyze
- コード解析で必要パッケージ・コマンド・起動コマンドを特定
Plan
- JSON形式でビルドプランを生成
- 各ステップに必要な入力・出力を明確化
Generate
- BuildKit用の LLBグラフ を生成
- コマンドごとにマルチステージでビルド
- キャッシュヒット最適化 のため、環境変数等の変更時はハッシュで管理

Railpackで実現できること

Vite, Astro, CRA, Angular 等の静的サイトを ゼロ設定でビルド・デプロイ
Railway UIとの統合
言語最新版対応 （Railpack自体の更新不要）
環境横断でのレイヤーキャッシュ最適化

対応言語・フレームワーク

Node, Python, Go, Php, Static HTML
Vite, Astro, CRA, Angular等の主要フレームワーク
- フロントエンド・バックエンド両対応

利用方法・今後の展望

Beta版として今すぐ利用可能
- サービス設定から Railpackを有効化
オープンソース （railpack.comにドキュメントあり）
今後も 対応言語・フレームワークを拡充予定
- コアAPIや抽象化の安定を優先
- 要望はHelp Stationで受付

まとめ

RailpackはNixpacksの課題を解決し、より柔軟・高速なビルド基盤を提供
イメージサイズ削減・キャッシュ最適化・バージョン管理強化 により、開発者体験を大幅向上
今すぐBeta版を試用可能、オープンソースとして継続的に進化

Hackerたちの意見

Nix自体には問題ないけど、使い方に問題があるんだよね。まさに「適材適所」って感じ。Nixは特定の使い方にはすごく良いけど、他の使い方には最悪。問題なのは、Nixの習得曲線がめっちゃ高いから、理解できる頃にはもう時間をかけすぎて引き返せなくなっちゃうんだよね。だから、元のニーズを解決するために無理やり使おうとする。

└

俺もそう感じるけど、ある意味でNixは他のOSよりも普通のプログラミングパラダイムに近いと思う。単に、そういうOSの考え方に慣れてないだけなんだよね。Nixの式は入力（パッケージリポ、たくさんのキーとバリューのペア）と出力（Linuxシステム）がある。数年後にはもっと普通になるかもね。つまり、AIが仕様通りのshell.nix（いくつかのPythonパッケージ、いくつかのLinuxパッケージ、いくつかの環境変数、いくつかのパスエントリなど）やconfiguration.nixを作るのはすごく簡単になると思う。このパラダイムのおかげで、完全にパッケージをサポートするリポと一緒に環境を含めることが多いんだ。フレークを使えばもっと再現性が高くなるだろうね（flake.nixはshell.nixのようなもので、バージョン固定がある…みたいな感じ、まだその学習の山を登ってるところ）。

バージョン選択の部分が変だね。nixpkgsのバージョンは、システムを運用・構築しているときには意味があるけど、ランタイムやコンパイラをプラットフォームとして提供するなら、devenvみたいに自分でバージョンを提供したいよね。古いnodejsを提供するために古いシステムを構築するなんて、本当に避けたい。依存関係にセキュリティパッチを残したままになっちゃうから。devenvは例えば、https://github.com/cachix/nixpkgs-python で「すべてのPythonバージョンを、Nixを使って毎時最新に保っている」ってやってる。> RailwayはすべてのビルドにデプロイIDの環境変数を注入してる。インストール後の次のレイヤーでやってもよかったはずだし、パッケージを異なるレイヤーに分けることもできる。レイヤーの数を減らすための自動化もあるし、バッチが必要ならそれもできるよ。

ここでの主な問題は、言語パッケージマネージャーが奨励する「特注バージョンスープ」的な考え方を手放したくないってことだね（これは完全に持続不可能）。代替のMiseは、パッケージ間のバージョン制約を理解する能力がないみたいだし、インストールされた各パッケージが周囲のバージョンと正しく動作するかテストもしてないから、全然同じものが得られないよ。

└

「言語パッケージマネージャーが奨励する「特注バージョンスープ」的な考え方」って何を意味するのか、そしてその代替は何なのか詳しく教えてくれる？

└

実際、うまくやれば両方とも持てるよ。例えば、Cargo.lockファイルからNixでRustパッケージをビルドするのは簡単だし。Nixpkgsは特注のバージョンスープとは逆だけど、Nix自体はそれでも大丈夫だよ。

└

特注のバージョンスープは持続不可能だけど、みんながそれを続ける理由の一つは、うまくいくことが多いから。OSレベルのライブラリは、互換性を壊さないように気を使う保守的な世界から来ているから、安定した、よく管理されたOSをベースにして、miseやasdfみたいなツールを使って特注のバージョンスープを構築して、その上でアプリを動かすことができる。ほとんど壊れることはないし、壊れたらバージョンや小さな修正をいじってまた動くようにして、次に進む。壊れたことはイライラするけど、重要ではない。摩擦を生むもの、学ぶことが増えるもの、作業が増えるものは時間の無駄だと思う人が多い。逆に、壊れないようにする解決策を探す人もいるけど、その解決策は摩擦を生んだり、学ぶことが増えたり、作業が増えたりすることが許される。なぜなら、その問題が重要だと考えているから。そういう人たちはNixを求めてる。ほとんどの人は最初のグループにいるから、成長したい会社はそのグループに合った解決策を提供することになるんだよね。

彼らはバージョンがないところに無理やりバージョンを押し込もうとしてるみたい。まるで四角い立方体を丸い穴に押し込もうとしてる感じ。「デフォルトバージョン」がそれに依存しているものを壊す？それって何？dockerの「:latest」タグを使って、毎回新しいサーバーが転倒するのに驚いてるみたいなもんだよ。前の「デフォルト」イメージとは実際には違うバージョンなのに。この記事の説明は全然理解できない。まるでソフトウェアの「バージョン」が何か全く分かってない人たちのようだ。「Nixの依存関係を別々のレイヤーに分ける方法がない」って - なんで？もちろん/nix/storeを必要なだけのレイヤーに分けることはできるよ。彼らはそもそもコンテナの使い方やNixの使い方を知ってるのか？この人たちの明らかな無能さを見れば、彼らの提案する解決策が腐った魚の匂いがするのも納得だね。典型的なNIH症候群。彼らがNixで解決できなかった問題に直面するのは驚くことじゃないよ。

└

VCを集めるのにどっちが良いか（多くの人にとってそれが目標） - Nixラッパーかデプロイメントプラットフォームか。

└

Nixを使わないのには賛成だけど、実際には問題じゃない理由で動作するシステムをゼロから再構築するのは根本的に狂ってると思う。ここで他の人が言ってるように、nix2containerやflakesは彼らの抱えている問題を解決すると思う。バージョン管理に関しては、3年前に書いたflakesが、最初に書いたときと全く同じバージョンと出力でビルドできるよ。市場に出てプラットフォームから資金を調達したいみたいだね :D 編集: さっきnixpacksのGitHubをチェックしたら、nixpkgsでrustPlatformを使っていることにすぐ気づいた。oxalicaのrust-overlayではなくて、これはRustの問題を調べる際にどんな軽い検索でも出てくるはずのものだし、私が使った中で最も便利で強力なオーバーレイの一つだよ。 [0] https://github.com/oxalica/rust-overlay

nixpkgsのハッシュに頼るんじゃなくて、自分たちの派生物を作れなかった理由が分からない。

Nixは、ランダムなバージョンじゃなくてコミット保証を提供してくれるんだ。エッジケースがあるときに、glibcの変更や競合する共有ライブラリがあると、厄介なことになるよ。ちょっと遅いかもしれないけど、Nixと上手く連携させる方法についてアドバイスできるよ。プロダクトはかっこいいね！

Hacker Newsで議論の続きを見る

ハクソク