Skip to content
Cloudflare Docs
DirectoryAPISDKsChangelog

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
Developer platform
hero image

  1. R2 SQL now supports UNION, INTERSECT, EXCEPT, and SELECT DISTINCT

    R2 SQL

    R2 SQL now supports set operations (UNION, INTERSECT, EXCEPT) and SELECT DISTINCT, expanding the range of analytical queries you can run directly on Apache Iceberg ↗ tables in R2 Data Catalog.

    Set operations

    Combine the results of multiple SELECT statements:

    • UNION — returns all rows from both queries, removing duplicates
    • UNION ALL — returns all rows from both queries, including duplicates
    • INTERSECT — returns only rows that appear in both queries
    • EXCEPT — returns rows from the first query that do not appear in the second
    -- Find zones that had either firewall blocks OR high-risk requests
    SELECT zone_id FROM my_namespace.firewall_events WHERE action = 'block'
    UNION
    SELECT zone_id FROM my_namespace.http_requests WHERE risk_score > 0.8
    -- Find zones with both firewall blocks AND high traffic
    SELECT zone_id FROM my_namespace.firewall_events WHERE action = 'block'
    INTERSECT
    SELECT zone_id FROM my_namespace.http_requests
    GROUP BY zone_id
    HAVING COUNT(*) > 10000
    -- Find enterprise zones that have not been compacted
    SELECT zone_id FROM my_namespace.zones WHERE plan = 'enterprise'
    EXCEPT
    SELECT zone_id FROM my_namespace.compaction_history

    Select distinct

    Eliminate duplicate rows from query results:

    SELECT DISTINCT region, department
    FROM my_namespace.sales_data
    WHERE total_amount > 1000
    ORDER BY region, department
    LIMIT 100

    For large datasets where approximate results are acceptable, approx_distinct() remains a faster alternative for counting unique values.

    For the full syntax reference, refer to the SQL reference. For performance guidance, refer to Limitations and best practices.

  1. Post-meeting transcriptions are now Generally Available in RealtimeKit

    Realtime

    RealtimeKit lets you build products where people meet over live audio and video — such as HealthTech, EdTech, proctoring, and other real-time platforms — on Cloudflare's global WebRTC infrastructure.

    Post-meeting transcription is now Generally Available, so completed RealtimeKit meetings can automatically produce full transcript files after they end. Those transcripts can also power AI-generated summaries for meeting notes, review workflows, and follow-up tasks after the transcript is available.

    Post-meeting transcription is a managed service powered by Workers AI using Whisper Large v3 Turbo. RealtimeKit handles transcription processing and can return transcript and summary files through webhooks or the REST API, so you do not need to run your own transcription infrastructure.

    Generate transcripts and summaries

    To generate a transcript after a meeting ends, set transcribe_on_end: true when creating a meeting. To also generate an AI summary automatically after the transcript is available, set summarize_on_end: true:

    Terminal window
    curl -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/realtime/kit/$APP_ID/meetings" \
      -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
      -H "Content-Type: application/json" \
      -d '{
        "title": "Weekly product review",
        "transcribe_on_end": true,
        "summarize_on_end": true,
        "ai_config": {
          "transcription": {
            "language": "en"
          },
          "summarization": {
            "word_limit": 500,
            "text_format": "markdown",
            "summary_type": "team_meeting"
          }
        }
      }'

    Consume results

    When RealtimeKit finishes processing a meeting, it creates download URLs for the transcript and, if summarize_on_end is set, the summary. You can receive those URLs automatically with webhooks, or fetch them later for a specific session with the REST API.

    To receive results as soon as they are ready, configure the meeting.transcript and meeting.summary webhook events:

    Terminal window
    curl -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/realtime/kit/$APP_ID/webhooks" \
      -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
      -H "Content-Type: application/json" \
      -d '{
        "name": "AI results webhook",
        "url": "https://example.com/webhook",
        "events": ["meeting.transcript", "meeting.summary"],
        "enabled": true
      }'

    To fetch results later, call the transcript or summary endpoint for the session:

    Terminal window
    curl -X GET "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/realtime/kit/$APP_ID/sessions/$SESSION_ID/transcript" \
      -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
    

    curl -X GET "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/realtime/kit/$APP_ID/sessions/$SESSION_ID/summary" \
      -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

    Use the Generate summary of transcripts for the session API only if summarize_on_end was not set and you want to generate a summary manually after the transcript is available:

    Terminal window
    curl -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/realtime/kit/$APP_ID/sessions/$SESSION_ID/summary" \
      -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

    Post-meeting transcription supports CSV, JSON, SRT, and VTT transcript outputs, automatic language detection and Whisper language codes. RealtimeKit also supports real-time transcription with Deepgram Nova-3 for live captions, in-meeting accessibility, and real-time note-taking.

    Learn more in the RealtimeKit transcription docs and summary docs.

  1. Rollback support now available in Workflows

    Workflows

    Workflows now supports saga-style rollbacks, allowing you to add compensating logic to each step.do() in case of downstream failures. If the instance fails, the rollback handlers will execute in reverse step-start order.

    This is useful for multi-step operations that touch external systems, such as inventory reservations, payment authorization, ticket creation, or infrastructure provisioning. Instead of writing all cleanup logic in a top-level catch, you can keep each compensating action next to the step it undoes.

    Rollback handlers support their own retry and timeout configuration, and Workflows now exposes rollback outcomes in instance status responses. Workflows analytics also emits rollback lifecycle events, making it easier to distinguish a forward execution failure from a rollback failure when debugging production workflows.

    JavaScript
    await step.do(
      "provision resource",
      async () => {
        const resource = await provisionResource();
        return { resourceId: resource.id };
      },
      {
        rollback: async ({ output }) => {
          const { resourceId } = output;
          await deleteResource(resourceId);
        },
        rollbackConfig: {
          retries: { limit: 3, delay: "15 seconds", backoff: "linear" },
          timeout: "2 minutes",
        },
      },
    );

    Refer to rollback options to learn more.

  1. Control AI costs with spend limits

    AI Gateway

    AI Gateway now supports spend limits — cost-based budgets that track cumulative dollar spend and block requests when the budget is exceeded. Unlike rate limiting, which caps the number of requests, spend limits track actual cost based on token usage and model pricing.

    You can scope limits by model, provider, or custom metadata dimensions. For example, give each user a $200/day budget, cap total gateway spend at $10,000/day, or limit a specific model to $50/day per user. Each rule uses a configurable time window with fixed or sliding enforcement.

    Spend limits work with both Unified Billing and BYOK requests for models with known pricing.

    For more details, refer to the Spend limits documentation.

  1. Filter Workers' public Internet traffic using Gateway policies

    Gateway Cloudflare Mesh Workers VPC

    Workers using a VPC Network binding with network_id: "cf1:network" now egress to public Internet destinations through Cloudflare Gateway. This means your existing Zero Trust traffic policies — DNS, HTTP, Network, and egress — extend to traffic that originates from your Workers, the same way they do for WARP users today.

    1. Worker

      Calls env.EGRESS.fetch()

    2. VPC binding
    3. Cloudflare Mesh

      Bind via cf1:network

    4. Cloudflare Gateway

      Policies applied:

      DNS HTTP Network
    5. Public Internet

      Any public hostname or IP

    Gateway logs DNS HTTP Network

    What you get by default:

    • Visibility. Worker egress shows up in Gateway DNS, HTTP, and Network logs alongside your other traffic, so you can audit what your Workers are calling and when.
    • Enforcement. Any existing Gateway policy whose selectors match a Worker request will apply — including allow / block lists, DNS category filtering, and HTTP destination rules. If you have already blocked a category for your workforce, your Workers inherit that block.
    JSONC
    {
      "vpc_networks": [
        {
          "binding": "EGRESS",
          "network_id": "cf1:network",
          "remote": true,
        },
      ],
    }
    JavaScript
    // Egress to a public destination — subject to your Gateway policies and logged
    const response = await env.EGRESS.fetch("https://api.example.com/data");

    For configuration options, refer to VPC Networks. For policy authoring, refer to Cloudflare Gateway traffic policies.

  1. Billable usage and budget alerts now in product sidebars

    Cloudflare Fundamentals Workers D1 R2 KV Queues Vectorize Durable Objects Containers

    Pay-as-you-go customers can now view billable usage and create budget alerts directly from the product overview pages for Workers & Pages, D1, R2, Workers KV, Queues, Vectorize, Durable Objects, and Containers. A new sidebar widget shows current-period spend and the billing cycle date range, alongside a button to create a budget alert.

    The widget pulls from the same data as the Billable Usage dashboard and aligns to your billing cycle (or the current day on Free plans), so the numbers match your invoice. Enterprise contract accounts are not yet supported.

    Billable usage widget in the Durable Objects product sidebar showing current-period spend and a breakdown by service

    Selecting Create budget alert opens the budget alert flow inline so you can set a dollar threshold in the same place you are reviewing usage. Budget alerts apply to your total account-level spend across all products, not just the product page you create them from.

    For more information, refer to the Usage-based billing documentation.

  1. Pipeline binding configuration field renamed to stream

    Pipelines Workers

    The pipeline field inside the pipelines binding configuration in your Wrangler configuration file has been renamed to stream. The old field is deprecated but still accepted.

    Update your configuration to use stream to avoid the deprecation warning.

    Before (deprecated):

    JSONC
    {
      "$schema": "./node_modules/wrangler/config-schema.json",
      "pipelines": [
        {
          "binding": "MY_PIPELINE",
          "pipeline": "<STREAM_ID>"
        }
      ]
    }

    After:

    JSONC
    {
      "$schema": "./node_modules/wrangler/config-schema.json",
      "pipelines": [
        {
          "binding": "MY_PIPELINE",
          "stream": "<STREAM_ID>"
        }
      ]
    }

    No other changes are required. The binding name, TypeScript types, and runtime API (env.MY_PIPELINE.send(...)) remain the same.

    For more information on configuring pipeline bindings, refer to Writing to streams.

  1. New Workers bulk secrets API endpoint

    Workers

    You can now create, update, or delete multiple secrets for your Worker in a single request using the bulk secrets endpoint.

    • Include a secret with a value to create or update.
    • Set a secret to null to delete.
    • Secrets not included in the request are left unchanged.

    The following example creates API_KEY, updates the already existing DB_PASSWORD, and deletes OLD_SECRET:

    {
      "secrets": {
        "API_KEY": { "type": "secret_text", "name": "API_KEY", "text": "my-api-key" },
        "DB_PASSWORD": { "type": "secret_text", "name": "DB_PASSWORD", "text": "my-db-password" },
        "OLD_SECRET": null
      }
    }

    You can do the same from the command line using wrangler secret bulk:

    Terminal window
    npx wrangler secret bulk < secrets.json

    To delete a key, set its value to null in the JSON file. Deletion is not supported with .env files.

    Each request supports up to 100 total operations (creates, updates, and deletes combined).

  1. Store Wrangler's OAuth credentials in your OS keychain

    Workers

    Wrangler can now store the OAuth credentials returned by wrangler login in an AES-256-GCM ↗-encrypted file, with the encryption key held in your operating system keychain. The default behavior is unchanged — credentials still live in a plaintext TOML file unless you opt in.

    To opt in, run:

    Terminal window
    npx wrangler login --use-keyring

    The choice is persisted across Wrangler invocations. Opt back out with npx wrangler login --no-use-keyring, or override the preference for a single command with the CLOUDFLARE_AUTH_USE_KEYRING environment variable.

    wrangler whoami now reports where credentials are stored:

    🔐 Credentials are stored in: Encrypted file (~/.config/.wrangler/config/default.enc) with key in macOS Keychain (service=wrangler, account=default)

    Per-platform backends:

    • macOS uses the built-in Keychain via /usr/bin/security.
    • Linux uses libsecret ↗ via the secret-tool CLI from the libsecret-tools package.
    • Windows uses Credential Manager via @napi-rs/keyring ↗, installed on-demand the first time you opt in.

    Refer to Storing OAuth credentials in the OS keychain for the full details, including the migration behavior on opt-in/opt-out and the CLOUDFLARE_AUTH_USE_KEYRING environment variable.

  1. Schedule Workflow instances directly from your Workflow binding

    Workflows Workers

    You can now attach cron schedules directly to a Workflow binding in wrangler.jsonc. Each scheduled run creates a new Workflow instance automatically, so you do not need to define a separate Worker with a scheduled handler just to trigger your Workflow on an interval.

    For example, you can configure hourly, every-15-minute, or weekday schedules on the same Workflow:

    JSONC
    {
      "workflows": [
        {
          "name": "my-scheduled-workflow",
          "binding": "MY_WORKFLOW",
          "class_name": "MyScheduledWorkflow",
          "schedules": ["0 * * * *", "*/15 * * * *", "0 9 * * MON-FRI"],
        },
      ],
    }

    Cron workloads get all the same benefits of Workflows with built-in retries, multi-step durable execution, and configurable timeouts of Workflows.

    TypeScript
    import {
      WorkflowEntrypoint,
      WorkflowEvent,
      WorkflowStep,
    } from "cloudflare:workers";
    

    // Runs automatically on each cron schedule defined for the MY_WORKFLOW binding in wrangler.jsonc.
    export class MyScheduledWorkflow extends WorkflowEntrypoint<Env> {
      async run(event: WorkflowEvent, step: WorkflowStep) {
        const data = await step.do("fetch source data", async () => {
          return await fetchSourceData();
        });
    

        // If this step fails, only this step is retried with the custom logic below
        await step.do(
          "process and store results",
          {
            retries: { limit: 5, delay: "30 seconds", backoff: "exponential" },
            timeout: "10 minutes",
          },
          async () => {
            await processAndStore(data);
          },
        );
      }
    }

    This makes it easier to build recurring, scheduled jobs such as database backups, invoice generation, report aggregation, and cleanup tasks without wiring up a separate Cron Trigger entrypoint.

    For more information, refer to Trigger Workflows.

  1. Agents SDK v0.14.0: Agent Skills, messengers, scheduled tasks, Workflows, and hardened chat recovery

    Agents Workers

    The latest release of the Agents SDK ↗ adds four new ways to build with @cloudflare/think: on-demand Agent Skills, chat messengers (starting with Telegram), declarative scheduled tasks, and durable reasoning steps inside Workflows. This release also significantly hardens durable chat recovery, so turns reliably ride through deploys, evictions, and stalled model streams in production.

    Agent Skills (experimental)

    Give an agent a catalog of on-demand instructions, resources, and scripts. A skill source adds a catalog to the system prompt, and the model activates a skill only when a task matches — so a large library of capabilities does not bloat every prompt.

    JavaScript
    import { Think, skills } from "@cloudflare/think";
    import bundledSkills from "agents:skills";
    

    export class SkillsAgent extends Think {
      getSkills() {
        return [
          bundledSkills,
          skills.r2(this.env.SKILLS_BUCKET, { prefix: "skills/" }),
        ];
      }
    }

    The agents:skills import bundles a local ./skills directory through the Agents Vite plugin (one directory per skill, each with a SKILL.md). Skills can also load from R2 or a manifest. When skills are available, Think exposes activate_skill, read_skill_resource, and an optional run_skill_script tool. Skill loading is resilient: a duplicate or failing source is skipped with a warning instead of breaking the agent.

    Agent Skills are experimental, and script execution in particular is early. The API may change in a future release. We would love your feedback — tell us what you are building and what is missing in the Agents repository ↗.

    Messengers

    Connect a Think agent directly to a chat platform. Think owns the webhook route, conversation routing, durable reply fiber, and streamed delivery back to the provider. Telegram ships as the first provider.

    JavaScript
    import { Think } from "@cloudflare/think";
    import {
      defineMessengers,
      ThinkMessengerStateAgent,
    } from "@cloudflare/think/messengers";
    import telegramMessenger from "@cloudflare/think/messengers/telegram";
    

    export { ThinkMessengerStateAgent };
    

    export class SupportAgent extends Think {
      getMessengers() {
        return defineMessengers({
          telegram: telegramMessenger({
            token: this.env.TELEGRAM_BOT_TOKEN,
            userName: "support_bot",
            secretToken: this.env.TELEGRAM_WEBHOOK_SECRET_TOKEN,
          }),
        });
      }
    }

    Each Chat SDK thread maps to its own Think sub-agent by default, so group chats and direct messages do not share memory. Multiple bots, custom conversation routing, and custom providers are all supported.

    Scheduled tasks

    Declare recurring, timezone-aware prompts and handlers with a typed domain-specific language (DSL). Think reconciles the declarations on startup and re-arms the next occurrence after each run, backed by durable idempotent submissions.

    JavaScript
    import { Think, defineScheduledTasks } from "@cloudflare/think";
    

    export class DigestAgent extends Think {
      getScheduledTasks() {
        return defineScheduledTasks({
          weeklyCommitReport: {
            schedule: "every week on monday at 09:00",
            prompt:
              "Compile my GitHub commits for the last week and summarize them.",
          },
          workout: {
            schedule: "every day at 08:00 in Europe/London",
            prompt: "Start my workout.",
          },
        });
      }
    }

    Think Workflows

    Run a model-driven reasoning step inside a Cloudflare Workflow with ThinkWorkflow and step.prompt(), with durable typed structured output, long waits, and approval gates.

    JavaScript
    import { z } from "zod";
    import { ThinkWorkflow } from "@cloudflare/think/workflows";
    

    const draftSchema = z.object({
      title: z.string(),
      summary: z.string(),
      labels: z.array(z.string()),
    });
    

    export class TriageWorkflow extends ThinkWorkflow {
      async run(event, step) {
        const draft = await step.prompt("triage-issue", {
          prompt: `Triage issue #${event.payload.issueNumber}`,
          output: draftSchema,
          timeout: "3 days",
        });
    

        await step.do("apply-labels", async () => {
          await this.agent.applyLabels(draft.labels);
        });
      }
    }

    Production hardening for durable chat recovery

    Durable chat turns have always been designed to survive a mid-turn deploy or Durable Object eviction. This release is a major hardening pass on that machinery for production.

    • Better recovery during deploys. Turns now ride through continuous deploys and evictions without losing completed work or re-running tools that already ran.
    • A live "recovering…" signal. useAgentChat exposes a new isRecovering flag, so a recovering turn shows progress instead of looking frozen. Most UIs render isStreaming || isRecovering as "busy".
    • Stalled streams recover. Set chatStreamStallTimeoutMs to route a hung provider stream into the same recovery path instead of leaving an infinite spinner.
    • Sub-agents re-attach. On parent recovery, an in-flight agentTool() child is re-attached to its result rather than abandoned and re-run, so long-running children no longer lose work under deploys.

    MCP transport improvements

    • Resumable streams — In-flight tool calls over Server-Sent Events (SSE) survive a dropped connection. Clients reconnect with Last-Event-ID and replay anything they missed.
    • Readable server IDs — addMcpServer accepts an optional id, so tools surface as readable keys (for example tool_github_create_pull_request) instead of opaque connection IDs.
    • Better handling of concurrent requests — Overlapping JSON-RPC requests are now correctly correlated to their responses across the HTTP and RPC transports.

    Other improvements

    • Compaction — A Session's tokenCounter now also drives the compaction boundary decision ("what to compress"), not just the fire/no-fire trigger.
    • @cloudflare/worker-bundler — Adds a virtualModules option to createWorker to provide in-memory module source during bundling.
    • Client-tool continuations — Parallel tool results now coalesce into a single continuation, immediate resume requests attach to the pending continuation, and server-side needsApproval continuations resume reliably after approval.

    Upgrade

    To update to the latest version:

    npm i agents@latest @cloudflare/think@latest @cloudflare/ai-chat@latest

    Refer to the Agents API reference and Chat agents documentation for more information.

  1. Share sandbox previews through Cloudflare Tunnel

    Agents

    Sandboxes can expose a service running inside the container on a public preview URL through the sandbox.tunnels namespace. The SDK uses cloudflared inside the sandbox so you can share a running service without configuring exposePort() or a custom domain.

    By default, sandbox.tunnels.get(port) creates a quick tunnel ↗ on a zero-config *.trycloudflare.com URL — no Cloudflare account, DNS record, or custom domain required. This is perfect for quick development and for .workers.dev deployments.

    JavaScript
    import { getSandbox } from "@cloudflare/sandbox";
    

    const sandbox = getSandbox(env.Sandbox, "my-sandbox");
    await sandbox.startProcess("python -m http.server 8080");
    

    const tunnel = await sandbox.tunnels.get(8080);
    console.log(tunnel.url); // → https://random-words-here.trycloudflare.com

    Named tunnels

    For more control you can create a named tunnel through sandbox.tunnels.get(port, { name }). A named tunnel binds a hostname (<name>.<your-zone>) backed by a Cloudflare Tunnel and a CNAME record on your zone resulting in something like https://my-app-preview.example.com ↗.

    Unlike quick tunnels, which generate a new random URL each time, a named tunnel produces a persistent URL that survives container restarts. This makes named tunnels suitable for production use cases where you want control over the tunnel and it's origin.

    JavaScript
    const tunnel = await sandbox.tunnels.get(8080, { name: "my-app-preview" });
    console.log(tunnel.url); // → https://my-app-preview.example.com

    Calling sandbox.destroy() tears down the Cloudflare Tunnel and the associated DNS record alongside the container, so you do not leave dangling tunnels or records behind.

    Upgrade

    To update to the latest version:

    npm i @cloudflare/sandbox@latest

    For full API details, refer to the Sandbox tunnels reference.

  1. D1 migrations support nested layouts via `migrations_pattern`

    D1

    You can now point wrangler d1 migrations apply at a nested migrations layout — such as the one produced by Drizzle ↗ (migrations/0001_init/migration.sql) — using the new migrations_pattern D1 binding config:

    JSONC
    {
      "d1_databases": [
        {
          "binding": "DB",
          "database_name": "my-database",
          "database_id": "<UUID>",
          "migrations_dir": "migrations",
          "migrations_pattern": "migrations/*/migration.sql",
        },
      ],
    }

    migrations_pattern is a glob (relative to your Wrangler config file) used to discover migration files. It defaults to ${migrations_dir}/*.sql, so existing projects keep working unchanged. Each migration's name is recorded in the migrations table as a path relative to migrations_dir.

    To learn more, visit D1's migrations documentation.

  1. Cloudflare's Realtime WebSocket adapter now auto-reconnects and buffers WebRTC media

    Realtime

    Cloudflare Realtime SFU is a WebRTC Selective Forwarding Unit that runs on Cloudflare's global network, so you can route live audio, video, and data between WebRTC clients around the world without managing SFU infrastructure or regions.

    When you use the WebSocket adapter to stream WebRTC media to a WebSocket endpoint, the adapter now auto-reconnects and buffers audio and video after brief endpoint disconnects or restarts.

    Streaming WebRTC media to WebSocket endpoints

    Many teams also use Realtime SFU as the media layer for backend applications, such as transcription, recording, note-taking, and agentic media-processing services. These systems often need to consume live WebRTC audio or video from the SFU in backend infrastructure, including Durable Objects, Workers, Containers, or external services, without running a WebRTC client themselves.

    The WebSocket adapter bridges that gap by streaming WebRTC media from the SFU to a standard WebSocket endpoint as application-consumable payloads: PCM audio frames and JPEG video frames.

    What changed

    When you use the WebSocket adapter in Stream mode (egress) to send live audio or video from the SFU to your own WebSocket endpoint, the SFU now automatically reconnects after brief endpoint disconnects or restarts. This is especially helpful for long-running media pipelines where the WebSocket endpoint may briefly restart while a recording, transcription, or live analysis job is still in progress.

    Previously, a brief disconnect from your WebSocket endpoint could close the adapter and require your application to recreate it before media could resume. Now, the SFU retries the same endpoint for up to 5 seconds with no API change required. If the endpoint comes back within that window, audio and video delivery resumes automatically.

    The reconnect behavior also includes live-first media buffering, so brief interruptions reduce media loss without replaying stale video.

    Reconnect behavior

    During reconnect:

    • Audio uses a short bounded backlog to reduce audible loss. If the interruption lasts longer than the backlog can cover, older audio may be dropped.
    • Video resumes from the latest available JPEG frame instead of replaying stale frames.
    • Recovery is best effort and does not guarantee gapless or exactly-once delivery.

    If the endpoint remains unavailable after the 5-second reconnect window, the adapter closes and must be recreated.

    Learn more

  1. Use Browser Run Quick Actions directly from Workers

    Browser Run

    You can now call Browser Run Quick Actions directly from a Cloudflare Worker using the quickAction() method on the browser binding. This simplifies how Workers interact with Browser Run by removing the need for API tokens or external HTTP requests. Your Worker communicates with Browser Run directly over Cloudflare's network, resulting in simpler code and lower latency.

    With the quickAction() method you can:

    To get started, add a browser binding to your Wrangler configuration:

    JSONC
    {
      "compatibility_date": "2026-03-24",
      "browser": {
        "binding": "BROWSER"
      }
    }

    Then call any Quick Action directly from your Worker. For example, to capture a screenshot:

    JavaScript
    const screenshot = await env.BROWSER.quickAction("screenshot", {
      url: "https://www.cloudflare.com/",
    });

    The quickAction() method requires a compatibility date of 2026-03-24 or later.

    For setup instructions and the full list of available actions, refer to Browser Run Quick Actions.

  1. Wrangler supports SSH ProxyCommand for Containers

    Containers

    Wrangler supports using wrangler containers ssh as an OpenSSH ProxyCommand for Containers. This lets your local SSH client connect to a running Container through Wrangler.

    Terminal window
    ssh -o ProxyCommand="wrangler containers ssh %h" cloudchamber@<INSTANCE_ID>

    When standard input and output are piped, Wrangler forwards data to the SSH server in the Container. You can also pass --stdio to force this mode.

    For more information, refer to the SSH documentation.

  1. Send emails with named recipient addresses

    Email Service

    You can now send emails with display names on recipient addresses in addition to the existing from support. Pass an object with email and an optional name field for to, cc, bcc, replyTo, or from:

    src/index.js
    export default {
      async fetch(request, env) {
        const response = await env.EMAIL.send({
          from: { email: "support@example.com", name: "Support Team" },
          to: { email: "jane@example.com", name: "Jane Doe" },
          cc: [
            "manager@company.com",
            { email: "team@company.com", name: "Engineering Team" },
          ],
          subject: "Welcome!",
          html: "<h1>Thanks for joining!</h1>",
          text: "Thanks for joining!",
        });
    

        return Response.json({ messageId: response.messageId });
      },
    };

    Plain strings remain fully supported for backward compatibility, and you can mix strings and named objects in the same array.

    Refer to the Workers API and REST API documentation for full request examples.

  1. Pipelines pricing announced

    Pipelines

    Cloudflare Pipelines is a streaming data platform that ingests events, transforms them with SQL, and writes to R2 as JSON, Parquet, or Apache Iceberg ↗ tables. Pipelines now has published pricing based on two usage dimensions: the volume of data processed by SQL transforms and the volume of data delivered to sinks. Ingress into a Pipeline stream is free.

    Billing is not yet enabled. We will provide at least 30 days notice before we start charging for Pipelines usage.

    Pipelines pricing model is designed to charge per GB based on what you use:

    • Streams (ingress): Free, regardless of volume.
    • SQL transforms: $0.04 / GB for stateless transforms (filter, reshape, unnest, cast, compute).
    • Sinks: $0.03 / GB for JSON, $0.06 / GB for Parquet or Iceberg output.

    Workers Free plans include 1 GB / month for each dimension. Workers Paid plans include 50 GB / month.

    For full pricing details and billing examples, refer to Pipelines pricing.

  1. R2 SQL pricing announced

    R2 SQL

    R2 SQL is a serverless, distributed query engine that runs SQL against Apache Iceberg ↗ tables stored in R2 Data Catalog. R2 SQL now has published pricing based on a single dimension: the volume of compressed data scanned to execute your queries. At $2.50 / TB ($0.0025 / GB), R2 SQL is priced at half the cost of AWS Athena and less than half of Google BigQuery on-demand.

    Billing is not yet enabled. We will provide at least 30 days notice before we start charging for R2 SQL usage.

    Data scanned is measured on compressed bytes read from R2 object storage. This matches what you see in your R2 bucket — if a Parquet file is 100 MB on disk, scanning that file bills for 100 MB. Each query has a minimum billing increment of 10 MB.

    Free plans include 1 GB / month and Paid plans include 10 GB / month. Standard R2 storage and operations and R2 Data Catalog charges apply separately.

    For full pricing details and billing examples, refer to R2 SQL pricing.

  1. R2 Data Catalog pricing announced

    R2

    R2 Data Catalog is a managed Apache Iceberg ↗ data catalog built directly into R2 buckets, queryable by any Iceberg-compatible engine such as Spark, Snowflake, and DuckDB. R2 Data Catalog now has published pricing for catalog operations and table compaction, in addition to standard R2 storage and operations.

    Billing is not yet enabled. We will provide at least 30 days notice before we start charging for R2 Data Catalog usage.

    Pricing is based on two dimensions:

    • Catalog operations: $9.00 / million operations for metadata requests such as creating tables, reading table metadata, and updating table properties.
    • Compaction: $0.005 / GB processed and $2.00 / million objects processed. These charges only apply when automatic compaction is turned on for a table.

    Both dimensions include a monthly free tier: 1 million catalog operations, 10 GB of compaction data processed, and 1 million compaction objects processed.

    For full pricing details and billing examples, refer to R2 Data Catalog pricing.

  1. R2 Data Catalog gets a dedicated dashboard experience

    R2

    R2 Data Catalog is a managed Apache Iceberg ↗ data catalog built directly into your R2 bucket. It exposes a standard Iceberg REST catalog interface so you can connect query engines like Spark, Snowflake, DuckDB, and R2 SQL to your data in R2.

    R2 Data Catalog now has a dedicated section in the Cloudflare dashboard, replacing the previous settings panel embedded in R2 bucket configuration. The new experience includes:

    R2 Data Catalog dashboard overview
    • Catalog overview — View all your catalogs in one place with catalog request counts, bucket sizes, and table maintenance status at a glance.
    • Guided setup wizard — Create a catalog in three steps: choose or create an R2 bucket, configure table maintenance (compaction and snapshot expiration), and review. The wizard creates the bucket and generates a service credential automatically.
    • Settings management — A dedicated settings page for each catalog with sections for general configuration, table maintenance, service credentials, and disabling the catalog. You can now enable and configure snapshot expiration directly from the dashboard.
    • Built-in metrics — Five charts on each catalog's metrics tab: bytes compacted, files compacted, catalog requests, storage size, and snapshots expired.

    To get started, go to R2 Data Catalog in the Cloudflare dashboard or refer to the getting started guide and manage catalogs documentation.

  1. Record specific participant audio tracks in RealtimeKit

    Realtime

    You can now record specific participant audio tracks in RealtimeKit with track recording. Track recording creates separate WebM files for each participant instead of a single composite recording, which is useful for post-processing, transcription, and regulated or content-sensitive workflows.

    To record specific participants, pass user_ids when starting a track recording:

    Terminal window
    curl --request POST \
      --url https://api.cloudflare.com/client/v4/accounts/<account_id>/realtime/kit/<app_id>/recordings/track \
      --header 'Authorization: Bearer <api_token>' \
      --header 'Content-Type: application/json' \
      --data '{
      "meeting_id": "97440c6a-140b-40a9-9499-b23fd7a3868a",
      "user_ids": ["user-123", "user-456"]
    }'

    To pass user_ids for selective track recording, use the following minimum SDK versions:

    • Web Core: @cloudflare/realtimekit version 1.4.0 or later
    • Web UI Kit: @cloudflare/realtimekit-ui, @cloudflare/realtimekit-react-ui, or @cloudflare/realtimekit-angular-ui version 1.1.2 or later
    • Android Core or iOS Core: version 2.0.0 or later
    • Android UI Kit or iOS UI Kit: version 1.1.0 or later

    RealtimeKit provides SDKs and UI components so that you can build your own meeting experience on Cloudflare's global WebRTC infrastructure. Teams today build products ranging from telehealth to education on RealtimeKit for global audiences. You can get started today with our Quickstart or take a look at our Cloudflare Meet repo ↗ as a reference.

  1. Transformation flows in Images

    Cloudflare Images
    Custom flow configuration panel

    Flows are automated rules that pair conditions (such as file extension, URL path, or query parameter) with parameters. Set up a flow to automatically apply image optimization to matching requests on your zone without writing code or changing URLs.

    There are two modes for transformation flows:

    • Provider flows — Migrate from another image optimization service. Your existing URLs continue to work while Cloudflare rewrites provider-specific parameters to their Cloudflare equivalents. Currently, Cloudflare supports provider flows for Fastly Image Optimizer.
    • Custom flows — Define your own conditions and actions for use cases like automatic format conversion, responsive sizing with width=auto, or directory-based optimization.

    To get started, go to Images > Transformations > Automation in the Cloudflare dashboard ↗.

    Learn more about transformation flows.

  1. Cloudflare Tunnel now runs connectivity pre-checks at startup

    Cloudflare Tunnel Cloudflare Tunnel for SASE

    Starting with cloudflared version 2026.5.2 ↗, Cloudflare Tunnel automates the entire connectivity pre-checks workflow directly inside the binary. Previously, customers had to install dig and netcat and run those commands by hand to verify their environment. Now cloudflared does it natively at startup — and surfaces actionable remediation when something is blocked.

    cloudflared connectivity pre-checks output

    On every cloudflared tunnel run (and cloudflared tunnel diag), the binary now natively checks:

    • DNS resolution — region1.v2.argotunnel.com and region2.v2.argotunnel.com resolve to valid Cloudflare IPs.
    • Transport connectivity — outbound UDP (QUIC) and TCP (HTTP/2) on port 7844.
    • Management API — outbound TCP/443 to api.cloudflare.com for software updates.

    Results are printed in a scannable CLI table with three states:

    • ✅ Pass — the check succeeded.
    • ⚠️ Warn — a non-blocking issue, for example the Management API is unreachable so automatic updates will not work, but the tunnel will still come up.
    • ❌ Fail — a blocking issue, with a specific remediation hint (for example, Allow outbound UDP on port 7844).

    If DNS is unresolvable, or both UDP and TCP fail on port 7844, cloudflared exits early with the failure rather than looping on opaque failed to dial errors.

    Pre-checks now run automatically on every start, which also catches regressions like overnight firewall policy changes — no need to remember to rerun the troubleshooting guide.

    To get the new behavior, upgrade cloudflared to version 2026.5.2 or later. For more details, refer to the Connectivity pre-checks documentation.

  1. Flagship now in public beta

    Flagship

    Flagship is now in public beta. Evaluate feature flags directly from Cloudflare Workers with no outbound HTTP calls, using globally distributed flag configuration backed by Workers KV and Durable Objects. Flagship supports typed flag values, targeting rules, percentage rollouts, audit history, and OpenFeature-compatible SDKs.

    Evaluate a flag from a Worker in a few lines of code:

    src/index.js
    export default {
      async fetch(request, env) {
        const showNewCheckout = await env.FLAGS.getBooleanValue(
          "new-checkout",
          false,
        );
    

        return new Response(showNewCheckout ? "New checkout" : "Standard checkout");
      },
    };

    Start creating flags from the Cloudflare dashboard today. Refer to the Flagship documentation to get started.