That's the issue with doing one FOSS version + one paid version, some things will be gated behind the paid version and probably never end up in the FOSS one, as it drives people to purchase the paid version.

In this particular case, the ngx_http_api module offers way more monitoring options but is gated behind nginx Plus.

I think that if there's one feature they should put behind Plus, that's monitoring.

Only "serious" companies need that (as a hobby project maintainer you probably don't need it)... and if you really want to make sure you don't give them a cent, you can build your own monitoring on top of nginx easily enough.

Here here! There are 2 or 3 other goodies they lock behind their paywall which I think would be prudent from them to release so they stop ceeding ground/mindshare.

Interesting! I’ve been using Caddy for a while and actually recently went back to Nginx just because I am now self hosting PeerTube and there was a config file for Nginx to proxy PeerTube server ready made.

But if Caddy can serve metrics which I can then collect with for example Grafana, that’s very interesting!

Yep, Caddy has metrics: https://caddyserver.com/docs/metrics

But caveat: we don't have maintainers who understand metrics currently, so it's nowhere near as good as we'd hope it to be. Help wanted!

Caddy's metrics have been disabled for like 9 months because they cause a massive performance penalty

https://github.com/caddyserver/caddy/issues/4644

HTTP metrics (and only HTTP metrics, not all metrics) were changed to being opt-in, support wasn't removed. See my docs link above. But yes, there are performance consideration we're not satisfied with, and we need help to get them resolved.

They're not disabled, just off-by-default for now.

I'm on the same boat. I started to use Nginx for side projects a while ago. When things became a little more serious and I needed decent metrics, my only option was to upgrade to Nginx Plus. So now I'm learning Caddy.

Not sure if this would help, but saw it some months ago - https://github.com/open-telemetry/opentelemetry-cpp-contrib/... - I've not used nginx myself, so not sure how viable/useful this is

nginx has been a fantastic project ever since its launch with little real competition out there.

That said, I've been running it since the early days, on super heavy production loads and never felt the need to have some more "decent" metrics out of it. I assume you're referring to real time metrics here.

Most if not everything can be gathered from the logs, which nginx is very flexible with.

I fail to understand why some missing metrics in a great product make you think to migrate everything to Caddy?

Because I use as a gateway for fastcgi and as TLS initiator, mostly. Nginx doesn't allow you to have distinct metrics for both use cases, which is far from ideal.

My tests in controlled environments show that caddy is absolutely fine for my workload and has perks that make my life easier. Some have been mentioned in this thread already.

Metrics is a must have in our case as we have many things to manage, few people to maintain things and alerts are the only way to grow. For alerts you need metrics.

Regarding metrics from logs, you might agree that it's now an overkill.

I don't disagree, but there are always multiple solutions to problems we face, and the solution is not always simply to move on to the next product.

No product would ever cater to each and every need, and that's fine.

You have choice, if something doesn't satisfy you, you can sometimes fix the problem, improve the product or write your own module (when its opensource), or switch to another solution. Look at the opentelemetry comment below as another possibility to get what you want done.

There are so many choices today, and you enjoy the freedom of choice. If something else works better for you, use that other something.

There's no need to complain.

How do Nginx and Caddy compare with Traefik in this regard?