---
title: "Supported CDNs — warmup.rocks Docs"
description: "warmup.rocks auto-detects Cloudflare, Fastly, Akamai, CloudFront, bunny.net and CDN77 from response headers — including Cloudflare Workers Cache."
canonical: https://warmup.rocks/docs/cdns
---

# Supported CDNs

Any CDN that caches at the edge benefits from warming. We recognize the major providers from their response headers automatically — no configuration, nothing to install.

## Auto-detection

Each CDN reveals itself through its own header scheme. Per request we record the provider, the edge location (colo/PoP) and the cache status:

| CDN | Detected via | Cache status | Edge location |
| --- | --- | --- | --- |
| Cloudflare | `cf-ray` | `cf-cache-status` | colo code in `cf-ray` |
| Fastly | `x-served-by` | `x-cache` | PoP suffix in `x-served-by` |
| Amazon CloudFront | `x-amz-cf-pop` | `x-cache` | `x-amz-cf-pop` |
| Akamai | `server` header | `x-cache` (debug) | —   |
| bunny.net | `server` header | `cdn-cache` | PoP in `server` |
| CDN77 | `x-77-pop` | `x-77-cache` | `x-77-pop` |

For Akamai, warming requests send the `pragma: akamai-x-cache-on` debug header so the cache status becomes visible in the response. Other CDNs ignore it.

## Cloudflare specifics

### Classic CDN cache and Workers Cache

Cloudflare has two per-colo caches: the classic CDN cache (controlled by Cache Rules and `Cloudflare-CDN-Cache-Control`) and the **Workers Cache** used by frameworks that render in a Worker (Astro, Next.js on Workers, EmDash and others). Both are per edge location and both are warmed by our requests — because the requests genuinely enter Cloudflare's network at different colos.

### Tiered caching

With Tiered Cache enabled, a miss at a small colo is fetched through a larger upper-tier data center that caches the response too. Warming passes fill those upper tiers, so even colos we never hit directly stop reaching your origin.

## What if my CDN isn't listed?

Warming still works — a GET request fills any well-behaved HTTP cache. We just can't label the provider, so those requests are reported under _origin_ with generic `x-cache` detection. If your CDN exposes identifiable headers, [tell us](mailto:hello@warmup.rocks) and we'll add detection.

## Desktop and mobile cache variants

Most sites are responsive: one cache entry per URL serves every device, and a single warm request covers all visitors. Some sites, however, split their cache by device type — for example Cloudflare's **Cache by Device Type** (Business/Enterprise), custom cache keys on `CF-Device-Type`, or dynamic serving with device detection on Akamai or Fastly. In that setup, desktop and mobile visitors hit _different_ cache entries.

For these sites, enable **Warm mobile variant** in your project settings (Boulder and Summit plans). Every URL is then warmed twice per proxy location: once with the regular desktop user agent and once with a mobile user agent (an iPhone UA that still carries the `WarmupRocks` token for your [WAF and analytics filters](https://warmup.rocks/docs/analytics-waf)). Note this doubles the requests per run. If your site is responsive with a single cache entry per URL, leave it off — the second pass would just duplicate work.

## Prerequisites on your side

-   Pages must be publicly reachable (no login wall on the URLs you warm).
-   Responses must be cacheable: a `Cache-Control` with `public, max-age=…` or `s-maxage=…`, or a CDN-level cache rule. A `no-store` response cannot be warmed by anyone.
-   Cookies that vary the response (session cookies on anonymous pages) usually make responses uncacheable — check your CDN's cacheability rules.