製品プロフィール

Caddy

Matt Holt / 2015年登場

Let’s Encrypt による HTTPS を自動化する新しい Web サーバ。設定が極めて簡単で、単一バイナリで動く。

3つの要点
TL;DR
  1. HTTPS を自動取得する新しい Web サーバ。
  2. 設定が極めて簡単で単一バイナリで動くのが強み。
  3. 手軽に HTTPS 化したいなら Nginx より Caddy。

基本情報

仕様と立ち位置

公開規模・コミュニティ・成熟度を比較できる指標です。GitHub / npm は2026年6月7日時点のスナップショットです。

製品・技術の概要CaddyLet’s Encrypt による HTTPS を自動化する新しい Web サーバ。設定が極めて簡単で、単一バイナリで動く。
GitHub Stars
73.2K2026-06-07時点
Forks
4.8KGitHub / コミュニティ規模
公開から
約11年2015年リリース
主要用途
2領域自動HTTPS / Proxy
最大の強み
HTTPS を自動取得更新設定が極めて簡単(Caddyfile)
代表的な用途
手軽に HTTPS 化小〜中規模サイト / リバースプロキシ
種別
Web サーバ自動 HTTPS)
ベース
Go
登場
2015年
作者
Matt Holt

選定ガイド

選定ポイント

採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。

採用に向く条件

選ぶ理由

  1. HTTPS を自動取得・更新
  2. 設定が極めて簡単(Caddyfile)
  3. 単一バイナリ・Go 製で手軽

事前に確認する条件

考慮すべき点

  1. 実績は Nginx/Apache に劣る
  2. 超大規模の知見が少なめ

詳しい解説

もっと詳しく

どんなサーバーか

Caddy(キャディ)は、Matt Holt 氏が開発し 2015 年に公開した Web サーバーです。Go 言語で書かれ、HTTPS をはじめから簡単に扱えることを最大の売りにしています。

横にスクロール

Caddyが対象ドメインの証明書を自動取得・更新してHTTPSを受け、マッチャーとハンドラー列から静的ファイルまたはリバースプロキシへ振り分け、上流応答をプロキシ経由で利用者へ返す経路と、オンデマンドTLSの許可確認
Caddyは証明書とHTTPS転送を自動管理します。要求は静的配信か上流往復へ分岐し、オンデマンドTLSでは発行許可を制限します。

設定の手軽さと運用のしやすさを重視した、比較的新しい世代の Web サーバー/リバースプロキシです。

仕組み・アーキテクチャ

最大の特徴は ACME プロトコル(Let's Encrypt 等)と連携した HTTPS の自動化です。ドメインを設定するだけで証明書を自動で取得・更新し、有効期限切れも自前で面倒を見ます。さらに既定で HTTPS が標準(自動リダイレクト) という思想で、TLS まわりの手作業がほぼ不要になります。ローカル開発では内部 CA を使って自己署名証明書を自動発行する仕組みもあります。

設定は Caddyfile という簡潔な形式で書け、数行で公開できます。

example.com {
    reverse_proxy localhost:8080
}

Go 製のため単一バイナリ・依存なしで動き、配布が容易です。内部は HTTP/1.1・HTTP/2・HTTP/3 に対応し、機能はプラグイン(モジュール)で拡張できます。設定は JSON 構造が基盤で、Caddyfile はその簡易表記にあたります。稼働中に 管理 API 経由で設定を動的変更できる点も特徴です。

得意・不得意

  • HTTPS の取得・更新が自動で、TLS の運用負担が小さい。
  • Caddyfile が読みやすく、最小限の設定で動かせる。
  • 単一バイナリで導入・配布が簡単。HTTP/3 にも標準対応。
  • 反面、実績の蓄積は Nginx/Apache に及ばず、超大規模・特殊構成の知見や事例は相対的に少ない。プラグイン追加にはビルドが絡む場合がある。

Nginx との違い

観点CaddyNginx
HTTPS自動取得・更新が標準証明書は自前で用意・更新設定
設定Caddyfile が極めて簡潔高機能だが記述量は多め
配布単一バイナリ・依存なしパッケージ導入が一般的
実績・事例新しめ・蓄積はこれから膨大・大規模運用の定番
拡張モジュール(要ビルドの場合あり)モジュール/OpenResty 等

いつ使うか

個人サイトや小〜中規模のサービス、社内ツールなど、HTTPS を手早く・確実に立ち上げたい場面に向きます。

まず HTTPS を確実に

証明書の取得・更新が標準で自動化されているため、TLS の設定や更新忘れによる失効事故を避けたい構成では特に有効です。手間を最小化したいなら有力ですが、長期運用の枯れた知見や大規模実績を重視するなら定番勢も比較検討します。

総じて Caddy は、HTTPS 自動化と設定の簡潔さで「立ち上げの速さ」に強みを持つ、現代的な Web サーバー/リバースプロキシです。

実装・運用の視点

Caddyを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

手軽に HTTPS 化

比較で見る軸

GitHub Stars: 73.2K / Forks: 4.8K / 公開から: 約11年

導入後に効く点

設定が極めて簡単(Caddyfile)

先に潰すリスク

実績は Nginx/Apache に劣る

数字・仕様の読み方
GitHub Stars
73.2K
2026-06-07時点
Forks
4.8K
GitHub / コミュニティ規模
公開から
約11年
2015年リリース
主要用途
2領域
自動HTTPS / Proxy

判断チェックリスト

  • 自社の用途が「手軽に HTTPS 化 / 小〜中規模サイト / リバースプロキシ」に近いか確認する。
  • 強みである「HTTPS を自動取得・更新」が本当に評価軸になるか確認する。
  • 注意点の「実績は Nginx/Apache に劣る」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

手軽に HTTPS 化小〜中規模サイト / リバースプロキシ

向いている用途

こんな用途に向く

手軽に HTTPS 化小〜中規模サイト / リバースプロキシ
公式サイト