I grew up on a stable in Iowa, then went to Utah to go to college and climb rocks.
My first job out of high school was at a tiny, unprofitable address verification company that was about as boring or mundane a subject matter as you could get. (I know more about addresses than I ever cared to know!) While address updates still arrived on a DVD every month, we were pushing for people to automate verification through online APIs, which back that was still kind of a novel thing. After a few years of just a small team working hard on it, we became the #1 search result, and by now, I think the company has dozens of employees.
Towards the end of college, I started doing my own thing — consulting work here and there or working on open source projects that I started as an undergraduate. After getting my master’s degree, I was looking for a company interested in taking the project under their wing to help it grow and to give that value back to the company and its customers.
Caddy is a powerful, enterprise-ready, open-source web server with automatic HTTPS written in Go. It offers stronger memory safety guarantees than other servers and keeps your sites up when other servers don’t. With Caddy, your deployments can have fewer moving parts, which means less to maintain, less sunk costs, and fewer things that can go wrong.
At the time, I was building lots of little websites for school, personal, and work projects; and I felt constrained by the web servers at the time. It felt like a space that hasn’t innovated for about a decade. So I wrote my own. It was also an excellent way to learn the Go programming language.
Caddy obtains and renews TLS certificates for all your sites, automatically, without needing any extra configuration.
Anyone who is setting up a production website or service, developing sites locally, or using TLS certificates at all would find Caddy useful.
Every site on HTTPS. We are calling on all other web servers to use TLS by default. Yet five years later, while there are more servers that you can configure to automate TLS, Caddy is still the only one to enable it by default. For some reason, we demand privacy from all our software and services, but among web servers, there’s been pushback in adopting this mentality, and that’s nonsensical. If we want to enjoy freedom online, we must act responsibly and provide privacy. I guess I’m hoping that Caddy will supplant the old, unsafe, error-prone, confining ways of doing things.
Caddy is particularly popular among companies offering services with “custom domains” features, as Caddy will automatically provision and manage certs for those domains, greatly simplifying their deployments. Other companies have swapped out other servers for Caddy and found that it significantly improved performance and increased capacity. I know of several large tech companies you’re familiar with which use Caddy, but that’s about all I can say.
For now, from our release page on GitHub. We also have some official packages, but lots of work still going on there, and we need help making new ones: https://caddyserver.com/docs/install#official-packages
You can refer to the docs here.
Caddy 2 is around the corner (and might already be released by the time you read this). It’s been 14 months in development, and we’ve closed about 400-500 issues in the process. It’s an entirely new architecture that acts more like an extensible platform for server apps than merely being a web server. I think the top new features include an online configuration API, config adapters so you can configure your server with whatever syntax/format you want to, and vastly improved request matching capabilities.
You can donate via GitHub Sponsors. I would definitely appreciate sponsors — this wouldn’t be possible without the help of both individual and corporate sponsors, since I do this full-time.