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, 2:59:53 AM 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

40 sources
I know it's not directly what you've asked for (it's neither apache nor nginx), but the Caddy webserver does just that - almost 0 configuration dealing of the ACME part, auto-redirection from http to https. You still need to tell it what your domain name is, but barely (there's some DNS plugins that make it truely 0 config). https://github.com/mholt/caddy (I'm not affiliated, just a happy user)
In Looking Forward to 2018
Thanks. Their licensing seems confusing: The https://caddyserver.com/download web page says "Caddy binaries are free for personal use, and a commercial license is required for internal company use, commercialized distribution, or other business purpose. " After seeing Caddy mentioned in another HN thread, I decided to make sure I got that right, and stumbled upon https://github.com/mholt/caddy which seems to be open-source. But how to reconcile this with the apparent ban on distributing binaries?
In Ask HN: Secure alternative to Nginx?
> If you're configuring a public facing server, a cronjob should not be considered "specialised knowledge". Knowing how HAProxy's OCSP implementation works (i.e., by looking for a $cert.ocsp file) is the specialized knowledge. Odds are, you don't know about it and just won't use OCSP stapling. This is especially true since every web server does this differently. > HAProxy and nginx do a fucking shit ton more than Caddy does. HAProxy doesn't really have a "default" you have to tell it what you want to do, specifically. This is a good thing. I'm not arguing that it doesn't do a lot of things Caddy doesn't. I'm arguing for sane defaults. If I tell HAProxy to enable TLS and provide a certificate that contains an OCSP AIA extension, a sane default would be to use that information to manage OCSP stapling. > You're both giving the impression tha
Read the rest
t Caddy is able to automatically renew certificates, while no other software does this. You're leaving out the part where I say these issues "[...] are essentially solved with a web server that supports ACME natively". I'm not referring to Caddy specifically. The web server doing this natively is far less error-prone. I have also mentioned alternatives. > - Separation of concerns. I don't ask my mechanic to build me a car, or to drive me to the shops in it. Where do you draw the line? Most deployments let their web servers handle TLS. OCSP stapling should be part of a modern TLS deployment. You could similarly argue that using HAProxy for TLS is wrong (and that you should rather put pound or stunnel in front of it). > - Not every organisation uses LetsEncrypt certificates. Some will even use self-signed certificates. That's fine; you can continue to manually configure certificates, even with Caddy, and I'm definitely not arguing that this option should be removed. ACME is also an open standard, so switching to other CAs can be as simple as configuring a different ACME server url. > - TCP or DNS load-balanced environments will want the exact same certificate & key on multiple servers. That's why you can replace the certificate and key storage in more complex environments[1]. > - Caddy has already shown that trusting some "automagic" solution can bite you in the ass. Remember that time Caddy wouldn't even start, even though it had perfectly valid certificate material in it's cache, because LE was down? Software can break, what a surprise. You could similarly have a broken OCSP updater script that puts empty or expired OCSP responses in your stapling file because the check is missing or incomplete and break the site for your visitors. Or your ACME client could fail on renewal because of a backend change on Let's Encrypt's end that exposes a bug in it[2]. > HAProxy doesn't know the email address I'd want LetsEncrypt to use for notifications. It also shouldn't be agreeing to LE's terms on my behalf. You can ... provide your email address? You keep arguing that this stuff is easy, surely adding a single line with your email address won't break the camel's back. Accepting the TOS can be solved as part of the installation or configuration process, much like ACME clients do it. Anyway, you seem to be having some kind of problem with Caddy. I'm not interested in that discussion (which is to say I'm not interested in discussing this further, I think I've made my point) - my goal is to improve the user experience of server admins when they enable HTTPS, and I have no doubt that native ACME support and automated OCSP management, both with sane defaults, would both help HTTPS adoption and improve the quality of the TLS configuration of your average web server. [1]: https://godoc.org/github.com/mholt/caddy/caddytls#Storage [2]: https://community.letsencrypt.org/t/acme-sh-standalone-fails...
In Optionsbleed – HTTP OPTIONS method can leak Apache's server memory
It's still a really nice web server. Easy to configure, incredibly reliable, twenty years of security fixes under its belt, endless docs/info available for it online. I've been meaning to learn nginx for a while, but with Apache working just fine, it doesn't feel very urgent. Besides Apache and nginx, there aren't really any servers I'd trust for production use. Conceptually, I really like what Caddy is doing, but it's simply too young, not to mention the concerns that came up when Let's Encrypt had an outage back in May: https://github.com/mholt/caddy/issues/1680
In Optionsbleed – HTTP OPTIONS method can leak Apache's server memory
The caddy source code is licensed under the Apache License. As a user, you can modify and/or use the software in pretty much any way you see fit -- as long as you download the source and build it yourself. You can add or remove features (including the controversial header) and use it as you wish, but redistributing modified versions and calling them "caddy" may not be permitted. Binary packages from your distro should also be fine. If you download and use the binaries from the caddy web site, you are bound by their EULA. To be safe, use the version provided by your distro or -- even better -- build it from source yourself. You may want to read the actual Apache License [0] yourself, skim over the "Licensing conditions" section [1] of the Wikipedia page, or, at the least, review GitHub's bullet points [2]. [0]: https://www.apache.org/licen
Read the rest
In The Realities of Being a FOSS Maintainer
> (Is anyone offended that you can’t remove nginx’s Server self-promotional header without an extra module?) Wait a second. The Caddy developers implemented a premium "thank you" feature that embeds their sponsors' company names in the HTTP headers of the binary distribution[0], and then defends this by complaining that you can't disable nginx from simply printing a header that says "server: nginx"? It's not even remotely the same thing! I think this was a very poor use of judgement. I don't even see why it's relevant that they asked their sponsors "do you want us to put your names in the HTTP headers of all the poor suckers running the binary builds?" There's a handful of other places that would be way more appropriate for spamming sponsors' names, for example: banner on the website, in the log files, on the download page, in the README,
Read the rest
In The Realities of Being a FOSS Maintainer
Actually, the defaults are quite insane. For example: You might know that all domain names are in the root zone, named ".", so any domain actually is resolved to e.g. news.ycombinator.com. And if you enter the domain with the dot, it is the same DNS name, and should give you the same result. Apache does that, Nginx does that, Google’s cloud does that, Amazon’s cloud does that, all major sites do that... Caddy considers it irrelevant, and something users should add manually for all of their rules if they want it. Ignoring all the RFCs, because of personal ideals. https://github.com/mholt/caddy/issues/1632
In Announcing Caddy Commercial Licenses
I don't know why people are freaking out about this so much. It's one header. Also, it's been made painfully clear that the source code is not covered by the EULA and is still licensed under Apache 2.0, so if you build from source yourself you can use it without any change, just like before this announcement. It's not like this is some ungodly C project where you need to gather all your dependencies together and debug the build process when it doesn't work on your machine. The project is written in Go and has no external dependencies so building from source is literally just: - Install Go if you don't have it already - Run `go get -u github.com/mholt/caddy/caddy` - cd to $GOPATH/src/github.com/mholt/caddy/caddy - Run `go install` - Use the resulting caddy.exe file for free like you always have done If you don't like the Caddy-S
Read the rest
ponsors header then you can just edit the `github.com/mholt/caddy/caddyhttp/header/header.go` file and comment out the lines: if name == "Caddy-Sponsors" || name == "-Caddy-Sponsors" { // see EULA continue } Then build the project, except now you can remove the sponsor header with `-Caddy-Sponsors` in your Caddyfile. If you need a plugin then just download the plugin you want from github and import it before building: https://github.com/mholt/caddy/wiki/Extending-Caddy @mholt has made the entire process so unbelievably easy that the whole process takes literally minutes...
In Announcing Caddy Commercial Licenses

Showing the 15 most recent of 40 sources. Enable JavaScript to search and browse every indexed mention.

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.