Other web servers and scripted certificate tools fall over with hundreds of thousands of sites or thousands of instances. Caddy is designed to manage certificates reliably at this scale.
Caddy is free software and relies on sponsorships to survive. Not just donations: sponsorships ensure ongoing development and provide your business with tangible benefits.
Caddy's TLS defaults are secure and pass PCI, HIPAA, and NIST compliance requirements. Yes, defaults: no hassle required.
</p>
</div>
<divclass="col">
<h3class="purple">HTTPS for localhost 🏠</h3>
<p>
We mean it when we say Caddy serves every site on HTTPS. Even localhost and internal IPs are served with TLS using the intermediate of a fully-automated, self-managed CA that is automatically installed into most local trust stores.
Simply configure multiple Caddy instances with the same storage, and they will automatically coordinate certificate management as a fleet and share resources such as keys and OCSP staples!
Not only is Caddy the industry leader in certificate automation, it also sports a fully-featured PKI suite for your own fully-automated internal PKI and private CAs.
Caddy will serve your localhost and internal sites over HTTPS using its own CA. And you can create your own CA to issue certs across your infrastructure. It has a built-in ACME server, powered by Smallstep, to automate your private PKI reliably at scale.
If you configure sites with local or internal addresses, Caddy will serve them over HTTPS using a locally-trusted certificate authority with short-lived, auto-renewing certificates. It even offers to install your unique root into your local trust stores for you.
Caddy lets you define as many CAs as you need. Root and intermediate keys are generated automatically, and intermediates are renewed before they expire.
Caddy is more than just a web server. For example, this config is all it takes to obtain and renew certificates for a set of domain names.
</p>
<p>
Additional config can be written to wire up certificate maintenance events, which can then be used to integrate with external scripts and tooling.
</p>
<!-- <p>
Caddy 2 is a <ahref="/docs/extending-caddy">highly extensible</a>, self-hosted platform on which you can build, configure, and deploy long-running services ("apps").
</p>
<p>
Caddy ships with apps for an <ahref="/docs/modules/http">HTTPS server</a> (static files, reverse proxying, load balancing, etc.), <ahref="/docs/modules/tls">TLS certificate manager</a>, and <ahref="/docs/modules/pki">fully-managed internal PKI</a>. Caddy apps collaborate to make complex infrastructure just work with fewer moving parts.
</p>
<p>
<b>For example, the config shown here keeps your TLS certificates renewed for other programs to use;</b> no external tools or HTTP daemon required!
</p>
<p>
Providing a unified configuration, on-line <ahref="/docs/api">config API</a>, and <ahref="/docs/json/">automatic documentation</a> for all apps, Caddy is nearly infinitely extensible. Thanks to its unique <ahref="/docs/architecture">modular architecture</a>, we can offer unlimited features without bloating the code base.
Caddy's proxy was designed to be as forward-compatible as possible and has major batteries included: load balancing, active and passive health checks, dynamic upstreams, retries, pluggable transports, and of course, best-in-class TLS security.
</p>
<divclass="asides asides-40-60">
<divclass="spacing">
<divclass="rollover"data-rollover="rollover-php">
<h3class="green">Proxy HTTP, FastCGI, WebSockets, and more</h3>
<p>
Capable of proxying HTTP and HTTPS, but also WebSockets, gRPC, FastCGI (usually PHP), and more! The underlying transport module is extensible for any custom way to generate an HTTP response.
Provide Caddy with a static list of backends or enable a module to retrieve backends dynamically during each request: ideal for rapidly changing environments. Caddy flows with your infrastructure!
</p>
</div>
<divclass="rollover"data-rollover="rollover-ha">
<h3class="blue">High availability</h3>
<p>
Caddy comes with a whole suite of high availability (HA) features: advanced health checking, graceful (hitless) config changes, circuit breaking, load limiting, on-line retries, and more. The best part? It's all free. No enterprise-level paywalls.
Without sponsorships, Caddy could stop being developed at any time.
With sponsorships, you gain peace of mind knowing that the project will continue to be developed, along with tangible benefits like private support and training.
Serving static files is a tried-and-true method of delivering sites to numerous clients efficiently. Caddy has a robust file server that can be combined with other middleware features for the ultimate effortless website.
Caddy can compress files on-the-fly or serve precompressed files for extra performance. Caddy is also the first web server to support Zstandard encoding.
</p>
</div>
<divclass="rollover"data-rollover="rollover-vfs">
<h3class="green">Virtual file systems</h3>
<p>
Serve your static site from anything: the local file system, remote cloud storage, a database, or even embedded in the server binary!
<h3class="yellow">Range requests, Etags, and more</h3>
<p>
Unlike many ad-hoc file servers intended for temporary local development, Caddy fully supports Range requests, Etags, and a full production feature set.
If a directory without an index file is requested, Caddy can show an elegant file browser with breadcrumb nav, file size visualizations, filetype icons, and a grid view.
Configure your server your way. Caddy's native configuration format is JSON, and with Caddy's config adapters, you can use any config format you prefer. All configuration is posted through a RESTful admin API, and Caddy's CLI helps you work with config files easily.
Caddy's native config format is JSON, giving you incredible power and flexibility for automated, large-scale deployments.
<p>
Make dynamic config changes through an <ahref="/docs/api">intuitive, programmable REST API</a> that offers ACID guarantees. It is also <b>safely scoped</b>, meaning that the URI path restricts changes, making it impossible to accidentally alter other parts of your config.
</p>
<!-- <ul>
<li><b>Atomic:</b> Multiple changes in a single request are treated as a single unit; any failed change aborts all the other changes.</li>
<li><b>Consistent:</b> No invalid configurations can be loaded; your server will never break if a problem is detected at config load.</li>
<li><b>Isolated:</b> No config changes rely on another. (It helps that HTTP is a stateless protocol!)</li>
<li><b>Durable:</b> Caddy automatically persists the current, valid configuration to disk and can safely resume it after a power cycle if the <code>--resume</code> flag is used.</li>
Although JSON offers ultimate control, most people prefer to use a <ahref="/docs/caddyfile">Caddyfile</a> because it lets you get a production-ready site up and running in just a few hand-written lines. It's not uncommon for Caddyfiles to be just <ahref="https://twitter.com/yakczar/status/713712646147743744">~15% the size of a less-capable nginx config</a>.
With first-class support for <ahref="/docs/config-adapters">config adaptation</a>, you can configure your web server with your favorite format: YAML, TOML, CUE, NGINX, HCL, Dhall, JSON with comments, or even a MySQL database... or anything else. The Caddyfile is a built-in config adapter.
Caddy is the only server in the world with its novel, modular architecture. At its core, Caddy is a configuration manager that runs apps like an HTTP server, internal certificate authority, TLS certificate manager, process supervisor, and more.
No RPC calls or flimsy dependency management. Plugins are compiled into the static binary, making successful deployments certain and runtimes blazing fast.
Caddy has the most robust TLS stack on the market. With stronger memory safety guarantees than OpenSSL (Apache & NGINX) and more advanced certificate automation logic than any other server or utility, Caddy keeps your sites online through problems when other servers... won't.
Caddy was the first server to fully automate public certificate management—so we've been doing this longer than anyone. With more than 50 million certificates under management, Caddy has set the gold standard for other servers to live up to.
Caddy automatically staples OCSP responses and caches them to weather outages. In 2018, many popular sites went down for users of mainstream browsers because crucial OCSP infrastructure had an extended outage. Only Caddy staples and caches OCSP responses by default, so all Caddy sites were unaffected.
In 2020, a mass certificate revocation event left many sysadmins scrambling to renew their certificates ahead of schedule. Caddy automatically renews certificates that get revoked, and all Caddy sites were unaffected. (This was before ARI existed.)
Companies have deployed Caddy in front of their site just hours before important audits—potentially saving their compliance status—because of Caddy's safe defaults and "batteries included" approach.
Academic and industry experts recommend Caddy, which has been cited in peer-reviewed journals for its security defaults, best practices, and its uniquely advanced feature set.
"Servers running Caddy exhibit nearly ubiquitous HTTPS deployment and use modern TLS configurations. ... We hope to see other popular server software follow Caddy's lead."
</p>
<pclass="cite">
—<b>Josh Aas, Richard Barnes, Benton Case, Zakir Durumeric, Peter Eckersley, Alan Flores-López, J. Alex Halderman, Jacob Hoffman-Andrews, James Kasten, Eric Rescorla, Seth Schoen, and Brad Warren.</b> 2019. <i>Let's Encrypt: An Automated Certificate Authority to Encrypt the Entire Web.</i> In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (CCS '19). Association for Computing Machinery, New York, NY, USA, 2473–2487. <ahref="https://doi.org/10.1145/3319535.3363192">https://doi.org/10.1145/3319535.3363192</a>
"TLS must be enabled by default ... and the Caddy web server is a good and usable example."
</p>
<pclass="cite">
—<b>Katharina Krombholz, Wilfried Mayer, Martin Schmiedecker, and Edgar Weippl.</b> 2017. <i>"I Have No Idea What I'm Doing" - On the Usability of Deploying HTTPS.</i> In 26th USENIX Security Symposium (USENIX Security 17), USENIX Association, Vancouver, BC, 1339-1356. Retrieved from <ahref="https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/krombholz">https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/krombholz</a>
—<b>Drew Springall, Zakir Durumeric, and J. Alex Halderman.</b> 2016. <i>Measuring the Security Harm of TLS Crypto Shortcuts.</i> In Proceedings of the 2016 Internet Measurement Conference (IMC '16), Association for Computing Machinery, Santa Monica, California, USA, 33-47. <ahref="https://doi.org/10.1145/2987443.2987480">https://doi.org/10.1145/2987443.2987480</a>
