Cloudflare — Examples

Example 1: Create an A Record for a New Deployment (Dynamic DNS Update)

Scenario: A CI/CD pipeline spins up a new server with a dynamically assigned IP address. After the server passes health checks, the workflow creates a DNS A record pointing the subdomain to the new IP, proxied through Cloudflare for CDN protection.

{
  "operation": "dns/create",
  "ApiToken": "{{ env.CF_API_TOKEN }}",
  "ZoneId": "{{ env.CF_ZONE_ID }}",
  "Type": "A",
  "Name": "{{ vars.subdomain }}.example.com",
  "Content": "{{ vars.new_server_ip }}",
  "Ttl": 1,
  "Proxied": true
}

Expected outcome: A new proxied A record is created. Ttl: 1 sets automatic TTL management by Cloudflare. The output contains the new id which can be stored in a workflow variable for a subsequent dns/delete or dns/update in a teardown workflow. Cloudflare's orange-cloud proxy is active, meaning origin IP is shielded and CDN features apply immediately.

Example 2: Purge Specific CDN Cache URLs After Content Deployment

Scenario: A content deployment workflow publishes three updated pages on a website. After the deploy step, the workflow triggers a Cloudflare cache purge for those exact URLs so visitors see the updated content immediately without waiting for TTL expiry.

{
  "operation": "cache/purgeByUrl",
  "ApiToken": "{{ env.CF_API_TOKEN }}",
  "ZoneId": "{{ env.CF_ZONE_ID }}",
  "Urls": [
    "https://example.com/products/new-arrivals",
    "https://example.com/blog/latest-post",
    "https://example.com/assets/js/app.{{ vars.deploy_hash }}.js"
  ]
}

Expected outcome: The three specified URLs are immediately purged from Cloudflare's global cache. The next request to each URL fetches fresh content from origin. The deploy hash variable ensures the versioned JS bundle is also purged if it changed. Purge propagates to all Cloudflare edge PoPs within seconds.

Tip: For larger deployments, build the Urls array dynamically using a previous workflow step that outputs the list of changed URLs. The maximum per call is 30 URLs. Use a Loop node to batch-purge more than 30 URLs across multiple calls.

Example 3: Set SSL Mode to "strict" for a Zone

Scenario: A security compliance workflow runs monthly across all company zones to verify and enforce that SSL mode is set to "strict". If a zone is found to be on "flexible" or "full", it is upgraded automatically.

// Step 1: Check current SSL settings
{
  "operation": "ssl/getSettings",
  "ApiToken": "{{ env.CF_API_TOKEN }}",
  "ZoneId": "{{ vars.zone_id }}"
}

// Step 2 (conditional — only if mode != "strict"):
{
  "operation": "ssl/setMode",
  "ApiToken": "{{ env.CF_API_TOKEN }}",
  "ZoneId": "{{ vars.zone_id }}",
  "Mode": "strict"
}

Expected outcome: The zone's SSL mode is enforced to strict. In strict mode, Cloudflare only connects to your origin over HTTPS with a valid (non-self-signed) certificate. An IfCondition node between the two steps checks {{ nodes.getSslSettings.output.ssl }} against "strict" and skips the setMode node if it is already correct.

Origin certificate required: Setting SSL mode to strict requires that your origin server has a valid SSL certificate. If your origin does not have one, enable it first (e.g. use a Cloudflare Origin Certificate). Setting strict mode without a valid origin certificate will make the site inaccessible.

Example 4: Batch Import DNS Records from BIND Zone File

Scenario: A domain migration workflow reads an existing BIND zone file from a file storage node, then imports all DNS records into a new Cloudflare zone in one operation.

{
  "operation": "dns/import",
  "ApiToken": "{{ env.CF_API_TOKEN }}",
  "ZoneId": "{{ vars.new_zone_id }}",
  "File": "{{ nodes.readZoneFile.output.content }}"
}

The BIND zone file content passed in File looks like:

$ORIGIN example.com.
$TTL 3600
@   IN  SOA ns1.example.com. admin.example.com. (2025052301 3600 900 604800 300)
@   IN  NS  ns1.example.com.
@   IN  A   198.51.100.1
www IN  A   198.51.100.1
api IN  A   198.51.100.2
mail IN  MX 10 mail.example.com.
@   IN  TXT "v=spf1 include:_spf.google.com ~all"

Expected outcome: All valid DNS records from the BIND zone file are created in the specified Cloudflare zone. Cloudflare skips SOA and NS records (managed by Cloudflare internally) and imports A, AAAA, CNAME, MX, TXT, and SRV records. The output includes a count of records parsed and any errors for individual records that could not be imported.

Example 5: Zero-Downtime DNS Switch — Update A Record IP, Purge Old Cache

Scenario: A blue/green deployment is complete. The workflow switches the live A record from the old server IP to the new server IP, then immediately purges the CDN cache so that users are routed to the new server on their next request.

// Step 1: List DNS records to find the target record ID
{
  "operation": "dns/list",
  "ApiToken": "{{ env.CF_API_TOKEN }}",
  "ZoneId": "{{ env.CF_ZONE_ID }}"
}

// Step 2: Update the A record to the new server IP
// (RecordId obtained from Step 1 via a DataMapping or IfCondition node)
{
  "operation": "dns/update",
  "ApiToken": "{{ env.CF_API_TOKEN }}",
  "ZoneId": "{{ env.CF_ZONE_ID }}",
  "RecordId": "{{ vars.a_record_id }}",
  "Type": "A",
  "Name": "example.com",
  "Content": "{{ vars.new_server_ip }}",
  "Ttl": 1,
  "Proxied": true
}

// Step 3: Purge cache to ensure no stale content is served
{
  "operation": "cache/purgeAll",
  "ApiToken": "{{ env.CF_API_TOKEN }}",
  "ZoneId": "{{ env.CF_ZONE_ID }}"
}

Expected outcome: DNS is updated to the new server IP with zero downtime — Cloudflare propagates the record change globally within seconds because the record is proxied (TTL only affects the proxy-to-origin path). The full cache purge ensures all cached assets are refreshed from the new server, eliminating any possibility of users hitting stale cached content from the old server.

Finding the record ID: In Step 1, use a DataMapping or CollectionOperation node after dns/list to find the record where name == "example.com" and type == "A", then extract its id field into vars.a_record_id for Step 2.