A plain-language configuration guide covering all three components: Regional Services, Customer Metadata Boundary, and Geo Key Manager.
Data Localization Suite lets a company tell Cloudflare "keep my data in this specific country/region and don't let it leave."
Who needs this and why: companies operating in Europe (GDPR), government contractors, banks, healthcare, or anyone under a law/contract requiring customer data to stay in a specific country. It's a compliance tool, not a speed booster — it can occasionally make things a bit slower since you're deliberately limiting where things can happen instead of letting Cloudflare pick the fastest option worldwide.
It's also an expensive, Enterprise-only add-on — not something a small business would buy without a specific legal/contractual reason.
The Data Localization Suite (DLS) is a collection of three Cloudflare tools that let you control where your traffic is decrypted, where your traffic logs are stored, and where your TLS private keys live — all while still using Cloudflare's global network for performance and security. It exists for organizations that need to comply with data residency regulations, such as GDPR, or that have contractual/regulatory requirements to keep certain data within a specific country or region.
It is an Enterprise-only paid add-on. Each of the three components below is configured and licensed separately — you don't need all three, and most customers start with just one, depending on what their compliance requirement is actually about (traffic processing, log storage, or key storage).
| If your requirement is about... | ...use this component |
|---|---|
| Where HTTPS traffic gets decrypted/inspected | Regional Services |
| Where request logs and analytics are stored | Customer Metadata Boundary |
| Where your private TLS/SSL keys are stored | Geo Key Manager |
Regional Services controls which Cloudflare data centers are allowed to decrypt and process your HTTPS traffic (TLS termination). Traffic is still accepted at any Cloudflare data center worldwide for basic network-layer DDoS protection, but if a request arrives outside your configured region, it's forwarded to your region still encrypted and only decrypted once it reaches an in-region data center. Everything that requires reading decrypted traffic — WAF, Bot Management, Cache, Workers, Load Balancing — only runs inside that region.
This is a compliance control, not a speed optimization — it may add latency in some cases since traffic isn't always routed to the geographically closest data center, only the closest in-region one.
There are three ways to apply Regional Services, and most customers only need one, depending on how traffic reaches Cloudflare:
| Option | Best for |
|---|---|
| Regional Hostnames | Most deployments — regionalizing specific proxied hostnames (most common) |
| Regionalized Spectrum Applications | Traffic addressed by IP that needs Static IPs or Bring Your Own IP (BYOIP) |
| Regionalized IP Bindings | Broad, self-serve regionalization of whole BYOIP prefixes via API |
After setup, you can confirm traffic is landing in the right region by checking the IngressColoName field in your Zero Trust Network Session logs, which shows the data center where traffic actually entered Cloudflare's network.
CMB controls where your traffic metadata and logs are stored — things like request URLs, timestamps, and firewall events that could identify your end users. It's a simpler, account-wide setting: you choose either the EU or the US as your boundary region, and by default no boundary is applied (logs may be stored anywhere globally).
eu or us. Selecting Global removes any boundary (the default).To review or change the setting later, go back to Settings > Configurations > Preferences and locate the Customer Metadata Boundary section.
Geo Key Manager controls where your private TLS/SSL keys are stored — the cryptographic keys Cloudflare uses to decrypt your HTTPS traffic. By default, keys are encrypted and distributed to every Cloudflare data center for fast local decryption; Geo Key Manager restricts that distribution to specific countries or regions.
V2 lets you define a policy with allow/block lists of specific countries or regions (e.g. "store in the EU and US" or "store in the EU but never France"). You follow the same custom-certificate upload flow via the API, but include a policy parameter on the request instead of the older geo_restrictions parameter (the two are mutually exclusive).
Not every region is available for every DLS component. A few common examples:
| Region | Geo Key Manager | Regional Services | Customer Metadata Boundary |
|---|---|---|---|
| European Union | ✅ | ✅ | ✅ |
| United States | ✅ | ✅ | ✅ |
| United Kingdom | ✅ (v2 only) | ✅ | Uses EU boundary |
| Canada | ✅ (v2 only) | ✅ | ✘ |
| Australia | ✅ (v2 only) | ✅ | ✘ |
| FedRAMP Moderate (Domestic) | ✅ (v2 only) | ✅ | ✅ (uses US boundary) |
Regional Services supports the widest range of regions — including individual countries (Germany, France, Japan, Brazil, and many others), compliance-framework regions (FedRAMP, IRAP Protected, ISO 27001 Certified EU), and even "exclusive of" regions that exclude specific countries rather than restrict to them. Customer Metadata Boundary is limited to just EU or US. Geo Key Manager's country list depends on whether you're using v1 (US/EU/High-Security only) or the v2 Closed Beta (broader country list).