I believe Caddy brought a much needed paradigm shift in web server space, it is an incredible piece of technology.<p>I have moved all my servers from NGINX to Caddy for the pass few years and I couldn't be happier.<p>Also, I would like to give a shoutout to the team behind Caddy. They have been nothing but great about constantly shipping updates and being incredibly helpful in their community forum.
Just a personal experience. About 6 months ago, we moved from NGINX to Caddy on our web app, which handled about 300 million HTTP requests per month at that time (2 web servers, so about 150 million each)<p>CPU Usage:<p>with NGINX - 15-20%
with Caddy - 70-80%<p>I tried multiple tweaks but nothing helped to get NGINX-level performance. So, after a few weeks, we migrated back to NGINX.<p>That being said, I still absolutely love Caddy and use it in a few small scale apps.<p>- The DX it provides is amazing.
- Creating a PHP-FPM reverse proxy is just a couple of lines.
- Generating SSL certificates on the server is a breeze. With NGINX, you have to mess with other software like certbot.
- It just works :)
I did benchmark it against nginx and found Caddy to be 5-7x times slower, but like all benchmarks go...results are subject to ones requirements (or mistakes).<p>What got me away from using it:<p>- the directives feel intuitive but as soon as I needed a complex config it all became a chain of very implicit strings<p>- the caddy author(s) decided few years ago to add custom http header with their sponsors[0]. That header could not be removed, it's no longer present in current Caddy but the bad taste still remains.<p>[0] <a href="https://news.ycombinator.com/item?id=15238315">https://news.ycombinator.com/item?id=15238315</a>
I love caddy, I used to litter my docker-compose.yaml files with Traefik labels like:<p><pre><code> labels:
- traefik.enable=true
- traefik.http.routers.foundryvtt-http.entrypoints=web
- traefik.http.routers.foundryvtt-http.rule=Host(`vtt.xxx.nl`)
- traefik.http.routers.foundryvtt-http.middlewares=foundryvtt-https
- traefik.http.middlewares.foundryvtt-https.redirectscheme.scheme=https
- traefik.http.routers.foundryvtt.middlewares=foundryvtt-auth
- traefik.http.middlewares.foundryvtt-auth.basicauth.users=${foundryvtt-BASIC_AUTH}
- traefik.http.routers.foundryvtt.entrypoints=websecure
- traefik.http.routers.foundryvtt.rule=Host(`vtt.xxx.nl`)
- traefik.http.routers.foundryvtt.tls=true
- traefik.http.routers.foundryvtt.tls.certresolver=mytlschallenge
- traefik.http.services.foundryvtt.loadbalancer.server.port=30000
</code></pre>
Now I just add the containers (by name), no labels, and map Caddy to their port, like so (in the Caddyfile):<p><pre><code> data.xxx.com {
reverse_proxy projectsend:80
}
</code></pre>
or, this snippet refers to a WordPress container with BasicAuth in front of it:<p><pre><code> restricted.xxxx.com {
root * /var/www/html/restricted.xxxx.com/wordpress
php_fastcgi wordpress-xxxx-restricted:9000 {
root /var/www/html
}
basicauth /* {
xxx $xx$x05xxxxxxxxx.xx
}
file_server
}
</code></pre>
Here's just an index.html (from Hugo in this case) in some dir:<p><pre><code> blog.xxx.nl {
# Set this path to your site's directory.
root * /var/www/html/blog.xxx.nl
# Enable the static file server.
file_server
}
</code></pre>
I love the simplicity.
Caddy had been a joy for me personally coming from NGINX. I especially love the ease of adding a new site and how little config it takes. Small self plug, I recently wrote an article about some cool config examples <a href="https://jarv.org/posts/cool-caddy-config-tricks/" rel="nofollow noreferrer">https://jarv.org/posts/cool-caddy-config-tricks/</a>
Backing the days (5+ years ago I think) we tried it, and while it was nice its licensing/pricing made us not use it for our startup, as it seemed to pose a sustainability threat when growing (or not growing the right pace).<p>Has it improved since then?<p>disclaimer: I don't remember the details, I was just told to use nginx because caddy is problematic, so I built the system with nginx open source.
I like Caddy, mainly for the ease of configuration. One thing that surprised me though: by default it has compression disabled. I discovered it 1 year after moving from nginx (with the nginx config having compression enabled) and it was funny, because at the time of migration I got comparable performance out of the two. Obviously, after enabling compression, it’s faster now.
I'm always a bit bothered by them saying they are the "only" web server that can do this. First you can also just configure it in a way where it will not use HTTPS (e.g. if you provide an IP:port instead of a hostname). And if you do require specific configuration to enable HTTPS and automatically get certificates via ACME, then lots of other web servers can do this too. Even my own web server can do it: <a href="https://github.com/pfirsich/htcpp">https://github.com/pfirsich/htcpp</a> (see <a href="https://github.com/pfirsich/htcpp/blob/main/configs/acme.joml">https://github.com/pfirsich/htcpp/blob/main/configs/acme.jom...</a> for an admittedly much more complicated config).
Caddy seems to be continuously getting better and I think mholt occasionally hangs around here and is a rather pleasant person.<p>I recall once needing to help a new person in another team setup TLS after they had tried to do it unsuccessfully themselves in some configuration (that might have had a networking setup where HTTP-01 for ACME doesn't work, actually). I just started recording my desktop, grabbed a server from Hetzner live and thanks to Caddy could give them an example of how things should work with all of the steps in like 5 minutes total.<p>Nowadays I use Apache (mod_md) for my personal needs due to some plugins I need, it actually makes me wonder why Nginx doesn't seem to have integrated support for ACME yet, even if certbot is serviceable too. Either way, props to Caddy for raising the bar for web servers.
I love Cadd and I have been using it for a few years now.
The documentation is kinda crap, but I still use less time to get things done.
Most projects are just copy/paste of old config files.
Everytime I had a problem, I asked and got an answer within 2 days. And nice answers, not like Stackoverflow...
I'm currently reverse proxying a few docker containers with nginx. Caddy seems tempting but one dealbreaker I can't find in the docs is whether or not it automatically refreshes its DNS cache if a docker container restarts and changes its IP address?<p>e.g. In nginx, I use "resolver 127.0.0.11 valid=30s" so "proxy_pass {container}:80" will only cache the {container}'s IP address for 30s
The thing I am missing the most is some kind of HTTP-01 by proxy,
like <a href="https://github.com/acmesh-official/acme.sh/wiki/Stateless-Mode">https://github.com/acmesh-official/acme.sh/wiki/Stateless-Mo...</a><p>If DNS-01 is not an option or to complicated, this saves you from exposing a host to the internet for no good reason.
Maybe first but not the only! <a href="https://github.com/donuts-are-good/appserve">https://github.com/donuts-are-good/appserve</a>
>All hostnames (domain names) qualify for fully-managed certificates if they:<p>-are non-empty<p>-consist only of alphanumerics, hyphens, dots, and wildcard (*)<p>-do not start or end with a dot (RFC 1034)<p>Someone help me understand this part...didn't know this
Caddy is great. My only complaint is they insist on sending a:<p><pre><code> Server: caddy
</code></pre>
Header that is impossible to turn off since it's hardcoded here: <a href="https://github.com/caddyserver/caddy/blob/master/modules/caddyhttp/server.go#L260">https://github.com/caddyserver/caddy/blob/master/modules/cad...</a><p>The developer's annoying response is "it doesnt improve privacy or security, so we won't give you the option to remove it".
Just curious. I use Ubuntu on my servers (as many do) and I deploy everything as standard Systemd service (even my apps). However, when I wanted to try out Caddy, I realized they don't provide you with one, so you have to write your own scripts putting systemd config files, enabling the service etc. Is this what everyone does these days? Seemed kinda strange for mainstream software.