Next.js / FastAPI / Rails 作れるけど踏みとどまっていた公開。そんなとき Caddy という選択。

Next.js も FastAPI も Rails も作れる。
でも「公開する」となると、急に nginx が重く見えて足が止まる。
そんなとき、最初の一歩として Caddy はいい選択かもしれません。

Next.js でも FastAPI でも Rails でも、ローカルで動かすところまでは行ける。
でも「じゃあこれを外に公開しよう」となった瞬間に、急に足が止まることがあります。

nginx の名前は知ってる。
たぶん前段に置くやつだよね、くらいの感覚もある。
でも、設定ファイルを見るとちょっと身構える。server、location、HTTPS、証明書、リバースプロキシ、ヘッダー……。
最初の一歩としては、少し情報量が多い。

そういう人にとって、まずは Caddy から入る というのは、良い選択肢だと思ってます。
Caddy は公式に automatic HTTPS を大きな特徴として掲げていて、証明書の取得・更新や HTTP から HTTPS へのリダイレクトを自動で扱います。
さらに、公式の reverse proxy quick-start も 「production-ready な reverse proxy をすばやく立ち上げる」 ことを前提に作られてます。
https://caddyserver.com/docs/automatic-https
https://caddyserver.com/docs/quick-starts/reverse-proxy

freelance-engineer.net では、エンジニアの価値は「コードが書けること」だけでなく、それを世に出せること にもあると考えてます。
ただ、最初から全部を重く理解しきる必要はない。

• まずは公開の流れを掴む。
• まずは外に出してみる。

そういう入口として、Caddy はいいと思います。
これは Caddy のドキュメント構成自体が、まず動かすことを重視している点からも読み取れます。
https://caddyserver.com/docs/quick-starts

Caddy が最初の一歩としてちょうどいい理由

Caddy の良さは、まず 見た目が軽い 。
ここでいう軽いは、性能の絶対比較というより、設定の理解コストが軽い という意味です。

ホスト名と宛先を書く。
以上！

しかも、ホスト名があれば HTTPS まで面倒を見てくれます。
Caddy の公式ドキュメントでも、automatic HTTPS は 「自動かつデフォルト」 で働く機能として説明されてます。
https://caddyserver.com/docs/automatic-https

インフラ初学者にとって大事なのは、細かい最適化より先に、

• アプリをローカルポートで動かす
• 前段で受ける
• ドメインで公開する
• HTTPS で配信する

この流れが腑に落ちることだと思ってます。
Caddy は、この一連の流れを比較的少ない設定で体験しやすい。
公開の全体像を掴むための入口 として扱いやすいです。
Caddy の quick-start 群も「多くの説明を挟まず、まず起動する」方針で書かれてます。
https://caddyserver.com/docs/quick-starts/reverse-proxy

たとえば設定はこれくらい違う

たとえば、127.0.0.1:3000 で動いてる Next.js や FastAPI や Rails を example.com で受けたい、だけならこんな感じです。

nginx

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

「これでリバースプロキシなん？ リバースってなんなのよ？」って思いましたよ｡｡｡

Caddy

example.com {
    reverse_proxy 127.0.0.1:3000
}

「あ、これがリバースプロキシなのね？」ってなりません？それがこれか！って｡｡｡

もちろん、実運用ではどちらも追加設定は入ります。
ただ、最初の見え方 の差は大きいです。
Caddy の公式 quick-start も、まずはバックエンドを 127.0.0.1 で動かして reverse proxy する流れを前提にしてます。
https://caddyserver.com/docs/quick-starts/reverse-proxy

この差は、初学者にとって重要です。
最初に「これなら読めるかも」と思えることは、そのまま学習継続率に効きます。
全部を理解してから公開するのではなく、公開しながら理解していける 形に乗せやすいのが、Caddy の強みだと思います。

Next.js / FastAPI / Rails みたいな構成と相性がいい

ここで言いたいのは、Caddy が特定フレームワーク専用に強い、という話ではありません。
むしろ逆で、最近の Web アプリは アプリケーションをローカルポートで動かして、前段の Web サーバで受ける 形にしやすいものが多いです。

なので、Next.js でも FastAPI でも Rails でも、まずは

• アプリを起動する
• Caddy で受ける
• ドメインで公開する

という流れに乗せやすい。
Caddy は公式トップでも automatic HTTPS を備えたオープンソース Web サーバとして案内されていて、公式 reverse proxy ドキュメントでも load balancing や health checks を含む拡張が説明されてます。
小〜中規模の HTTP 公開用途では扱いやすい。
https://caddyserver.com/
https://caddyserver.com/docs/caddyfile/directives/reverse_proxy

今どきは前段がマネージドなことも多い

実際のお仕事では、外部公開の前段に最初から CDN や managed edge が入ることも多いです。
たとえば CloudFront は、静的・動的コンテンツをエッジロケーションから配信し、オリジンには S3 や HTTP サーバを指定できます。
Cloudflare も、トラフィックが Cloudflare の reverse proxy を通って origin に届く前提で、多くの機能を提供してます。
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html
https://developers.cloudflare.com/support/troubleshooting/restoring-visitor-ips/restoring-original-visitor-ips/

そう考えると、nginx の多機能さを最初から全部背負わなくてもよい場面は多いです。
CDN、TLS 終端、キャッシュ、保護の一部を managed service 側に寄せて、origin 側はシンプルな HTTP サーバ + Caddy で十分、という考え方。
Caddy を選ぶことは「nginx を避ける」ではなく、今どきの責務分割に合わせて origin を軽くする方向性としていいと思います。
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html
https://developers.cloudflare.com/dns/proxy-status/

「じゃあ nginx はもういらない？」は違う

まだ nginx は主役ですかねぇ

nginx は今でも公式に、HTTP web server、reverse proxy、content cache、load balancer、TCP/UDP proxy、mail proxy server として案内されてます。
つまり、単なる「Web アプリの前段」にとどまらない、広い守備範囲を持ってます。
さらに公式ドキュメントには、HTTPS 設定、HTTP load balancer、TCP/UDP セッション処理、njs scripting などの章があります。
https://nginx.org/en/
https://docs.nginx.com/nginx/admin-guide/web-server/web-server/
https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/
https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-http/
https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/
https://docs.nginx.com/nginx/admin-guide/dynamic-modules/nginscript/

nginx は、今でも

• より広い用途を持てる
• より細かい制御ができる
• 情報量がとても多い
• 既存構成や複雑構成とつなぎやすい

という強みがあります。

• Caddy は入口として軽い
• nginx は王道として厚い

まずはこれでよさそうです。
nginx の公式の打ち出し自体が、その「厚さ」を示してます。
https://nginx.org/en/

Caddy にできなくて nginx にできること、というより「守備範囲の思想が違う」

雑に「Caddy では無理」と言い切るつもりはなく、nginx の方が標準で広く持っている領域がある と捉えるといいと思ってます。

nginx は公式に content cache、TCP/UDP proxy、mail proxy を前面に出してます。
対して Caddy が前面に出しているのは、automatic HTTPS と reverse proxy の分かりやすさです。
Caddy にもモジュール拡張はありますが、少なくとも公式トップや入門導線の主戦場は HTTP 公開です。
https://nginx.org/en/
https://caddyserver.com/
https://caddyserver.com/docs/automatic-https

たとえば

• L4 も含めて扱いたい
• メールまわりも視野に入る
• キャッシュも含めてしっかり設計したい
• 複雑な既存構成にきめ細かく合わせたい

みたいな場面では、 nginx の存在感はある。
最初の一歩として Caddy が良い、という話と、実務の王道として nginx が強い という話はそれぞれあります。
https://nginx.org/en/

大規模運用の話になると、今のところは nginx 感

2026年4月5日時点の W3Techs では、公開 Web のうち Web サーバが判明しているサイトベースで、nginx は 32.7%、Caddy は 0.2% とされてます。
公開 Web 全体の「王道感」という意味では、まだ nginx は大きいです。
https://w3techs.com/technologies/comparison/ws-caddy,ws-nginx

もちろん、シェアが高いから即優れている、ということじゃない。
ただ、大規模運用や複雑運用では、

• 事例・知見・前例・ネット情報が多い
• トラブル時に検索しやすい
• 脆弱性対応やアップデート実績への信頼

という現実的な強みが効いてます。
この意味で、「さすがに今のところ大規模は nginx だよね」 という感覚でいいと思います。
https://w3techs.com/technologies/comparison/ws-caddy,ws-nginx

そもそもなぜそんなに nginx なのか？ Caddy でもよくない？

指摘を恐れずに言うと、公開用途の概ねのニーズは Apache でも nginx でも成立することが多いと思ってます。
それでも「今採用するなら、ひとまず nginx でしょ」となりやすいのは、nginx が十分な守備範囲の広さで、採用・運用実績を積んできたからでしょう。

私はそこに Caddy の出番があると思ってます。
結局みんな、最初は

• よく使われていて、情報が多くて、だいたい困らないもの

から入るわけです。
だったら、今の時代に、小〜中規模の HTTP 公開を素直に始めやすいものとして Caddy が刺さる事例も積み上がると思ってます。（実際私には刺さってる）

最初に Caddy を触る価値

freelance-engineer.net としては、ここを大事にしたい。

敷居の高い情報より、まず一歩踏み出せる 方が価値が高いことありますよね。
最初から nginx を完璧に理解しなくていい。
まずは Caddy で、

• リバースプロキシってこういうことか
• 前段で受けるってこういうことか
• ドメインで公開するってこういうことか
• HTTPS を付けるってこういうことか

を掴む。
そのあとで必要に応じて nginx に進めばいい。
その順番は、逃げではなく、コスパだと思ってます。

実際、Caddy の quick-start 群は「すばやく立ち上げる」「多くの説明を挟みすぎない」という方針で作られてます。
学びの入口として使いやすいのは、単なる印象ではなく、ドキュメントの設計にも表れてます。
https://caddyserver.com/docs/quick-starts/reverse-proxy

まとめ

nginx は今でも強い。
守備範囲が広く、情報量も多く、大規模運用や複雑構成での安心感もある。公開 Web 全体のシェアを見ても、王道感はあります。
https://nginx.org/en/
https://w3techs.com/technologies/comparison/ws-caddy,ws-nginx

最初の学習対象としては Caddy も良い。
設定が短く、自動 HTTPS が強く、Web 公開の全体像を掴みやすい。
https://caddyserver.com/docs/automatic-https
https://caddyserver.com/docs/quick-starts/reverse-proxy

最初から全部を重く抱えなくていい。
まずは公開してみる。
まずは流れを掴む。

その入口として、Caddy はかなり優秀だと思ってます。

あとがき

nginx の「エンジンエックス」という響きがフツーにカッコイイ…
Caddy の「キャディ」が霞んで見える…