CacheBoost now runs booster agents in 12 regions. Until now you could warm from France, Germany, Spain, the United Kingdom and the United States. Seven new regions are open as of today: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney.
If your visitors are outside Western Europe and the US, you can now warm the CDN edges that actually serve them.
The full list
| Region | City | API code |
|---|---|---|
| France | Paris | fr |
| Germany | Frankfurt | de |
| United Kingdom | London | gb |
| Spain | Madrid | es |
| Italy (new) | Milan | it |
| Switzerland (new) | Zurich | ch |
| United States | Iowa | us |
| Canada (new) | Toronto | ca |
| Brazil (new) | São Paulo | br |
| Singapore (new) | Singapore | sg |
| India (new) | Mumbai | in |
| Australia (new) | Sydney | au |
The live list is always on the regions page.
Why the region matters
A CDN doesn't have one cache. It has one per location. When a booster in Paris requests your homepage through Cloudflare, it fills the cache of the Paris data center. A visitor in Sydney goes through the Sydney data center, which hasn't seen the page yet: that request is a miss, and it travels all the way to your origin.
The further the origin, the worse that miss gets. The network round trip between Sydney and a server in Europe alone is around 250 to 300 ms, before your application has even started building the page.
Tiered caching (Cloudflare Tiered Cache, CloudFront Origin Shield) softens this: a miss at the edge is served by an upper-tier cache instead of the origin. But the edge in front of the visitor still misses on the first request. Warming from a nearby region is what turns that first request into a hit.
We covered the per-edge logic in more detail in Cache Warming vs CDN.
Which regions to choose
Start from your analytics, not from the map. Look at where your traffic comes from, then match each large audience with the nearest region:
- Brazil: São Paulo.
- Canada: Toronto.
- Southeast Asia: Singapore.
- India: Mumbai.
- Australia: Sydney.
- Switzerland and Italy: Zurich and Milan.
A booster warms the edges its own requests go through, which are the ones closest to it. Large CDNs have several locations per country, so one region won't warm all of them. For the edges it doesn't reach, tiered caching (see above) keeps the misses away from your origin.
Keep the US region on if search traffic matters to you: Googlebot crawls mostly from the United States, and a crawler that hits a cold page gets the slow version.
Don't enable every region by default. Each region sends its own requests to your origin, so ten regions mean ten times the warming load. Enable the ones where you have real visitors.
How to enable a new region
In the app, open a boost, select the regions you want and save. The next run warms from every selected region.
With the API, pass the region codes in the region field when you create or update a boost, or when you warm a list of URLs:
POST /v1/sites/{id}/warm
X-API-Key: cb_live_...
Content-Type: application/json
{
"urls": ["https://www.example.com/", "https://www.example.com/pricing"],
"region": ["fr", "sg", "au"]
}GET /v1/me returns the regions available to your account. The old uk code still works as an alias for gb.
With the MCP server, the warm_site tool takes the same region list, so you can ask your assistant to "warm the homepage from Singapore and Sydney" after a deploy. Setup is in Warm Your Cache from Claude, Cursor, or Any MCP Client.
Missing a region?
If your audience is somewhere we don't cover yet, tell us on the regions page. Requests sent from that form help us decide which regions to open next.
