self-hosted 4 min read

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.

#github-trending #go #web-server#automatic-https #self-hosted
By
Share: X in
GitHub social preview card for caddyserver/caddy

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.

FieldValue
Full namecaddyserver/caddy
DescriptionFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS
Stars76,583
Forks5,048
Primary languageGo
LicenseApache-2.0
Topicsacme, automatic-https, caddy, caddyfile, go
Homepagehttps://caddyserver.com
Created2015-01-13
Last push2026-10-04
Owner typeOrganization

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.