This appears to be continued development of OpenResty (which Taobao had previously been funding) - https://github.com/alibaba/tengine/blob/04baff4645f078331e00...
At this point it seems like openresty is almost completely unsupported. The largest user that I was aware of was cloudflare and they've now abandoned it in favor of their home built Rust server.
Another fork is Angie: https://angie.software/en/
It can automatically provision TLS certificates like Caddy, which is pretty cool.
Angie is also notable in that it's led by former Nginx core team members who left F5. Freenginx is another fork which is also led by one of the former core Nginx devs who became disillusioned with F5s leadership and wanted to make it fully open source, unlike Nginx and Angie which both have paywalled features. I'm not sure if any of the original team are still at F5 at this point, Igor Sysoev retired from working on Nginx (or its forks) altogether.
I'm more impressed these days with the pace, activity, and helpful support from the Caddy development team: https://github.com/caddyserver/caddy/
Not sure of the appeal of caddy.
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, I don't understand what you mean. What format are you talking about? We definitely push everyone to use the Caddyfile.
Complete opposite of my experience. Caddy is by far the most sane reverse proxy configuration out of the ones I tried (Nginx, Traefik, Caddy).
I use it in dev to proxy to multiple backend services but I don’t think I’d ever run with it in prod.
Why not? What are your concerns? Many large companies use it in production.
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.
That's already a thing! https://caddyserver.com/docs/caddyfile/directives/import
And somehow while reading the documentation, we all missed it. :FACEPALM:
Not true.
Caddy has always allowed even the most sophisticated configuration for me.
Sure I’ve needed to talk to ChatGPT about it and sometimes ask in the forums which the maintainers are active in.
And I find the config to be much more sensible than nginx which I really came to not be a fan of.
How about the level of security of Caddy and Nginx?
Maybe there is a difference there too.
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).
ChatGPT is invaluable when configuring caddy.
The news for me is XQUIC; not Tengine. I did know about Tengine for years. It's the chinese equivalent of nginx. But I didn't know about XQUIC from Alibaba. We lack information (and news) on the evolution of the BATX.
Envoy. The answer and final word in this space is Envoy.
Envoy Proxy, to be more specific -- https://www.envoyproxy.io
The name “Envoy” conflicts with a company (envoy[.]com) that has nothing to do with proxies.
I like Envoy Proxy too. I have used it to support a couple of projects at Apple, and the gRPC Access Log Service works well -- https://www.envoyproxy.io/docs/envoy/latest/api-v3/extension... , although, I wish the configuration file was more obvious when you read it, I spend hours decyphering names, understanding the meeting of certain things, and tuning values that otherwise should be self explanatory. As Leon Bambrick said, naming things is hard, and some engineers tend to name things in a stupid way.
I looked into Envoy a few years ago and found it difficult to get started. I recall the syntax involving long names that were hard to look up from the docs.
I'm assuming some of those issues may be why it isnt as commonly talked about as nginx or caddy
It's not a reverse proxy cache though.