はじめに
Railsアプリを本番運用するとき、「前段にNginxを置くべきか？」で迷ったことはありませんか？
調べてみると「Nginxが必要な理由」はたくさん出てくるのに、「無くてもいいケース」の情報はあまり見つからない、という方も多いと思います。
確かに2020年ごろまでは、Railsの前段にNginxを置く構成がほぼ定番でした。ですが、Rails 7.2〜8にかけて状況は大きく変わっています。
この記事では、Rails 8時点での事実（静的ファイル配信のデフォルト化・標準同梱のThruster・Kamal 2）を踏まえて、「今のRailsにNginxは本当に必要なのか？」を判断基準つきで整理します。
結論：Rails 8では、多くのケースでNginxは不要
先に結論です。クラウド上でコンテナ（Docker）ベースに運用するなら、Rails 8では前段のNginxはほとんどのケースで不要になりました。
理由は大きく3つあります。順番に見ていきましょう。
- ① Rails自身が静的ファイルを配信するのがデフォルトになった
- ② Rails 8はThruster（キャッシュ・圧縮・X-Sendfile）を標準同梱している
- ③ Kamal 2のkamal-proxyがTLSとゼロダウンタイムデプロイを担う
理由①：Railsが静的ファイルを配信するのがデフォルトに
かつてRailsには、環境変数で静的ファイル（public/assets など）をRailsが配信するかどうかを切り替える設定がありました。
# 昔の config/environments/production.rb
config.public_file_server.enabled = ENV['RAILS_SERVE_STATIC_FILES'].present?この時代は、RAILS_SERVE_STATIC_FILES を設定しない限りRailsは静的ファイルを配信しませんでした。だからNginxで静的ファイルを配る必要があったわけですね。
ですが、DHHのプルリク（rails/rails#47137）で、静的ファイル配信はデフォルトで有効になりました。今のRails（7.1以降）では、生成される production.rb からこの行自体が消えています。
つまり、Rails 8を素直に使えば、追加設定なしでRailsが静的ファイルを返してくれます。「静的ファイルを配るためだけにNginxを置く」という理由は、もうほぼ無くなったということです。
理由②：Rails 8はThrusterを標準同梱している
「でも、静的ファイルのキャッシュや圧縮はNginxの仕事では？」と思うかもしれません。ここを埋めるのがRails 8から標準同梱された Thruster です。
Thrusterは、Pumaの前段で動く軽量なHTTP/2プロキシです。Rails 8のデフォルトのDockerfileに最初から組み込まれていて、次のような、これまでNginxに任せていた仕事を肩代わりします。
- 静的アセットのHTTPキャッシュ
- gzipによるレスポンス圧縮
- X-Sendfileによる効率的なファイル配信
- HTTP/2のサポート
- （オプション）Let's EncryptによるTLS自動取得
Rails 8のDockerfileでは、bin/thrust 経由でPumaを起動する形になっています。イメージとしては次のようなコマンドです。
# Rails 8 の Dockerfile（抜粋イメージ）
# Thruster が Puma をラップして起動する
CMD ["./bin/thrust", "./bin/rails", "server"]Thrusterはゼロコンフィグで動きますが、環境変数で細かく調整もできます。よく使うものだけ挙げておきます。
# Thruster の主な環境変数
TARGET_PORT=3000 # 背後の Puma のポート
HTTP_PORT=80 # Thruster が待ち受けるポート
CACHE_SIZE=67108864 # キャッシュサイズ（バイト）
GZIP_COMPRESSION_ENABLED=true # gzip 圧縮の有効/無効
TLS_DOMAIN=example.com # 指定すると Let's Encrypt で TLS を自動取得ポイントは、これらが「Nginxの設定ファイルを書かずに」環境変数だけで済むことです。小規模チームにとっては、この差はかなり大きいと思います。
理由③：Kamal 2のkamal-proxyがTLSとデプロイを担う
本番でもう一つ気になるのが「TLS（HTTPS）」と「無停止デプロイ」です。ここはRails 8に同梱される Kamal 2 がカバーします。
Kamal 2では、これまでのTraefikに代わって kamal-proxy という専用リバースプロキシが導入されました。これがホスト側で次の役割を担います。
- Let's Encryptによる証明書の自動取得・更新（TLS終端）
- ゼロダウンタイムのローリングデプロイ
- 1台のサーバーで複数アプリをホストするルーティング
役割分担を整理すると、ホスト側でkamal-proxyがTLSを終端し、コンテナ内ではThrusterがキャッシュ・圧縮・X-Sendfileを担当し、その背後でPumaがRailsを動かす、という3層構成になります。この並びに、Nginxが入る隙間はほとんどありません。
Kamalを使った具体的なデプロイ手順は、別記事のRails 8 × Kamal 2でAWSにデプロイする手順【2026年版】で解説しているので、あわせて読んでみてください。
それでもNginxを前段に置くケース
とはいえ、Nginxが完全に不要になったわけではありません。次のようなケースでは、今でも前段にNginxを置く選択肢は有効です。
- 複雑なリライト・リダイレクトやパスベースのルーティングを細かく制御したい
- Rails外で大きな静的ファイルや動画を直接配信したい
- WAF・レートリミット・IP制限などをプロキシ層で入れたい
- すでにNginx前提のオンプレ/既存インフラがあり、運用ノウハウが揃っている
- コンテナ化しておらず、1台に複数の非コンテナアプリを同居させている
逆に言うと、これらに当てはまらない「コンテナ＋クラウド」の標準的なRailsアプリなら、Nginxを外して構成をシンプルにできる、ということです。
背景：DHH自身のコメント
この流れは、Railsの生みの親であるDHHのコメントからも読み取れます。前述のプルリク（rails/rails#47137）には、次のような趣旨のコメントがありました（翻訳）。
最新のデプロイメントでは、CDNやキャッシュLBを前面に使用する場合、NGINX/Apacheは必要ありません。つまり、ファイル配信もすぐに動作します。
rails/rails#47137
そしてRails 8のリリースでは「No PaaS Required（PaaSはもう要らない）」というテーマが掲げられ、ThrusterとKamalによって、自前のサーバーでも手軽に本番運用できる世界観が打ち出されました。Nginxを外す流れは、Railsコアチームの明確な方針でもあるわけですね。
railsの前段にnginxを配置するかどうか疑問だったけど、このプルリクを見るとデフォルトで静的ファイル配信を行うようになっているから、nginxの代わりにCDNを前段に置く構成で良さそうhttps://t.co/yztmAwHA2c
— Takuya Harayama (@harayama22) July 17, 2024
まとめ
Rails 8時点での「Railsの前段にNginxは必要か？」の答えを整理します。
- 静的ファイル配信はデフォルトで有効。Railsだけで返せる
- Thrusterが標準同梱され、キャッシュ・圧縮・X-Sendfile・HTTP/2をカバー
- Kamal 2のkamal-proxyがTLSとゼロダウンタイムデプロイを担う
- だから「コンテナ＋クラウド」の標準構成なら、多くの場合Nginxは不要
- 複雑なルーティング・WAF・既存インフラなど、明確な理由があるときだけ前段に置く
個人的にも、管理コストを増やすNginxは「理由があるときだけ足す」くらいのスタンスが、今のRailsには合っていると思います。まずはRails標準の構成から始めて、必要になったら足す——という順番がおすすめです。
スポンサーリンク
コメント
Comments are closed.