# CacheBoost — Automatic Cache Warming for Your Website

> CacheBoost warms your cache before visitors arrive. Boost performance, improve SEO, and deliver instant page loads — compatible with WordPress, Magento, PrestaShop and more.

Source: https://www.cache-boost.com/home.md
Language: en

---



## What is CacheBoost?

CacheBoost is a distributed cache warming platform. It pre-warms CDN and reverse-proxy caches by simulating real HTTP traffic — ensuring end users always hit cached content instead of a cold origin.

CacheBoost automatically crawls your pages before visitors arrive: better page rendering, better TTFB for users and search engine crawlers (SEO/GEO).

**Key stats:** 5M+ URLs warmed per day — 4× average speed improvement — available in 12 regions.

## The problem: cold caches

Without warming, the first visitor after a cache flush pays the full generation cost — sometimes 5× slower than cached pages.

- **Slow first byte** — Cold pages are generated on each request. Your server works hard, your visitor waits.
- **SEO impact** — Core Web Vitals (LCP, TTFB) degrade when crawlers hit an empty cache.
- **Lost conversions** — Every 100ms of latency costs up to 1% in conversions. Cold caches add seconds.

## How it works

1. **Add your site** — Verify domain ownership with a file upload or meta tag.
2. **Configure a boost** — Point CacheBoost at your sitemap, choose regions, user-agents, and a schedule.
3. **Stay warm** — CacheBoost crawls and pre-loads your pages automatically, on your schedule.

## Key features

- **Sitemap-based crawling** — Automatically discovers and warms all URLs from standard or nested XML sitemaps.
- **Multi-region warming** — Warm from 12 regions across Europe, the Americas and Asia-Pacific — reduce TTFB for visitors worldwide.
- **User-agent variations** — Simulate desktop, mobile, bots, and AI crawlers — fills every cache variant.
- **Flexible scheduling** — Run on a cron schedule. Choose interval, time of day, or trigger after deployments.
- **Email reports** — Get a summary after each warming run: URLs hit, errors, and performance data.
- **CMS compatible** — Works with WordPress, WooCommerce, Magento, PrestaShop, Shopify, Drupal, Symfony, Laravel, TYPO3, Joomla, and custom stacks.

## AI-powered cache recommendations

Pro and Unlimited plans include AI-powered cache recommendations to help you optimize warming strategy.

## Frequently asked questions

**What is cache warming?**
Cache warming is the practice of proactively requesting a site's pages right after a cache flush — before real visitors or crawlers arrive — so every subsequent request is served from a warm cache instead of triggering a slow, uncached rebuild.

**What is a cold cache?**
A cold cache is the state of a page whose cached copy is missing or has just expired. The next request can't be served from cache, so the origin server has to rebuild the page from scratch, making it markedly slower than a cached response.

**What is cache hit ratio?**
Cache hit ratio is the percentage of requests served directly from cache instead of the origin server. A ratio above 90% is considered healthy; below 70% usually signals a configuration issue or an unwarmed cache.

**What is TTFB (Time to First Byte)?**
TTFB is the time between a browser sending an HTTP request and receiving the first byte of the server's response. It measures raw server responsiveness and is the foundation Google's LCP (Largest Contentful Paint) metric is built on.

**Does CacheBoost work with my CDN?**
Yes. CacheBoost works with any CDN that serves content via HTTP — Cloudflare, Fastly, BunnyCDN, KeyCDN, and more.

**Does it work without a CDN?**
Absolutely. CacheBoost works with any caching layer — Varnish, Redis, file cache, database cache, or any HTTP-based caching system.

**Will warming requests affect server load?**
Warming requests are sent at a controlled rate. You can configure concurrency and request rate per job.

**How does the post-deploy trigger work?**
CacheBoost provides a webhook URL you add to your CI/CD pipeline (GitHub Actions, GitLab CI, etc.). Warming starts automatically when your deploy finishes.

**What if my site has thousands of URLs?**
No limit. CacheBoost handles multi-level sitemaps, sitemap index files, and Google Shopping feeds natively.

**Is my data safe?**
CacheBoost only sends HTTP requests to your public URLs — the same requests any visitor would make. No credentials or private data is ever accessed.

**Can I cancel anytime?**
Yes. No commitment, no cancellation fee. Cancel at any time from your dashboard.

## Pricing

Start free (500 URLs/month, no credit card). Paid plans from €9/month.
See: https://www.cache-boost.com/pricing



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Features — CacheBoost

> Scheduled warming, multi-region, multiple user-agents, sitemap parsing, email reports and more.

Source: https://www.cache-boost.com/features.md
Language: en

---



## Smart crawling

**XML Sitemap parsing** — Automatically discovers all URLs from standard or nested XML sitemaps.

**Multi-sitemap support** — Add multiple sitemaps per site: products, categories, blog, landing pages.

**Concurrent requests** — Control concurrency per booster to balance speed vs. server load.

## Warming engine

**Multiple user-agents** — Desktop Chrome, iPhone Safari, Googlebot, GPTBot — warm each cache bucket independently.

**Cookie variations** — Provide cookie name/value pairs to warm authenticated or segmented caches.

**Custom headers** — Send custom HTTP headers — useful for staging environments or CDN bypass.

**Content-type targeting** — Restrict warming to HTML pages, assets (CSS/JS), or images independently.

## Operations

**Cron scheduling** — Pick any cron interval. Runs happen server-side with no browser tab needed.

**Run history** — Full log of every run: URLs processed, duration, errors, and status.

**Email reports** — Optional post-run email with a summary of the warming session.

**Multiple regions** — Deploy booster agents worldwide. Each region warms independently.

## Integrations

**WordPress & WooCommerce** — Install our free plugin to warm your cache automatically after every update or purchase. See: https://www.cache-boost.com/wordpress

**MCP server** — Drive cache warming from Claude, Cursor, and other AI assistants using your API key. See: https://www.cache-boost.com/support/mcp/overview

**Magento** — Native Magento 2 integration to warm product and category caches. *(In progress)*

## Global reach

Available regions: France (Paris), United States (Iowa), Germany (Frankfurt), Spain (Madrid), United Kingdom (London).
Coming soon: Asia Pacific (Singapore), Canada (Toronto), Australia (Sydney), Brazil (São Paulo).

See: https://www.cache-boost.com/regions



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Pricing — CacheBoost

> Simple, transparent pricing. Start for free, upgrade when you grow.

Source: https://www.cache-boost.com/pricing.md
Language: en

---



Simple, transparent pricing. Start free, upgrade as you grow. No credit card required to try.

## Plans

| Plan | Monthly quota | Monthly price | Annual price (per month) |
|------|--------------|---------------|--------------------------|
| Free | 500 URLs | €0 | €0 |
| Starter | 60,000 URLs | €9 | €7 |
| Pro | 250,000 URLs | €35 | €28 |
| Unlimited | Unlimited URLs | €78 | €62 |

Annual billing saves approximately 20%. Annual plans are billed upfront (Starter: €84/yr, Pro: €336/yr, Unlimited: €744/yr).

## All plans include

- Unlimited sites
- Unlimited projects (boosts)
- Multi-region warming
- Multiple user-agents
- Cookie and header variations
- Sitemap crawling
- Cron scheduling
- Email reports
- MCP support
- SEO & GEO crawler cache tracking

Pro and Unlimited plans also include AI-powered cache recommendations.

## Frequently asked questions

**What counts as a URL?**
Each HTTP request made during a warming run counts as one URL. One page warmed across 2 user-agents = 2 URLs.

**Can I cancel anytime?**
Yes. No contracts, no cancellation fees. Cancel from your dashboard at any time.

**Does it work with Cloudflare or Varnish?**
Yes. CacheBoost works with any HTTP cache layer — Cloudflare, Varnish, Redis, WP Super Cache, and more.

**What happens when I hit my URL quota?**
Warming runs stop when the quota is reached. We notify you by email and you can upgrade at any time.

## Start free

14-day free trial. No credit card required.
Sign up: https://www.cache-boost.com/try



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Available Regions — CacheBoost

> Warm your cache from multiple regions around the world for global performance.

Source: https://www.cache-boost.com/regions.md
Language: en

---



CacheBoost operates booster agents in multiple regions. Serve cache-hit responses everywhere.

## Available regions

| Region | City | Status |
|--------|------|--------|

| France | Paris | Available |
| Germany | Frankfurt | Available |
| United Kingdom | London | Available |
| United States | Iowa | Available |
| Spain | Madrid | Available |
| Italy | Milan | Available |
| Switzerland | Zurich | Available |
| Singapore | Singapore | Available |
| India | Mumbai | Available |
| Australia | Sydney | Available |
| Brazil | São Paulo | Available |
| Canada | Toronto | Available |


## Why multi-region warming?

**CDN priming** — When your CDN misses, the origin pays. Warming from the right region primes the nearest edge node.

**Global consistency** — A cache flush in one region should not leave other regions cold. Multi-region warming solves this.

**Search engine coverage** — Googlebot crawls from US datacenters. Keep your US region warm for crawl-time performance.

## Getting started

Create a free account and configure multi-region warming in minutes.
Sign up: https://www.cache-boost.com/try



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost for WordPress & WooCommerce — Automatic cache warming after every update

> Install the CacheBoost Warmer plugin and your WordPress or WooCommerce cache warms automatically after every post save, plugin update, or product change.

Source: https://www.cache-boost.com/wordpress.md
Language: en

---



## CacheBoost for WordPress & WooCommerce

Automatic cache warming after every post save, plugin update, product change, or theme switch — without touching your server.

CacheBoost integrates with WordPress and WooCommerce via a lightweight plugin or the REST API. When content changes, CacheBoost immediately re-warms the affected pages so visitors always hit a hot cache.

## The problem: stale and cold caches

WordPress and WooCommerce sites flush their cache constantly — on every post save, product update, plugin upgrade, or theme change. Each flush exposes your visitors to cold pages:

- **Slow first byte** — The first visitor after a flush pays the full PHP/database generation cost.
- **SEO impact** — Googlebot and Core Web Vitals measurements degrade on cold pages.
- **Lost conversions** — Every 100ms of latency costs up to 1% in conversions on e-commerce pages.

## Two integration paths

### Path 1 — WordPress plugin (recommended)

Install the CacheBoost Warmer plugin. Zero configuration: the plugin automatically detects your cache layer (WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache, and more) and triggers a warm after every relevant event.

WordPress.org: https://wordpress.org/plugins/cacheboost-warmer/ — Source code: https://github.com/nhodin/cacheboost-wordpress-plugin

**Installation:**
```
wp plugin install cacheboost-warmer --activate
```

Or search for "CacheBoost Warmer" in your WordPress admin under Plugins → Add New.

After activation, open the **CacheBoost** admin menu and click **Connect to CacheBoost**: sign in or create a free account, then click **Authorize**. Your site is added and validated, its sitemap registered and a Boost created automatically — no API key to copy. (Prefer an API key? Paste it in the **API Key** field instead.)

### Path 2 — REST API

Call the CacheBoost REST API directly from your theme's `functions.php` or a custom plugin. Full control over which events trigger a warm and which URLs are targeted.

```php
add_action('save_post', function(int $postId): void {
    if (wp_is_post_revision($postId) || wp_is_post_autosave($postId)) return;
    wp_remote_post('https://api.cache-boost.com/v1/sites/YOUR_SITE_ID/warm', [
        'headers' => ['Authorization' => 'Bearer YOUR_API_KEY'],
        'body'    => json_encode(['urls' => [get_permalink($postId)]]),
    ]);
});
```

## WordPress hooks covered by the plugin

The plugin listens to these native WordPress events:

- `save_post` — Post/page published or updated
- `deleted_post` — Post or page deleted
- `edit_term` — Category, tag, or custom taxonomy updated
- `switch_theme` — Theme activated
- `wp_update_nav_menu` — Navigation menu updated
- `customize_save_after` — Customizer changes saved
- `upgrader_process_complete` — Plugin or theme updated

WooCommerce hooks (when WooCommerce is active):

- `woocommerce_update_product` — Product updated
- `woocommerce_new_product` — New product created
- `woocommerce_product_set_stock` — Stock level changed

Third-party cache plugin hooks (auto-detected):

- `after_rocket_clean_domain` — WP Rocket full-cache flush
- `w3tc_flush_all` — W3 Total Cache full flush
- `litespeed_purge_all` — LiteSpeed Cache full purge

## How warming works

1. WordPress event fires (e.g. `save_post`)
2. Plugin or API call notifies CacheBoost
3. CacheBoost queues the affected URLs
4. Distributed booster agents crawl the URLs from your chosen regions
5. Cache is hot before the next visitor arrives

## Features

- **Multi-region warming** — Warm from 12 regions across Europe, the Americas and Asia-Pacific — fills CDN edge caches worldwide.
- **Compatible with all cache layers** — Cloudflare, Varnish, Redis, WP Rocket, LiteSpeed, W3TC, and more.
- **User-agent variations** — Warm desktop, mobile, and bot cache buckets independently.
- **WooCommerce stock warming** — Re-warms product pages when inventory changes.
- **No server-side dependencies** — Warming runs on CacheBoost infrastructure, not your hosting.
- **Email reports** — Summary after each warming run: URLs hit, errors, cache HIT ratio.

## Pricing

- **Free** — 500 URLs/month. No credit card required.
- **Starter — €9/month (€7/month billed yearly)** — 60,000 URLs/month.
- **Pro — €35/month (€28/month billed yearly)** — 250,000 URLs/month. AI-powered recommendations.
- **Unlimited — €78/month (€62/month billed yearly)** — Unlimited URLs. Dedicated support.

All plans include multi-region warming, multiple user-agents, sitemap crawling, cron scheduling, and a 14-day free trial.

Start free: https://www.cache-boost.com/try

## Frequently asked questions

**Does it work with WP Rocket, LiteSpeed Cache, and W3 Total Cache?**
Yes. The plugin auto-detects these plugins and hooks into their purge events so warming starts immediately after any cache flush.

**Does it work with Cloudflare?**
Yes. CacheBoost sends real HTTP requests that populate Cloudflare's edge cache, just like a real visitor would.

**Will it slow down my WordPress admin?**
No. Warming requests are dispatched asynchronously after the WordPress action completes. There is no impact on save times.

**Can I warm only specific pages instead of the full site?**
Yes. The API path gives you full control over which URLs are warmed. The plugin warms the specific post/product URL plus its parent archive pages.

**Does it work with headless WordPress (REST API / WPGraphQL)?**
Yes. Point CacheBoost at the sitemap of your front-end domain. The plugin triggers a full-site warm after content updates.

**What if I have thousands of products?**
CacheBoost handles multi-level XML sitemaps with no URL limit. For WooCommerce stores with large catalogs, use the Unlimited plan.

See: https://www.cache-boost.com/wordpress



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Terms of Service — CacheBoost

> CacheBoost terms of service governing the use of our cache warming platform.

Source: https://www.cache-boost.com/terms.md
Language: en

---



These Terms of Service govern the use of the CacheBoost cache warming platform accessible at https://www.cache-boost.com.

By creating an account or using CacheBoost, you agree to these terms.

## Service description

CacheBoost provides an automated cache warming service. The service sends HTTP requests to URLs you configure in order to pre-populate caches on your web infrastructure.

## Acceptable use

You may use CacheBoost only for URLs and domains you own or are authorized to warm. You must not use CacheBoost to:
- Warm domains you do not own or control
- Generate traffic to harm or disrupt third-party services
- Circumvent rate limits or abuse the platform

## Account and quotas

URL quotas are counted per calendar month per plan. Unused quota does not roll over. Warming stops automatically when the monthly quota is reached.

## Subscriptions and billing

Paid subscriptions are billed monthly or annually. Annual plans are non-refundable once the billing period has started. You may cancel at any time; cancellation takes effect at the end of the current billing period.

## Service availability

CacheBoost aims for high availability but does not guarantee uninterrupted service. Scheduled maintenance may temporarily interrupt warming runs.

## Limitation of liability

CacheBoost is provided "as is". We are not liable for indirect, incidental, or consequential damages resulting from use of the service.

## Changes to terms

We may update these terms at any time. Continued use of the service after changes constitutes acceptance of the new terms.

## Contact

For questions about these terms: https://www.cache-boost.com/contact



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Introduction — CacheBoost Docs

> Learn what CacheBoost is and how it works.

Source: https://www.cache-boost.com/support/getting-started/introduction.md
Language: en

---



CacheBoost warms your site's cache by crawling URLs after each deploy, so visitors never hit a cold cache.

CacheBoost is a cache warming service. You give it a list of URLs or a sitemap, and it fetches them so your CDN or server-side cache is populated before real users arrive.

## Key concepts

**Site** — A domain you've registered with CacheBoost. Each site has a validation token you add to your server to prove ownership.

**Sitemap / Feed** — An XML sitemap or Google Shopping feed URL registered under a site. CacheBoost parses it to discover URLs to warm.

**Boost** — A warming campaign attached to a site. A boost defines which URLs to crawl, the crawl concurrency, and optionally a schedule.

**Run** — A single execution of a boost. Each run records the URLs fetched, response codes, and timing.

## Pricing

CacheBoost charges per URL crawled per month. Plans start at €0 (free tier, 500 URLs/month).
See: https://www.cache-boost.com/pricing

## Next steps

- Authentication: https://www.cache-boost.com/support/getting-started/authentication
- Quickstart: https://www.cache-boost.com/support/getting-started/quickstart
- Allow traffic: https://www.cache-boost.com/support/guides/allow-traffic



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Authentication — CacheBoost Docs

> Create and manage API keys for the CacheBoost API.

Source: https://www.cache-boost.com/support/getting-started/authentication.md
Language: en

---



All API requests require a Bearer token. This page explains how to create and manage API keys.

Every request to the CacheBoost API must include an `Authorization` header:

```
Authorization: Bearer cb_live_<your-api-key>
```

## Create an API key

1. Go to your profile page: https://app.cache-boost.com/profile
2. Click **Create API key**.
3. Give the key a name and select the scopes it needs.
4. Optionally restrict the key to specific sites.
5. Click **Create**. Copy the key — it is shown only once.

## Scopes

| Scope | Access |
|-------|--------|
| `sites:read` | List and get sites |
| `sites:write` | Create and delete sites, manage sitemaps |
| `boosts:read` | List and get boosts |
| `boosts:write` | Create, update, delete, and run boosts |
| `runs:read` | List and get runs |

## Key format

API keys have the format `cb_live_` followed by 32 hex characters. Only the first 8 characters of the key suffix are stored in the dashboard — the full key cannot be retrieved after creation.

## Revoking a key

On the profile page, click **Revoke** next to any key. Revocation is immediate.

> Store keys in environment variables or a secrets manager. Never commit them to source control.

## Next

- Quickstart: https://www.cache-boost.com/support/getting-started/quickstart
- API reference: https://www.cache-boost.com/support/api-reference/overview



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Quickstart — CacheBoost Docs

> Warm your cache in 5 minutes.

Source: https://www.cache-boost.com/support/getting-started/quickstart.md
Language: en

---



Register a site, add a sitemap, create a boost, and trigger your first run in 5 minutes.

## Prerequisites

- An API key with `sites:write`, `boosts:write`, and `runs:read` scopes
- A domain you control

## Step 1 — Register your site

```bash
curl -X POST https://api.cache-boost.com/v1/sites \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "www.example.com"}'
```

The response includes a `validation_token`. Add it to your server before proceeding.

## Step 2 — Allow CacheBoost traffic

CacheBoost sends the `X-CacheBoost-Token` header on every warm-up request. If your site has a WAF, CDN, or rate limiter, create a rule that allows requests carrying this header.

Find your token in the dashboard under **My Sites** → key icon. See: https://www.cache-boost.com/support/guides/allow-traffic

## Step 3 — Add a sitemap

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/sitemaps \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://www.example.com/sitemap.xml"}'
```

Replace `42` with your site ID from step 1. Google Shopping feeds (RSS/Atom) are also accepted.

## Step 4 — Create a boost

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/boosts \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "Full site warm", "source": "sitemap", "concurrency": 3}'
```

## Step 5 — Run the boost

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/boosts/1/run \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

The response includes a `run_id`. Poll `GET /v1/runs/{runId}` to check progress.

## Next steps

- Schedule a boost: https://www.cache-boost.com/support/guides/schedule-a-boost
- Automate with GitHub Actions: https://www.cache-boost.com/support/guides/automate-with-github-actions



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Allow traffic — CacheBoost Docs

> Verify site ownership and allowlist CacheBoost IPs.

Source: https://www.cache-boost.com/support/guides/allow-traffic.md
Language: en

---



Verify site ownership and authorize CacheBoost requests using a security token header.

CacheBoost needs to reach your site to warm it. Instead of managing IP addresses, CacheBoost identifies itself with a per-site security token sent on every request. Configure your WAF, CDN, or firewall to allow requests that carry this header.

## Site verification

When you register a site, CacheBoost gives you a `validation_token`. Choose one method, then click **Verify** in the dashboard.

### Method 1: HTML file

Create a file named `{validation_token}.html` at the root of your site:

```
https://www.example.com/a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4.html
```

The file must return HTTP 200. Its content is not checked. You can delete it after verification.

### Method 2: Meta tag

Add a `<meta>` tag to the `<head>` of your homepage:

```html
<meta name="cacheboost-token" content="YOUR_VALIDATION_TOKEN" />
```

CacheBoost fetches your homepage and checks for this tag. The token must match exactly.

## Security token header

CacheBoost sends the `X-CacheBoost-Token` header on all warm-up requests and sitemap downloads. Whitelist this header in your firewall, CDN, or WAF to authorize CacheBoost traffic.

### Find your token

Go to **My Sites** in the dashboard and click the key icon next to your site. Your header value is displayed ready to copy:

```
X-CacheBoost-Token: YOUR_SECURITY_TOKEN
```

### Configure your firewall / WAF / CDN

Create a rule that bypasses blocking or rate-limiting for requests where `X-CacheBoost-Token` matches your site's token. The exact steps depend on your provider — consult its documentation for header-based allowlist rules.

You can regenerate your token at any time from the key icon menu. Update your firewall rule whenever you regenerate it.

## Test the configuration

After configuring the header rule, trigger a manual run from the dashboard or via:

```
POST /v1/sites/{siteId}/boosts/{boostId}/run
```

Check the run results — a successful fetch for each URL confirms CacheBoost traffic is getting through.



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Schedule a boost — CacheBoost Docs

> Use cron expressions to schedule automatic cache warming.

Source: https://www.cache-boost.com/support/guides/schedule-a-boost.md
Language: en

---



Use cron expressions to run a boost automatically on a recurring schedule.

Boosts can run on a schedule using standard cron expressions. Set the `schedule` field when creating or updating a boost.

## Cron expression format

```
┌─ minute (0–59)
│ ┌─ hour (0–23)
│ │ ┌─ day of month (1–31)
│ │ │ ┌─ month (1–12)
│ │ │ │ ┌─ day of week (0–7, 0 and 7 = Sunday)
│ │ │ │ │
* * * * *
```

## Common schedules

| Schedule | Cron |
|----------|------|
| Every hour | `0 * * * *` |
| Every day at 2 AM UTC | `0 2 * * *` |
| Every Monday at 8 AM UTC | `0 8 * * 1` |
| Every 6 hours | `0 */6 * * *` |

All schedule times are in UTC.

## Set a schedule via the API

Include `schedule` in the request body when creating or updating a boost:

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/boosts \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "Nightly warm", "source": "sitemap", "concurrency": 3, "schedule": "0 3 * * *"}'
```

To remove a schedule, set `"schedule": null` via `PATCH`.

## On-demand runs

A scheduled boost can also be triggered manually at any time via `POST /v1/sites/{siteId}/boosts/{boostId}/run`. Manual runs do not affect the next scheduled run.



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Automate with GitHub Actions — CacheBoost Docs

> Trigger a cache warm after each deployment.

Source: https://www.cache-boost.com/support/guides/automate-with-github-actions.md
Language: en

---



Trigger a cache warm automatically after each deployment using GitHub Actions.

## Prerequisites

- A boost already created via the API or dashboard
- Your site ID and boost ID
- An API key with `boosts:write` scope

## Workflow

Add this workflow to `.github/workflows/warm-cache.yml` in your repository:

```yaml
name: Warm cache

on:
  deployment_status:

jobs:
  warm:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - name: Trigger CacheBoost run
        run: |
          curl -sf -X POST \
            https://api.cache-boost.com/v1/sites/${{ vars.CACHEBOOST_SITE_ID }}/boosts/${{ vars.CACHEBOOST_BOOST_ID }}/run \
            -H "Authorization: Bearer ${{ secrets.CACHEBOOST_API_KEY }}"
```

## Configuration

Add the following to your repository (Settings → Secrets and variables → Actions):

| Name | Where | Value |
|------|-------|-------|
| `CACHEBOOST_API_KEY` | Secrets | Your API key (`cb_live_...`) |
| `CACHEBOOST_SITE_ID` | Variables | Your site ID |
| `CACHEBOOST_BOOST_ID` | Variables | Your boost ID |

## Wait for the run to finish

If you want the workflow to wait until the run completes:

```yaml
      - name: Wait for run
        run: |
          RUN_ID=$(curl -sf -X POST \
            https://api.cache-boost.com/v1/sites/${{ vars.CACHEBOOST_SITE_ID }}/boosts/${{ vars.CACHEBOOST_BOOST_ID }}/run \
            -H "Authorization: Bearer ${{ secrets.CACHEBOOST_API_KEY }}" \
            | jq -r '.id')

          for i in $(seq 1 30); do
            STATUS=$(curl -sf \
              https://api.cache-boost.com/v1/runs/$RUN_ID \
              -H "Authorization: Bearer ${{ secrets.CACHEBOOST_API_KEY }}" \
              | jq -r '.status')
            echo "Run status: $STATUS"
            [ "$STATUS" = "done" ] && exit 0
            [ "$STATUS" = "failed" ] && exit 1
            sleep 10
          done
          echo "Timed out waiting for run"
          exit 1
```

> The poll loop above times out after 5 minutes (30 x 10s). Adjust `seq 1 30` and `sleep 10` to match your expected crawl duration.



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# API overview — CacheBoost Docs

> Base URL, authentication, response format, errors, and pagination.

Source: https://www.cache-boost.com/support/api-reference/overview.md
Language: en

---



Base URL, authentication, response format, errors, and pagination.

OpenAPI spec: https://www.cache-boost.com/openapi.yaml

## Base URL

```
https://api.cache-boost.com/v1
```

## Authentication

Pass your API key as a Bearer token in every request:

```
Authorization: Bearer cb_live_YOUR_KEY
```

See: https://www.cache-boost.com/support/getting-started/authentication

## Response format

All responses are JSON. Single resources return the object directly; collections return an array.

Paginated endpoints (e.g. `GET /runs`) wrap results:

```json
{
  "data": [ ... ],
  "limit": 20,
  "offset": 0
}
```

## Errors

```json
{ "error": "Invalid or expired API key." }
```

| HTTP status | Meaning |
|-------------|---------|
| `401` | Missing or invalid API key |
| `403` | Key lacks the required scope |
| `404` | Resource not found |
| `409` | Conflict (boost already running, duplicate sitemap) |
| `422` | Validation error |
| `500` | Server error |

## Pagination

`GET /runs` accepts `limit` (default: 20, max: 100) and `offset` query parameters:

```
GET /v1/runs?limit=50&offset=100
```

## Available endpoints

### Sites
- `GET /v1/sites` — https://www.cache-boost.com/support/api-reference/sites/list
- `POST /v1/sites` — https://www.cache-boost.com/support/api-reference/sites/create
- `GET /v1/sites/{siteId}` — https://www.cache-boost.com/support/api-reference/sites/get
- `DELETE /v1/sites/{siteId}` — https://www.cache-boost.com/support/api-reference/sites/delete
- `POST /v1/sites/{siteId}/validate` — https://www.cache-boost.com/support/api-reference/sites/validate

### Sitemaps
- `GET /v1/sites/{siteId}/sitemaps` — https://www.cache-boost.com/support/api-reference/sitemaps/list
- `POST /v1/sites/{siteId}/sitemaps` — https://www.cache-boost.com/support/api-reference/sitemaps/create
- `DELETE /v1/sites/{siteId}/sitemaps/{sitemapId}` — https://www.cache-boost.com/support/api-reference/sitemaps/delete

### Boosts
- `GET /v1/sites/{siteId}/boosts` — https://www.cache-boost.com/support/api-reference/boosts/list
- `POST /v1/sites/{siteId}/boosts` — https://www.cache-boost.com/support/api-reference/boosts/create
- `GET /v1/sites/{siteId}/boosts/{boostId}` — https://www.cache-boost.com/support/api-reference/boosts/get
- `PATCH /v1/sites/{siteId}/boosts/{boostId}` — https://www.cache-boost.com/support/api-reference/boosts/update
- `DELETE /v1/sites/{siteId}/boosts/{boostId}` — https://www.cache-boost.com/support/api-reference/boosts/delete
- `POST /v1/sites/{siteId}/boosts/{boostId}/run` — https://www.cache-boost.com/support/api-reference/boosts/run

### Runs
- `GET /v1/runs` — https://www.cache-boost.com/support/api-reference/runs/list
- `GET /v1/runs/{runId}` — https://www.cache-boost.com/support/api-reference/runs/get



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Get current key — CacheBoost API

> Returns the identity and scopes granted to the authenticated API key.

Source: https://www.cache-boost.com/support/api-reference/me.md
Language: en

---



Returns the identity and scopes granted to the authenticated API key.

**`GET /v1/me`** — No scope required.

## Example request

```bash
curl https://api.cache-boost.com/v1/me \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK`

```json
{
  "user_id": 42,
  "scopes": ["sites:read", "boosts:read", "boosts:write"],
  "site_ids": null
}
```

`site_ids` is `null` when the key has access to all sites, or an array of integers when restricted to specific sites.

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# List sites — CacheBoost API

> Retrieve all sites for the authenticated user.

Source: https://www.cache-boost.com/support/api-reference/sites/list.md
Language: en

---



Returns all sites belonging to the authenticated user. If the API key is restricted to specific sites, only those are returned.

**`GET /v1/sites`** — Scope: `sites:read`

## Example request

```bash
curl https://api.cache-boost.com/v1/sites \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — array of site objects.

```json
[
  {
    "id": 42,
    "domain": "www.example.com",
    "validated": true,
    "created_at": "2025-01-15T10:30:00Z"
  }
]
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Create a site — CacheBoost API

> Add a new site and get a validation token.

Source: https://www.cache-boost.com/support/api-reference/sites/create.md
Language: en

---



Add a new site. Returns a `validation_token` needed to prove site ownership. Unverified sites are capped at 10 URLs per boost.

**`POST /v1/sites`** — Scope: `sites:write`

## Body parameters

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `domain` | string | Required | Domain without scheme or trailing slash. `https://` prefix is stripped automatically. |

## Example request

```bash
curl -X POST https://api.cache-boost.com/v1/sites \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "www.example.com"}'
```

## Response

`201 Created` — new site object.

```json
{
  "id": 42,
  "domain": "www.example.com",
  "validated": false,
  "validation_token": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4",
  "created_at": "2025-01-15T10:30:00Z"
}
```

Use the `validation_token` to verify site ownership. See: https://www.cache-boost.com/support/guides/allow-traffic

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope |
| `422` | Missing or invalid `domain` |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Get a site — CacheBoost API

> Retrieve a single site by ID.

Source: https://www.cache-boost.com/support/api-reference/sites/get.md
Language: en

---



Retrieve a single site by ID.

**`GET /v1/sites/{id}`** — Scope: `sites:read`

## Example request

```bash
curl https://api.cache-boost.com/v1/sites/42 \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — site object.

```json
{
  "id": 42,
  "domain": "www.example.com",
  "validated": true,
  "validation_token": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4",
  "created_at": "2025-01-15T10:30:00Z"
}
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Site not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Delete a site — CacheBoost API

> Permanently delete a site and all associated data.

Source: https://www.cache-boost.com/support/api-reference/sites/delete.md
Language: en

---



Permanently deletes the site and all associated sitemaps, boosts, and run history. This action is irreversible.

**`DELETE /v1/sites/{id}`** — Scope: `sites:write`

## Example request

```bash
curl -X DELETE https://api.cache-boost.com/v1/sites/42 \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`204 No Content` — no response body.

> Deleting a site permanently removes all associated sitemaps, boosts, and run history.

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Site not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Validate a site — CacheBoost API

> Trigger an ownership check and mark the site as validated.

Source: https://www.cache-boost.com/support/api-reference/sites/validate.md
Language: en

---



Triggers an ownership check for a site. CacheBoost makes an HTTP request to the site and looks for the validation token. The check is synchronous — the result is returned immediately.

**`POST /v1/sites/{id}/validate`** — Scope: `sites:write`

CacheBoost tries two methods (HTTPS then HTTP):
1. **HTML file** — `{validation_token}.html` must be accessible at the site root and return HTTP 200.
2. **Meta tag** — the homepage must contain `<meta name="cacheboost-token" content="{validation_token}">` in `<head>`.

The `validation_token` is returned when creating a site (`POST /v1/sites`) and via `GET /v1/sites/{id}`.

## Example request

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/validate \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Responses

`200` — Validation succeeded:
```json
{ "validated": true }
```

`200` — Already validated:
```json
{ "validated": true, "already_validated": true }
```

`422` — Token not found:
```json
{ "validated": false, "error": "Validation token not found on the site." }
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope (`sites:write` required) |
| `404` | Site not found |
| `422` | Validation token not found on the site |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Warm URLs — CacheBoost API

> Trigger an on-demand cache warm for a list of URLs.

Source: https://www.cache-boost.com/support/api-reference/sites/warm.md
Language: en

---



Trigger an on-demand cache warm for a specific list of URLs. The response is `202 Accepted` — the run is queued and processed asynchronously.

**`POST /v1/sites/{id}/warm`** — Scope: `boosts:write`

## Body parameters

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `urls` | array | Required | List of URLs to warm. All URLs must belong to the site's domain. Maximum 5,000. |
| `region` | array | Optional | Target regions, e.g. `fr`, `de`, `es`, `gb`, `us` (`GET /v1/me` lists the available ones; `uk` is accepted as `gb`). Default: `["fr"]`. |
| `variations` | object | Optional | `user_agents` (mobile, desktop, bot, ai_crawler) and `languages`. Each combination counts as one call per URL. |

## Example request

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/warm \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"urls": ["https://www.example.com/", "https://www.example.com/about"], "region": ["fr", "us"]}'
```

## Response

`202 Accepted`

```json
{
  "run_id": 91,
  "url_count": 2,
  "status": "pending"
}
```

The site must be validated before warming. Use the returned `run_id` to poll `GET /v1/runs/{id}` for progress.
See: https://www.cache-boost.com/support/api-reference/runs/get

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope, access denied, or quota exceeded |
| `404` | Site not found |
| `409` | Site is not validated, or a warm run is already in progress |
| `422` | Validation error — missing or invalid fields, or URLs outside the site's domain |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# List warm runs — CacheBoost API

> List on-demand warm run history for a site.

Source: https://www.cache-boost.com/support/api-reference/sites/warm-runs.md
Language: en

---



Returns on-demand warm run history for a site, newest first.

**`GET /v1/sites/{id}/warm-runs`** — Scope: `boosts:read`

## Query parameters

| Parameter | Type | Description |
|-----------|------|-------------|
| `limit` | integer | Number of results to return. Default: 20, max: 100. |
| `offset` | integer | Pagination offset. Default: 0. |

## Example request

```bash
curl https://api.cache-boost.com/v1/sites/42/warm-runs \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK`

```json
{
  "data": [
    {
      "id": 91,
      "status": "done",
      "status_message": null,
      "source_urls": ["https://www.example.com/", "https://www.example.com/about"],
      "run_region": ["fr", "us"],
      "started_at": "2025-01-15T10:31:00Z",
      "finished_at": "2025-01-15T10:31:45Z",
      "summary": {
        "total_calls": 4,
        "successful_calls": 4,
        "failed_calls": 0,
        "cache_hits": 3,
        "average_response_time_ms": 98.2,
        "pops": { "CDG": 2, "IAD": 2 }
      },
      "created_at": "2025-01-15T10:30:58Z"
    }
  ],
  "total": 1,
  "limit": 20,
  "offset": 0
}
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Site not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# List sitemaps — CacheBoost API

> Retrieve all sitemaps for a site.

Source: https://www.cache-boost.com/support/api-reference/sitemaps/list.md
Language: en

---



Returns all top-level sitemaps for a site. Child sitemaps (from sitemap indexes) are not included.

**`GET /v1/sites/{id}/sitemaps`** — Scope: `sites:read`

## Example request

```bash
curl https://api.cache-boost.com/v1/sites/42/sitemaps \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — array of sitemap objects.

```json
[
  {
    "id": 7,
    "url": "https://www.example.com/sitemap.xml",
    "status": "ready",
    "status_message": null,
    "last_processed_at": "2025-01-15T02:00:00Z",
    "created_at": "2025-01-10T09:00:00Z"
  }
]
```

### Status values

| Value | Description |
|-------|-------------|
| `waiting` | Queued for download |
| `downloading` | Currently downloading the sitemap file |
| `parsing` | Extracting URLs from the sitemap |
| `ready` | Processed successfully — URLs are available |
| `error` | Processing failed — see `status_message` |

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Site not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Add a sitemap — CacheBoost API

> Add a sitemap URL to a site.

Source: https://www.cache-boost.com/support/api-reference/sitemaps/create.md
Language: en

---



Add an XML sitemap or Google Shopping feed URL to a site. CacheBoost downloads and parses it automatically in the background. Sitemap indexes are supported — child sitemaps are followed automatically.

**`POST /v1/sites/{id}/sitemaps`** — Scope: `sites:write`

## Body parameters

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `url` | string | Required | Full URL of an XML sitemap or Google Shopping feed (RSS/Atom). Must belong to the site's domain. |

## Example request

```bash
curl -X POST https://api.cache-boost.com/v1/sites/42/sitemaps \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://www.example.com/sitemap.xml"}'
```

## Response

`201 Created` — new sitemap object.

```json
{
  "id": 7,
  "url": "https://www.example.com/sitemap.xml",
  "status": "waiting",
  "status_message": null,
  "last_processed_at": null,
  "created_at": "2025-01-15T10:30:00Z"
}
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Site not found |
| `409` | Sitemap URL already exists for this site |
| `422` | Missing or invalid `url` |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Delete a sitemap — CacheBoost API

> Remove a sitemap and all its extracted URLs.

Source: https://www.cache-boost.com/support/api-reference/sitemaps/delete.md
Language: en

---



Removes a sitemap and all its extracted URLs.

**`DELETE /v1/sitemaps/{id}`** — Scope: `sites:write`

## Example request

```bash
curl -X DELETE https://api.cache-boost.com/v1/sitemaps/7 \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`204 No Content` — no response body.

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Sitemap not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# List boosts — CacheBoost API

> Retrieve all boost campaigns for the authenticated user.

Source: https://www.cache-boost.com/support/api-reference/boosts/list.md
Language: en

---



Returns all boosts belonging to the authenticated user.

**`GET /v1/boosts`** — Scope: `boosts:read`

## Example request

```bash
curl https://api.cache-boost.com/v1/boosts \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — array of boost objects.

```json
[
  {
    "id": 15,
    "site_id": 42,
    "name": "Daily warm",
    "status": "pending",
    "source_type": "sitemap",
    "region": ["fr"],
    "schedule": "0 1 * * *",
    "next_run_at": "2025-01-16T01:00:00Z",
    "created_at": "2025-01-10T09:00:00Z"
  }
]
```

### Boost status values

| Value | Description |
|-------|-------------|
| `pending` | Waiting to be scheduled or triggered |
| `running` | A run is currently in progress |
| `paused` | Boost is paused (manually or due to high error rate) |
| `done` | Last run completed successfully |
| `failed` | Last run failed |

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Create a boost — CacheBoost API

> Create a new cache warming campaign.

Source: https://www.cache-boost.com/support/api-reference/boosts/create.md
Language: en

---



Create a new cache warming campaign.

**`POST /v1/boosts`** — Scope: `boosts:write`

## Body parameters

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `name` | string | Required | Display name for the boost. |
| `site_id` | integer | Required | ID of the site to warm. |
| `source_type` | string | Required | `sitemap` or `csv`. |
| `region` | array | Required | Target regions, e.g. `fr`, `de`, `es`, `gb`, `us` (`GET /v1/me` lists the available ones; `uk` is accepted as `gb`). |
| `sitemap_ids` | array | Optional | IDs of sitemaps to warm (required when `source_type` is `sitemap`). |
| `source_url` | string | Optional | CSV file URL (required when `source_type` is `csv`). |
| `url_root` | string | Optional | Only warm URLs starting with this path. Default: `/`. |
| `exclude_ext` | array | Optional | File extensions to skip (e.g. `jpg`, `png`, `css`, `js`). |
| `variations` | object | Optional | `user_agents` (mobile, desktop, bot, ai_crawler) and `languages`. Each combination counts as one call per URL. |
| `schedule` | string | Optional | Cron expression (UTC) for automatic scheduling. |
| `call_limit` | integer | Optional | Maximum number of calls for this boost. |
| `ignore_errors` | boolean | Optional | If `true`, the boost will not auto-pause on high error rates. Default: `false`. |
| `report_email_enabled` | boolean | Optional | Send an email report when a run completes. Default: `true`. |

## Example request

```bash
curl -X POST https://api.cache-boost.com/v1/boosts \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "Daily warm", "site_id": 42, "source_type": "sitemap", "region": ["fr"], "sitemap_ids": [7], "schedule": "0 1 * * *"}'
```

## Response

`201 Created` — full boost object.

```json
{
  "id": 15,
  "site_id": 42,
  "name": "Daily warm",
  "status": "pending",
  "source_type": "sitemap",
  "region": ["fr"],
  "sitemap_ids": [7],
  "schedule": "0 1 * * *",
  "next_run_at": "2025-01-16T01:00:00Z",
  "created_at": "2025-01-15T10:30:00Z"
}
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Site or sitemap not found |
| `422` | Validation error — missing or invalid fields |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Get a boost — CacheBoost API

> Retrieve a single boost by ID.

Source: https://www.cache-boost.com/support/api-reference/boosts/get.md
Language: en

---



Retrieve a single boost by ID.

**`GET /v1/boosts/{id}`** — Scope: `boosts:read`

## Example request

```bash
curl https://api.cache-boost.com/v1/boosts/15 \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — full boost object.

```json
{
  "id": 15,
  "site_id": 42,
  "name": "Daily warm",
  "status": "pending",
  "source_type": "sitemap",
  "region": ["fr"],
  "sitemap_ids": [7],
  "variations": null,
  "report_email_enabled": true,
  "schedule": "0 1 * * *",
  "next_run_at": "2025-01-16T01:00:00Z",
  "call_limit": null,
  "created_at": "2025-01-15T10:30:00Z"
}
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Boost not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Update a boost — CacheBoost API

> Update a boost configuration.

Source: https://www.cache-boost.com/support/api-reference/boosts/update.md
Language: en

---



Update a boost's configuration. All fields are optional — only include what you want to change. Returns `409` if the boost is currently running.

**`PUT /v1/boosts/{id}`** — Scope: `boosts:write`

## Body parameters (all optional)

| Parameter | Type | Description |
|-----------|------|-------------|
| `name` | string | Display name for the boost. |
| `region` | array | Target regions. |
| `url_root` | string | Only warm URLs starting with this path. |
| `exclude_ext` | array | File extensions to skip. |
| `variations` | object | Warming variations (user agents and languages). |
| `sitemap_ids` | array | IDs of sitemaps to warm. |
| `schedule` | string\|null | Cron expression (UTC). Set to `null` to remove the schedule. |
| `call_limit` | integer\|null | Maximum number of calls. Set to `null` to remove the limit. |
| `ignore_errors` | boolean | If `true`, boost will not auto-pause on high error rates. |
| `report_email_enabled` | boolean | Send an email report when a run completes. |

## Example request

```bash
curl -X PUT https://api.cache-boost.com/v1/boosts/15 \
  -H "Authorization: Bearer cb_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"schedule": "0 3 * * *", "region": ["fr", "de"]}'
```

## Response

`200 OK` — updated boost object.

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Boost not found |
| `409` | Boost is currently running — cannot be updated |
| `422` | Validation error — invalid field values |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Delete a boost — CacheBoost API

> Permanently delete a boost and its run history.

Source: https://www.cache-boost.com/support/api-reference/boosts/delete.md
Language: en

---



Permanently deletes a boost and all its run history.

**`DELETE /v1/boosts/{id}`** — Scope: `boosts:write`

## Example request

```bash
curl -X DELETE https://api.cache-boost.com/v1/boosts/15 \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`204 No Content` — no response body.

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Boost not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Trigger a run — CacheBoost API

> Manually trigger a boost run immediately.

Source: https://www.cache-boost.com/support/api-reference/boosts/run.md
Language: en

---



Manually trigger a boost run immediately. The response is `202 Accepted` — the run is queued and processed asynchronously. Poll `GET /v1/runs/{run_id}` to track progress.

**`POST /v1/boosts/{id}/run`** — Scope: `boosts:write`

## Example request

```bash
curl -X POST https://api.cache-boost.com/v1/boosts/15/run \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`202 Accepted`

```json
{
  "run_id": 88,
  "status": "pending"
}
```

Use the returned `run_id` to poll `GET /v1/runs/{id}` for progress.
See: https://www.cache-boost.com/support/api-reference/runs/get

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Boost not found |
| `409` | A run is already in progress for this boost |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# List runs — CacheBoost API

> Retrieve run history across all boosts.

Source: https://www.cache-boost.com/support/api-reference/runs/list.md
Language: en

---



Returns run history across all boosts, newest first.

**`GET /v1/runs`** — Scope: `runs:read`

## Query parameters

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `boost_id` | integer | Optional | Filter by boost ID. |
| `limit` | integer | Optional | Results per page. Default: 20, max: 100. |
| `offset` | integer | Optional | Pagination offset. Default: 0. |

## Example request

```bash
curl "https://api.cache-boost.com/v1/runs?boost_id=15&limit=20" \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — paginated list of run objects.

```json
{
  "data": [
    {
      "id": 88,
      "boost_id": 15,
      "status": "done",
      "started_at": "2025-01-15T01:00:05Z",
      "finished_at": "2025-01-15T01:04:22Z",
      "summary": {
        "total_calls": 1240,
        "successful_calls": 1238,
        "failed_calls": 2,
        "cache_hits": 1165,
        "average_response_time_ms": 112.5
      }
    }
  ],
  "limit": 20,
  "offset": 0
}
```

### Run status values

| Value | Description |
|-------|-------------|
| `pending` | Queued and waiting to start |
| `running` | Currently in progress |
| `done` | Completed successfully |
| `failed` | Ended with errors |
| `paused` | Paused due to high error rate |

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Get a run — CacheBoost API

> Retrieve a single run by ID with summary statistics.

Source: https://www.cache-boost.com/support/api-reference/runs/get.md
Language: en

---



Retrieve a single run by ID, including full summary statistics.

**`GET /v1/runs/{id}`** — Scope: `runs:read`

## Example request

```bash
curl https://api.cache-boost.com/v1/runs/88 \
  -H "Authorization: Bearer cb_live_YOUR_KEY"
```

## Response

`200 OK` — run object with boost name and site ID.

```json
{
  "id": 88,
  "boost_id": 15,
  "boost_name": "Daily warm",
  "site_id": 42,
  "status": "done",
  "status_message": null,
  "started_at": "2025-01-15T01:00:05Z",
  "finished_at": "2025-01-15T01:04:22Z",
  "summary": {
    "total_calls": 1240,
    "successful_calls": 1238,
    "failed_calls": 2,
    "cache_hits": 1165,
    "average_response_time_ms": 112.5,
    "pops": {"CDG": 620, "AMS": 618}
  },
  "created_at": "2025-01-15T01:00:00Z"
}
```

## Errors

| Code | Description |
|------|-------------|
| `401` | Missing or invalid API key |
| `403` | Insufficient scope or access denied |
| `404` | Run not found |



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# Connect via MCP — CacheBoost Docs

> Drive cache warming from Claude Desktop, Claude Code, or Cursor with the CacheBoost MCP server.

Source: https://www.cache-boost.com/support/mcp/overview.md
Language: en

---



Drive CacheBoost cache warming from an AI agent — Claude Desktop, Claude Code, or Cursor — using the CacheBoost MCP server.

The CacheBoost MCP server exposes cache warming and run monitoring as Model Context Protocol tools. An agent connected to the server can warm your critical URLs after a deployment and report back when the cache is hot — in natural language, without writing API calls by hand.

## Endpoint

The server is a single remote Streamable HTTP endpoint:

```
https://api.cache-boost.com/mcp
```

It runs on the same host as the REST API. The protocol is session-based: your MCP client performs the `initialize` handshake, receives an `Mcp-Session-Id` header, and replays it on every subsequent tool call. Compliant clients handle this automatically.

## Authentication

The MCP server uses your existing CacheBoost API key — there is no separate MCP credential. Create a key in the app under Profile → API Keys, grant it the scopes for the tools you intend to use (see the table below), then send it in the `X-API-Key` header:

```http
X-API-Key: cb_live_YOUR_KEY
```

`Authorization: Bearer cb_live_YOUR_KEY` is also accepted (and takes precedence when both are present), but `X-API-Key` works with every MCP client, including the Claude custom connector.

A missing or invalid key is rejected with `401`. The key's scopes and its optional site restriction apply exactly as they do on the REST API: a tool called without the required scope returns an explicit tool error (never a silent success), and a site outside the key's access is reported as not found.

## Add the server to your client

CacheBoost is listed in the official MCP registry (https://registry.modelcontextprotocol.io) as `com.cache-boost/cacheboost`. If your client can browse the registry, that is the short path; everything below it is the manual equivalent.

### From your client's server directory

Search for **CacheBoost** in your client's MCP directory, add it, and paste your `cb_live_…` key when it asks for `X-API-Key`. The endpoint and transport come from the listing — there is nothing else to configure.

If your client has no directory, register CacheBoost by hand as a remote (Streamable HTTP) MCP server with an `X-API-Key` header.

### Claude Code (CLI)

```bash
claude mcp add --transport http cacheboost https://api.cache-boost.com/mcp \
  --header "X-API-Key: cb_live_YOUR_KEY"
```

### Claude Desktop / Cursor

Add an entry to the MCP servers configuration:

```json
{
  "mcpServers": {
    "cacheboost": {
      "type": "http",
      "url": "https://api.cache-boost.com/mcp",
      "headers": {
        "X-API-Key": "cb_live_YOUR_KEY"
      }
    }
  }
}
```

### Claude (custom connector)

In Claude, open Settings → Connectors → Add custom connector and enter `https://api.cache-boost.com/mcp`. Then:

- **Authentication**: choose **No authentication** (CacheBoost uses an API key, not OAuth).
- **Request headers**: add `X-API-Key` with your key `cb_live_YOUR_KEY`. Do not use `Authorization` here: the connector does not send it.

## Available tools

Each tool mirrors the scope of its REST counterpart. Grant the API key only the scopes for the tools you need.

| Tool | Required scope | Description |
|------|----------------|-------------|
| `whoami` | — | Return the identity of the API key (user, scopes, site access). Useful to validate the connection. |
| `warm_site` | `boosts:write` | Warm a list of same-origin URLs for a site, create a run, and return its `run_id`. |
| `list_warm_runs` | `boosts:read` | List a site's on-demand warm runs to poll status after `warm_site`. |
| `get_run` | `runs:read` | Retrieve a single run with its status and cache-hit statistics. |
| `list_sites` | `sites:read` | List every site the key can access. |
| `get_site` | `sites:read` | Retrieve a single site by ID. |
| `list_runs` | `runs:read` | List runs across all of the key's sites. |

`warm_site` keeps the same business rules as the REST API: URLs must be same-origin with the site, at most 5000 URLs per call, duplicates are removed, quota is pre-checked, and a `409` is returned if a run is already in progress for the site.

## Example: warm critical URLs after a deploy

Once the server is connected, ask your agent in natural language, for example:

```
Warm the critical URLs of my site after this deploy and tell me when the cache is hot.
```

The agent calls the tools in sequence:

1. `warm_site(site_id, urls)` returns `{ run_id, url_count, status: "pending" }`.
2. `get_run(run_id)` (or `list_warm_runs(site_id)`) is polled until `status` is `done` or `failed`, then reports the cache-hit results.

## Compatibility

The server targets the stateful MCP protocol lineage up to `2025-11-25`. The newer stateless `2026-07-28` protocol is not yet supported; clients negotiate down to a supported version automatically.



---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try


# CacheBoost Now Warms Your Cache from 12 Regions — CacheBoost Blog

> Seven new warming regions are live: Milan, Zurich, Toronto, São Paulo, Singapore, Mumbai and Sydney. Here's why the region matters for a CDN cache, and how to pick yours.

Source: https://www.cache-boost.com/blog/cache-warming-from-12-regions.md
Language: en

---


Tags: news, cdn, performance
Published: 2026-10-01
Author: Nicolas Hodin
Reading time: 3 min

---

**In summary:**
- Seven new regions: Italy, Switzerland, Canada, Brazil, Singapore, India and Australia
- CacheBoost now warms from 12 regions across Europe, the Americas and Asia-Pacific
- A CDN keeps one cache per edge location, so warming has to happen near your visitors
- Pick regions in the boost settings, or pass region codes to the API and MCP server
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](/regions).

## 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](/blog/cache-warming-vs-cdn-cloudflare).

## 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:

```http
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](/blog/warm-your-cache-from-claude-with-mcp).

## Missing a region?

If your audience is somewhere we don't cover yet, tell us on the [regions page](/regions). Requests sent from that form help us decide which regions to open next.


---

**CacheBoost** — Automatic cache warming for faster websites.

- Website: https://www.cache-boost.com
- Full content (all pages): https://www.cache-boost.com/llms-full.txt
- LLM index: https://www.cache-boost.com/llms.txt
- Documentation: https://www.cache-boost.com/support/getting-started/introduction
- Start free: https://www.cache-boost.com/try