Fastly Emergency Purge All with Confirmation Gate

Sometimes the right answer is to burn the whole cache: poisoned content, a leaked document cached at the edge, a config change that corrupted responses site-wide. Fastly's purge-all API is one call, which is exactly the problem, one call that empties every cached object and points all traffic at origin. This blueprint wraps that call in the two things a break-glass action needs: a safety catch and an audit trail. The flow fails immediately unless the confirm input is explicitly set to true, and when it does run, io.kestra.plugin.fastly.purge.All empties the service cache and Slack gets an audit message naming the service, the status, and the execution.

How it works

1. require_confirmation (io.kestra.plugin.core.flow.If) checks the confirm input, which defaults to false. Unconfirmed, the nested abort_unconfirmed task (io.kestra.plugin.core.execution.Fail) stops the flow with a message spelling out what the purge would have done.
2. Confirmed, purge_everything (io.kestra.plugin.fastly.purge.All) purges the entire cache of service_id. Its status output feeds the audit message.
3. audit_message posts the service, purge status, flow, and execution ID to Slack, with a reminder to watch origin load while the cache refills.
4. The errors block posts to the same channel on any failure, which includes refused unconfirmed attempts, so even someone poking the button leaves a trace.

What you get

• A purge-all that cannot fire by accident: default inputs abort, only an explicit true runs it.
• An audit trail in two places, the Slack channel and Kestra's execution history, for every attempt, successful or refused.
• One sanctioned path for the most destructive cache operation, instead of API tokens and curl one-liners spread across laptops.
• A built-in reminder of the blast radius, since the origin takes all traffic until the cache refills.

Who it's for

• SRE and platform teams who need an incident-response purge that is fast but not frictionless.
• Security teams handling cached-content takedowns who must show when the purge happened.
• Anyone who has watched an intern discover what purge-all does in production.

Why orchestrate this with Kestra

The Fastly console and API will happily purge everything with no confirmation, no record beyond an API log, and no notification to the team about to see origin load spike. Kestra adds the guardrails without slowing the emergency: the confirmation gate is one input toggle in the execution form, the audit lands in Slack automatically, and every attempt, refused or executed, is preserved in the execution history for the postmortem.

Prerequisites

• A Fastly service and an API token with purge permission.
• A Slack incoming webhook routed to the operations or incident channel.
• An origin sized to survive a cold cache, or at least a team that knows to watch it.

Secrets

• FASTLY_API_TOKEN: Fastly API token with purge scope.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add the two secrets to your Kestra namespace.
2. Execute the flow with only service_id set and confirm it refuses with the confirmation message.
3. Execute again with confirm set to true against a staging service and check the Slack audit message.

How to extend

• Add io.kestra.plugin.core.flow.Pause for a second approval step, so one person requests and another approves from the Kestra UI.
• Escalate the audit to PagerDuty or Opsgenie in parallel with Slack for services where a cold cache is itself an incident.
• Follow the purge with a cache warm-up task that requests the most critical URLs to shorten the origin-heavy window.
• Prefer io.kestra.plugin.fastly.purge.Keys for anything short of a true emergency, as the CMS surrogate purge blueprint shows.

Links

• Fastly plugin documentation
• Fastly purging documentation