[abhishekjha]

Is there more to the philosophy of why caddy exists? I am trying to jump into a few open source projects to hone my programming skills and I have a harder time comprehending things if I don't know what was the overall intention of the authors.

[mholt]

Caddy 1 was created because I needed a quick and easy web server for a lot of my projects.

Caddy 2 was created when I got serious about it, and we had governments and enterprises starting to rely on the project.

Now we exist because we advocate for (and deliver!) HTTPS on every site, memory safety, dynamic configuration, extensibility, and many more features valuable in a modern web server.

Hope that helps :)

[abhishekjha]

Thank you for the response. It looks interesting.

>I needed a quick and easy web server

I am trying to reason with what I know, but wouldn't something like "python -m http.server 9000" suffice? Or nginx? These are battle tested and python is there on most platforms.

Or is there more depth to this specific web server that others don't have?

[mholt]

No, because python's simple HTTP server isn't production ready (doesn't support Range requests last I checked, and quite a few other limitations). And nginx is not "quick and easy" by any means, doesn't grant me the security of memory safety (it was vulnerable to Heartbleed, for example -- I wrote Caddy shortly after Heartbleed), and doesn't give me automatic HTTPS.

And Caddy is very well battle-tested too, btw. ;)

[housemusicfan]

From afar, Caddy is one of those weird HN cargo cults.

It seems like in every thread about web servers, the developers are in here peddling their wares, and the disciples pour in with endless praise.

It's another product with insane footgun defaults (the admin API on localhost) in a sea of mature alternatives. That's all I need to know.

I don't mean to insult anyone's hard work but in the words of Josh Baskin, "I don't get it."

[mholt]

What's wrong with the admin API on localhost, exactly?

[simonw]

One of the big selling points of Caddy for me is that you can reconfigure it "live" without restarting the server.

This is great for if you want to be able to do zero-downtime deploys of new applications behind a proxy server or similar.

[rcme]

I think nginx does that too; if you send it a hup signal, it will reload the config.

[housemusicfan]

Indeed, many programs interpret a kill -HUP signal as a "re-read config" command.

[mholt]

This is problematic as when you log out your shell, HUP is sent to the web server process unintentionally...

(One reason we don't use signals in Caddy 2. So uncivilized.)

[mholt]

Absolutely! Thanks for the feedback, Simon!

[unethical_ban]

Caddy's appeal when I last looked at it some years ago was that the configuration file format was very easy to read and use; and that configuration itself was minimal. It came/comes with Letsencrypt integration which was novel some years ago, so setting up a secure site was even easier for people who weren't used to it.

Its syntax for being configured as a reverse proxy (secure front-end to less secure back-end servers) is similarly pretty easy.

I haven't looked at it in a long time because I recall them screwing with their terms of service so it wasn't fully FOSS by the most liberal definition.

[mholt]

Caddy has ALWAYS had the Apache 2.0 license. For a time we did additionally offer officially licensed binaries for companies, but Caddy has never deviated from Apache 2.

Caddy's ease of use is one feature, but there are many more - like the ability to massively scale your TLS to thousands of sites reliably. And to use the on-line configuration API to make changes to your server. There's a ton to discover with Caddy, it's not just a tool for beginners. ;)

[kstrauser]

It’s had an Apache-2.0 license for at least the last 4 years: https://github.com/caddyserver/caddy/blob/master/LICENSE