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.
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 :)
>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?
And Caddy is very well battle-tested too, btw. ;)
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."
This is great for if you want to be able to do zero-downtime deploys of new applications behind a proxy server or similar.
(One reason we don't use signals in Caddy 2. So uncivilized.)
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.
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. ;)