Nixpacks vs Docker：サイズ、速度、そしてRailwayが移行した理由を徹底解説

Nixpacks vs Docker の選択は、かつては「制御性を犠牲にして利便性を得る」という単純なものでした。しかし2025年、Nixpacksを開発したチームであるRailwayは、これをメンテナンスモードに移行し、後継としてRailpackを発表しました。これにより、状況は完全に変わりました。ここでは、実際のイメージサイズ、ビルド速度データ、コードの並列比較、そして2026年現在の状況を考慮した意思決定フレームワークを用いて、docker vs nixpacks を完全比較します。

Nixpacks vs Docker：概要

Dockerfileなしでデプロイする必要があり、かつあなたのスタックがサポートされている場合、Nixpacks（またはその後継であるRailpack）を使えば数秒で実行できます。一方、イメージサイズ、ビルド速度、本番環境での最適化を重視するなら、カスタムDockerfileが常に勝利します。

最初に理解しておくべき重要な点として、NixpacksはDockerを置き換えるものではありません。内部でDockerfileを生成し、DockerのBuildKitを使用してOCI準拠のイメージを作成します。これはDockerに対する代替手段ではなく、その上の抽象化レイヤーです。

Nixpacksとは？（そしてNixとの違い）

Nixpacks は、Railway が作成したビルドツールで、アプリの言語やフレームワークを自動検出し、設定なしでコンテナイメージを生成します。コードをプッシュすれば、Nixpacksが残りを処理します。これが売り文句であり、シンプルなアプリであれば確かにその通りです。

Nixpacksのビルドは以下のようになります。

# Zero config -- Nixpacks detects your stack automatically
nixpacks build . --name my-app

# Or with a custom start command
nixpacks build . --name my-app --start-cmd "node dist/index.js"

Nixpacksはソースコード内の package.json、requirements.txt、go.mod などのファイルを検索し、適切な「プロバイダー」（言語固有のビルドレシピ）を選択します。これはHerokuスタイルのbuildpacksよりも高速でシンプルになるように設計されており、一時はRailwayのデフォルトビルダーでした。

Nixpacksがスタックを検出する方法

検出パイプラインは単純明快です。Nixpacksはプロジェクトルートにある既知の設定ファイルを探します。package.json が見つかったら？ Node.jsプロバイダー。requirements.txt や pyproject.toml が見つかったら？ Pythonプロバイダー。モノレポもある程度処理できますが、標準的でないプロジェクト構成では複雑になります。

Nix vs Nixpacks：別物です

この点はほぼ全員（このクエリで上位表示される記事の多くも含む）を混乱させます。Nix は、再現可能なビルドに焦点を当てた関数型パッケージマネージャーおよびビルドシステムです。Nixpacks は、依存関係の解決のために内部的にNixパッケージを使用する特定のツールです。これらは関連していますが異なります。「npm」と「create-react-app」が同じものだと言うのが誤りなのと同様です。

2026年における重要なコンテキスト：Nixpacksはメンテナンスモードにあります。Railwayは新機能の追加を停止し、根本的な制限に対処するためにRailpackを構築しました。既存のプロジェクトは引き続き動作しますが、改善のためのロードマップはありません。

DockerとDockerfile：業界標準

Dockerについてはご存知でしょう。「Dockerはコンテナ化プラットフォームです」という説明は省略し、この比較において重要な点に焦点を当てます。

Dockerfile は、コンテナイメージに対してレイヤーごとの明示的な制御を提供します。ベースイメージの選択、コピーされるファイルの制御、インストールされる依存関係の指定、そしてマルチステージビルドによる最終結果の最適化が可能です。本番環境対応の例を以下に示します。

# Multi-stage Node.js Dockerfile -- optimized for size
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
EXPOSE 3000
CMD ["node", "dist/index.js"]

この比較に関連する主要なDocker機能：マルチステージビルドにより、ビルド時の依存関係とランタイムイメージを分離できます。BuildKitによるレイヤーキャッシングは、後続のビルドを高速かつ予測可能にします。また、ベースイメージの選択（Alpine、distroless、scratch）により、イメージサイズと攻撃対象領域を直接制御できます。

Dockerの知識は普遍的に転用可能です。すべてのクラウドプロバイダー、すべてのCI/CDプラットフォーム、すべてのデプロイ先が Dockerfile を理解しています。

Nixpacks vs Docker：頭突き比較

設定と構成

Nixpacksの最大のセールスポイントは、ゼロコンフィグデプロイです。標準的なNode.jsアプリの場合、設定ファイルは literally 不要です。コードをプッシュすれば、コンテナが得られます。Dockerでは、Dockerfile を記述して維持する必要があります。

Nixpacksをカスタマイズする必要がある場合は、nixpacks.toml を使用します。

# nixpacks.toml -- customize Nixpacks behavior
[phases.setup]
nixPkgs = ["...", "ffmpeg"]  # Add system dependencies

[phases.build]
cmds = ["npm run build"]

[start]
cmd = "node dist/index.js"

同等の Dockerfile はより冗長ですが、はるかに明示的です。

FROM node:20-alpine
RUN apk add --no-cache ffmpeg
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
CMD ["node", "dist/index.js"]

ハッカソンやプロトタイプの場合、Nixpacksは実質的な時間を節約します。週末以上維持する任何东西にとって、その Dockerfile はデバッグの容易さと最適化の可能性において元を取ります。

判定：引き分け。 デプロイまでの速さではNixpacksが勝ちます。長期的な保守性ではDockerが勝ちます。タイムラインに基づいて選択してください。

イメージサイズ

ここで比較は残酷になります。Nixpacksのイメージは巨大です。「わずかに大きい」レベルではなく、同じアプリケーションに対する最適化されたDockerfileと比較して10〜17倍大きいのです。

よく文書化された事例：ある開発者がNext.jsアプリをNixpacksからカスタムDockerfileに移行したところ、イメージサイズが1.3GBから76.83MBに縮小し、17倍の削減を実現しました。これは珍しいことではありません。

理由はアーキテクチャにあります。Nixpacksはすべてを /nix/store に詰め込みます。ビルドツール、コンパイラ、デバッグシンボル、ランタイムで決して必要にならないライブラリまで、すべてが1つの巨大なレイヤーに含まれます。Dockerのマルチステージビルドでは、実際のランタイム成果物以外をすべて捨てることができます。

判定：Dockerの圧勝。 接戦ではありません。プロジェクトにおいてイメージサイズが重要である場合（本番環境ではほぼ常に重要です）、Dockerが唯一の実用的な選択肢です。

ビルド速度とキャッシング

Nixpacksによる初回ビルドは、Nixパッケージをゼロからダウンロードするため、通常は遅くなります。Railway自身のデータによると、典型的なNixpacksビルドには約1分27秒かかるのに対し、Dockerfileビルドは15秒、プリビルドイメージは6秒です。

後続のビルドはより微妙な話になります。Nixバイナリキャッシングは物事を高速化できますが、Dockerのレイヤーキャッシングほど予測可能ではありません。package.json の変更はNixキャッシュを広範囲に無効化しますが、Dockerのレイヤーキャッシングは変更されたステップ以降のレイヤーのみを再ビルドします。

Dockerのレイヤーキャッシングはより透明です。どのレイヤーがなぜ変更されたかを正確に見ることができます。Nixpacksのキャッシングはブラックボックスであり、ヒットするかしないかだけです。Nixストアでのキャッシュミスに関するデバッグには、ほとんどのチームが持っていない専門知識が必要です。

判定：Dockerの勝ち。 より予測可能で、初回およびキャッシュ利用時の両方のビルドで高速であり、キャッシングが失敗した際のデバッグも容易です。

言語とフレームワークのサポート

Nixpacksは約20の言語とフレームワークを自動検出します。Node.js、Python、Go、Rust、Java、Ruby、PHP、.NET、Elixirなどです。サポートされているスタックの場合、検出は本当に印象的で、正しいランタイムバージョンを選び、ビルドコマンドを設定し、開始コマンドを自動的に構成します。

Dockerは、Dockerfile を記述できるものは何でもサポートします。これは事実上無制限です。エキゾチックなランタイム、カスタムツールチェーン、多言語モノレポ、Linux上で動作するものであれば、Dockerは処理します。

バージョン固定の違いは、あなたが考える以上に重要です。NixpacksはNixパッケージに対してコミットベースのバージョニングを使用します。「Python 3.11.4」と指定することはできず、Nixコミットが提供する任意のバージョンになります。Dockerでは正確なバージョン管理が可能です。FROM python:3.11.4-slim は決定論的です。

判定：柔軟性ではDockerの勝ち。 スタックがサポートリストにある場合、Nixpacksは便利です。Dockerはすべてを処理し、精密なバージョン管理を提供します。

本番環境への適合性とセキュリティ

Nixpacksイメージには、アプリが実際に必要とするよりもはるかに多くのパッケージが含まれています。これはより大きな攻撃対象領域を意味し、より多くのバイナリはより多くの潜在的な脆弱性を意味します。肥大化した /nix/store レイヤーには、本番イメージにあるべきではないコンパイラ、ビルドツール、ライブラリが含まれています。

Dockerでは、Alpine（最小限）、distroless（シェルなし、パッケージマネージャーなし）、さらにはコンパイル言語用の FROM scratch などのオプションがあります。これらの最小限のイメージには、アプリの実行に必要なもののみが含まれており、攻撃対象領域を劇的に減らします。

デバッグも另一个ギャップです。Nixpacksイメージは、ハッシュベースのパスを持つ /nix/store を中心とした馴染みのないディレクトリ構造を持っています。本番環境で問題が発生した場合、トラブルシューティングを開始する前にファイルシステムレイアウトを理解するのに時間を費やすことになります。

判定：本番環境ではDockerの勝ち。 より小さな攻撃対象領域、馴染みのあるデバッグツール、確立されたセキュリティスキャンパイプラインのすべてがDockerを支持しています。

開発者体験

ここでNixpacksが真に輝きます。Dockerfile を書いたことのない開発者にとって、コードから実行中のコンテナまでを1つのコマンドで実現するのは魔法のようなものです。nixpacks build .、完了。学ぶべき構文、選ぶべきベースイメージ、考えるべきレイヤー順序はありません。

Dockerの学習曲線は急ではありませんが、現実に存在します。効率的な Dockerfile を記述するには、レイヤーキャッシング、マルチステージビルド、.dockerignore、そして COPY と ADD の違いを理解する必要があります。これは報われる知識ですが、習得には時間がかかります。

長期的なトレードオフを考慮する価値があります。Nixpacksの知識はプラットフォーム固有であり、Railway、Coolify、その他いくつかのプラットフォームで役立ちます。Dockerの知識は普遍的であり、どんな仕事、どんなクラウドプロバイダー、どんなデプロイ先にも転用可能です。

判定：スタートアップではNixpacksの勝ち。 キャリア全体での有用性ではDockerが勝ちます。学習中なら、Nixpacksで迅速に出荷し、その後本番環境用にDockerを学びましょう。

並列比較：同じアプリ、両方の方法

実際的な違いを見てみましょう。両方のツール用に構成されたNode.js Express APIです。

Nixpacks（ゼロコンフィグ、ファイル不要）：

# Nixpacks auto-detects Node.js from package.json
# No configuration file required
nixpacks build . --name express-api

# Result: ~900MB image

Nixpacksの場合、アプリが標準的であれば nixpacks.toml さえ不要です。package.json を読み取り、ビルドスクリプトを検出し、開始コマンドを設定します。

Docker（最適化されたマルチステージDockerfile）：

# Dockerfile for the same Express API
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:20-alpine
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY ./src ./src
EXPOSE 3000
CMD ["node", "src/index.js"]

次に、Python FastAPIアプリの場合：

Nixpacks（ゼロコンフィグ）：

# Nixpacks detects Python from requirements.txt
nixpacks build . --name fastapi-app

# Result: ~1.1GB image

Docker（最適化されたDockerfile）：

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY ./app ./app
EXPOSE 8000
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

出力を並べると以下のようになります。

# Image size comparison
$ docker images
REPOSITORY          TAG       SIZE
express-api-nix     latest    924MB    # Nixpacks build
express-api         latest    83MB     # Docker multi-stage
fastapi-nix         latest    1.12GB   # Nixpacks build
fastapi-app         latest    92MB     # Docker slim

Nixpacks版はゼロの努力で「ただ動く」状態になります。Docker版は記述に10〜15分かかりますが、イメージサイズが10倍小さく、デプロイが高速で、保存および転送コストが低いイメージを生成します。

イメージサイズの問題：なぜNixpacksは800MBのコンテナを作成するのか

イメージの肥大化は設定で回避できるバグではなく、Nixが内部でどのように動作するかの根本的な結果です。

1.3GBのイメージの中に実際に入っているもの

Nixpacksがアプリをビルドするとき、Nixパッケージマネージャーはすべての依存関係（ビルド時のも含む）を解決し、それらを /nix/store にコピーします。そのストアがコンテナイメージ内の1つの巨大なレイヤーになります。典型的なNixpacksでビルドされたNode.jsイメージの中には、以下が見つかります。

• ビルドコンパイラ（gcc, g++）：npm install 中にのみ必要だったもの
• ネイティブモジュールの開発ヘッダー：使用しない可能性のあるもの
• デバッグシンボル：数百MBを追加するもの
• 未使用のシステムライブラリ：推移的なNix依存関係として引き込まれたもの
• Nixストアメタデータ全体：ハッシュ、派生参照、依存グラフ

なぜ最適化で除去できないのか

Dockerはマルチステージビルドでこれを解決します。1つのステージでコンパイルし、出力のみをクリーンなランタイムステージにコピーします。Nixpacksには同等のメカニズムがありません。/nix/store アーキテクチャは、すべてのパッケージを単一の原子単位として扱います。最終イメージに含まれるNixパッケージを選別することはできません。

aptPkgs やNixパッケージを明示的に指定することで nixpacks.toml でパッケージを制限しようとすることはできますが、コアのNixランタイム依存関係は依然として含まれます。Nixpacks最適化の実用的な上限でも、同等のDockerビルドと比較してイメージは5〜8倍大きくなります。

800MB以上のイメージの実世界のコスト：デプロイの遅延、コンテナレジストリのストレージコストの増加、サーバーレスプラットフォームでのコールドスタート時間の延長、ノードがイメージをプルするたびに消費される帯域幅の増加。頻繁なデプロイで10レプリカを実行するスタートアップにとって、余分なギガバイトは時間とお金の両方で蓄積されます。

イメージサイズが重要な場合（プロトタイプ以外のすべてで重要です）、答えは明白です。Dockerfile を書きましょう。

Railpack要因：なぜRailwayはNixpacksを放棄したのか

これが nixpacks vs docker の議論におけるすべてを変えるコンテキストです。2025年3月、Nixpacksを構築し、1400万回のアプリビルド acrossでデプロイしたチームであるRailwayは、移行を発表しました。

彼らの理由は具体的かつ技術的でした。

1. コミットベースのバージョニング：Nixパッケージはセマンティックバージョニングを使用しません。「Node 20.11.1」をリクエストすることはできません。特定のNixコミットが提供する任意のバージョンになり、再現可能なビルドが本来あるべきよりも困難になります。
2. 巨大なイメージサイズ：/nix/store アーキテクチャにより、最適化が構造的に不可能になりました。Railwayの20万人以上のユーザーは、不必要に肥大化したイメージをデプロイしていました。
3. 予測不可能なキャッシング：Nixバイナリキャッシングは一貫して機能せず、開発者を苛立たせる遅いビルドにつながっていました。

RailpackがNixpacksを超えて改善する点

Railpack はNixを完全に捨てます。Ubuntuベースを使用し、標準のパッケージマネージャー（apt、言語固有のツール）と適切なマルチフェーズビルドを採用しています。結果は顕著です。

• Node.jsイメージ：Nixpacksより38%小さい
• Pythonイメージ：Nixpacksより77%小さい
• 適切なセマンティックバージョニングサポート：node@20 や [email protected] をリクエストすると、まさにそれが得られます
• 予測可能なキャッシング：開発者が理解する標準的なレイヤーベースのキャッシング

Railpackはまだベータ版です。現在、Node.js、Python、Go、PHP、静的HTMLをサポートしています。Nixpacksが処理するRust、Ruby、Java、その他のいくつかの言語は、まだRailpackでは利用できません。

Docker vs Nixpacks vs Railpack：サマリーテーブル

プラットフォームサポート：各ツールが動作する場所

コンテナ化の選択は、デプロイ先にも部分的に依存します。以下の現代のデプロイプラットフォームがどのビルドツールをサポートしているかを示します。

いくつかの要点：Dockerは everywhere でサポートされている唯一のビルドツールです。プラットフォームの移植性が重要であれば、Dockerfile が最も安全な賭けです。Nixpacksのサポートは、セルフホスト型PaaSツール（Coolify、Dokploy）といくつかのマネージドプラットフォーム（Kinsta）に集中しています。Railpackは現時点ではRailway限定です。

何时使用各工具：意思決定フレームワーク

これが意思決定マトリックスです。あなたの状況が行と一致する場合、その推奨事項は実際のプロジェクトでテストされています。

3つの経験則：

1. プロトタイピング中？ ゼロコンフィグツール（Nixpacks、Railpack）を使用してください。捨てられるかもしれないもののためにDockerfileを書く時間を無駄にしないでください。
2. 本番環境に向かっている？ Dockerfileを書いてください。投資する30分は、肥大化したイメージと予測不可能なビルドのデバッグに費やす何時間も節約します。
3. すでにNixpacksを使用している？ パニック移行しないでください。プロジェクトが自然にマイルストーンに到達したときに、RailpackまたはDockerへの切り替えを計画してください。

Techsyがコンテナデプロイにアプローチする方法

私たちはNixpacksとカスタムDockerfileの両方で本番アプリを出荷してきたため、ここでの正直な見解をお伝えします。

クライアントのプロトタイプやMVPの場合、ゼロコンフィグビルダーから始めることがよくあります。これらは、毎日機能を反復しており、プロジェクトに将来性があるかどうかまだわからない段階での摩擦を取り除きます。Nixpacks（または現在のRailway上のRailpack）はこの目的に完璧で、数秒でデプロイし、製品に集中できます。

プロジェクトが本番環境に達した瞬間、私たちは最適化されたDockerfileに切り替えます。私たちのプロセスは以下の通りです。

1. 現在のイメージの監査：サイズを確認し、不要なパッケージを特定し、脆弱性をスキャン
2. マルチステージDockerfileの記述：ビルド依存関係をランタイムから分離
3. 適切なレイヤーキャッシングの設定：キャッシュヒットを最大化するために COPY 命令を順序付け
4. 適切なベースイメージの選択：ほとんどのアプリにはAlpine、セキュリティ重視のサービスにはdistroless
5. CI/CDへの統合：ビルド、テスト、レジストリへのプッシュ、デプロイ

私たちはスタートアップが1GB以上のNixpacksイメージから100MB未満のDockerイメージに移行するのを支援し、デプロイ時間を5倍短縮し、コンテナレジストリコストで意味のある金額を節約してきました。

何かを構築していて、デプロイ設定に不安がありますか？無料相談をご利用ください。プロジェクトに適したアプローチを選ぶお手伝いをします。

よくある質問

Nixpacksは非推奨ですか？

はい。Nixpacksは2025年時点でメンテナンスモードにあります。作成者であるRailwayは、後継としてRailpackを構築しました。既存のNixpacksプロジェクトは引き続き動作し、重要なバグ修正を受けますが、新機能や言語プロバイダーは追加されていません。新規プロジェクトでは、RailpackまたはカスタムDockerfileを検討してください。

Nixpacksの後継は何ですか？

Railpackです。Nixpacksと同じチーム（Railway）によって構築されました。Nix依存関係を完全に排除し、標準パッケージマネージャーを使用したUbuntuベースのビルドを採用しています。結果として、Nixpacksと比較してNode.jsイメージは38%小さく、Pythonイメージは77%小さくなり、適切なセマンティックバージョニングバージョンサポートを備えています。

なぜNixpacksのイメージはそれほど大きいのですか？

Nixストアアーキテクチャは、コンパイラやデバッグシンボルなどのビルド時依存関係を含むすべてのパッケージを1つの大きなレイヤーにコピーします。不要なファイルを取り除くためのDockerのマルチステージビルドに相当するものがありません。シンプルなNode.jsアプリは、Nixpacks経由で通常800MB-1.3GBのイメージを生成しますが、最適化されたDockerfileでは50-100MBです。

NixpacksとDocker、どちらを使うべきですか？

サポートされているプラットフォームでの迅速なプロトタイピングには、Nixpacksならゼロコンフィグでデプロイできます。イメージサイズ、セキュリティ、ビルドパフォーマンスが重要な本番アプリには、カスタムDockerfileにより10〜50倍小さいイメージと遥かなる制御が得られます。Nixpacksの非推奨ステータスを考慮すると、Dockerの方が長期的な投資として安全です。

NixpacksとDockerを一緒に使用できますか？

はい。Nixpacksは内部でDockerfileを生成し、DockerのBuildKitエンジンを使用してイメージを作成します。多くのチームが開発およびステージング環境（高速な反復、ゼロコンフィグ）にNixpacksを使用し、本番デプロイにはカスタムDockerfileを維持しています。

NixとNixpacksの違いは何ですか？

Nixは、再現可能なビルドに焦点を当てた関数型パッケージマネージャーおよびビルドシステムです。Nixpacksは、Railwayによって作成されたビルドツールで、Nixパッケージを使用して言語を自動検出し、アプリケーションをコンテナ化します。これらは関連していますが異なるツールです。Nixは基盤技術であり、Nixpacksはその上に構築された意見を持ったラッパーです。

RailwayはまだNixpacksをサポートしていますか？

Railwayは既存のプロジェクトに対してNixpacksをサポートしていますが、新規プロジェクトのデフォルトビルダーは現在Railpackです。RailwayではカスタムDockerfileも使用できます。切り替えるには、プロジェクトルートに Dockerfile を追加するだけで、Railwayがそれを自動検出してNixpacksの代わりに使用します。

NixpacksはDockerより高速ですか？

一般的にはいいえ。Nixpacksによる初回ビルドは、Nixパッケージのダウンロードのため遅くなります（Railwayのベンチマークによると、Dockerfileビルドの15秒に対し約1分27秒）。キャッシュされたビルドは単純な変更で同等になる場合がありますが、全体的にDockerのレイヤーキャッシングの方がより予測可能できめ細かいです。

RailwayでNixpacksからDockerfileに切り替えるにはどうすればよいですか？

プロジェクトルートに Dockerfile を追加してください。Railwayはそれを自動検出し、設定変更なしでNixpacksよりも優先します。スタックに合わせて最適化されたマルチステージDockerfileを記述し、プッシュすれば、Railwayが残りを処理します。

どのプラットフォームがNixpacksを使用していますか？

Coolify、Dokploy、Kinsta、およびDokku（プラグイン経由）は依然としてNixpacksを積極的に使用しています。RailwayはデフォルトとしてRailpackに移行しました。Render、Fly.io、Vercelは独自のプロプライエタリビルドシステムを使用しています。Dockerは、すべてのプラットフォームでサポートされている唯一のビルドアプローチです。

Nixpacksは本番環境に適していますか？

Nixpacksは本番環境よりも開発およびステージングに適しています。大きなイメージサイズ（800MB以上）、限られた最適化オプション、および非推奨ステータスは、本番ワークロードにとってリスクの高い選択となります。本番環境には、カスタムDockerfileまたは（Railway上使用の場合）Railpackのいずれかがより強力なオプションです。

最終結論

本番品質を重視するほとんどの開発者にとって、Dockerがより良い選択です。 7カテゴリ中5つで勝利し、Nixpacksが勝利する2つのカテゴリ（設定速度、初心者DX）は、定義上臨時であるプロトタイピング段階で最も重要です。

Nixpacksは真の目的を果たしました。ゼロコンフィグコンテナ化が可能で価値あることを証明しました。しかし、その根本的な制限（肥大化したイメージ、予測不可能なキャッシング、コミットベースのバージョニング）により、その作成者自身が良いものを構築することになりました。Railpackはいつか両方の長所（合理的なイメージサイズでのゼロコンフィグ）を提供するかもしれませんが、まだベータ版で言語サポートは限られています。

実用的な推奨事項：Railwayで新規プロジェクトを開始する場合、ビルドはRailpackに任せましょう。他の場所にデプロイする場合、または本番環境に向かっている場合は、適切なDockerfileを書くための30分を投資してください。その小さな初期コストは、1GBのイメージのデバッグ、遅いデプロイ、そして進化しなくなったビルドツールからの解放をもたらします。

ソース

• Why We're Moving on From Nix - Railway Blog
• Nixpacks Official Documentation
• Replacing Nixpack with a Docker Image on Railway - Apvarun
• Docker Best Practices - Official Documentation
• Railpack Official Documentation
• Nixpacks GitHub Repository