Alternatywa tylko UE dla 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 Stack zastępczy, wyłącznie UE 11 zmapowanych usług
Dostawca
Cloudflare
Siedziba
San Francisco, CA
Jurysdykcja
United States
Reżim prawny
CLOUD Act, FISA 702, EO 12333

"Region UE" to nie suwerenność. Decydują cztery pytania.

Rezydencja danych mówi, gdzie leżą bity. Suwerenność mówi, który system prawny może wymusić dostęp. Odpowiedź musi się bronić we wszystkich czterech punktach, inaczej stack nie jest suwerenny.

Rezydencja

Gdzie dane są fizycznie przechowywane?

Nie "w chmurze": które centrum danych, w jakim kraju, pod jaką jurysdykcją.

Podprzetwarzający

Kto jeszcze znajduje się w Państwa ścieżce danych?

Każdy dostawca dotykający danych: CDN, przekaźnik e-mail, tracker błędów, pipeline analityczny.

Jurysdykcja

Czyje prawa mogą wymusić ujawnienie?

Dostawca z siedzibą w USA podlega FISA 702 i CLOUD Act, nawet gdy dane leżą we Frankfurcie.

Depozyt kluczy

Kto faktycznie ma klucze szyfrujące?

Jeśli dostawca chmury trzyma zarówno dane, jak i klucze, może je odczytać, niezależnie od jakiejkolwiek umowy powierzenia.

Nie spełnia AWS · Azure · GCP · Region UE

Nie spełnia kryterium jurysdykcji i depozytu kluczy.

Bity w UE, spółka matka w USA, podprzetwarzający z USA w domyślnej ścieżce, klucze zarządzane przez dostawcę.

Spełnia Stack zarządzany przez Binadit

Spełnia wszystkie cztery kryteria.

Hostowane w UE na infrastrukturze z siedzibą europejską. Zero podprzetwarzających z USA w domyślnej ścieżce. Klucze klienta lub europejskiego KMS. Wymienieni z nazwy w Państwa DPA z Artykułu 28.

Dlaczego zespoły wychodzą 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 usługi i ich odpowiedniki tylko z UE

Migracja to nie "zamiana jednej skrzynki na drugą". Poniższe mapowanie jest tym, co uruchamiamy dla klientów opuszczających Cloudflare na gruncie Schrems II: pełna jurysdykcja UE, brak amerykańskiej spółki matki w ścieżce danych.

Cloudflare CDN

Czego używamy zamiast tego
Wdrażamy i utrzymujemy dla Ciebie CDN w UE: Bunny.net lub KeyCDN, z cache'owaniem Nginx i Varnish na Twoim origin.
Notatka inżynierska
CDN to jedna z niewielu warstw, których nie utrzymujemy samodzielnie. Wybieramy dostawcę z UE, konfigurujemy nagłówki cache, strategię czyszczenia cache oraz origin shielding, i zarządzamy tym w ramach usługi managed.

Cloudflare WAF

Czego używamy zamiast tego
Binadit Managed Cloud Platform. Coraza lub ModSecurity z OWASP Core Rule Set, plus CrowdSec do blokowania behawioralnego.
Notatka inżynierska
Reguły są dostrajane na podstawie Twojego ruchu, a nie dostarczane jako domyślny zestaw, co zapobiega sytuacji, w której WAF po cichu blokuje prawdziwych klientów.

Cloudflare DDoS protection

Czego używamy zamiast tego
Binadit Private Infrastructure. Upstream filtrowanie wolumetryczne, z rate limiting i CrowdSec na edge aplikacji.
Notatka inżynierska
Ataki wolumetryczne są wchłaniane zanim dotrą do Twoich serwerów. Nadużycia na poziomie aplikacji obsługiwane są tam, gdzie faktycznie można je zrozumieć - jak najbliżej Twojego ruchu.

Cloudflare DNS

Czego używamy zamiast tego
Binadit Managed Cloud Platform. PowerDNS lub Knot, autorytatywne, podpisane DNSSEC.
Notatka inżynierska
Strefy są eksportowane i importowane jako standardowe pliki stref, więc zazwyczaj jest to najmniej problematyczna część migracji. Obniż TTL na tydzień przed migracją.

Cloudflare R2 (storage)

Czego używamy zamiast tego
Binadit Managed Cloud Platform. MinIO lub Ceph RGW, kompatybilne z S3.
Notatka inżynierska
Zerowy egress R2 jest unikalny; u unijnych dostawców egress również jest zwykle darmowy lub bardzo niski, więc argument kosztowy pozostaje aktualny.

Cloudflare Workers

Czego używamy zamiast tego
Binadit Managed Cloud Platform. Knative lub OpenFaaS na Twoim klastrze Kubernetes.
Notatka inżynierska
Większość funkcji, które migrujemy, okazuje się być niewielkimi handlerami HTTP, które bez problemu działają jako zwykłe kontenery, często taniej i bez cold startu.

Cloudflare Pages

Czego używamy zamiast tego
Binadit Managed Cloud Platform. Nginx serwujący zbudowane assety, wdrażane z GitLab CI.
Notatka inżynierska
Główną wartością Pages jest pipeline budowania; ten element przenosi się do dostawcy CI.

Cloudflare Tunnel (Argo)

Czego używamy zamiast tego
Binadit Managed Cloud Platform. Tunele WireGuard lub reverse proxy Nginx w Twoim własnym DMZ.
Notatka inżynierska
Netbird ma siedzibę w Niemczech i zapewnia wzorzec "bez publicznego IP" w jurysdykcji UE. Standardową suwerenną odpowiedzią jest samodzielnie zarządzany Wireguard.

Cloudflare Access (zero trust)

Czego używamy zamiast tego
Binadit Managed Cloud Platform. WireGuard z Keycloak lub Authentik przed usługami wewnętrznymi.
Notatka inżynierska
Dla aplikacji wyłącznie wewnętrznych, reverse proxy zabezpieczone przez OIDC na infrastrukturze UE jest funkcjonalnie równoważne.

Cloudflare Stream (video)

Czego używamy zamiast tego
Transkodowanie za pomocą FFmpeg na infrastrukturze Binadit, dostarczane przez europejski CDN, taki jak Bunny.net.
Notatka inżynierska
Transkodowanie to obciążenie wsadowe, które działa na posiadanej już mocy obliczeniowej. Dostarczanie odbywa się zwykłym HTTP przez CDN, który dla Ciebie skonfigurujemy.

Cloudflare Bot Management

Czego używamy zamiast tego
Binadit Managed Cloud Platform. CrowdSec do wykrywania behawioralnego, z rate limiting i stronami wyzwań na brzegu sieci.
Notatka inżynierska
CrowdSec ma siedzibę we Francji i staje się coraz bardziej rozbudowany. Dla e-commerce o wysokim ruchu, DataDome (również z Francji) jest alternatywą klasy enterprise.

Jak migrujemy z Cloudflare

Typowa migracja segmentu mid-market przebiega w trzech fazach. Poniższe liczby zakładają zespół inżynierski 6-10 osób i umiarkowanie złożony stack aplikacyjny.

  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).

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.

Zaplanuj wyjście z Cloudflare.

30-minutowa rozmowa zakresowa. Mapujemy Państwa stack względem alternatyw tylko z UE, szacujemy nakład pracy migracji i mówimy, czy to właściwa decyzja.