Wait, file-server without arguments does dynamic content (templating)?!

I assume that's just poorly phrased?

Only for directory listings I think. And of course you can turn that off as well.

To clarify, you do need to use --templates to enable template evaluation on the static files.

But for the `caddy respond` command, minimal templates are available by default; see the docs here: https://caddyserver.com/docs/command-line#examples

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'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.

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

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. ;)

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.

Absolutely! Thanks for the feedback, Simon!

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

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

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.)

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 :)

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?

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. ;)

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."

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

Thanks for the comment, Matt! I love Caddy. For some reason I thought it needs a configuration file.

The simplest cmdline I found to run it as a local server on a non-priveledged port with listings is:

    $ caddy file-server --listen localhost:8099 --browse

Is there a simpler way I'm missing?

On Mac, the defaults aren't privileged. (Not sure why. That's just how it is.)

The --browse flag is optional and unrelated to ports/privileges. Otherwise, that sounds about right. Caddy defaults to port 80 unless you give it a domain name, then it defaults to port 443 and redirects HTTP on port 80 to HTTPS.

Thank you for Caddy! Going from a complex nginx setup to the delight that's the Caddyfile was a breeze.

And a special call-out to your dedication to providing amazing documentation. Caddy is what all projects should aspire to be.

Caddy is amazing. I accidentally wiped my fairly complex nginx configuration (yay apt-get purge) and have been so spoiled by Guix that I did not care about etckeeper or ansible on my one Debian server.

Anyway I decided to try Caddy to quickly get up and running and had a good setup in minutes including certificates for multiple domains. Even added wildcard certificates which I never figured out with Lets Encrypt, just because I could.

Thanks for this amazing software :-)

That's awesome! Thank you for the experience/feedback.

Thank you! We try very hard (collectively, as a community).

Hey, I was just wondering if there's any timeline on when the caddy-l4 module be compatible with Caddyfile?

I know I can write it in JSON, but IMO the greatest appeal of Caddy is its simple and easy-to-read Caddyfile!

I, too, would like to see this, but it'll be a lot of work. It's just not a top priority right now for me, unfortunately.

This is something I could prioritize if a business wanted to sponsor this; but right now the most pressing things are updating the docs, revamping our test suite, and I have a few action items for existing sponsors I need to prioritize too.

Anyway, no timeline -- but definitely something wanted!

PS. There is kind of Caddyfile support here: https://github.com/RussellLuo/caddy-ext/tree/master/layer4

I'm (very) unfamiliar with webdev and hosting. Is this 'oneliner' a secure way to host files? I have heard that using a reverse proxy, some 2FA on a cloud gateway that forwards to another location, with a VLAN for the file server, and containerization, etc are all the standard practice now for ensuring security. Is there anything that works toward making this goal more easily amenable (since it's not possible with one project), or should I just keep using python -m http.serve and not care?

What is your definition of "security"? There's lots of dimensions of security in the web serving space. If you list out specific requirements and specify your threat model, then answers become a lot clearer.