Skip to content
Docs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
Developer platform
hero image

  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. 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"]
        }
      ]
    }

    This makes it easier to build recurring 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. 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.

  1. Call any AI model through AI Gateway's new REST API

    AI Gateway

    AI Gateway now uses the AI REST API on api.cloudflare.com. You can call any model — whether from OpenAI, Anthropic, Google, or hosted on Workers AI — through one unified API, using the same endpoints and authentication regardless of provider. Four endpoints are available:

    • POST /ai/run — universal endpoint for all models and modalities
    • POST /ai/v1/chat/completions — OpenAI SDK compatible
    • POST /ai/v1/responses — OpenAI Responses API compatible
    • POST /ai/v1/messages — Anthropic SDK compatible
    Terminal window
    curl -X POST "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/v1/chat/completions" \
      --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
      --header "Content-Type: application/json" \
      --data '{
        "model": "openai/gpt-5.5",
        "messages": [{"role": "user", "content": "What is Cloudflare?"}]
      }'

    All AI Gateway features — logging, caching, rate limiting, and guardrails — are applied automatically. Third-party models are billed through Unified Billing, so you do not need to manage separate provider API keys.

    Third-party model requests are routed through your account's default gateway, which is created automatically on first use. To route requests through a specific gateway, add the cf-aig-gateway-id header.

    If you are already calling Workers AI models through the existing REST API, that path (/ai/run/@cf/{model}) continues to work. To call Workers AI models through AI Gateway, use the @cf/ model prefix (for example, @cf/moonshotai/kimi-k2.6) and include the cf-aig-gateway-id header to specify which gateway to route through.

    For more details and examples, refer to the REST API documentation.

  1. Granular permissions for Cloudflare Tunnel and Cloudflare Mesh

    Cloudflare Fundamentals Cloudflare One Cloudflare Tunnel for SASE Cloudflare Tunnel Cloudflare Mesh

    You can now scope Cloudflare permissions to individual Cloudflare Tunnel instances and Cloudflare Mesh nodes. Administrators can delegate access to specific Tunnels or Mesh nodes without granting account-wide control over private networking.

    What is new

    When you add a member or create a permission policy, the resource picker now lists Cloudflare Tunnel instances and Cloudflare Mesh nodes as scopable resource types. You can:

    • Grant a read-only role on a single Cloudflare Tunnel instance to a support operator for log streaming and diagnostics — without exposing other Tunnels or destructive actions.
    • Grant a write role on a specific Cloudflare Mesh node to an application team — without giving them access to the rest of your private network.
    • Scope a single policy to one or many Tunnels and Mesh nodes at once.

    How it works

    Granular permissions are a parallel layer to existing account-level roles — they do not replace them.

    • Existing account-level roles continue to work. A member with Cloudflare Access or Cloudflare Zero Trust retains write access to every Tunnel and Mesh node in the account. This ensures backward compatibility for existing automation and tokens.
    • Granular permissions are additive. For any API request on a specific Tunnel or Mesh node, access is granted if the principal has either the account-level role or a granular permission for that resource.
    • Resource enumeration is authorization-aware. Listing endpoints (GET /accounts/{id}/cfd_tunnel, GET /accounts/{id}/warp_connector) return only the resources the principal has at least read access to.

    Get started

  1. Reach Cloudflare WAN destinations from Workers VPC

    Workers VPC

    You can now use VPC Network bindings with network_id: "cf1:network" to reach your full private network from Workers, including:

    This means a single VPC Network binding can route Worker requests to private services regardless of how those services are connected to Cloudflare: through a Cloudflare Tunnel from a cloud VPC, a Mesh node on a private subnet, or a Cloudflare WAN on-ramp from your data center or branch site.

    JSONC
    {
      "vpc_networks": [
        {
          "binding": "PRIVATE_NETWORK",
          "network_id": "cf1:network",
          "remote": true,
        },
      ],
    }

    At runtime, the URL you pass to fetch() determines the destination:

    JavaScript
    // Reach a service behind a Cloudflare WAN IPsec on-ramp
    const response = await env.PRIVATE_NETWORK.fetch("http://10.50.0.100:8080/api");

    For configuration options, refer to VPC Networks.

  1. Event subscriptions for Artifacts lifecycle events

    Artifacts Queues

    You can now receive event notifications for Artifacts repository changes and consume them from a Worker to build commit-driven automation.

    This allows you to:

    • Run custom workflows when a repository is created or imported
    • Kick off a build and deploy a change when an agent pushes to a repo
    • Trigger a review agent on every push

    Available events include:

    • Account-level events (artifacts source) — repo.created, repo.deleted, repo.forked, repo.imported
    • Repository-level events (artifacts.repo source) — pushed, cloned, fetched

    To learn more, refer to Artifacts documentation.

  1. Manage Artifacts namespaces and repos with Wrangler CLI

    Artifacts

    You can now manage Artifacts namespaces, repos, and repo-scoped tokens directly from Wrangler CLI.

    Available commands:

    • wrangler artifacts namespaces list — List Artifacts namespaces in your account.
    • wrangler artifacts namespaces get — Get metadata for a namespace.
    • wrangler artifacts repos create — Create a repo in a namespace.
    • wrangler artifacts repos list — List repos in a namespace.
    • wrangler artifacts repos get — Get metadata for a repo.
    • wrangler artifacts repos delete — Delete a repo.
    • wrangler artifacts repos issue-token — Issue a repo-scoped token for Git access.

    To get started, refer to the Wrangler Artifacts commands documentation.

  1. Share local dev servers through Cloudflare Tunnel in Wrangler and Vite

    Workers

    You can now share local dev sessions through Cloudflare Tunnel and get a public URL when using either Wrangler or the Cloudflare Vite plugin. This is useful when you need to share a preview, test a webhook, or access your app from another device.

    Vite local dev tunnel demo

    This lets you either:

    To start a tunnel, press t in Wrangler or t + Enter in Vite while your dev server is running. For details on setting up a named tunnel, refer to Share a local dev server.

  1. Hyperdrive exposes database connection pool size metrics

    Hyperdrive Workers

    You can now view the size of your Hyperdrive database connection pools, giving you the ability to self-diagnose connection issues. Using the Cloudflare dashboard or the hyperdrivePoolSizesAdaptiveGroups dataset in the GraphQL Analytics API, you can see waitingClients, currentPoolSize, availablePoolSlots, and maxPoolSize for each of your configurations.

    A new Pool connections chart has been added to the Metrics tab of each Hyperdrive configuration in the Cloudflare dashboard ↗. You can use the location selector to drill down into specific locations hosting your connection pool by airport code.

    Hyperdrive pool size metrics chart

    The chart shows:

    • Waiting clients: Client requests waiting for an available connection.
    • Open connections: Active connections to your database.
    • Pool size maximum: Your configured origin connection limit.

    Connection contention appears as a spike in waiting clients, or when open connections consistently approach the pool size maximum. If your open connections regularly approach this limit, consider contacting Cloudflare to increase your Hyperdrive connection limit.

    Pool size metrics

    The hyperdrivePoolSizesAdaptiveGroups dataset in the GraphQL Analytics API exposes the following key connection pool metrics for each Hyperdrive configuration:

    Under avg:

    • currentPoolSize — Average number of connections currently open in the pool.
    • availablePoolSlots — Average number of pool connections available for checkout.
    • waitingClients — Average number of clients waiting for a connection from the pool.

    Under max:

    • maxPoolSize — Configured maximum size of the connection pool.
    • currentPoolSize — Peak number of connections open in the pool.
    • waitingClients — Peak number of clients waiting for a connection from the pool.

    For more information, refer to Metrics and analytics and Connection pooling.

  1. R2 SQL now supports JOINs, subqueries, and multi-table queries

    R2 SQL

    R2 SQL is Cloudflare's serverless, distributed SQL engine for querying Apache Iceberg ↗ tables stored in R2 Data Catalog. R2 SQL runs directly on Cloudflare's global network with no infrastructure to manage, so you can analyze data in R2 without exporting it to an external warehouse.

    R2 SQL now supports joining multiple Iceberg tables in a single query. You can combine tables with JOINs, filter with subqueries, and define multi-table CTEs to build complex analytical queries.

    New capabilities

    • JOINs — INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL OUTER JOIN, CROSS JOIN, and implicit joins (comma-separated FROM with conditions in WHERE)
    • Subqueries — IN / NOT IN, EXISTS / NOT EXISTS, scalar subqueries in SELECT / WHERE / HAVING, and derived tables (subqueries in FROM)
    • Multi-table CTEs — WITH clauses can reference different tables and include JOINs
    • Self-joins — join a table with itself using different aliases
    • Multi-way joins — join three or more tables in a single query

    Examples

    Two-table JOIN with aggregation

    SELECT z.domain, z.plan, COUNT(*) AS request_count
    FROM my_namespace.zones z
    INNER JOIN my_namespace.http_requests h ON z.zone_id = h.zone_id
    WHERE z.plan = 'enterprise'
    GROUP BY z.domain, z.plan
    ORDER BY request_count DESC
    LIMIT 20

    EXISTS subquery

    SELECT z.domain, z.plan
    FROM my_namespace.zones z
    WHERE EXISTS (
        SELECT 1 FROM my_namespace.firewall_events f
        WHERE f.zone_id = z.zone_id AND f.action = 'block'
    )
    ORDER BY z.domain
    LIMIT 20

    Multi-table CTE with JOIN

    WITH top_zones AS (
        SELECT zone_id, COUNT(*) AS req_count
        FROM my_namespace.http_requests
        GROUP BY zone_id
        ORDER BY req_count DESC
        LIMIT 50
    ),
    zone_threats AS (
        SELECT zone_id, COUNT(*) AS threat_count
        FROM my_namespace.firewall_events
        WHERE risk_score > 0.5
        GROUP BY zone_id
    )
    SELECT tz.zone_id, tz.req_count, COALESCE(zt.threat_count, 0) AS threat_count
    FROM top_zones tz
    LEFT JOIN zone_threats zt ON tz.zone_id = zt.zone_id
    ORDER BY tz.req_count DESC
    LIMIT 20

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

  1. New Domains tab in the Workers dashboard

    Workers

    In your Worker's dashboard, there is now a dedicated Domains tab where you can purchase a new domain through Cloudflare Registrar and have it automatically connected, add an existing domain, and manage all of your Worker's routing in one place.

    The new Domains tab in the Workers dashboard

    You can also enable or disable your workers.dev subdomain and Preview URLs, put them behind Cloudflare Access to require sign-in, and jump directly to analytics or domain overview for any connected domain.

    To get started, go to Workers & Pages, select a Worker, and open the Domains tab.

    Go to Workers & Pages