From the article all I gathered was that you’re essentially right.

In more general terms:

A distributed reverse proxy with sensible defaults for caching.

Even though it doesn’t sound like much, it’s pretty cool and useful.

One of the things in ops that can be hard and expensive is any kind of high availability. Say you’re restarting your origin server regularly after pushing new code.

Depending on your use case, it might just be enough to have exactly two well provisioned web servers (VM/dedicated) and maybe one DB server. Then put a CDN in front of it and voila, high availability reads.

Much of the ops related to high availability is also abstracted now since Cloud is extensively used and managed solutions are employed instead of having bare metal deployments. The era before cloud was radically different, now we don't hear the word downtime so often.

If you care mostly about reads, the above setup can be operationally simpler and likely more cost effective and agnostic than a full suite of Cloud products.

Yes, depends on the product that is being built and the traffic it is going to server. In case it's not a high traffic website, we can definitely bypass Cloud. In my stint at a startup, we were directly serving the content via Nginx instead of CDN. Our scope was limited to only country and the use case was also simple, just to display a transaction page with few images to the customers.

That is correct. Internally, it's a high performing web server to return the static content at speed. In addition, the websites get additional functionality such as DDOS protection out of the box by leveraging CDNs.

Well, it was that once. It's certainly got a lot more features now.

I'm betting they don't just use NGINX, but also specialized hardware.

Cloudflare has an article on introducing specialist hardware to their stack [0]

[0] https://blog.cloudflare.com/asics-at-the-edge/

Not the same type of specialized "CDN Hardware" that was implied in the parent, this is just "big network" customization at the packet forwarding layer.

They don’t use NGINX anymore

With multicast IPs too - that's the other critical component.

It's free bandwidth as well. That's a fairly huge part of the deal.

It's more like Cloudflare forked nginx a long time ago, and is meanwhile in the very slow (like, decade-long) process of replacing it entirely.

The Cloudflare Workers Runtime∗, for instance, is built directly around V8; it does not use nginx or any other existing web server stack. Many new features of Cloudflare are in turn built on Workers, and much of the old stack build on nginx is gradually being migrated to Workers. https://workers.dev https://github.com/cloudflare/workerd

In another part of the stack, there is Pingora, another built-from-scratch web server focused on high-performance proxying and caching: https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t...

Even when using nginx, Cloudflare has rewritten or added big chunks of code, such as implementing HTTP/3: https://github.com/cloudflare/quiche And of course there is a ton of business logic written in Lua on top of that nginx base.

Though arguably, Cloudflare's biggest piece of magic is the layer 3 network. It's so magical that people don't even think about it, it just works. Seamlessly balancing traffic across hundreds of locations without even varying IP addresses is, well, not easy.

I could go on... automatic SSL certificate provisioning? DDoS protection? etc. These aren't nginx features.

So while Cloudflare may have gotten started being more-or-less nginx-as-a-service I don't think you can really call it that anymore.

∗ I'm the tech lead for Cloudflare Workers.