European-only alternative to Cloudflare.

Cloudflare is the most US-exposed vendor in most "EU" stacks because it sits in front of the user - every visitor connects to a Cloudflare edge server before reaching your origin. The EU regions of Cloudflare are EU-located edges, but the parent company is a Delaware corporation with US-controlled key material and US-controlled traffic logs. For Schrems II purposes, Cloudflare in front of personal-data traffic is one of the most defensible problems to remove first, because the alternatives - Bunny.net (SI) and KeyCDN (CH) - have comparable feature sets and dramatically simpler legal stories.

United States EU-only replacement stack 11 services mapped
Schedule a call Scan your domain first
Provider
Cloudflare
Headquarters
San Francisco, CA
Jurisdiction
United States
Legal regime
CLOUD Act, FISA 702, EO 12333

"EU region" is not sovereignty. Four questions decide it.

Data residency tells you where the bits sit. Sovereignty tells you which legal system can compel access. The answer must hold on all four - or the stack is not sovereign.

Residency

Where is the data physically stored?

Not "in the cloud" - which datacenter, in which country, under which jurisdiction.

Subprocessors

Who else is in your data path?

Every vendor that touches the data: the CDN, the email relay, the error tracker, the analytics pipe.

Jurisdiction

Whose laws can compel disclosure?

A US-headquartered provider falls under FISA 702 and the CLOUD Act - even when the bits sit in Frankfurt.

Key custody

Who actually holds the encryption keys?

If the cloud provider holds both the data and the keys, the data is readable by them - regardless of any DPA.

Fails AWS · Azure · GCP · EU region

Fails on jurisdiction and key custody.

EU bits, US-headquartered parent, US subprocessors in the default path, provider-managed keys.

Passes Binadit managed stack

Passes on all four.

EU-hosted on EU-headquartered infrastructure. Zero US subprocessors in the default path. Customer-held or EU-KMS keys. Listed by name in your Article 28 DPA.

Why teams are exiting Cloudflare

The pattern we see: a privacy or DPO review identifies Cloudflare as a US subprocessor that processes every visitor request including IP addresses, browser fingerprints (via Bot Management) and cookies. Under Schrems II that is a transfer that needs supplementary measures - typically encryption that Cloudflare cannot read, which defeats the WAF and Bot Management features that were the reason for using Cloudflare. The simpler answer is to swap to an EU-jurisdictional provider where the legal analysis collapses to "no transfer." Bunny.net is the standard target and the migration is genuinely a few hours of DNS and configuration work.

Cloudflare services and their EU-only equivalents

A migration is not "swap one box for another". The mapping below is what we run for clients leaving Cloudflare on Schrems II grounds - full EU jurisdiction, no US parent in the data path.

Cloudflare CDN

What we run instead
We implement and operate an EU CDN for you: Bunny.net or KeyCDN, with Nginx and Varnish caching at your origin.
Engineering note
A CDN is one of the few layers we do not run ourselves. We pick the EU provider, configure cache headers, purge strategy and origin shielding, and operate it as part of the managed service.

Cloudflare WAF

What we run instead
Binadit Managed Cloud Platform. Coraza or ModSecurity with the OWASP Core Rule Set, plus CrowdSec for behavioural blocking.
Engineering note
Rules are tuned against your traffic instead of shipped as a default set, which is what stops a WAF from quietly blocking real customers.

Cloudflare DDoS protection

What we run instead
Binadit Private Infrastructure. Upstream volumetric filtering, with rate limiting and CrowdSec at the application edge.
Engineering note
Volumetric attacks are absorbed upstream of your servers. Application-layer abuse is handled where it can actually be understood, next to your traffic.

Cloudflare DNS

What we run instead
Binadit Managed Cloud Platform. PowerDNS or Knot, authoritative, DNSSEC signed.
Engineering note
Zones are exported and imported as standard zone files, so this is usually the least eventful part of a migration. Lower the TTLs a week ahead.

Cloudflare R2 (storage)

What we run instead
Binadit Managed Cloud Platform. MinIO or Ceph RGW, S3-compatible.
Engineering note
R2's zero-egress story is unique; on EU providers, egress is also typically free or very low, so the cost argument transfers.

Cloudflare Workers

What we run instead
Binadit Managed Cloud Platform. Knative or OpenFaaS on your Kubernetes cluster.
Engineering note
Most functions we migrate turn out to be small HTTP handlers that run happily as ordinary containers, often cheaper and with no cold start.

Cloudflare Pages

What we run instead
Binadit Managed Cloud Platform. Nginx serving built assets, deployed from GitLab CI.
Engineering note
Pages' main value is the build pipeline; that piece moves to your CI provider.

Cloudflare Tunnel (Argo)

What we run instead
Binadit Managed Cloud Platform. WireGuard tunnels, or an Nginx reverse proxy in your own DMZ.
Engineering note
Netbird is DE-headquartered and provides the "no-public-IP" pattern with EU jurisdiction. Wireguard self-managed is the standard sovereign answer.

Cloudflare Access (zero trust)

What we run instead
Binadit Managed Cloud Platform. WireGuard with Keycloak or Authentik in front of internal services.
Engineering note
For internal-only applications, an OIDC-protected reverse proxy on EU infrastructure is functionally equivalent.

Cloudflare Stream (video)

What we run instead
Transcoding with FFmpeg on Binadit infrastructure, delivered over an EU CDN such as Bunny.net.
Engineering note
Transcoding is a batch workload that runs on capacity you already own. Delivery is ordinary HTTP over a CDN we configure for you.

Cloudflare Bot Management

What we run instead
Binadit Managed Cloud Platform. CrowdSec for behavioural detection, with rate limiting and challenge pages at the edge.
Engineering note
CrowdSec is FR-headquartered and increasingly capable. For high-traffic e-commerce, DataDome (also FR) is the enterprise alternative.

How we migrate off Cloudflare

A typical mid-market migration runs in three phases. The numbers below assume a 6-10 person engineering team and a moderately complex application stack.

  1. Days 1-3

    Inventory & risk-rank

    List every Cloudflare product in use: CDN, DNS, WAF rules, Workers, Pages, R2, Tunnel, Access. Map each to a personal-data exposure (does it touch PII?) and migration complexity. Output: priority list, usually CDN/DNS first.

  2. Days 4-10

    Soft swap (CDN, DNS, R2)

    Provision Bunny pull zones for the same hostnames. Test with a staging hostname. Cut DNS over with low TTL pre-stage. R2 → Bunny Storage migration via parallel-write. WAF rules ported manually to Bunny WAF.

  3. Weeks 2-6

    Hard pieces (Workers, Tunnel, Access)

    Worker code reviewed and either ported to Bunny Edge Scripting, rewritten as origin-side middleware, or self-hosted on Knative. Tunnel replaced with Netbird or self-managed Wireguard. Access replaced with Pomerium or Authelia. Pages workloads moved to GitLab Pages or self-hosted.

Cloudflare-to-Bunny migrations almost always reduce monthly spend by 40-70% at typical mid-market volumes. The exceptions are Workers-heavy stacks (where the equivalent self-hosted infrastructure has higher fixed cost) and high-traffic Pages stacks (where Cloudflare's aggressive free tier is hard to match).

Frequently asked questions

View all frequently asked questions

Cloudflare has EU-only data plans now - does that solve it?
Cloudflare's "Data Localization Suite" can keep EU traffic on EU edges and EU keys, which addresses residency. It does not address jurisdiction: Cloudflare Inc. remains a US corporation subject to the CLOUD Act. For most Schrems II analyses, the data-localization product is an improvement but not full sovereignty.
Will switching CDN affect performance for European visitors?
For European users specifically, Bunny.net often performs equal or better than Cloudflare because their EU POP density is higher per-traffic. Real-world tests on e-commerce migrations have shown TTFB improvements of 10-30ms for EU-specific traffic. For global users (US, APAC), Cloudflare's POP count is larger.
How do we handle Cloudflare Workers replacement?
Three patterns depending on the Worker: (1) trivial request rewrites move to Bunny Edge Scripting unchanged, (2) Workers that talk to KV / Durable Objects need a re-architect - typically the logic moves to the origin and uses Redis or Postgres, (3) Workers acting as API endpoints become small Knative services on EU infrastructure.
Is Bunny.net a real Schrems II-safe alternative?
Bunny.net is BunnyWay d.o.o., headquartered in Ljubljana, Slovenia (EU member). The legal entity is fully under EU jurisdiction. Their published subprocessor list is short and EU-focused. For Schrems II, the analysis collapses to "no third-country transfer" which is materially easier than Cloudflare's data-localization story.
What about Fastly or Akamai?
Both US-headquartered. Fastly is San Francisco; Akamai is Cambridge, MA. Same CLOUD Act analysis as Cloudflare. They are not Schrems II-easier than Cloudflare; they are different US providers with different feature sets.
How long does a Cloudflare migration take?
For a typical workload (CDN, DNS, basic WAF, no Workers): 1-2 weeks elapsed. For a Workers-heavy or Tunnel-dependent setup: 4-8 weeks. We can run the whole thing as a managed migration if you want it done without burning your team's capacity.

Plan your exit from Cloudflare.

30-minute scoping call. We map your stack against EU-only alternatives, estimate the migration effort, and tell you whether it is the right call.

Schedule a call Compare another provider