• thebeardisred 9 months ago

    This appears to be continued development of OpenResty (which Taobao had previously been funding) - https://github.com/alibaba/tengine/blob/04baff4645f078331e00...

    • VWWHFSfQ 9 months ago

      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.

    • jedisct1 9 months ago

      Another fork is Angie: https://angie.software/en/

      It can automatically provision TLS certificates like Caddy, which is pretty cool.

      • jsheard 9 months ago

        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.

      • brudgers 9 months ago
        • bklyn11201 9 months ago

          I'm more impressed these days with the pace, activity, and helpful support from the Caddy development team: https://github.com/caddyserver/caddy/

          • Eikon 9 months ago

            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.

            • imiric 9 months ago

              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.

              • heavensteeth 9 months ago

                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.

                • bklyn11201 9 months ago

                  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.

                  • francislavoie 9 months ago

                    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.

                    • mholt 9 months ago

                      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.

                    • francislavoie 9 months ago

                      Caddy maintainer here, I don't understand what you mean. What format are you talking about? We definitely push everyone to use the Caddyfile.

                    • mgrandl 9 months ago

                      Complete opposite of my experience. Caddy is by far the most sane reverse proxy configuration out of the ones I tried (Nginx, Traefik, Caddy).

                      • whalesalad 9 months ago

                        I use it in dev to proxy to multiple backend services but I don’t think I’d ever run with it in prod.

                        • francislavoie 9 months ago

                          Why not? What are your concerns? Many large companies use it in production.

                        • francislavoie 9 months ago

                          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.

                          • stackskipton 9 months ago

                            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.

                        • andrewstuart 9 months ago

                          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.

                          • aborsy 9 months ago

                            How about the level of security of Caddy and Nginx?

                            Maybe there is a difference there too.

                          • adrianvincent 9 months ago

                            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.

                            • francislavoie 9 months ago

                              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).

                              • andrewstuart 9 months ago

                                ChatGPT is invaluable when configuring caddy.

                          • _ache_ 9 months ago

                            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.

                            https://github.com/alibaba/xquic

                            • zelcon 9 months ago

                              Envoy. The answer and final word in this space is Envoy.

                              • guessmyname 9 months ago

                                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.

                                • justin_oaks 9 months ago

                                  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

                                  • ddorian43 9 months ago

                                    It's not a reverse proxy cache though.

                                  • undefined 9 months ago
                                    [deleted]