Caddy: Automatic HTTPS for Multiple Apps on One Server
Serve many apps over HTTPS with zero certificate management using a single, tiny Caddyfile.
Cloud & DevOpsPDF · 5 pages· v1.0
4.6Serve many apps over HTTPS with zero certificate management using a single, tiny Caddyfile.
Cloud & DevOpsPDF · 5 pages· v1.0
4.6A short, high-value guide to using Caddy as a reverse proxy that gives every app on your server automatic, auto-renewing HTTPS — with a configuration file so simple it fits on a postcard. If wrangling Nginx server blocks and Certbot feels like more ceremony than you want, Caddy is the answer: it obtains and renews Let's Encrypt certificates automatically the first time a domain is requested, and its config is dramatically shorter. This guide shows you how to install Caddy from its official repository, write a Caddyfile that reverse-proxies several apps on different subdomains, run it as a managed service, and reload config with zero downtime. You'll also learn the handful of things worth knowing: how Caddy stores certificates, how to add security headers and gzip in one line, how to serve static files alongside proxied apps, and how to debug the rare case where automatic certificate issuance fails. After this guide you'll be able to add a new HTTPS site by appending a few lines to one file and reloading — no manual certificates, no renewal cron, no per-site boilerplate. Free, because it's a genuinely useful tool more people should know.
Caddy gets and renews certificates automatically with no Certbot and far less config. The trade-off is less ecosystem familiarity; the guide covers the essentials you need.
Yes. Like any public CA, Let's Encrypt issues for domains. Caddy needs ports 80 and 443 open to validate.
Yes — that's the whole point. Each site is a few lines in one Caddyfile, each gets its own automatic certificate.
Usually DNS or a blocked port. The guide includes a short troubleshooting section and shows where Caddy logs the reason.
Read the full refund policy and trust & safety terms.