Fastly Surrogate Key Purge for CMS Content Updates

The reflex fix for "the article still shows the old headline" is purging the entire site, which trades one stale page for a cold cache and an origin traffic spike. Fastly's surrogate keys make that unnecessary: tag every cached response with a key derived from its content ID, and an update can invalidate exactly the objects that changed. This blueprint wraps that pattern in a flow a CMS can call: io.kestra.plugin.fastly.purge.Key soft-purges the single surrogate key for the changed content, and Discord gets the purge ID as a receipt. Editors get instant updates at the edge, the rest of the cache stays warm, and origin never notices.

How it works

1. The flow takes two inputs: the Fastly service_id and the content_key, the surrogate key the CMS stamps on the content's responses through the Surrogate-Key header.
2. purge_content (io.kestra.plugin.fastly.purge.Key) purges that one key with soft: true, marking the tagged objects stale so the edge revalidates them on the next request instead of dropping them outright.
3. notify (io.kestra.plugin.discord.DiscordIncomingWebhook) posts the purge status and id outputs to the content channel, so every invalidation has a receipt.
4. The errors block posts a distinct Discord alert when the purge fails, because an editor who believes an update is live when it is not will publish on top of stale content.

What you get

• Exact-scope invalidation: one article update purges one key, not the site.
• A warm cache everywhere else, so hit ratio and origin load are unaffected by editorial activity.
• Soft purge semantics, meaning stale-while-revalidate behavior instead of hard cache misses.
• A purge ID receipt in Discord for every content update, useful when someone asks why a page changed.

Who it's for

• Publishing and e-commerce teams whose CMS sits behind Fastly and updates content all day.
• Platform engineers replacing the "purge all on every save" webhook their CMS shipped with.
• Editorial teams who need proof an update actually reached the edge.

Why orchestrate this with Kestra

A CMS webhook that calls the Fastly API directly is invisible: no retry when the API blips, no record of what was purged when, no alert when it fails. Kestra makes each purge an execution with inputs, outputs, retries, and history, and the flow becomes the single place where purge behavior lives, swap soft for hard purge or add a verification probe without touching the CMS.

Prerequisites

• A Fastly service serving responses tagged with Surrogate-Key headers derived from content IDs.
• A Fastly API token with purge permission.
• A Discord webhook for the content channel.
• A CMS able to call the Kestra API, or a Kestra webhook trigger added in front of this flow.

Secrets

• FASTLY_API_TOKEN: Fastly API token with purge scope.
• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.

Quick start

1. Add the two secrets to your Kestra namespace.
2. Execute the flow with your service_id and a surrogate key you know is cached, then confirm the Discord receipt.
3. Wire your CMS save hook to execute this flow with the content's key.

How to extend

• Add a io.kestra.plugin.core.trigger.Webhook trigger so the CMS fires the purge directly with the key in the request body.
• Purge several related keys in one call by switching to io.kestra.plugin.fastly.purge.Keys, for example the article plus its section index.
• Follow the purge with io.kestra.plugin.core.http.Request against the content URL to verify the new version is served.
• Route receipts to Slack instead by swapping the notification task.

Links

• Fastly plugin documentation
• Fastly surrogate keys documentation