Sync Cloudflare DNS from Terraform Output

Keep your Cloudflare DNS records in lockstep with the infrastructure Terraform provisions. Every time a server, load balancer, or instance changes its public IP, this Kestra blueprint reapplies Terraform, reads the new IP, and upserts the matching Cloudflare A record so traffic always reaches the current origin. It closes the gap between infrastructure as code and DNS that usually requires a manual edit in the Cloudflare dashboard or a brittle glue script. The flow purges the Cloudflare cache for the hostname so clients pick up the change immediately, then posts a confirmation to Slack for an auditable record of every DNS update.

How it works

1. The provision task (io.kestra.plugin.terraform.cli.TerraformCLI) runs inside a Docker task runner on the hashicorp/terraform:latest image. It runs terraform init, then terraform apply -auto-approve, and writes the instance_ip output to ip.txt via outputFiles.
2. The upsert_dns task (io.kestra.plugin.cloudflare.dns.records.Upsert) reads ip.txt, trims it, and creates or updates the A record named from inputs.record_name in the zone given by inputs.zone_id, with proxied: true.
3. The purge_cache task (io.kestra.plugin.cloudflare.cache.Purge) purges the cached responses for https://{record_name}/ so the new origin takes effect right away.
4. The notify task (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts the record name, new IP (outputs.upsert_dns.content), and the action taken to Slack.
5. A disabled Schedule trigger (nightly_sync) is wired to reconcile DNS with infrastructure every night at 0 1 * * *. Enable it to run unattended.

What you get

• DNS records that always match the IP Terraform actually provisioned.
• Immediate cache invalidation so clients are not served a stale origin.
• A Slack message documenting each create or update for traceability.
• A reusable, declarative pipeline instead of ad hoc dashboard edits.

Who it's for

• Platform and DevOps engineers managing infrastructure with Terraform.
• SREs who need DNS to follow ephemeral or rebuilt instances.
• Teams standardizing release and provisioning workflows on Kestra.

Why orchestrate this with Kestra

Terraform can provision infrastructure but has no native scheduler, no retry semantics across external systems, and no built-in way to react to events or chain a DNS update, cache purge, and notification after an apply. Kestra adds event and schedule triggers, automatic retries, full execution lineage across Terraform, Cloudflare, and Slack, and a single declarative YAML definition you can version and review. The result is a reconciliation loop that runs reliably on its own rather than depending on someone remembering to update DNS by hand.

Prerequisites

• A Terraform configuration that exposes the target IP as an output named instance_ip (the blueprint ships a stub you replace with your real infrastructure).
• A Cloudflare zone and the zone ID that owns the record.

Secrets

• CLOUDFLARE_API_TOKEN: Cloudflare token with DNS edit and cache purge permissions, used by both Cloudflare tasks via pluginDefaults.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL for the notification.

Quick start

1. Set CLOUDFLARE_API_TOKEN and SLACK_WEBHOOK_URL as secrets in your Kestra namespace.
2. Replace the stub main.tf with your real Terraform, keeping an instance_ip output.
3. Run the flow with your zone_id and record_name inputs.
4. Confirm the DNS change in Cloudflare and the message in your Slack channel.

How to extend

• Set proxied: false on upsert_dns for a DNS-only record instead of a proxied one.
• Change recordType to manage AAAA, CNAME, or other record types.
• Add records for multiple hostnames by looping the Terraform outputs.
• Enable the nightly_sync Schedule trigger, or swap it for a webhook or flow trigger to reconcile DNS on every deploy.

Links

• Cloudflare plugin docs
• Cloudflare orchestration with Kestra