Cloudflare and the EU: GDPR, Data Localization, and Whether Your Traffic Actually Stays in Europe

Cloudflare can be used by an EU business under GDPR: it acts as a processor under a data processing addendum, relies on its certification under the EU-US Data Privacy Framework and on standard contractual clauses for transfers, and is verified under the EU Cloud Code of Conduct. What that does not automatically mean is that your traffic stays in Europe. By default, requests are answered at the nearest edge location worldwide, and logs and metadata flow to wherever the account is configured to send them. Keeping data in the EU is a set of settings and a paid product, not the default, and the origin server behind Cloudflare has to be in Europe too.

Searches for this phrase split into two groups: people checking whether they are allowed to use Cloudflare at all, and people who have decided they would rather not and want a European alternative. This post is for the first group, and for anyone in the second who has not yet checked what the settings actually do. It is a practical walk through what Cloudflare sees, where it keeps it, which controls move it, and what still has to be true about the rest of your stack.

Table of contents

• What Cloudflare sees when it sits in front of a site
• The legal basis, in plain terms
• What the data localization options actually control
• The origin is your problem, not Cloudflare’s
• Do you need a European alternative
• A practical checklist
• How this fits the rest of the stack
• FAQ

What Cloudflare sees when it sits in front of a site

Cloudflare is a reverse proxy. Every request to a proxied hostname terminates at a Cloudflare edge, is inspected, cached or forwarded, and the response comes back the same way. That means Cloudflare sees, for each request: the visitor’s IP address, the full URL, the headers, cookies, and, unless you are running a mode where the edge cannot decrypt, the body. The TLS termination modes post covers that last part.

Under GDPR the visitor’s IP address is personal data, and so is anything identifying in a cookie or URL. So a site on Cloudflare has a processor handling personal data on its behalf, which is fine and normal, provided the paperwork and the transfer basis exist. Cloudflare’s data processing addendum is incorporated into its terms for that reason.

The part people miss is the second stream: not the request itself, but what Cloudflare records about it. Analytics, logs, firewall events, bot scores. That metadata is where the where-is-it-stored question really lives.

The legal basis, in plain terms

Three things make the transfer lawful, and Cloudflare publishes all three.

• The EU-US Data Privacy Framework. Cloudflare is certified under it, and that certification is the primary basis it cites for moving personal data from the EEA, Switzerland and the UK to the United States.
• Standard contractual clauses. The fallback, built into the data processing addendum, in case the framework is invalidated the way its two predecessors were.
• The EU Cloud Code of Conduct. Cloudflare’s services are verified compliant under it, with a published verification ID, which is a third-party attestation that the processing terms meet GDPR requirements.

That is a defensible position for a controller. It is not the same as data residency. A lawful transfer is still a transfer, and if your obligation, contractual or regulatory, is that the data does not leave the EU, the legal basis is beside the point and the settings are the whole point.

What the data localization options actually control

Cloudflare sells regional controls as a paid add-on on its enterprise tier, and the two halves do different things.

• Regional Services restricts where traffic is decrypted and inspected. With the EU region selected, TLS is terminated and the request is processed only at data centres inside the EU, even though the visitor may have connected to a closer edge elsewhere, which forwards the encrypted bytes on.
• The customer metadata boundary restricts where the logs and analytics about that traffic are stored and processed. It is the setting that keeps the IP addresses in firewall events and request logs in Europe.

Two consequences. First, on the free, pro and business plans neither control exists, so the accurate description of those plans is lawful under GDPR, not EU-resident. Second, even with both enabled, some products are excluded from the boundary and the documentation lists which. If a compliance officer asks whether everything is in the EU, the answer is a list, not a yes.

The origin is your problem, not Cloudflare’s

Localizing the proxy does nothing about where the site itself runs. If the origin server is in a US region, the request is inspected in Frankfurt and then answered from Virginia, and the data is stored there. Residency is end to end or it is not residency.

So the checklist for an EU-resident stack has three rows, and Cloudflare is only one of them: the proxy and its metadata, the origin service, and the database and storage behind it. On RunxBuild, services, managed Postgres and MySQL, and storage are placed in a region you choose, and the database’s network security keeps it reachable only from the service beside it. That is the origin row of the table. The proxy row is a Cloudflare setting; the database row is a region selection at create time.

The frequent mistake is to spend a week on the proxy row and then discover the backups are replicated to another continent by default. Ask every layer the same question: where does it store, and where does it send copies?

Do you need a European alternative

Plenty of teams decide the honest answer to the residency question, a list of exclusions and an enterprise contract, is more than they want to manage, and move to a European CDN or WAF, or to none. That is a reasonable decision, and it is a decision about scope rather than about Cloudflare being non-compliant.

The cases where it is clearly the right call: a regulator or a customer contract that says EU-only with no exceptions, a data protection officer who wants a single-jurisdiction supplier list, or a public-sector procurement rule. The cases where it usually is not: a marketing site with analytics, a SaaS whose customers are worldwide anyway, or a team that has not yet enabled the settings that exist. Turn on what you have first, write down what it covers, and then decide whether the gap is a product problem or a procurement problem.

A practical checklist

1. Sign the data processing addendum and keep a copy with the rest of the processor records.
2. Decide what the obligation actually is: lawful transfer, or no transfer. They are different projects.
3. If no transfer: price Regional Services and the metadata boundary, and read the exclusion list before buying.
4. Put the origin, the database and the backups in an EU region, and check where each replicates.
5. Set log retention and analytics retention to the minimum the business needs.
6. Write the data map down: request path, log path, backup path, and where each one lands.

The map is the deliverable. The next time someone asks whether the site is EU-hosted, the answer is a diagram with regions on it, not a shrug at the CDN.

How this fits the rest of the stack

Residency is a property of the whole stack, and the proxy is the cheapest layer to fix. The expensive ones are the origin and the database, and it helps to price them with the region already decided. The RunxBuild hosting calculator lays out the service plan, the managed database, the storage and the bandwidth as separate line items, so the cost of running the origin in Europe is a number rather than a guess. Decide the region, place every layer in it, and keep the map current.

Useful related references:

• Cloudflare Logpush: What It Ships, What It Costs, and What It Misses
• Cloudflare TLS Termination: The Encryption Modes and the One That Is a Trap
• namecheap with cloudflare: The Three Modes and the One That Actually Saves Money
• Services on RunxBuild

FAQ

Is Cloudflare GDPR compliant?

Cloudflare acts as a processor under a data processing addendum, is certified under the EU-US Data Privacy Framework, falls back on standard contractual clauses, and is verified under the EU Cloud Code of Conduct. That makes using it lawful for an EU controller. It does not by itself keep data in the EU.

Does Cloudflare store EU data in the EU?

Not by default. Traffic is processed at the nearest edge worldwide and metadata is stored according to the account configuration. Keeping processing and logs inside the EU requires the paid regional controls, Regional Services and the customer metadata boundary, which are available on the enterprise tier and have documented exclusions.

Can I restrict Cloudflare to EU-only traffic processing?

With Regional Services set to the EU region, TLS termination and inspection happen only in EU data centres; edges elsewhere forward encrypted traffic. Metadata storage is controlled separately by the metadata boundary. Both are enterprise add-ons, and neither affects where your origin server or database live.

What is the EU-US Data Privacy Framework?

An adequacy arrangement under which certified US companies can receive personal data from the EEA. Cloudflare cites its certification as the primary transfer basis, with standard contractual clauses as the fallback if the framework is invalidated as its two predecessors were.

Do I need a European alternative to Cloudflare?

Only if your obligation is no transfer at all rather than a lawful transfer, or if procurement rules require a single-jurisdiction supplier. Before switching, enable the controls you already have, place the origin and database in an EU region, and write down what remains outside. Then decide whether the gap is real.