edit: a project like Kong could easily be done with haproxy as far as I know and you can actually monitor your server. https://getkong.org

What killer feature do normal projects require that is not in opensource edition?

If you enable the stub status, that gives you metrics for the master process and not any of the virtual hosts.

That's not comparable to a proper monitoring page and exposing its stats by statsd (or similar) for integration with a real monitoring system.

nginx free edition is a black box, hence the criticism.

and TLS v1.3 works fine for me too https://community.centminmod.com/posts/48818/

Because the free version covers all the things they need, and they feel nginx creators also have a right to make some bucks?

Slava > And our users clearly thought of us as an open-source developer tools company, because that’s what we really were. Which turned out to be very unfortunate, because the open-source developer tools market is one of the worst markets one could possibly end up in. Thousands of people used RethinkDB, often in business contexts, but most were willing to pay less for the lifetime of usage than the price of a single Starbucks coffee (which is to say, they weren’t willing to pay anything at all).

I understand it's because of the support cost - but it makes the adoption very hard. You cannot go from 0$ to 10,000$ overnight. And that's the problem.

And if you're operating at the scale where this doesn't make sense, and you still can't afford $10k/year, then maybe you need VC money? ;-)

At my previous business we wanted to use nginx plus, so we asked them for a quote saying we had between 10 and 50 servers running nginx per day (autoscaled depending on load)

We got back a short email saying it's $2500 per server, so $125000/year.

Considering our total hosting costs at this point were around $30-40k, that is absolutely absurd.

That is stretch of a statement - maybe you are not entirely incorrect. But the onus is on both sides. I'm also at that stage where I can migrate to traefik or caddy relatively easily... but I dont mind paying 100$ to nginx for something familiar and an almost negligible incremental cost to them.

I am not claiming a magic bullet, but there's a reason why SAAS companies with easy switchability have a gradually increasing payment plan. Instead of heartburn inducing 0-10K USD.

> OpenResty® is not an Nginx fork. It is just a software bundle. Most of the patches applied to the Nginx core in OpenResty® have already been submitted to the official Nginx team and most of the patches submitted have also been accepted. We are trying hard not to fork Nginx and always to use the latest best Nginx core from the official Nginx team.

> because the open-source developer tools market is one of the worst markets one could possibly end up in

Well, a production-quality database isn't really a 'developer tool', but even then, there are dev tools that have carved out a comfortable niche for themselves, such as SublimeText.

The problem isn't the open source mentality, the problem for RethinkDB was competing in a saturated market with a major competitor who had already won a lot of mindshare and gained a lot of traction.

Those feature sets overlap, but HAProxy cannot serve files, cannot cache. OTHO, most Nginx load balancer features are premium.

Overall, I'd say Nginx has a broader range of features and friendlier configuration. Hence high adoption.

Anyone using HAProxy is serious about load balancing.

Sure, we could accomplish all of that with some combination of haproxy and/or varnish and/or apache and/or nginx and/or various Ruby/Rack app servers... but we don't have to. Nginx does an acceptably good job of all of those things for our needs right now, and the support they provide for the license cost is pretty reasonable.

edit: This is also where your use case makes it easy to see why nginx (or caddy) won't cut it.

Their website is superb, with simple explanations of what the tool does and transparent pricing for their paid options.

The only thing I'm initially a tiny bit weary about is their claim of it being production ready. Being used by thousands of sites is an amazing feat, but how big are the loads on these sites? Production-ready can mean completely different things depending on what you're building. I think it'd be a nice improvement to see a bit more data backing up that claim. Just from a quick google search it looks like there's a decent number of articles comparing it with nginx, so I guess I"ll stat digging in a bit deeper.

[0] https://caddyserver.com

I like to tell people it's production-ready if it's a good fit for your website and workflow. Many people are using Caddy in production. There's so much variance it's hard to pin it down in a simple phrase, so we have to settle with a term that's "good enough", which I think the most fitting is "production-ready."

And upfront, I'll say: Careful with chasing benchmarks. They don't transfer well (or at all), and most people (including me) don't know how to run them properly. Just test with your own staging setups and see if it works well enough for what you need.

Anyway, thanks for your feedback about the site -- definitely taking it into account.

However, honestly, I don't dare to use it on "big" production sites yet (besides maybe my blog), because for example packaging [0] still isn't tackled or clear at this point in time (and if Caddy wants to also gain traction on "big" production websites, this matters, because these are often not just run by devs, but sysops/devops people that will, very likely, never wget a binary because [insert one or more of valid reasons]). I think Matt (mholt) said that they will work this out when Caddy will hit 1.x, but for me it is a showstopper atm. Also if you read the topic from top to bottom you will notice that there seems to be no clear vision, not even for a base-caddy OS package or PPA.

Before this comment is considered negative, please know that I am actually a Contributor to the Caddy project (yet I have only contributed to the Init/Service Scripts), and a passive reader of the packaging discussion mentioned earlier, trying to come up with a great idea there to tackle that one point that I think will make Caddy's growth accelerate very quickly for "big" production websites.

[0] https://caddy.community/t/packaging-caddy/61

Well, you can always add more boxes.

People have been putting horrendously performing Ruby or other small-time servers in production for very mainstream sites.Compared to things like these, Caddy will soar...

Regarding the status of the backendservers - I use monitoring with health checks for every backend server anyway.

That are the reasons I chose nginx as reverse proxy recently.

- Create 1 process per core and pin to a core.

- In extreme cases, pin the NIC interrupt to a dedicated core. (If you have multiple NIC, one dedicated core per NIC).

HAProxy lets you do that very easily. That's why it's configured the way it's configured, because it's the options you need to make a high performance load balancer.

Shared memory is not necessarily and would kill the performances dramatically. The "inconsistencies" you might have heard about mean that the stats in the stats page are approximate, nothing important.

I'm looking at moving to something a bit more application aware now, such as Traefik, which works better in my workflow anyway.

Will say though - HAProxy has been rock solid for me, and was a million times easier to configure and manage than F5 LTM for our use case.

But given the current culture of even large profitable companies just using open source projects without giving back - see the HN story about Github and Redis - and let alone contributing but even giving credit, some open source companies have no way to earn any revenue. They may then have to resort to this to support their development which ultimately benefits all users.

Nginx is a highly regarded, widely used and high performance web server. As a long time user I would not grudge them trying to make some money to support and improve the project. As is Haproxy. I think there is room to accommodate both models and we are just incredibly lucky to have 2 such high performance projects available as open source.

In essence there is a wrapper that:

- reads service information and current backend instances out of service catalog (either Marathon or Consul)

- writes nginx configuration

- runs nginx configtest

- tells nginx to reload its configuration

Nixy referenced above takes service information directly from Marathon event stream but I usually have Consul so I use homebaked consul-template + nginx solution.

That's a red flag. Don't make architectures where you depend on crazy requirements like that.

This is a PaaS supporting many micro-services. There is a hold-off to not reload more than once a second just as an insurance against runaway processes but beyond that nginx handles this without any sweat.

Frequent reloads are currently in the non-prod cluster only but I don't see any reason why it would be an issue in prod as well.

P.S. I am in finance, assume my requirements are severely more extreme than yours. Just like my errors.

http://tengine.taobao.org/

https://github.com/alibaba/tengine

Apparently its a big enough issue to grumble about but not big enough to front some cash to resolve.

I agree though. DNS backend lookups for this would be an excellent thing to add.

That? Works like a charm.

It's available with the on-premise enterprise subscription and on the AWS and Azure clouds as Varnish Plus - Caching Engine:

https://aws.amazon.com/marketplace/seller-profile?id=263c020...

https://azuremarketplace.microsoft.com/en-us/marketplace/app...

https://www.varnish-software.com/pricing/varnish-plus/

Also, why wouldn't you just solve this with SRV records? Just patch Varnish to support SRV properly and magic you get everything you ever wanted including failover and priorities. That's probably a more sane request.

You need to compile the "draft-18" branch of OpenSSL as current browsers are on draft-18 (master is on draft-19).

Building apache from source is not only very straightforward but a great way to maximimize httpd performance (all modules static, only include the modules you need). OpenSSL on the other hand, that's distro specific, and definitely more involved.

  git clone https://github.com/openssl/openssl.git -b tls1.3-draft-18 openssl-1.1.1-tls1.3-draft-18

    services.nginx = {
      enable = true;
      virtualHosts."example.com" = {
        root = "/webroot";
        enableACME = true;
      };
    };

Recently released Ubuntu Zesty (17.04) uses OpenSSL 1.0.2, and upcoming Debian Stretch (9) release uses 1.1.0.

http://packages.ubuntu.com/zesty/openssl https://packages.debian.org/stretch/openssl

Builds of at least Firefox and Chrome / Chromium with TLS 1.3 exist in the wild if you're interested in testing this out.

In particular you should look at this if you have middle boxes such as a "transparent" TLS proxy or "traffic inspection" feature in a corporate or educational network. It is very likely these boxes have defects regarding TLS 1.3 because all of them are garbage built by idiots. If you find out early you might be able to plan for what to do about that before the proverbial impact with a fan.