Caddy: web server with automatic HTTPS by default
Caddy is an Apache-2.0 licensed Go web server with 76,583 stars that automates HTTPS through ACME and speaks HTTP/1, 2 and 3 across platforms.
TL;DR: Caddy is a Go web server with 76,583 stars and 5,048 forks that has been shipping since January 2015. Its whole reason for existing is in the description: automatic HTTPS, handled through ACME, with HTTP/1, HTTP/2 and HTTP/3 support and an Apache-2.0 license. The configuration file format, Caddyfile, is one of its five published topics.
What it is
Caddy is a web server, and the specific thing it does differently from nginx or Apache is certificate lifecycle management. Most servers treat TLS as configuration you write and certificates as files you obtain out of band. Caddy treats TLS as something the server handles for you, obtaining and renewing certificates through ACME as a normal part of running.
| Field | Value |
|---|---|
| Full name | caddyserver/caddy |
| Description | Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS |
| Stars | 76,583 |
| Forks | 5,048 |
| Primary language | Go |
| License | Apache-2.0 |
| Topics | acme, automatic-https, caddy, caddyfile, go |
| Homepage | https://caddyserver.com |
| Created | 2015-01-13 |
| Last push | 2026-10-04 |
| Owner type | Organization |
The acme and automatic-https topics make the mechanism explicit, and caddyfile is there because the config format is a real part of the project’s identity. Worth noting the age: created in January 2015 and pushed to the day before this post, so this is an eleven-year-old project with current commits. That combination is rarer in infrastructure than it should be.
Why automatic HTTPS is the whole pitch
Getting TLS right is mostly administrative work, and administrative work is exactly the kind of thing that quietly rots. A certificate expires at the worst moment, a renewal fails because a DNS record moved, and the failure surfaces as a browser warning that everyone learns to click through. Folding that into the server’s normal operation removes a category of incident.
The multi-platform claim in the description is the other half. caddyfile in the topic list suggests the configuration is a single text file rather than generated from a template, which is the part that makes the automatic behaviour tolerable across environments, since the config you move between machines is the same file.
What the license means for you
Apache-2.0 is permissive and includes an explicit patent grant, which is why it is a common default for infrastructure that companies run unmodified in production. If you are self-hosting Caddy, the license is not a consideration. If you are considering a derivative, the patent clause is the reason Apache-2.0 is generally preferred over MIT for server software.
How to try it
Caddy publishes its own docs at caddyserver.com. The fastest evaluation is a container with a site block pointed at a local port, since the automatic HTTPS behaviour is the part worth seeing rather than the request handling:
docker run -p 80:80 caddy
From a clone, the build path is the standard Go one, and the caddy module is the same binary that packages produce:
git clone https://github.com/caddyserver/caddy.git
cd caddy
go build
To check what the project publishes as its own metadata without cloning, the API endpoint is authoritative for the language, license and topic list:
curl -s https://api.github.com/repos/caddyserver/caddy \
| jq '{topics, language, license: .license.spdx_id, stars: .stargazers_count}'
When to use it and when not to
Reach for Caddy when you are standing up something on the public internet and you do not want TLS to be a separate system with its own failure modes. The automatic certificate handling pays for itself quickly on anything that has more than one hostname.
Think twice if you need HTTP/2 tunnelling or the very specific proxy behaviours you already depend on, because Caddy is a different architecture rather than a drop-in replacement for an existing config. The eleven-year history helps here: this is a project with a long record of shipping, not an experiment that trended for a week.
Source and Accuracy Notes
- Project page: https://caddyserver.com
- Source repository: github.com/caddyserver/caddy (verified via GitHub API
html_url) - License: Apache-2.0 (verified via GitHub API
license.spdx_id) - Stars at time of writing: 76,583
- Forks at time of writing: 5,048
- Facts in this post come from the GitHub API repository endpoint and the repository description only. The README was not fetched, so no module list, directive reference or benchmark is claimed here beyond what the description, topics, language and license fields state.
Related Posts
dev-tools
Automotive Skills Suite for AI Engineering
Evaluate Automotive Skills Suite for APQP, ASPICE, HARA, safety-plan, and DIA workflows with setup notes, governance risks, and SME review guidance.
5/28/2026
dev-tools
awesome-agentic-ai-zh Roadmap Guide
Explore awesome-agentic-ai-zh as a Chinese agentic AI learning roadmap, with setup notes, track selection, study workflow, and evaluation guidance.
5/28/2026
dev-tools
Baguette iOS Simulator Automation Guide
Set up Baguette for iOS Simulator automation, web dashboards, device farms, gesture input, streaming, and camera testing with Xcode caveats.
5/28/2026