Purge all

The documentation only applies to instances deployed on Alokai@Edge.

Purge all instantly invalidates every cached object across the CDN for your instance. After a purge-all, the next request for any page will bypass the cache and be served directly by your origin until the cache repopulates.

This is the most aggressive purging option available. In most cases, purging by keys or purging the automatic host key for a specific domain is a better choice — it lets you clear exactly what changed without affecting the rest of your cache.

When to use purge all

Purge all is appropriate when cached content across the entire instance needs to be refreshed at once and targeted purging is not practical. Typical scenarios include:

• Major deployment — A new storefront version has shipped with structural changes to layouts, scripts, or shared assets that affect every page.
• Global configuration change — A pricing engine update, currency switch, or platform-wide content migration that touches all responses.
• Incident recovery — Incorrect or sensitive content was cached broadly and must be removed immediately.

If only a subset of content has changed, prefer purge by keys instead.

Impact on your origin

Purge all removes every cached object at once. Until the cache rebuilds, all incoming traffic is forwarded directly to your origin servers. This creates a temporary but significant traffic spike.

Before triggering a purge all, make sure your origin can handle the increased load. Consider the following:

• Cache hit ratio drops to zero immediately after the purge and recovers gradually as pages are re-requested and re-cached.
• Response times increase during the rebuild window because every request requires a full round-trip to the origin.
• There is no soft purge option for purge all. Unlike key-based purging, purge all always performs a hard purge — stale content cannot be served while the cache repopulates.

If you need a "soft purge all" effect — marking all content as stale while keeping it servable during revalidation — consider assigning a constant surrogate key (e.g., storefront) to all responses via the Surrogate-Key header, and then soft-purging that key instead.

Purging all content from the Console

1. In the Alokai Console, navigate to your instance.
2. Open Caching Layer.
3. Click CDN Cache.
4. Click Purge all.
5. Confirm the action when prompted.

The purge takes effect within seconds. All cached objects are invalidated and subsequent requests will be served from the origin until the cache is rebuilt.

Best practices

• Use purge all sparingly. If you find yourself purging all content regularly, invest in a surrogate key tagging strategy to enable targeted invalidation instead.
• Time it carefully. Trigger a purge all during low-traffic periods when possible to minimize the impact of origin load spikes.
• Monitor your origin. Watch origin response times and error rates after a purge all to catch capacity issues early.
• Consider a global surrogate key as an alternative. Tag all responses with a constant key like storefront, and soft-purge that key when you want a gentler version of purge all that allows stale content to be served during revalidation.
• Combine with cache rules. Purge all works alongside your existing caching rules — after the purge, responses are re-cached according to your configured TTL and cache key settings.

For more background on how Fastly handles full cache purging, see the Fastly documentation on purging all content.