4 ms·

These are fun to make. I've done it several times. :) That is why I wrote Caddy: $ caddy file-server It does templates, TLS, and other production things r

by mholt 3y ago

These are fun to make. I've done it several times. :) That is why I wrote Caddy: $ caddy file-server It does templates, TLS, and other production things really easily from the command line too, including automatically getting certificates: $ caddy file-server --domain example.com Done! I think projects like static-server are wonderful learning examples of how to get Useful Things done in Go.

eliben 3y ago
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?
- mholt 3y ago
  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.
mnstngr 3y ago
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.
- mbakke 3y ago
  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 :-)
  - mholt 3y ago
    That's awesome! Thank you for the experience/feedback.
- mholt 3y ago
  Thank you! We try very hard (collectively, as a community).
timenova 3y ago
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!
- mholt 3y ago
  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 https://github.com/RussellLuo/caddy-ext/tree/master/layer4
deleted 3y ago
[deleted]
chaxor 3y ago
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?
- mholt 3y ago
  It depends. What is your definition of "security"? There's lots of dimensions of security in the web serving space. If you list out your requirements and specify your threat model, then answers become a lot clearer. But yes, in general: Caddy's one-liner is a safe way to serve static files in the sense that remote services can't upload files or escape memory bounds to run arbitrary code. It encrypts your connections for you, so they're basically safe from surveillance and modification. The elements you're describing are all external factors that have nothing to do with serving static files specifically. For example, a reverse proxy just multiplexes requests coming in on a port to various backends, maybe making modifications along the way. Authentication will restrict access to only allowed users, if that's something you require. Containers are more a way of administering a system or mitigating very specific risks that have niche relevance with static Go programs; and VLANs are just ways of isolating network traffic, but again it's somewhat orthogonal to file serving. Overall, `caddy file-server` is better than Python's simple HTTP server in every way, though: static binary, faster performing, production-ready (handles Range requests properly, and a few other details), automatic HTTPS, folder indices, etc...
e12e 3y ago
Wait, file-server without arguments does dynamic content (templating)?! I assume that's just poorly phrased?
- mholt 3y ago
  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 https://caddyserver.com/docs/command-line#examples
- deleted 3y ago
  [deleted]
- skrebbel 3y ago
  Only for directory listings I think. And of course you can turn that off as well.
abhishekjha 3y ago
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.
- simonw 3y ago
  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.
  - mholt 3y ago
    Absolutely! Thanks for the feedback, Simon!
  - rcme 3y ago
    I think nginx does that too; if you send it a hup signal, it will reload the config.
    - housemusicfan 3y ago
      Indeed, many programs interpret a kill -HUP signal as a "re-read config" command.
      - mholt 3y ago
        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 3y ago
  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 :)

by mholt 3y ago

eliben 3y ago

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?

mholt 3y ago
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.

mnstngr 3y ago

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.

mbakke 3y ago
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 :-)
- mholt 3y ago
  That's awesome! Thank you for the experience/feedback.
mholt 3y ago
Thank you! We try very hard (collectively, as a community).

timenova 3y ago

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!

mholt 3y ago
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 https://github.com/RussellLuo/caddy-ext/tree/master/layer4

deleted 3y ago

[deleted]

chaxor 3y ago

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?

mholt 3y ago
It depends. What is your definition of "security"? There's lots of dimensions of security in the web serving space. If you list out your requirements and specify your threat model, then answers become a lot clearer. But yes, in general: Caddy's one-liner is a safe way to serve static files in the sense that remote services can't upload files or escape memory bounds to run arbitrary code. It encrypts your connections for you, so they're basically safe from surveillance and modification. The elements you're describing are all external factors that have nothing to do with serving static files specifically. For example, a reverse proxy just multiplexes requests coming in on a port to various backends, maybe making modifications along the way. Authentication will restrict access to only allowed users, if that's something you require. Containers are more a way of administering a system or mitigating very specific risks that have niche relevance with static Go programs; and VLANs are just ways of isolating network traffic, but again it's somewhat orthogonal to file serving. Overall, `caddy file-server` is better than Python's simple HTTP server in every way, though: static binary, faster performing, production-ready (handles Range requests properly, and a few other details), automatic HTTPS, folder indices, etc...

e12e 3y ago

Wait, file-server without arguments does dynamic content (templating)?! I assume that's just poorly phrased?

mholt 3y ago
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 https://caddyserver.com/docs/command-line#examples
deleted 3y ago
[deleted]
skrebbel 3y ago
Only for directory listings I think. And of course you can turn that off as well.

abhishekjha 3y ago

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.

simonw 3y ago
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.
- mholt 3y ago
  Absolutely! Thanks for the feedback, Simon!
- rcme 3y ago
  I think nginx does that too; if you send it a hup signal, it will reload the config.
  - housemusicfan 3y ago
    Indeed, many programs interpret a kill -HUP signal as a "re-read config" command.
    - mholt 3y ago
      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 3y ago
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 :)