What it is
Caddy is a web server and reverse proxy written in Go. It is often chosen for automatic HTTPS: the server can obtain and renew TLS certificates, reducing manual work with ACME clients and cron scripts.
The caddyserver/caddy repository has been on GitHub since 2015. Its primary language is Go, the license is Apache-2.0, and the official site is caddyserver.com. Topics include automatic-https, http3, reverse-proxy, tls, and web-server.
What is inside
Inside are the Caddy server, module system, Caddyfile configuration, HTTP/1, HTTP/2 and HTTP/3 support, reverse proxy, TLS logic, and documentation. Caddy can be used as a static server, a proxy in front of an application, or an extensible platform for modules.
A simple Caddyfile
This example shows the typical simplicity: a domain, reverse proxy to a local application, and HTTPS that Caddy usually handles automatically when DNS is configured correctly.
example.com {
reverse_proxy 127.0.0.1:3000
}
static.example.com {
root * /var/www/site
file_server
}Where it helps
Caddy helps with small sites, personal services, internal dashboards, microservices, APIs, and cases where HTTPS needs to be placed in front of an application quickly and safely. It is especially pleasant when Nginx configuration feels too noisy for a simple task.
In more complex systems, Caddy can sit alongside Kubernetes, containers, load balancers, and services. Its core value remains clear configuration and good TLS behavior by default.
Strengths and tradeoffs
The strength is certificate automation and readable setup. For many projects, that lowers the chance of forgetting TLS renewal or building fragile multi-file configuration.
The tradeoff is habits and ecosystem fit. Organizations already invested in Nginx, Envoy, or Apache need to check modules, logging, observability processes, and team skills. Simplicity does not remove the need for tests before production deployment.