Sure, the 1 liner config file looks fine at first glance but anywhere more complex than a basic reverse proxy setup and it becomes a nightmare to configure with a crazy configuration format.
Nginx also has its own custom configuration format, which looks alien to anyone who isn't used to it. Many engineers are at this point, but think about the amount of documentation and books written about it. It's full of quirks and gotchas, where misconfiguration is very easy, and configuring complex behavior very difficult.
The appeal of Caddy is that it has sane modern defaults so that it doesn't need a lot of configuration. Things like HTTPS by default, automated cert management, Tailscale integration, etc., are all very convenient to have OOB. It's also much easier to extend than Nginx with tools like xcaddy. The configuration format itself is arguably less quirky than Nginx's. Someone below mentioned replacing a 10k Nginx setup with a 1k Caddy one, and while this is always going to be painful, it speaks for itself.
I tried messing with Caddy a little while ago and this was my experience.
I'm sure being able to configure it in a million different languages conveniences someone, but [un]official docs documenting things in a format I don't use, and having to figure out what the option is in the format I do use, was immediately annoying.
I agree that the Caddy team should hide all of the config adapters, the powerful JSON configs, and just focus on Caddyfile. I was extremely skeptical that I could convert 100+ Nginx Plus configs over to Caddyfile, but it was worth it. I moved 10k lines of Nginx config down to 1000 lines of Caddyfile. It is a big change, no question, but I've spent so much time on Nginx, Nginx Plus, Tengine, new forks, and moving away is the only sensible answer I could land on.
Caddy maintainer here; hiding things doesn't make sense, some people do need to see that information, namely users of the API who perform scripted config changes on their running servers. The Caddyfile is pretty up-front-and-center, so I don't know where the confusion is coming from.
We have many large integrators who rely on the JSON format and the JSON API quite heavily.
I also understand the burden of moving to a new server stack. It's a lot to swallow and a new way of thinking about things!
Anyway, we only mention config adapters in a few places in our docs: we automate our JSON docs, which are at the heart of Caddy, and we try to invest considerable effort to document the only official config adapter format: the Caddyfile.
Caddy maintainer here; could you be more specific about the usecases you think look like a nightmare? We're always looking to improve config ergonomics, but we need specific feedback.
Former Caddy user here but we converted to Kubernetes and Ingress-Nginx replaced it.
I wish we could have multiple config files that would get combined together at run time, bonus points for "All files ending with *.caddyfile in /dir" would get loaded.
Why might you ask? GitOps. We kept Caddyfiles in Git, but JSON would get corrupted when being edited. If they were individual files, it probably would have resulted in less headache and easier maintenance.
Caddy is great. But it has some of the worst documentation I’ve ever seen. It’s so messy and unstructured.
One example: it was almost impossible to find instructions on where to actually put the damn Caddyfile. After reading the docs 10 minutes, I gave up and resorted to Google site search.
This page explains all that: https://caddyserver.com/docs/running. Ultimately it depends how you installed Caddy and how you're running it (Docker vs Systemd vs directly via CLI, etc).
