Interview with Matthew Holt – Author of Caddy – Innovative Open Source Web Server

If you have had anything to do with maintaining websites then you will be familiar with the web server software Apache and Nginx. Recently an alternative server solution has started grabbing headlines, namely Caddy developed by Matthew Holt.

Caddy focuses on security and usability, and does a number of clever things much more easily than older web servers, especially (a) making it easy to serve websites over HTTP/2  and (b) automagically providing free publicly usable https using Let's Encrypt - a big deal in itself since that is not easy for inexperienced sysadmins to set up manually.

The following video demonstrates the speed of automatic setup:

The developer who created Caddy, Matthew Holt, has kindly answered our questions in this exclusive blog interview:
(Note: all bold/formatting for emphasis added by the KnowledgePower Editor)

Can you tell us the story of how Caddy came into being?

Matthew Holt: During my 12+ years of web development (back when JavaScript libraries weren't a thing; XHTML and Java applets were all the rage), I found myself configuring web servers. A lot. And it got annoying, especially for the little one-off sites I wanted to work on.

At the end of 2014, after writing Go almost exclusively for two years, I finally had an opportunity to write a web server that was more compatible with my workflow.

Caddy was nameless for the first four months until I announced it in April 2015.

After much debate, I settled on Caddy in the hopes it would convey the goals of the project: a user experience focused on the person, taking care of all the little details, and to _just work_ so the user can get on with things.

Caddy will always be easy to use. And as of last December, it will always keep your sites secure by default.

What has the response been like?

So far, people love it. A year later, it's been downloaded well over 27,000 times and plays an important role in several companies and organizations.

It's not right for everyone, but it's right for a lot of people, and more than 70 people have contributed code to make it even better.

text in image - list of caddy features - easy deployment, multi core, ip v 6, logging, reverse proxy, rewrites and redirects, directory browsing, virtual hosts text in image - list of caddy features - http 2, automatic https, websockets, markdown, fastcgi, headers, clean urls, gzip

What's the significance of auto-enabled https and HTTP/2?

Every website you load makes a long journey on its way to your computer. This journey involves going through infrastructure that neither you nor the website control.

By default [with http], none of the data is encrypted. By default, anyone in the middle can read everything you're transmitting to the website--URLs, passwords, medical records--and the contents of the website you're loading--text, images, account details--all of it.

What's worse, they can modify it. They can deface websites, change text, replace images, redirect you. They can inject ads, tracking scripts, and malicious code to exploit you. They can even impersonate real websites in order to steal your information. And you could have no way of knowing.

This stuff is real. It happens, and not only from criminals. ISPs like Comcast are known for injecting unwelcome code into unencrypted pages. Last week, CNBC was called out for inviting readers to transmit passwords without encryption or consent. And don't even get me started on what various governments are doing with your communications.

The burden of encrypting lies largely with site owners. Unfortunately, for as long as HTTPS (encrypted HTTP) has existed, the process of setting it up for even a small website was expensive, tedious, and technical.

That changed in December 2015 when a new non-profit organization, Let's Encrypt, made their service publicly available. The excuses for not encrypting have finally disappeared.

Caddy is the first (and so far only) general-purpose web server to use encryption by default.

Since Caddy is for site owners, they can now serve sites with encryption without thinking about it. In other words, if all site owners used Caddy, privacy and security on the Web would be ubiquitous, and nobody would have to give it a second thought.

insecure website shown with red cross in browser bar

http is insecure and all-too-slowly getting replaced by https including in HTTP/2 - Caddy is the first and so far only general-purpose web server to use encryption by default.

An extra bonus of using HTTPS by default is that Caddy can also use HTTP/2 by default. HTTP/2 is a new version of HTTP that makes sites load much faster, especially for big pages with lots of media.

Is it correct to say Caddy's https on demand relies on Let's Encrypt at the moment?

Yes. Right now, Let's Encrypt is the only certificate authority (CA) to use the ACME protocol, which is the technical means of getting TLS certificates automatically. If their service degrades or slows down, so will Caddy startup times and specific TLS handshakes. Of course, all other ACME clients would be negatively affected as well.

The good news is that ACME is an open protocol. I'm hoping that other ACME-capable CAs will appear in the next few years. In fact, if I had any authority to do so, I would call on existing CAs to urgently add support for ACME.

The more ACME CAs we have, the more robust our shared security infrastructure will become.

As well as the auto https, what advantages do webmasters get from using Caddy instead of Apache or Nginx?

This depends how you consider benefits. If your idea of a stellar web server is like the Millennium Falcon with all its knobs and switches and controls exposed, where you can even lift up the floorboards and change the way the ship works, then Caddy looks unappealing to you.

However, if you're more into the Nubian Royal Starship that is elegant, modern, and just works, then Caddy is for you!

J-type 327 Nubian royal starship - via

J-type 327 Nubian royal starship - via

The most obvious advantage of Caddy is usability.

Site owners who serve with Caddy are more productive and secure because less configuration is required. It's not uncommon for converts from nginx to have a Caddyfile that is 80% shorter than their nginx.conf file. And converts from Apache actually get how Caddy works after they try it. This is because Caddy is a simple way to layer on the technologies your site needs: Markdown, WebSockets, gzip, FastCGI, proxy -- usually just by adding a word to the Caddyfile.

screenshot of caddy configuration file text

The Caddyfile is where you set up how your server / virtual hosts work - similar in purpose to httpd.conf or nginx.conf.

Caddy is extensible so other developers can write even more features for Caddy. One popular example is a git integration so you can deploy your site with `git push`. People love this, and I think it's because it's just something you want your web server to do and makes for a simpler workflow.

More subtle benefits are virtues of being a Go program. Consider the number of CVEs that have been issued because of C programming mistakes, due simply to the nature of C. Also consider how long it can take for a new web developer to get a site up and running with traditional web servers and actually understand the configuration rather than just copy-pasting from Stack Overflow or some tutorial blog and hoping it is secure and correct. With Caddy, these aren't problems.

Caddy configuration aims for the admin actually to understand what she's doing. (Sloth / Copy pasting image orig source unknown - will update if we find out.)

Caddy configuration aims for the admin actually to understand what she's doing.
(Sloth / Copy pasting image orig source unknown - will update if we find out.)

Will Caddy be included in server distros?

Caddy is a single, self-contained binary that doesn't require installation to run like you're used to with other web servers. Nonetheless, some members of the community are working on distro packages and init scripts to help tune the OS and configure a process manager to make the system a more reliable environment in which to run Caddy.

The Caddy documentation is really comprehensive and reader-friendly - was that a lot of additional work?!

To initially write, yes, but once written, they're pretty low maintenance. The hardest part is writing them in a way that is obvious and intuitive for readers. We're still working on that, and you can help us; just file an issue with your feedback.

I do want to have the site and docs translated into other languages. We have a lot of demand for French and Chinese, and some requests for Spanish, Portuguese, and Dutch.

If somebody wants to spearhead this effort, we already have volunteers who want to translate!

Who is involved in development and are you getting the support needed to grow the project?

Although I still do most of the development, Caddy is a global effort and it wouldn't be possible without contributors. That said, if you want to help with the project, the best ways to do so are:

  1. Help close issues.
    - Usually this involves fixing a bug or developing a feature and submitting a pull request.
  2. Support the project financially by donating.
    - I don't rely on Caddy for a living, of course, but I can put more time into it when people donate.
    - We can also talk about sponsorships if your company is interested in that.

Your top advice for developers and entrepreneurs undertaking similar projects?

For anyone who wants to start a long-term open source project, I would suggest you pretend the project is already popular and figure out these things right away:

  • What is your contribution policy and process?
    - Consider code reviews, code quality, automated deploys, documentation.
  • How will you introduce and explain your project to newcomers?
    - Consider web site, design/branding, and community resources such as chat or forum.
  • How will you license the code?
    - Consider if you plan to commercialize it and how you might do so.
  • What does MVP (minimum viable product) look like and what does version 1.0 look like?

Don't let people make you believe that all software has to be finished; some small projects certainly can be, but some can be perpetually useful and thus are perpetually in development.

text in image - list of features of Caddy

Caddy's documentation and website do an excellent job of describing features and how to get started

What's next for Caddy?

We're on the way to version 1.0. Right now I'm reworking a lot of the internal structure of Caddy, and then Caddy will get a RESTful API so its management can be more easily automated.

After that, it'll be a lot of improvements to make it stable and even more performant for 1.0.

Long-term, I hope to see Caddy serving millions of sites all across the Web.

As Caddy is adopted more broadly, it proves how user experience matters server-side as much as it does in front-end web apps.

Finally, I want Caddy to make a bold statement to the world:
We expect security and privacy on the Internet by default,
transmitting any content unencrypted is unacceptable,
and security's usability problem is, in fact, solvable.

[Editor: W00t - We hold those truths to be self evident and more power to those making this happen!]

KnowledgePower George: MANY THANKS Matt for taking the time to share this info and your excellent advice! An added bonus is having an obligatory Star Wars reference ready-provided without us having to add one ourselves!

About Caddy

Caddy logo

"The HTTP/2 Web Server with Automatic, Fully-Managed HTTPS"

  • Location: Utah, USA
  • Team: Abiola Ibrahim has extensive server application experience; Sebastian Erhart is a post-secondary computer security student. We've had many other talented & skilled contributors.
  • Usage: over 27,000 downloads and growing.

Contact Caddy



Community chat: