Development & infrastructureCaddy projectOpen source
Caddy
Decision matrix
Caddy runtime decision matrix
Overview
Caddy is a free, open-source web server and reverse proxy that provisions and renews HTTPS certificates automatically, so putting a self-hosted app behind a real domain takes a few lines of config instead of a manual certificate process. Pick it for any self-hosted service you're exposing publicly; pick your platform's built-in proxy when it already does the job.
Other good fits
A small homelab or single-server setup where a short Caddyfile is easier to maintain than a full nginx configuration.
+ Pros
Read pros
Caddy is a web server and reverse proxy: point it at a domain and a backend service, and it fetches, installs and renews a real HTTPS certificate automatically, falling back from Let's Encrypt to ZeroSSL if needed. It's free, open source, and a small Caddyfile can replace what would otherwise be a manual nginx-plus-Certbot setup.
Pick it when…
You're exposing a self-hosted app to the internet and want HTTPS handled for you, not configured by hand.
You want a short, readable configuration file instead of a longer nginx config for a simple reverse-proxy case.
You're comfortable running one more service alongside the app you're actually trying to expose.
− Cons
Read cons
HTTPS protects the connection, not who's allowed to use the app behind it; Caddy won't fix a backend with no login screen or a leaked secret. Automatic HTTPS only fires when the public DNS and port requirements are actually met, so a misconfigured domain or a blocked port 80 will quietly leave you on plain HTTP.
Pick something else when…
Your hosting platform already terminates HTTPS. If you deploy through Dokploy or a similar platform, check whether it's already doing this before adding another layer.
You need the largest ecosystem of guides and third-party modules. nginx has more of both, at the cost of a more verbose configuration syntax.
Avoid if
You need the widest possible ecosystem of tutorials and third-party modules; nginx has a much larger one.
Requirements
For automatic public HTTPS, your domain's A/AAAA DNS records must point at the server, ports 80 and 443 must be reachable from the internet, and Caddy needs a writable, persistent data directory to store certificates and keys across restarts. None of that is needed for local, plaintext testing.
First run
Documentation-based suggestion — not run here.
Route a local test service through Caddy before you touch a real domain. Run a harmless demo backend on 127.0.0.1:9000 that returns a fixed message, then:
Request it from another terminal with curl -v http://127.0.0.1:2080 and confirm the backend's response comes back through Caddy. Only after this works locally should you point a real domain at a real server and let Caddy fetch a certificate.
Integration
Caddy can run in the foreground (caddy run), as a background service, or reload configuration without dropping connections. It sits in front of any HTTP backend, so it works with almost anything you're already self-hosting, an n8n instance, a Gitea server, a small API, without those apps needing to know Caddy is there.
Check the result
Compare the response Caddy forwards against a direct request to the backend; they should match. If you get a gateway error, check the backend address and whether it's actually running before touching certificate settings, which aren't involved in a local, plaintext test at all.
Links & evidence
Documentation-based · not hands-on · Sep 23, 2026
Rests on Caddy's reverse-proxy quick start, its automatic HTTPS documentation and its command reference, read on 2026-09-23. No Caddy process was run for this review.
Automatic HTTPS · Sep 23, 2026 — DNS/port/storage requirements, Let's Encrypt with ZeroSSL fallback, free and open source.
Caddy command reference · Sep 23, 2026 — Foreground/background run modes and zero-downtime config reload.
Further review notes & alternatives
Costs and operating effort
Caddy itself is free, open-source software, and the certificates it fetches from Let's Encrypt or ZeroSSL are free too; you pay only for the machine you run it on. The ongoing work is keeping the Caddyfile in sync with whatever you're exposing, and making sure the certificate data directory survives backups and restarts. There's no subscription, credit system or usage cap to track.
Restrictions
A client-facing HTTPS connection doesn't automatically encrypt the connection from Caddy to its backend; configure and trust that upstream connection separately if it matters. Local HTTPS testing uses Caddy's own local certificate authority, which your machine has to be told to trust; it's a different path from the public Let's Encrypt/ZeroSSL flow.
Alternatives and trade-offs
nginx wins when you want the most widely deployed reverse proxy with the largest base of existing tutorials, at the cost of manual certificate setup unless you add Certbot.
Traefik wins when you're running containers and want the proxy to auto-discover services from Docker labels.
Your platform's built-in proxy (on Dokploy or similar) wins when it already handles HTTPS and you'd just be adding a redundant layer.
Route web traffic through a reverse proxy that can obtain HTTPS automatically.
Choose it when one TLS entry point should front private application ports.
Its automatic certificates reduce routine certificate configuration work.