Table of contents of the article:
Introduction: The Deafening Silence of the Web
It happened again. This morning, while sipping your coffee and trying to access the dashboard of your favorite service, or maybe just trying to read the latest news, you hit that digital wall we've become all too familiar with: 502 Bad Gateway . Or, ironically, an error page branded by the very people who are supposed to ensure errors never happen.
Today's Cloudflare outage, promptly reported by QuiFinanza , isn't just a technical glitch. It's a seismic event. When Cloudflare sneezes, half the internet catches a cold. E-commerce sites, institutional portals, banking APIs, and even the little cooking blog next door: they all go down, all at once, at the same time.
This event reignites a debate that's been simmering for years in IT departments and developer communities, but is often drowned out by the convenience of the "default": does it still make sense to use Cloudflare for everything? And above all, for sites other than Amazon or Netflix, is the indiscriminate use of a CDN a technical necessity or just a dangerous fad?
The Age of Unconscious Centralization
To understand whether we can do without Cloudflare, we must first honestly admit why we use it. Over the past decade, Cloudflare has accomplished a marketing and engineering feat: it has made infrastructure “invisible.”
In the early days of Web 2.0, setting up a web server required vertical expertise. You had to manage SSL certificates (remember the pain of manually renewing them?), configure iptables to block Russian bots, and pray your Apache server doesn't collapse under the weight of a Reddit link.
Then came Cloudflare with its magical promise: change your nameservers and we'll take care of everything.
-
Free SSL? Done.
-
DDoS protection? Included.
-
Global caching? Enabled.
-
CSS/JS minification? One click.
It's become the default layer. Today, when you launch a new project, the first thing you do after purchasing a domain is almost always connect it to Cloudflare. We don't ask ourselves if it's necessary. We just do it. It's become the "seatbelt" of the web. But what happens if your seatbelt jams and prevents you from getting out of your car while it's on fire?
Today's outage demonstrates the SPOF (Single Point of Failure) problem . We built a decentralized Internet by design (TCP/IP was built to withstand a nuclear war), only to then deliberately centralize traffic through the proxies of a single private company.
The Analysis: Your site has truly need a CDN?
Here we get to the heart of the matter. If you run a video streaming platform, an international e-commerce business, or a SaaS app with users across three continents, the answer is yes: you need a CDN (Content Delivery Network). Physical latency is a real problem, and bringing content closer to the user is a must.
But we're talking about the vast majority of the web: blogs, local business sites, portfolios, niche forums, local news sites.
Let's take a hypothetical case study: an Italian blog, hosted on a server in Milan or Frankfurt, whose audience is 95% Italian.
-
The Speed Myth: If your server is in Milan and your user is in Rome, latency is negligible (perhaps 15-20ms). Putting Cloudflare in the middle means the DNS request must be resolved, the connection must go to the nearest Cloudflare POP (Point of Presence), which must process the request, contact your origin server (if the cache misses), and then return. For a well-configured, unharmed site , Cloudflare may not add any noticeable speed. In fact, if there's congestion on Cloudflare's network or inefficient routing (which happens), it could introduce latency.
-
The "Cache Everything" Myth: Many believe that activating Cloudflare stops their server from working. False. The free version of Cloudflare does a great job of caching static resources (images, CSS, JS), but what about HTML? By default, dynamic HTML (the page WordPress generates for you) isn't cached . Every visit still hits your server. Unless you configure advanced page rules (often paid) or use specific plugins, your server will still work.
-
The Security Myth for Small Businesses: "But they protect me from DDoS attacks!" True. But who wants to attack your B&B website? Most attacks on small websites are automated bot scans looking for vulnerabilities (old PHP versions, outdated plugins). These can be effectively mitigated at the server level (with Fail2Ban, well-configured firewalls, or application-based WAFs like Wordfence/NinjaFirewall) without having to hand over the keys to a middleman.
Hidden (Non-Monetary) Costs
Beyond the technical aspect, there is a “philosophical” and user experience cost that we often ignore.
-
The CAPTCHA Loop: How many times have you had to click on traffic lights or crosswalks just to read an article? Cloudflare often gets paranoid. For the end user, being faced with a "Checking your browser..." screen is a huge frustration. We're degrading the UX for security we probably don't need.
-
Privacy: When you use Cloudflare in proxy mode (the orange cloud), you're essentially running a Man-in-the-Middle attack on yourself. Your traffic is decrypted on Cloudflare's servers and then re-encrypted back to your server. Cloudflare sees everything: every password, every piece of personal data, every cookie. We trust them, sure, but the fact is that we're centralizing visibility of all global traffic.
-
Vendor Lock-in: The more you use their specific features (Cloudflare Workers, R2, Tunnel, Rules), the more impossible it becomes to leave. If tomorrow they decide to triple their prices or change the rules (as happened in the past with other tech giants), the migration cost will be extremely high.
The Alternative: Return to “Bare Metal” (or almost)
Today's outage, documented by our colleagues at QuiFinanza, should be a wake-up call. Is it possible to live without the orange cloud?
Absolutely. And for many, it might even be better. Here's what you need to "unhook" in 2025:
1. SSL is easy now
It's not 2010 anymore. Let's Encrypt and Certbot have made HTTPS free and automatic. Setting up automatic renewal on an Nginx or Apache server takes two minutes and requires zero maintenance. You don't need Cloudflare to get the green padlock.
2. HTTP/3 Performance and Compression
Modern web servers (Nginx, Caddy, LiteSpeed) natively support HTTP/2 and HTTP/3 (QUIC), as well as Brotli/Gzip compression. If your server is well-configured and geographically close to your audience, the speed will be excellent. What about images? You can serve them in WebP format directly from the server or use a "passive" CDN (like BunnyCDN or an S3 bucket) just for media, keeping DNS and main traffic direct.
3. “In-House” Security
Learning how to set up an Uncomplicated Firewall (UFW) on Linux or using tools like CrowdSec (an open-source, collaborative alternative to IP protection) offers excellent security. CrowdSec, for example, shares malicious IP addresses among all users: if an IP attacks me, it'll be blocked by you too. It's the same logic as Cloudflare, but decentralized.
When Cloudflare is still King
Don't get me wrong: this isn't a hate post about Cloudflare. They offer a technologically amazing service. There are times when you can't do without it:
-
Sites under active attack: If someone truly hates you and launches a 50Gbps botnet at you, your server will go down. Period. Only Cloudflare's massive bandwidth can absorb that hit.
-
Unpredictable Global Traffic: If your post goes viral on Hacker News or Reddit, the traffic spike (the "Slashdot effect") could bring down your server. Cloudflare caching is a lifesaver.
-
Complex Infrastructure: Whether you use Cloudflare for load balancing between different servers or managing complex DNS, the convenience is unbeatable.
Conclusion: Use the tool, don't marry the religion
The mistake we make is treating Cloudflare as an integral part of the Internet protocols, as if it were TCP/IP. It's not. It's a service, an intermediary, and as such, it can fail.
Today's incident teaches us that redundancy is not just about having data backups, but also about path redundancy.
For my blog and my clients' projects, the new rule will be this: Critical Evaluation. Is the site purely informational and local? Perhaps good, fast, direct hosting without intermediaries is better. Is the site critical, transactional, and global? Then let's use a CDN, but let's prepare ourselves psychologically (and technically, perhaps with a secondary DNS) for the day the lights go out again.
The Internet was born to be a distributed network. Every time we place a single giant node in front of millions of other nodes, we challenge the very nature of the network. And sometimes, like today, the network presents us with the bill.
What about you? Were you left in the dark today? Are you considering turning off the "orange cloud"?
