What Is Caddy? The Web Server That Automates SSL Certificates

Serving a website or API over HTTPS used to mean a whole side-project of its own: generate a certificate signing request, get it signed by a CA, install it in the right format for your web server, and set a reminder to do it all again before it expired. Tools like Certbot automated pieces of this for Nginx and Apache, but you still had to install it, configure it, and trust that its renewal cron job kept running. Caddy takes a different approach — it treats HTTPS as the default, not an add-on.

The problem Caddy solves

Most of the pain in running HTTPS isn't the cryptography, it's the lifecycle management. Certificates from Let's Encrypt expire every 90 days, which means renewal has to happen reliably, unattended, indefinitely. Miss a renewal — because a cron job silently failed, a server was rebuilt without reconfiguring it, or nobody remembered a manual step — and visitors start seeing "Your connection is not private" errors instead of your site. Caddy was built specifically to remove that failure mode: certificate issuance and renewal are handled by the server process itself, not by a separate tool you have to remember to maintain.

How automatic HTTPS actually works

When Caddy starts serving a site, it checks whether it already has a valid certificate for that domain. If not, it requests one automatically from a certificate authority — Let's Encrypt by default — using the ACME protocol, the same standard Certbot uses under the hood. Caddy proves it controls the domain by completing a challenge: typically an HTTP-01 challenge, where it briefly serves a specific file at a well-known URL that the CA fetches to confirm ownership, or a TLS-ALPN-01 challenge, which does the same proof directly over a TLS handshake without needing port 80 at all. Once the CA is satisfied, it issues the certificate, and Caddy stores it locally and starts serving traffic over HTTPS immediately — no separate install step.

From then on, Caddy tracks each certificate's expiry in the background and renews it automatically, well before the 90-day window runs out. There's no cron job to configure and nothing to forget — it's a property of the running server, not a script bolted on next to it.

Config that matches the simplicity

This philosophy carries into Caddy's configuration format, the Caddyfile. A working HTTPS reverse proxy for a domain can be as short as:

example.com {
    reverse_proxy localhost:3000
}

That's the entire configuration — no separate certificate paths, no manual HTTP-to-HTTPS redirect rule, no listen directives for port 443. Caddy infers all of it from the domain name in the block and handles the redirect and certificate automatically.

On-demand TLS for many domains

Caddy can also issue certificates on demand, the first time a request for a given domain actually arrives, rather than requiring every domain to be listed in the config ahead of time. This matters for any platform that lets customers bring their own custom domains — you don't want to hand-edit a config file and restart a server every time someone adds one. Caddy can be configured to check an endpoint you control to confirm a domain is legitimate before requesting a certificate for it, then issue and renew that certificate automatically, the same as any statically configured one.

Why this matters for status pages

A status page is exactly the kind of thing people expect to load instantly and securely, especially during an incident when they're actively checking whether it's safe to trust. Whether it's served from a subdomain or a fully custom domain a customer brings themselves, the certificate behind it needs to exist, be valid, and stay valid without anyone having to remember a renewal date. That's the whole point of automatic HTTPS — it's infrastructure that's supposed to be invisible when it's working.