Deploying Web Apps with Caddy: A Beginner's Guide Caddy
betterstack.com
betterstack.com
nginx has a ton of inertia, but Caddy is a welcome player. I highly recommend anyone into this sort of thing give it a try. The configuration is so easy by comparison and its handling of HTTPS certs automatically is a huge win.
I feel its a leap forward from the typical Apache / nginx setup to me nowadays
There are a number of complex configurations used by larger organizations that are well served today by Nginx Plus, HAProxy, and Traefik that don't seem possible with Caddy. And it's difficult to get a sense of whether the Caddy developers are interested in meeting those more complex use cases or whether they want to keep Caddy smaller and simpler.
But yes, by all means, for a simple project pick Caddy!
> welcome to 2024. it is shame that traefik cannot handle functionality which can be handled by caddy2.
(posted this morning)
Anyway, we already do walk up to quite a few complex requirements in large enterprise deployments. Happy to hear about your use case that isn't possible!
2) Nginx has this concept of rewrite "last" (instead of permanent or temporary)
3) Nginx Plus and HAProxy both have TCP routing OOTB without needing to recompile
4) Nginx and Nginx Plus have more ability to intercept a response from an upstream and modify it vs Caddy's fairly limited handle_response {}
5) Modify body content from upstream seems to require a Caddy module
6) Very difficult to find good Caddy configs and thus why LLMs have such a hard-time helping people with Caddy configs. Having a library of configs would probably help this training
There seems to be an incredible market opportunity for Caddy as I've lost a lost of trust in the Nginx ecosystem and commercial environment. I would get some of these modules into core Caddy so that they are easy to distribute to people used to just installing via apt. And then attack the Nginx Plus features one by one. Add a visual console even though I understand why it doesn't seem like a necessity. I'd love to see Caddy take share and would love to re-allocate my Nginx Plus spend over to Caddy support.
Anything in particular you find confusing?
Just want to say, it's great for large deployments too! (Ask Stripe and Framer)
```
{
order webdav before file_server
log {
level DEBUG
}
}
files.example.org {
log {
output stdout
format json
}
@notget {
not method GET
}
root * /srv/ssftp
route @notget {
basicauth {
bob $2y$10$f/asdasd.asdsadasd.asdasdasd
}
webdav
}
file_server browse
}
The integrated LetsEncrypt support makes life so much easier than a comparable setup with apache or nginx.
https://blog.tjll.net/reverse-proxy-hot-dog-eating-contest-c...
For me personally I really want to know what is going on in each folder and keep track of new folders, files etc. It’s maybe my paranoia of hacking. Context; when I was a kid I hacked so many things and knowing where the files are kept and hiding them is a key part of hacking. Therefore it’s always been a priority for me to check in regularly see what’s happening.
I do still manage a couple of fairly complex Nginx configurations, and I don't really see any benefit to retrofitting Caddy into that kind of scenario. But for a new deployment, I'll almost always reach for Caddy in the first instance.
> without needing to configure separate certificate infrastructure or Letsencrypt/acme.
is not only that your deployment is simpler, it also scales better and is more robust to failures. It can tolerate external factors more robustly.
Our docs cover many installation methods, most commonly used is our apt or rpm repos, which run Caddy as a systemd service. See https://caddyserver.com/docs/install
Edit: I just saw the other post here saying it may be as good as nginx.
I largely agree with this, but it's not like there's a huge gap between Caddy and Apache with mod_md (https://httpd.apache.org/docs/2.4/mod/mod_md.html) or even Nginx with certbot (https://www.digitalocean.com/community/tutorials/how-to-secu...), at least for HTTP-01 challenges.
Personally I think that Caddy v1 configuration was a little bit nicer than the current versions, but honestly it's a cool web server and I see its popularity continuing to rise in the future!
That's actually how most of my personal and homelab stuff runs, with Docker Swarm due to how lightweight and simple it is. There, Apache actually works better for me since if I have 10 different domains configured and only 9 resolve (e.g. containers not running yet) then something like Nginx would complain about a non existent domain and crash the whole thing, whereas Apache would serve the 9 other domains and eventually proxy the 10th as well, instead of just returning an error.
I did tune Apache a little bit, in that I disabled .htaccess to avoid too much I/O (now the config is more like nginx.conf), though also sometimes add other modules, like mod_security (simple WAF) or mod_auth_openidc (Relying Party, so using OIDC wouldn't make me insane), as well as PHP-FPM if I ever need PHP in a particular container.
Nginx is still better for serving static files in general (e.g. packaged SPA), Traefik for HTTPS, but Apache is generally okay at most things.
I'm still an Apache/nginx user, but certificates that require no configuration are the selling point of Caddy for me (and I use it on two very small projects because of that).
[1] Which meant that I had to write some sort of automation that detected the reissue and restart Apache (and set up appropriate systemd service/timers, limited user permissions to only allow passwordless restart, etc). In the end I kept certbot (which I wanted to get rid off) and let it manage the certificate (DNS challenge) and Apache restart. I'm open to a suggestion on how this can be done in a minimal way and requiring no supervision after.
For something more precise, there is MDMessageCmd (e.g. listen for "renewed" and trigger reload; probably a short Bash script). Reload instead of restart should also be less disruptive.
The other option with MDMessageCmd, would require (on a SELinux distro) to grant Apache command exec permissions, among other tweaks.
What would be better in this case were if Apache could message via DBus these events and I could make a dbus service that listens and restarts accordingly (better execution isolation).
If Apache would do internally the certificate swap, now that would be perfect.
In what way? Caddy v1 config was very inflexible, so there were lots of things that were simply impossible to do with it. I think we struck a good balance of simplicity to expressiveness.
That actually does look like it'll be reasonable, but 1. it still requires that the user figure out how to enable mod_md and add the config to enable it, and 2. it's currently labeled "Status: Experimental", which https://httpd.apache.org/docs/2.4/mod/module-dict.html#Statu... describes as
> "Experimental" status indicates that the module is available as part of the Apache kit, but you are on your own if you try to use it. The module is being documented for completeness, and is not necessarily supported.
so it seems more like something that will eventually become a good alternative.
> Nginx with certbot
I'm fine with certbot, but there's a world of difference between "install this web server and tell it your URL starts with https://" vs "install the web server, install this other package, read the docs to configure the other package or run the setup script and follow the prompts".
Traefik has that.
I'm speak objectively here. Of course, any built-in auto HTTPS that works (more or less) is better than none. Traefik uses an ACME library that was originally written for Caddy. After the original author left that project, Traefik team started maintaining it. Caddy's users' requirements exceeded what the library was capable of, but unfortunately there was friction in getting it to achieve our requirements. So I ended up writing a new ACME client library in Go and, together with upgrades in CertMagic (Caddy's auto-TLS lib), Caddy has the more flexible, robust, and capable auto-HTTPS functionality.
That is to say, not all auto-HTTPS functionalities are the same.