Your options
People want off Cloudflare for four reasons: concentration risk, a nameserver takeover they did not want, a US data controller, or one feature sitting on a plan they cannot justify. Here are the actual options, what each one can and cannot do, and where Itnetic fits.
This page is not an argument that you should leave Cloudflare. It is an answer to a question people ask for good reasons, and the honest version of that answer includes the option you cannot build yourself.
The reasons come up in roughly this order. Concentration risk: a large share of the web sits behind one provider, and its bad afternoon becomes your bad afternoon. Control: standard onboarding takes over your zone’s nameservers. Jurisdiction: the data controller is in the United States, which is a real question for an EU organisation with a compliance reviewer. And cost-of-feature: the one control you need turns out to be two tiers up.
There are three ways to answer any of those. Build it yourself, lean on your hosting provider, or use a different hosted edge. They are not equivalent, and the table below is about what each approach can physically do.
Approaches compared
The self-hosted column describes a typical open-source stack — Nginx or Traefik with ModSecurity or Coraza, CrowdSec and fail2ban — running on your own servers.
| Requirement | Itnetic (hosted edge) | Self-hosted stack |
|---|---|---|
| Absorb a volumetric flood before it reaches your line | Yes — upstream backbone, every plan | No — your uplink is the bottleneck by definition |
| Filter Layer-7 floods | Yes — adaptive detection, challenges, signatures | Yes, until CPU or the connection table runs out |
| Managed OWASP WAF rules | Every plan, including free | Yes — ModSecurity/Coraza with a rule set you maintain |
| IP reputation | Every plan | Yes — CrowdSec or a commercial feed |
| Rate limiting | Every plan — global across all nodes | Per-server only; a cluster needs shared state you build |
| Browser challenge without a third-party CAPTCHA | Every plan — proof-of-work | Possible, but you are writing and maintaining it |
| Hide your origin IP address | Yes — visitors only ever see the edge | No — the origin is what they connect to |
| Waiting room / virtual queue | Every plan, including free | Build it yourself, per server |
| CDN caching near the visitor | Every plan | One location, unless you run several |
| Global visibility across all edge nodes | Every plan — per-request logs and analytics | Your own logging pipeline |
| Kernel-level packet filtering (XDP/nftables) | Yes — managed for you | Yes — if you write and operate it |
| Who is on call at 3am | Us | You |
| Ongoing cost | Free plan, then €5–€99/month by size | Servers, bandwidth and your time |
| Data controller | Czech Republic (EU) | You |
This page compares approaches, not vendors: the self-hosted column describes what a typical open-source stack can and cannot do by construction, not any specific product. Cloudflare is a trademark of Cloudflare, Inc.; Itnetic Technologies is not affiliated with, endorsed by or sponsored by Cloudflare, Inc., and nothing here is a claim about Cloudflare’s pricing, performance, capacity or availability. Prices named are Itnetic’s own, correct on 10 September 2026.
You can put Nginx or Traefik in front of your app, add Coraza or ModSecurity for WAF rules, run CrowdSec for reputation and write nftables rules by hand. That is a genuinely good stack and it will stop a great deal. What it cannot do is absorb a flood, because mitigation has to happen on a network with more capacity than the attack, upstream of the thing being attacked. Once the packets are on your uplink, the damage is already done — every filtering decision you make is being made after the bandwidth was spent.
Check this before buying anything. Several large hosts include network-level DDoS protection as standard — OVHcloud is the usual example — and that covers the volumetric layer for free. What it does not cover is Layer-7: a flood of well-formed HTTPS requests to your login page is, from the network’s point of view, a website being popular. If your host already handles L3/L4, what you are shopping for is specifically application-layer filtering, and you can ignore anyone selling you capacity.
This is the option that actually replaces what you had. The things worth checking are unglamorous: is the control you need available on the plan you would be on, or two tiers up? Do you get raw per-request logs, or only aggregated charts? Does onboarding demand your nameservers? Is attack traffic billed against your bandwidth? Who is the data controller, and can you read the DPA without asking a salesperson? Those five questions separate providers far more reliably than any capacity number.
One product, every feature on every plan including free, operated from the Czech Republic. Layer-7 mitigation, managed and custom WAF, IP reputation, rate limits, waiting room, per-request logs, origin load balancing and the CDN — none of them gated. Setup is two DNS records at your existing provider, so your nameservers, your registrar and your email records are untouched and you can migrate one hostname at a time. Attack traffic is never metered against your quota.
Do not stack two proxying edges in front of the same hostname on the theory that more is safer. You get two challenge layers, two caching decisions, and — the part that actually hurts — the inner edge sees the outer edge’s IP addresses instead of your visitors’, which degrades every per-IP rate limit, block and geo rule it has. Split by hostname if you want both. Chain them and you have quietly disabled half of what you are paying for.
FAQ
Yes, and there are three routes: your hosting provider’s network-level protection (which covers volumetric attacks but not Layer-7), a self-hosted stack such as Nginx with Coraza and CrowdSec (good at filtering, unable to absorb), or another hosted edge such as Itnetic, which does both.
You can self-host the filtering half — WAF rules, reputation, rate limits, kernel packet rules. You cannot self-host the absorbing half, because that requires more capacity than the attack, sitting upstream of your server. Once traffic reaches your uplink the bandwidth is already spent.
For parts of it: Nginx or Traefik as the proxy, Coraza or ModSecurity for WAF, CrowdSec for reputation, and nftables or XDP for packet filtering. Plus your own logging. It is a real stack, and it is missing upstream capacity and origin concealment — the two things that are structural rather than software.
Usually one of four: concentration risk (one provider’s outage taking a large slice of the web with it), not wanting to hand over their zone’s nameservers, wanting an EU data controller, or finding that a specific feature they need sits on a plan they cannot justify.
Not to Itnetic. Setup is two DNS records — a TXT proof and one traffic record — at whatever DNS provider you use today. Your registrar, MX records and everything else stay put, which is also what makes a hostname-at-a-time migration possible.
For volumetric attacks, often yes. For Layer-7 — a flood of valid HTTPS requests to an uncacheable path — no, because at the network layer that traffic is indistinguishable from popularity. That is the gap an application-layer edge fills.
Split by hostname, yes. Chained on one hostname, it is a bad idea: two challenge layers, doubled caching decisions, and the inner edge seeing the outer edge’s addresses instead of your visitors’.
Same provider, different question — each page compares what matters to one specific use case.
Same method, different provider — feature availability by plan, with the date it was checked.
Two DNS records, no nameserver change, free plan with no card.