The simple edge story is not enough for real applications. Once you have stateful backends, data residency requirements, or compliance constraints, you need to distinguish where code runs, where data lives, and where HTTPS traffic is decrypted.
User -> nearest Cloudflare colo -> request handled there
That works very well for stateless edge workloads such as CDN caching, WAF decisions, redirects, header manipulation, simple authentication checks, and static asset handling.
User in Sydney -> Worker runs near Sydney -> Worker calls database in Frankfurt -> multiple Sydney <-> Frankfurt round trips
When the backend is far away and the application is chatty, nearest-user execution can be slower than better-placed execution.
For Workers, placement answers one question: where does my code execute?
Default: User -> nearest colo -> Worker Smarter options: - smart placement - region-based placement - host or hostname-based placement
This is especially useful when the Worker depends on an AWS-backed database or API that remains in a specific region.
D1 placement is not the same thing. It is about where the database runs and stores data.
Worker placement = code locality D1 data location = data locality Jurisdiction = compliance boundary
A location hint is a preference. A jurisdiction is a stronger constraint about where data is allowed to exist.
| Control | What It Controls |
|---|---|
| Workers placement | Where code runs. |
| D1 data location | Where the database runs and stores data. |
| D1 jurisdiction | The legal or compliance boundary for database location. |
| Regional Services | Where HTTPS traffic is decrypted and serviced. |
If a Worker performs many database queries or API calls, running closer to the backend often matters more than running closest to the user.
Enterprises need clear answers about where customer data is stored, where traffic is decrypted, and which jurisdiction applies.
Many systems move to Cloudflare gradually: frontend and security first, then edge logic, while databases and internal APIs remain in AWS for some time.
Regional Services adds a different control again: where Cloudflare decrypts and processes HTTPS traffic.
User -> nearest Cloudflare site receives encrypted traffic -> traffic is forwarded encrypted to an allowed region -> TLS termination and application processing happen there
Cloudflare = global edge by default
+ service-specific placement controls
+ data locality controls
+ compliance boundaries
Cloudflare is not abandoning the edge model. It is making the edge model usable for more serious and more regulated applications.
PoP and colo explain where traffic enters and can be served. Placement explains where code should run, where data should live, and where decrypted traffic should be processed.