Cloudflare Canary Deployment Blueprint

Ship production changes behind Cloudflare safely with a canary deployment that shifts traffic to a new backend IP, gives you a validation window, and rolls back automatically if you do not promote. This blueprint solves the classic problem of risky DNS cutovers: instead of flipping a record and hoping, it sequences the DNS change, cache purge, and WAF allow rule, then waits for human or metric driven sign off before committing. It uses the official Kestra Cloudflare plugin, so the entire canary release lives in declarative, version controlled YAML rather than scattered scripts and console clicks.

How it works

1. upsert_canary_dns (io.kestra.plugin.cloudflare.dns.records.Upsert) points host_name at canary_ip for the given record_type, with a low TTL so the change propagates fast.
2. purge_canary (io.kestra.plugin.cloudflare.cache.Purge) clears the cached URL for the hostname so live requests reach the canary instead of stale cached responses.
3. allow_canary_source (io.kestra.plugin.cloudflare.waf.accessrules.Create) adds a temporary whitelist IP access rule for allow_ip, letting your test source through the WAF.
4. wait_for_validation (io.kestra.plugin.core.flow.Pause) holds for pause_duration (default PT15M) while you check traffic, metrics, and health.
5. cleanup (io.kestra.plugin.core.flow.Switch) branches on the promote input: true logs the promotion and keeps DNS as is, while false reverts DNS to original_ip (Upsert) and deletes the temporary access rule (io.kestra.plugin.cloudflare.waf.accessrules.Delete).

What you get

• A repeatable, auditable canary release for any Cloudflare proxied or DNS hostname.
• A built in validation pause so a human or downstream check decides promote versus rollback.
• Automatic, deterministic rollback of both DNS and the firewall allow rule when you do not promote.
• Fast cache purge so canary traffic is not masked by cached responses.

Who it's for

• Platform and SRE teams running progressive delivery on Cloudflare fronted services.
• DevOps engineers who want DNS based canaries without bespoke shell scripts.
• Release managers who need a clear, gated promote or rollback decision point.

Why orchestrate this with Kestra

Cloudflare gives you DNS, cache, and WAF APIs, but it has no native scheduler to sequence them into a guarded release with a wait gate and conditional rollback. Kestra adds event triggers and APIs to kick the canary off from CI or a webhook, retries on transient API failures, full execution lineage so every DNS flip and rule change is recorded, and a declarative YAML definition you can version and review. The Pause and Switch tasks turn promote or rollback into first class workflow logic instead of manual console steps.

Prerequisites

• A Cloudflare account with the Zone ID for your domain.
• The Kestra Cloudflare plugin installed.

Secrets

• CLOUDFLARE_API_TOKEN: a scoped Cloudflare API token with Zone:Read, Zone:DNS:Edit, Zone:Cache Purge:Edit, and Firewall:Edit (or equivalent granular scopes).

Quick start

1. Store your token as a Kestra secret named CLOUDFLARE_API_TOKEN.
2. Add the Cloudflare plugin to your Kestra instance.
3. Run the flow with zone_id, host_name, canary_ip, and original_ip. Optionally set allow_ip, record_type (default A), and pause_duration.
4. During the pause, validate the canary, then resume with promote set to true to keep it or false to roll back.

How to extend

• Replace the manual Pause with an automated health check (HTTP request plus a conditional task) that sets promote for you.
• Add a Schedule or webhook trigger to start canaries straight from your CI pipeline.
• Send a Slack or email notification on promote and rollback for release visibility.
• Chain multiple canary IPs to model weighted, multi step traffic shifting.

Links

• Cloudflare plugin docs: https://kestra.io/plugins/plugin-cloudflare
• Cloudflare orchestration guide: https://kestra.io/orchestration/cloudflare