> I don't have anything bad to say about Caddy

Here's one: it does not support dynamically loadable modules, like most (all?) Go programs. So if you need e.g. geoip, you have to build your own, and then maintain it, tracking CVEs, etc. You can't rely on your distribution's package maintainer to do the work.

It's not like you have to maintain a fork, it's pretty minimal, all you need is a Dockerfile with what you want and build the container. Other than that you just keep bumping the version like you would the standard distribution.

For example to use rate limiting I just have a Dockerfile like this:

FROM caddy:2.9.1-builder AS builder

RUN xcaddy build --with github.com/mholt/caddy-ratelimit

FROM caddy:2.9.1

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

It is still a problem if you want caddy to run outside of docker (e.g. for getting real remote addr).

You don’t really need to track anything either, you can set up a GitHub Actions workflow and have dependabot bump the version for you.

Or you can just ‘apt install -y nginx certbot’ and not have to worry about a build or package environment.

Golang fundamentally doesn't support dynamically loaded libraries. It appears at first that it does, which can waste your time, but actually it doesn't.

Can you expand? I thought the plugin package handled this now, though I've not actually tried it. Is it a dud?

It is one, yes.

Only a POC, supported in Linux and macOS, and basically relies on doing casts from loaded symbols into what they are supposed to mean.

This was the big deal-breaker for me when I last looked a little while ago.

I need route 53 and a few other DNS providers built in for let's encrypt support and the docs implied that I was going to have to build those plugins myself?!!!

I stopped reading at that point because cert bot is trivial to install and just works with the web server that was also one command to install. At no point did I have to create a ephemeral container just to build nginx or certbot...

I wonder if caddy3 might implement WASM plugins via something like Wazero. Maybe too much of a performance hit.

Caddy is an opinionated alternative to nginx with modern defaults.

I’m perfectly able to configure all of the bits and pieces of nginx or apache, but instead of spending 15 minutes or so doing it I tell caddy “here’s my domain name” and move on with my life. The massive benefit is that the features are easily replaced or replicated so if I do decide I want to use traefik or nginx for a specific feature, I can do it when I care about that. But caddy is just batteries included

> but instead of spending 15 minutes or so doing it I

you forgot to add on the months or years of experience you already have that lets you do that in 15 minutes. Maybe today with an LLM I could figure out certs but the every time I've tried it in the past there's tons and tons of jargon and tons and tons of options and everything is written from the POV of someone that already knows it all.

Certs are a real pain. I’ve been doing infra engineering for the last few years and man oh man people are so quick to handwave away the hidden costs of ssl. You need to understand where it terminates in your stack and how to handle the termination and which pieces of the stack handle ssl and which don’t and all the while make sure you aren’t doing something dumb and insecure.

A classic example is people thinking self signed certs are a good idea without fully understanding the implications of getting every single piece of your application stack and all its third party dependencies to trust the thing.

Which I guess is a good thing, but also man it does place a lot of power into those root CA’s the internet uses.

Oh I’m agreeing with you. My point is that even as someone who is able to and knows how to do this stuff it’s a value add.

I haven't used Caddy but it's config format can't be worse than nginx's. Some crazy gotchas with the way nginx config works...

> it's config format can't be worse than nginx's.

It's alright — the main upside for me is that it supports parameterized includes, thus letting you reuse large chunks of configuration without relying on something like ansible or bash + envsubst.

https://caddyserver.com/docs/caddyfile/directives/import

That's true. Nginx config has quirks that have bewildered me in the past, but nothing I couldn't figure out, and not something I have to touch often.

- Single executable (you know where all the files are regardless of os)

- Config so easy you can remember how to do it in a day

This is it for me. I got frustrated trying to do something with Nginx, which I had ~five years of experience with at the time.

Someone recommended I try Caddy, I was surprised I could just `chmod +x caddy; caddy start`, and I had replaced my laborious Nginx configuration + the new reverse proxy I wanted in ten minutes.

If I already knew Nginx in-and-out, I'd not have had the impetus to use Caddy. If Nginx config is a daunting task or something that takes longer than two minutes, I'd recommend taking a few minutes to try out Caddy.

> Single executable (you know where all the files are regardless of os)

This is your package manager's job, which even Windows has these days. Other operating systems solved this problem decades ago.

https://winstall.app/apps/nginxinc.nginx

They're not solving it well in many cases; so-called "portable apps" are a great thing.

(If you don't believe me, consider why exactly Docker got so popular.)

In a way, it's ironic that you need package managers to keep track of software on Linux, compared to Windows, which used to let you get away with the assumption that everything that makes a program lives in a single folder tree; half the software was effectively portable by default.

Where's the irony, you ask? On Windows, you could almost say that an application install is equivalent to its folder. And a folder is a type of file. And per Unix philosophy, everything is supposed to be a file!

Everything is a file is only true if we ignore OS IPC and networking.

Windows way goes back to 8 and 16 bit home computer days, across all systems that is mostly how it worked, applications were placed inside their own directory, or their own floppy, actually.

I didn't try Caddy yet, but to me there are obvious downsides to nginx due to which i'd like to run away from it eventually. First and foremost: slow query detection. Out of the box, it doesn't allow you to do that easily, you either need to hack your own log format (and parse it), or to get a paid version. Another is simple stuff like log rotation (access.log/error.log). Could just use journald, but it doesn't. There are others, but these are enough to find a better alternative.

Shouldn't log rotation be handled by `logrotate`?

I mostly don't look at the logs outside of dev. Errors are caught by Sentry. Still, I can see the use for that... I'd probably try to ingest it into Grafana or some silly k8s solution if I cared enough.

I'd used nginx for work stuff for close to 10 years and still didn't trust myself writing configs from scratch without comparing with known-good ones. I never had that problem with Apache, so take from that what you want.

I'm not doing SRE stuff at work anymore (or it's on AWS) - so I've been using caddy for my own stuff for a couple of years with nearly zero problems.

For work I still might use traefik or nginx, my only reason against caddy were bad experiences in their support forum, but that was years ago.

I think nginx is great if your enterprise and want to squeeze the most utility out of your boxes. The issue is there's a large disconnect between nginx and Nginx plus, and you quickly end up making cursed configs to do basic things if you're using the former. It's literally what drove me to seek out alternatives and settle on caddy years ago.

What kind of cursed configs are you running into? My prod config is less than 65 lines to enable php-fpm and serve some static assets.