HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
caddyserver
caddy
Go2015–2026
caddyserver / caddy

caddy

Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS

120Distinct people
214Mentions
2Explicit recommenders
79KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

Hmm, went into this article skeptical, but came out agreeing with it more than I expected. Makes some excellent points, and highlights some real challenges of the ecosystem.…

mholt used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:03:30 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year214 dated mentions

Observed mentions: 2015-04-28 15:00:32 UTC to 2026-10-06 13:28:50 UTC.

0102030402015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 11 mentions; 1 submissions, 10 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 40 mentions; 2 submissions, 38 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 22 mentions; 4 submissions, 18 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 28 mentions; 3 submissions, 25 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 11 mentions; 3 submissions, 8 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 36 mentions; 4 submissions, 32 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 21 mentions; 1 submissions, 20 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 13 mentions; 1 submissions, 12 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 9 mentions; 2 submissions, 7 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC11110
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC10010
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC40238
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC808
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC22418
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC28325
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC1138
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC36432
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC21120
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC13112
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC927
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC514

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
a project Every site on HTTPS Caddy is an extensible server platform that uses TLS by default. Releases · Documentation · Get Help           Powered by Special thanks to: Warp, built for coding with multiple AI agents Available for MacOS, Linux, & Windows Menu Features Install Build from source For development With version information and/or plugins Quick start Overview Full documentation Getting help About Features Easy configuration with the Caddyfile Powerful configuration with its native JSON config Dynamic configuration with the JSON API Config adapters if you don't like JSON Automatic HTTPS by default ZeroSSL and Let's Encrypt for public names Fully-managed local CA for internal names & IPs Can coordinate with other Caddy instances in a cluster Multi-issuer fallback Encrypted ClientHello (ECH) support Stays up when other servers go down due to TLS/OCSP/certificate-related issues Production-ready after serving trillions of requests and managing millions of TLS certificates Scales to hundreds of thousands of sites as proven in production HTTP/1.1, HTTP/2, and HTTP/3 all supported by default Highly extensible modular architecture lets Caddy do anything without bloat Runs anywhere with no external dependencies (not even libc) Written in Go, a language with higher memory safety guarantees than other servers Actually fun to use So much more to discover Install The simplest, cross-platform way to get started is to download Caddy from GitHub Releases and place the executable file in your PATH. See our online documentation for other install instructions. Build from source Requirements: Go 1.26.0 or newer For development Note: These steps will not embed proper version information. For that, please follow the instructions in the next section. $ git clone "https://github.com/caddyserver/caddy.git" $ cd caddy/cmd/caddy/ $ go build When you run Caddy, it may try to bind to low ports unless otherwise specified in your config. If your OS requires elevated privileges for this, you will need to give your new binary permission to do so. On Linux, this can be done easily with: sudo setcap cap_net_bind_service=+ep ./caddy If you prefer to use go run which only creates temporary binaries, you can still do this with the included setcap.sh like so: $ go run -exec ./setcap.sh main.go If you don't want to type your password for setcap, use sudo visudo to edit your sudoers file and allow your user account to run that command without a password, for example: username ALL=(ALL:ALL) NOPASSWD: /usr/sbin/setcap replacing username with your actual username. Please be careful and only do this if you know what you are doing! We are only qualified to document how to use Caddy, not Go tooling or your computer, and we are providing these instructions for convenience only; please learn how to use your own computer at your own risk and make any needful adjustments. Then you can run the tests in all modules or a specific one: $ go test ./... $ go test ./modules/caddyhttp/tracing/ With version information and/or plugins Using our builder tool, xcaddy... $ xcaddy build ...the following steps are automated: Create a new folder: mkdir caddy Change into it: cd caddy Copy Caddy's main.go into the empty folder. Add imports for any custom plugins you want to add. Initialize a Go module: go mod init caddy (Optional) Pin Caddy version: go get github.com/caddyserver/caddy/v2@version replacing version with a git tag, commit, or branch name. (Optional) Add plugins by adding their import: _ "import/path/here" Compile: go build -tags=nobadger,nomysql,nopgx Quick start The Caddy website has documentation that includes tutorials, quick-start guides, reference, and more. We recommend that all users -- regardless of experience level -- do our Getting Started guide to become familiar with using Caddy. If you've only got a minute, the website has several quick-start tutorials to choose from! However, after finishing a quick-start tutorial, please read more documentation to understand how the software works. 🙂 Overview Caddy is most often used as an HTTPS server, but it is suitable for any long-running Go program. First and foremost, it is a platform to run Go applications. Caddy "apps" are just Go programs that are implemented as Caddy modules. Two apps -- tls and http -- ship standard with Caddy. Caddy apps instantly benefit from automated documentation, graceful on-line config changes via API, and unification with other Caddy apps. Although JSON is Caddy's native config language, Caddy can accept input from config adapters which can essentially convert any config format of your choice into JSON: Caddyfile, JSON 5, YAML, TOML, NGINX config, and more. The primary way to configure Caddy is through its API, but if you prefer config files, the command-line interface supports those too. Caddy exposes an unprecedented level of control compared to any web server in existence. In Caddy, you are usually setting the actual values of the initialized types in memory that power everything from your HTTP handlers and TLS handshakes to your storage medium. Caddy is also ridiculously extensible, with a powerful plugin system that makes vast improvements over other web servers. To wield the power of this design, you need to know how the config document is structured. Please see our documentation site for details about Caddy's config structure. Nearly all of Caddy's configuration is contained in a single config document, rather than being scattered across CLI flags and env variables and a configuration file as with other web servers. This makes managing your server config more straightforward and reduces hidden variables/factors. Full documentation Our website has complete documentation: https://caddyserver.com/docs/ The docs are also open source. You can contribute to them here: https://github.com/caddyserver/website Getting help We advise companies using Caddy to
Read the full README on GitHub

What Hacker News says

11 sources
It wasn't a security incident, actually. It's true that "a GitHub bug caused it". It wasn't malicious. TLDR, a contributor made a tag on their own fork of Caddy, and for some reason our next release used their tag, because it turns out forks in GitHub aren't actual separate repos, but rather "still technically the same repo". It's really strange. Wasn't that contributor's fault either, they had no idea that would happen. All that happened is that the v2.2.2 git tag wasn't properly signed with Matt's signing key. There was no problem with the code at all. We've put in place checks during our CI actions to ensure that releases are always verified to be signed by Matt's key. See https://github.com/caddyserver/caddy/pull/3932 Specifically, commit https://github.com/caddyserver/caddy/commit/1d473ae924f0d52c... (which you'll notice is _not_ par
Read the rest
t of the Caddy repo, it was actually from a fork which was later deleted) triggered this GitHub Actions job for the release https://github.com/caddyserver/caddy/actions/runs/392345801 which we cancelled when we noticed it was happening. But we can't remove the tag from Go's caching server https://pkg.go.dev/github.com/caddyserver/caddy/v2@v2.2.2 so it's kinda there forever. More context: https://twitter.com/mholt6/status/1337879764317564928, https://twitter.com/danlsgiga/status/1338859470227529732, that whole twitter thread has many branches, so click around to get the whole conversation.
In Caddy – Open-source web server with automatic HTTPS
I really like Caddy and use it on a few projects. Its a good piece of software that generally just works. Their latest security incident leaves me feeling somewhat uneasy though. The only announcement for it was on twitter[1] and a footnote on one of the releases[2]. I don't believe there was ever a mention of the incident on the official forum so if you weren't following them on Twitter you'd never find out. The general messaging around it was "a GitHub bug caused it" and its never really been followed up on publicly :\ [1]: https://twitter.com/caddyserver/status/1338324878441603073 [2]: https://github.com/caddyserver/caddy/releases/tag/v2.2.1
In Caddy – Open-source web server with automatic HTTPS
In my eyes, Caddy is a lovely web server that works pretty well as ingress for container clusters (e.g. Nomad, Docker Swarm etc.). That said, i can't help but to feel that v1 was easier and in some ways nicer to use than v2, even though it's abandoned at this point. That said, i have certain grievances with most of the web servers out there. Apache2/httpd - actually decently usable even nowadays, but if the fragmentation of service names (httpd vs apache2, with additional scripts like a2enmod) between different distros doesn't hurt it, then the configuration format and how it does reverse proxying and path rewriting most certainly will. The performance is still passable, no matter what anyone says, my applications still have been the bottleneck in approx. 95% of the cases, though that might change with frameworks like Vert.X or such. The
Read the rest
further down you scroll, the less user friendly it becomes: https://httpd.apache.org/docs/2.4/rewrite/remapping.html Admittedly, the docs themselves are good, though, despite the syntax that you're stuck with. Nginx - recently migrated my ingress to it at work, seems pretty okay so far, the configuration format seems to make a bit more sense and probably lies somewhere between Apache and Caddy as far as its ease of use and pleasantness goes. I no longer even need rewrite rules to get websockets working properly, which is nice. And my containers can have all of the necessary config in a single file vs the unnecessary boilerplate fragmentation that httpd forces upon me. For example, both of these seem more passable to me when compared to Apache2: https://docs.nginx.com/nginx/admin-guide/web-server/reverse-... and https://www.nginx.com/blog/creating-nginx-rewrite-rules/ Currently, my biggest gripe is that Nginx kills itself when it cannot resolve an upstream host, for example, while Docker containers are still starting, their health checks haven't passed and therefore their DNS records also haven't been created: https://stackoverflow.com/questions/42720618/docker-nginx-st... The worst part is that none of the suggested answers actually work for me, so i can't have a single Nginx instance be in front of the development environment with about 20 containers, a few of those being down when Nginx is being restarted will not let many of them be used until the startup finishes. Unacceptable. Caddy - as stated before, i liked v1 more than v2, though the project itself is pretty close to as good as a web server might get. What i don't enjoy is them taking the old docs offline, merely letting you download an archive, nor am i a fan of the current docs, since at the current point in time they are a bit like running "tar --usage": https://caddyserver.com/docs/caddyfile/directives/reverse_pr... It's nice that there are a few examples for the common use cases, but there probably could be even more, just look at what the PHP documentation has at the bottom for a good example: https://www.php.net/manual/en/function.str-replace.php (crowd sourced, but i like the idea of letting the community contribute useful information like that). Apart from that, some of the behavior is weird and you will get a 200 when you'd expect to get a 502/404 in most other web servers: https://caddy.community/t/why-does-caddy-return-an-empty-200... which will sometimes be misleading ("Huh, i'm not getting any data in the response to my request, even though the status is 200 in my log, weird...") Also, i remember when v1 had this "fail-fast" habit of shutting down the entire server when renewing/obtaining a certificate failed, something that i utterly hate when web servers do: https://github.com/caddyserver/caddy/issues/642 Admittedly, things are a bit better now: https://caddyserver.com/docs/automatic-https#errors I just don't understand why web servers can be so opinionated about these things and not provide something like "failure_action" in Docker Compose (https://docs.docker.com/compose/compose-file/compose-file-v3...) so that people can choose between either stopping everything as soon as problems manifest, or continuing with a "best effort" strategy. If i'm hosting 100 sites behind a reverse proxy, i don't want 99 to be taken down just because 1 of them was misconfigured, the web server should be able to throw out a warning about that one host if i tell it to, and proceed to run the rest 99 as instructed. When no web server forces me to cope with such brittleness will be a good day.
In Caddy – Open-source web server with automatic HTTPS
In Ask HN: What are the best publicly available FAMANG code repos?
Just a reminder that users of Caddy (v2.3.0 or higher) are not at risk when LE gets hit like this, because it will fallback to having a certificate issued from ZeroSSL. Both issuers would need to be down for the whole last 30 days of the certificate's 90 day lifetime before Caddy would be stuck with expired certificates. https://caddyserver.com/docs/automatic-https#errors https://github.com/caddyserver/caddy/releases/tag/v2.3.0
In Let's Encrypt's performance is currently degraded due to a DDoS attack
Ah, we actually have one of these at Caddy: https://caddyserver.com/docs/architecture (The filename on disk is literally "architecture.md" -- it is a Markdown file rendered by Caddy's template handler: https://github.com/caddyserver/website/blob/master/src/docs/...) It could use some improvement, but it's been really great for helping people learn how Caddy 2 works at a high level. Beyond our docs, I always encourage new contributors to thoroughly explore the godoc and code: it's very well-commented and organized, especially once you know how it all comes together. A single document will never be sufficient. But it can help you map between concepts and code. Code search is also invaluable for this; I recommend Sourcegraph: https://sourcegraph.com/github.com/caddyserver/caddy Edit: One other valuable piece is explaining why the architectur
Read the rest
e is the way it is. Our architecture.md doc links to a video that explains how I arrived at Caddy 2's architecture (and why it's not arbitrary): https://www.youtube.com/watch?v=EhJO8giOqQs
In Architecture.md

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.