Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
Workers
hero image

  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. 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

  1. Agents SDK v0.12.4: chat recovery, routing retries, durable Think submissions, and Voice connection control

    Agents Workers

    The latest release of the Agents SDK ↗ brings more reliable chat recovery, fixes Agent state synchronization during reconnects, adds durable submissions for Think, exposes routing retry configuration, and adds connection control for Voice agents.

    Chat recovery improvements

    @cloudflare/ai-chat now keeps server turns running when a browser or client stream is interrupted. This is useful for long-running AI responses where users refresh the page, close a tab, or temporarily lose connection. Calling stop() still cancels the server turn.

    Set cancelOnClientAbort: true if browser or client aborts should also cancel the server turn:

    JavaScript
    const chat = useAgentChat({
      agent: "assistant",
      name: "user-123",
      cancelOnClientAbort: true,
    });

    Notable bug fixes:

    • Chat stream resume negotiation no longer throws when replay races with a closed WebSocket connection.
    • Recovered chat continuations no longer leave useAgentChat stuck in a streaming state when the original socket disconnects before a terminal response.
    • Approval auto-continuation preserves reasoning parts and persists continuation reasoning in the final message.
    • isServerStreaming now resets correctly when a resumed stream moves from the fallback observer path to a transport-owned stream.

    Agent state and routing fixes

    agents@0.12.4 prevents duplicate initial state frames during WebSocket connection setup. This avoids stale initial state messages overwriting state updates already sent by the client.

    Agent recovery is also more reliable when tool calls span a Durable Object restart. Recovery now defers user finish hooks until after agent startup and isolates hook failures, so one failed hook does not block other recovered runs from finalizing.

    getAgentByName() now supports routingRetry for transient Durable Object routing failures:

    JavaScript
    import { getAgentByName } from "agents";
    

    const agent = await getAgentByName(env.AssistantAgent, "user-123", {
      routingRetry: {
        maxAttempts: 3,
      },
    });

    Durable Think submissions

    @cloudflare/think now supports durable programmatic submissions. submitMessages() provides durable acceptance, idempotent retries, status inspection, cancellation, and cleanup for server-driven turns that should continue after the caller returns.

    Think.chat() RPC turns now run inside chat recovery fibers and persist their stream chunks. Interrupted sub-agent turns can recover partial output instead of starting over.

    ChatOptions.tools has been removed from the TypeScript API. Define durable tools on the child agent or use agent tools for orchestration. Runtime options.tools values passed by legacy callers are ignored with a warning.

    Think message pruning behavior change

    @cloudflare/think no longer applies pruneMessages({ toolCalls: "before-last-2-messages" }) to model context by default. The previous default could strip client-side tool results from longer multi-turn flows.

    truncateOlderMessages still runs as before, so context cost remains bounded. Subclasses that relied on the old aggressive pruning can opt back in from beforeTurn:

    JavaScript
    import { Think } from "@cloudflare/think";
    import { pruneMessages } from "ai";
    

    export class MyAgent extends Think {
      beforeTurn(ctx) {
        return {
          messages: pruneMessages({
            messages: ctx.messages,
            toolCalls: "before-last-2-messages",
          }),
        };
      }
    }

    Voice agent connection control

    @cloudflare/voice adds an enabled option to useVoiceAgent. React apps can now delay creating and connecting a VoiceClient until prerequisites such as capability tokens are ready.

    JavaScript
    const voice = useVoiceAgent({
      agent: "MyVoiceAgent",
      enabled: Boolean(token),
    });

    This release also fixes Workers AI speech-to-text session edge cases and withVoice text streaming from AI SDK textStream responses.

    Other improvements

    • Streamable HTTP routing — Server-to-client requests now route through the originating POST stream when no standalone SSE stream is available.
    • Structured tool output — Tool output shapes are preserved when truncating older messages or oversized persisted rows.
    • Non-chat Think tool steps — Think agent-tool children can complete without emitting assistant text and can return structured output through getAgentToolOutput.
    • Sub-agent schedules — Stale sub-agent schedule rows are pruned when their owning facet registry entry no longer exists.
    • @cloudflare/codemode — Adds a browser-safe export with an iframe sandbox executor and resolves OpenAPI specs inside the sandbox to avoid Worker Loader RPC size limits.

    Upgrade

    To update to the latest version:

    Terminal window
    npm i agents@latest @cloudflare/ai-chat@latest @cloudflare/think@latest @cloudflare/voice@latest

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

  1. WAF and framework adapter mitigations for React and Next.js vulnerabilities

    Workers WAF

    Multiple security vulnerabilities were disclosed by the React team and Vercel affecting React Server Components and Next.js. These include denial of service, middleware and proxy bypass, server-side request forgery, cross-site scripting, and cache poisoning issues across a range of severity levels.

    We strongly recommend updating your application and its dependencies immediately. Patched versions are available for React (react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack 19.0.6, 19.1.7, and 19.2.6) and Next.js (15.5.16 and 16.2.5).

    WAF protections

    Cloudflare WAF rules deployed in response to prior React Server Component CVEs (CVE-2025-55184 ↗ and CVE-2026-23864 ↗) already provide coverage for the newly disclosed denial-of-service vulnerabilities. These rules are enabled by default with a Block action for all customers using the Cloudflare Managed Ruleset, including Free plan customers using the Free Managed Ruleset.

    RulesetRule descriptionRule IDDefault action
    Cloudflare Managed RulesetReact - DoS - CVE-2025-55184 ↗2694f1610c0b471393b21aef102ec699Block
    Cloudflare Managed RulesetReact - DoS - CVE-2026-23864 ↗aaede80b4d414dc89c443cea61680354Block

    The existing rules detect the underlying attack patterns generically. As a result, they apply to the new CVE-2026-23870 ↗ denial-of-service vulnerability in Server Components and the corresponding Next.js advisory GHSA-8h8q-6873-q5fj ↗.

    Cloudflare is investigating whether WAF rules can be safely and effectively deployed for three of the high-severity advisories: CVE-2026-23870 ↗ / GHSA-8h8q-6873-q5fj ↗, GHSA-267c-6grr-h53f ↗, and GHSA-mg66-mrh9-m8jx ↗. If it is possible to create a managed WAF rule that mitigates these CVEs and does not potentially break application behavior, Cloudflare will add additional managed WAF rules. These rules will be announced through the WAF changelog. Because these vulnerabilities were shared with Cloudflare with minimal advance notice, we are still investigating what WAF mitigations are possible.

    Several of the disclosed vulnerabilities are not possible to block in WAF. We strongly recommend updating your applications so they are not purely reliant on WAF mitigations.

    Customers on Pro, Business, or Enterprise plans should ensure that Managed Rules are enabled.

    Next.js adapters

    Vinext: Vinext ↗ is a Vite plugin that reimplements the Next.js API surface. Vinext's latest release is not vulnerable to any of the disclosed CVEs. Vinext's architecture differs from stock Next.js in ways that sidestep the affected code paths. For example, it does not implement the PPR resume protocol, does not expose Pages Router data-route endpoints, and strips internal headers such as x-nextjs-data at request boundaries. As an extra layer of defense, we added a React 19.2.6 or later requirement when running vinext init (PR #1118 ↗, PR #1112 ↗) to prevent accidentally running a vulnerable version of React with Vinext.

    OpenNext on Cloudflare: OpenNext is an adapter that lets you deploy Next.js apps to the Cloudflare Workers platform. OpenNext itself is not directly vulnerable to the React denial-of-service CVE, but users must update the Next.js version in their application. The OpenNext team has updated the adapter to further harden against these vectors and released a new version of the Cloudflare adapter. Test fixtures and examples have been updated to use patched versions (PR #1255 ↗).

    Summary of disclosed vulnerabilities

    AdvisorySeverityIssueWAF status
    CVE-2026-23870 ↗ / GHSA-8h8q-6873-q5fj ↗HighDenial of service in Server ComponentsWAF rules in place: 2694f1610c0b471393b21aef102ec699, aaede80b4d414dc89c443cea61680354
    Cloudflare is investigating additional managed WAF coverage
    GHSA-267c-6grr-h53f ↗HighMiddleware bypass via segment-prefetch routesCloudflare is investigating if this can be safely and effectively mitigated by a managed WAF rule
    GHSA-mg66-mrh9-m8jx ↗HighDenial of service via connection exhaustion in Cache ComponentsCloudflare is investigating if this can be safely and effectively mitigated by a managed WAF rule
    GHSA-492v-c6pp-mqqv ↗HighMiddleware bypass via dynamic route parameter injectionNot possible to safely enable a managed WAF rule without potentially breaking application behavior
    GHSA-c4j6-fc7j-m34r ↗HighSSRF via WebSocket upgradesNot possible to safely enable a managed WAF rule without potentially breaking application behavior
    GHSA-36qx-fr4f-26g5 ↗HighMiddleware bypass in Pages Router i18nCustom WAF rule possible; global managed rule could potentially break application behavior
    GHSA-ffhc-5mcf-pf4q ↗ModerateXSS via CSP noncesCustom WAF rule possible; global managed rule could potentially break application behavior
    GHSA-gx5p-jg67-6x7h ↗ModerateXSS in beforeInteractive scriptsNot possible to safely enable a managed WAF rule without potentially breaking application behavior
    GHSA-h64f-5h5j-jqjh ↗ModerateDenial of service in Image Optimization APICustom WAF rule possible; global managed rule could potentially break application behavior
    GHSA-wfc6-r584-vfw7 ↗ModerateCache poisoning in RSC responsesCustom WAF rule possible; global managed rule could potentially break application behavior
    GHSA-vfv6-92ff-j949 ↗LowCache poisoning via RSC cache-busting collisionsNot possible to safely enable a managed WAF rule without potentially breaking application behavior
    GHSA-3g8h-86w9-wvmq ↗LowMiddleware redirect cache poisoningCustom WAF rule possible; global managed rule could potentially break application behavior

  1. Automatic tracing across Durable Object and Worker subrequests

    Workers

    You can now get a single unified trace across Worker-to-Worker subrequests, with trace context propagating automatically. Previously, automatic tracing produced disconnected traces when a Worker called another Worker through a service binding or Durable Object.

    Unified trace showing nested spans across a Durable Object subrequest and a service binding call

    This means you can:

    • Follow a request through your entire Worker architecture in one trace view
    • See service binding and Durable Object calls as nested child spans instead of separate traces
    • Debug cross-Worker request flows in the Cloudflare dashboard or in an external observability platform via OpenTelemetry

    Tracing must be enabled in your Wrangler configuration for traces to be recorded. Checkout Workers tracing to get started.

    Up next, we are working on external trace context propagation using W3C Trace Context standards ↗, which will allow traces from your Workers to link with traces from services outside of Cloudflare.

  1. Run Workflows inside Dynamic Workers with the @cloudflare/dynamic-workflows library

    Workflows Workers

    You can now use @cloudflare/dynamic-workflows ↗ to run a Workflow inside a Dynamic Worker, ensuring durable execution for code that is loaded at runtime.

    The Worker Loader loads Dynamic Workers on demand, which previously made durability challenging. Even within a Dynamic Worker, a Workflow might sleep for hours or days between steps, and by the time it resumes, the original Dynamic Worker code would no longer be in memory.

    The library solves this by tagging each Workflow instance with metadata that identifies which Dynamic Worker to load — for example, a tenant ID — then reloading the matching Dynamic Worker through the Worker Loader whenever a Workflow awakens.

    Because Dynamic Workers are created on-demand, you do not have to register each Workflow up front or manage them individually. Load the Workflow code in the Dynamic Worker when it is needed, and the Workflows engine handles persistence and retries behind the scenes. Your Workflow code itself is unaffected by the routing and behaves as normal.

    This unlocks patterns where the Workflow code itself is dynamic. For example, this is useful with:

    • SaaS platforms where each tenant defines their own automation, such as onboarding sequences, approval chains, or billing retry logic.
    • AI agent frameworks where agents generate and execute multi-step plans at runtime, surviving restarts and waiting for human approval between tool calls.
    • Multi-tenant job systems where each customer submits their own processing logic and every step persists progress and retries on failure.
    TypeScript
    import {
      createDynamicWorkflowEntrypoint,
      DynamicWorkflowBinding,
      wrapWorkflowBinding,
      type WorkflowRunner,
    } from "@cloudflare/dynamic-workflows";
    

    export { DynamicWorkflowBinding };
    

    interface Env {
      WORKFLOWS: Workflow;
      LOADER: WorkerLoader;
    }
    

    function loadTenant(env: Env, tenantId: string) {
      return env.LOADER.get(tenantId, async () => ({
        compatibilityDate: "2026-01-01",
        mainModule: "index.js",
        modules: { "index.js": await fetchTenantCode(tenantId) },
        // The Dynamic Worker uses this exactly like a real Workflow binding;
        // every create() is tagged with { tenantId } automatically.
        env: { WORKFLOWS: wrapWorkflowBinding({ tenantId }) },
      }));
    }
    

    // The entrypoint name must match `class_name` in the workflows binding of your Wrangler config file.
    export const DynamicWorkflow = createDynamicWorkflowEntrypoint<Env>(
      async ({ env, metadata }) => {
        const stub = loadTenant(env, metadata.tenantId as string);
        return stub.getEntrypoint("TenantWorkflow") as unknown as WorkflowRunner;
      },
    );
    

    export default {
      fetch(request: Request, env: Env) {
        const tenantId = request.headers.get("x-tenant-id")!;
        return loadTenant(env, tenantId).getEntrypoint().fetch(request);
      },
    };

    For a full walkthrough, refer to the Dynamic Workflows guide.

  1. Introducing Billable Usage dashboard and Budget alerts

    Cloudflare Fundamentals Workers

    Pay-as-you-go customers can now monitor usage-based costs and configure spend alerts through two new features: the Billable Usage dashboard and Budget alerts.

    Billable Usage dashboard

    The Billable Usage dashboard provides daily visibility into usage-based costs across your Cloudflare account. The data comes from the same system that generates your monthly invoice, so the figures match your bill.

    The dashboard displays:

    • A bar chart showing daily usage charges for your billing period
    • A sortable table breaking down usage by product, including total usage, billable usage, and cumulative costs
    • Ability to view previous billing periods

    Usage data aligns to your billing cycle, not the calendar month. The total usage cost shown at the end of a completed billing period matches the usage overage charges on your corresponding invoice.

    To access the dashboard, go to Manage Account > Billing > Billable Usage.

    Screenshot of the Billable Usage dashboard in the Cloudflare dashboard

    Budget alerts

    Budget alerts allow you to set dollar-based thresholds for your account-level usage spend. You receive an email notification when your projected monthly spend reaches your configured threshold, giving you proactive visibility into your bill before month-end.

    To configure a budget alert:

    1. Go to Manage Account > Billing > Billable Usage.
    2. Select Set Budget Alert.
    3. Enter a budget threshold amount greater than $0.
    4. Select Create.

    Alternatively, configure alerts via Notifications > Add > Budget Alert.

    Create Budget Alert modal in the Cloudflare dashboard

    You can create multiple budget alerts at different dollar amounts. The notifications system automatically deduplicates alerts if multiple thresholds trigger at the same time. Budget alerts are calculated daily based on your usage trends and fire once per billing cycle when your projected spend first crosses your threshold.

    Both features are available to Pay-as-you-go accounts with usage-based products (Workers, R2, Images, etc.). Enterprise contract accounts are not supported.

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

  1. WebSocket binary messages now delivered as Blob by default

    Workers

    Binary frames received on a WebSocket are now delivered to the message event as Blob ↗ objects by default. This matches the WebSocket specification ↗ and standard browser behavior. Previously, binary frames were always delivered as ArrayBuffer ↗. The binaryType property on WebSocket controls the delivery type on a per-WebSocket basis.

    This change has been active for Workers with compatibility dates on or after 2026-03-17, via the websocket_standard_binary_type compatibility flag. We should have documented this change when it shipped but didn't. We're sorry for the trouble that caused. If your Worker handles binary WebSocket messages and assumes event.data is an ArrayBuffer, the frames will arrive as Blob instead, and a naive instanceof ArrayBuffer check will silently drop every frame.

    To opt back into ArrayBuffer delivery, assign binaryType before calling accept(). This works regardless of the compatibility flag:

    JavaScript
    const resp = await fetch("https://example.com", {
      headers: { Upgrade: "websocket" },
    });
    const ws = resp.webSocket;
    

    // Opt back into ArrayBuffer delivery for this WebSocket.
    ws.binaryType = "arraybuffer";
    ws.accept();
    

    ws.addEventListener("message", (event) => {
      if (typeof event.data === "string") {
        // Text frame.
      } else {
        // event.data is an ArrayBuffer because we set binaryType above.
      }
    });

    If you are not ready to migrate and want to keep ArrayBuffer as the default for all WebSockets in your Worker, add the no_websocket_standard_binary_type flag to your Wrangler configuration file.

    This change has no effect on the Durable Object hibernatable WebSocket webSocketMessage handler, which continues to receive binary data as ArrayBuffer.

    For more information, refer to WebSockets binary messages.

  1. Increased concurrency, creation rate, and queued instance limits for Workflows instances

    Workflows Workers

    Workflows limits have been raised to the following:

    LimitPreviousNew
    Concurrent instances (running in parallel)10,00050,000
    Instance creation rate (per account)100/second per account300/second per account, 100/second per workflow
    Queued instances per Workflow 11 million2 million

    These increases apply to all users on the Workers Paid plan. Refer to the Workflows limits documentation for more details.

    Footnotes

    1. Queued instances are instances that have been created or awoken and are waiting for a concurrency slot. ↩

  1. Local Explorer for local resource data

    Workers

    Local Explorer is a browser-based interface and REST API for viewing and editing local resource data during development. It removes the need to write throwaway scripts or dig through .wrangler/state to understand what data your Worker has stored locally.

    Local Explorer is available in Wrangler 4.82.1+ and the Cloudflare Vite plugin 1.32.0+. Start a local development session and press e in your terminal, or navigate to /cdn-cgi/explorer on your local dev server.

    Supported resources

    Local Explorer supports five resource types and works across multiple workers running locally:

    • KV — Browse keys, view values and metadata, create, update, and delete key-value pairs.
    • R2 — List objects, view metadata, upload files, and delete objects. Supports directory views and multi-select.
    • D1 — Browse tables and rows, run arbitrary SQL queries, and edit schemas in a full data studio.
    • Durable Objects (SQLite storage) — Browse individual object SQLite tables, run SQL queries, and edit schemas.
    • Workflows — List instances, view status and step history, trigger new runs, and pause, resume, restart, or terminate instances.

    OpenAPI-powered REST API

    Local Explorer exposes a REST API at /cdn-cgi/explorer/api that provides programmatic access to the same operations available in the browser. The root endpoint returns an OpenAPI specification ↗ describing all available endpoints, parameters, and response formats.

    Terminal window
    curl http://localhost:8787/cdn-cgi/explorer/api

    Point an AI coding agent at /cdn-cgi/explorer/api and it can discover and interact with your local resources without manual setup. This enables iterative development loops where an agent can populate test data in KV or D1, inspect Durable Object state, trigger Workflow runs, or upload files to R2.

    For more details, refer to the Local Explorer documentation.

  1. Relaxed simultaneous connection limiting for Workers

    Workers

    The simultaneous open connections limit has been relaxed. Previously, each Worker invocation was limited to six open connections at a time for the entire lifetime of each connection, including while reading the response body. Now, a connection is freed as soon as response headers arrive, so the six-connection limit only constrains how many connections can be in the initial "waiting for headers" phase simultaneously.

    Before: New connections are blocked until an earlier connection fully completes

    A 7th fetch is queued until an earlier connection fully completes, including reading its entire response body

    After: New connections can start as soon as response headers arrive

    A 7th fetch starts as soon as any earlier connection receives its response headers

    This means Workers can now have many more connections open at the same time without queueing, as long as no more than six are waiting for their initial response. This eliminates the Response closed due to connection limit exception that could previously occur when the runtime canceled stalled connections to prevent deadlocks.

    Previously, the runtime used a deadlock avoidance algorithm that watched each open connection for I/O activity. If all six connections appeared idle — even momentarily — the runtime would cancel the least-recently-used connection to make room for new requests. In practice, this heuristic was fragile. For example, when a response used Content-Encoding: gzip, the runtime's internal decompression created brief gaps between read and write operations. During these gaps, the connection appeared stalled despite being actively read by the Worker. If multiple connections hit these gaps at the same time, the runtime could spuriously cancel a connection that was working correctly. By only counting connections during the waiting-for-headers phase — where the runtime is fully in control and there is no ambiguity about whether the connection is active — this class of bug is eliminated entirely.

    Before: Connections could be canceled during brief internal pauses

    A connection with gaps from gzip decompression appears idle and is canceled by the runtime

    After: Connections complete normally regardless of internal pauses

    The same connection completes normally because the body phase is no longer counted against the limit

  1. WebSockets now automatically reply to Close frames

    Workers

    The Workers runtime now automatically sends a reciprocal Close frame when it receives a Close frame from the peer. The readyState transitions to CLOSED before the close event fires. This matches the WebSocket specification ↗ and standard browser behavior.

    This change is enabled by default for Workers using compatibility dates on or after 2026-04-07 (via the web_socket_auto_reply_to_close compatibility flag). Existing code that manually calls close() inside the close event handler will continue to work — the call is silently ignored when the WebSocket is already closed.

    JavaScript
    const [client, server] = Object.values(new WebSocketPair());
    server.accept();
    

    server.addEventListener("close", (event) => {
      // readyState is already CLOSED — no need to call server.close().
      console.log(server.readyState); // WebSocket.CLOSED
      console.log(event.code); // 1000
      console.log(event.wasClean); // true
    });

    Half-open mode for WebSocket proxying

    The automatic close behavior can interfere with WebSocket proxying, where a Worker sits between a client and a backend and needs to coordinate the close on both sides independently. To support this use case, pass { allowHalfOpen: true } to accept():

    JavaScript
    const [client, server] = Object.values(new WebSocketPair());
    

    server.accept({ allowHalfOpen: true });
    

    server.addEventListener("close", (event) => {
      // readyState is still CLOSING here, giving you time
      // to coordinate the close on the other side.
      console.log(server.readyState); // WebSocket.CLOSING
    

      // Manually close when ready.
      server.close(event.code, "done");
    });

    For more information, refer to WebSockets Close behavior.

  1. All Wrangler commands for Workflows now support local development

    Workflows Workers

    All wrangler workflows commands now accept a --local flag to target a Workflow running in a local wrangler dev session instead of the production API.

    You can now manage the full Workflow lifecycle locally, including triggering Workflows, listing instances, pausing, resuming, restarting, terminating, and sending events:

    Terminal window
    npx wrangler workflows list --local
    npx wrangler workflows trigger my-workflow --local
    npx wrangler workflows instances list my-workflow --local
    npx wrangler workflows instances pause my-workflow <INSTANCE_ID> --local
    npx wrangler workflows instances send-event my-workflow <INSTANCE_ID> --type my-event --local

    All commands also accept --port to target a specific wrangler dev session (defaults to 8787).

    For more information, refer to Workflows local development.

  1. Deploy Hooks are now available for Workers Builds

    Workers

    Workers Builds now supports Deploy Hooks — trigger builds from your headless CMS, a Cron Trigger, a Slack bot, or any system that can send an HTTP request.

    Each Deploy Hook is a unique URL tied to a specific branch. Send it a POST and your Worker builds and deploys.

    Terminal window
    curl -X POST "https://api.cloudflare.com/client/v4/workers/builds/deploy_hooks/<DEPLOY_HOOK_ID>"

    To create one, go to Workers & Pages > your Worker > Settings > Builds > Deploy Hooks.

    Since a Deploy Hook is a URL, you can also call it from another Worker. For example, a Worker with a Cron Trigger can rebuild your project on a schedule:

    JavaScript
    export default {
      async scheduled(event, env, ctx) {
        ctx.waitUntil(fetch(env.DEPLOY_HOOK_URL, { method: "POST" }));
      },
    };

    You can also use Deploy Hooks to rebuild when your CMS publishes new content or deploy from a Slack slash command.

    Built-in optimizations

    • Automatic deduplication: If a Deploy Hook fires multiple times before the first build starts running, redundant builds are automatically skipped. This keeps your build queue clean when webhooks retry or CMS events arrive in bursts.
    • Last triggered: The dashboard shows when each hook was last triggered.
    • Build source: Your Worker's build history shows which Deploy Hook started each build by name.

    Deploy Hooks are rate limited to 10 builds per minute per Worker and 100 builds per minute per account. For all limits, see Limits & pricing.

    To get started, read the Deploy Hooks documentation.

  1. New L4 transport telemetry fields in Workers

    Workers

    Three new properties are now available on request.cf in Workers that expose Layer 4 transport telemetry from the client connection. These properties let your Worker make decisions based on real-time connection quality signals — such as round-trip time and data delivery rate — without requiring any client-side changes.

    Previously, this telemetry was only available via the Server-Timing: cfL4 response header. These new properties surface the same data directly in the Workers runtime, so you can use it for routing, logging, or response customization.

    New properties

    PropertyTypeDescription
    clientTcpRttnumber | undefinedThe smoothed TCP round-trip time (RTT) between Cloudflare and the client in milliseconds. Only present for TCP connections (HTTP/1, HTTP/2). For example, 22.
    clientQuicRttnumber | undefinedThe smoothed QUIC round-trip time (RTT) between Cloudflare and the client in milliseconds. Only present for QUIC connections (HTTP/3). For example, 42.
    edgeL4Object | undefinedLayer 4 transport statistics. Contains deliveryRate (number) — the most recent data delivery rate estimate for the connection, in bytes per second. For example, 123456.

    Example: Log connection quality metrics

    JavaScript
    export default {
      async fetch(request) {
        const cf = request.cf;
    

        const rtt = cf.clientTcpRtt ?? cf.clientQuicRtt ?? 0;
        const deliveryRate = cf.edgeL4?.deliveryRate ?? 0;
        const transport = cf.clientTcpRtt ? "TCP" : "QUIC";
    

        console.log(`Transport: ${transport}, RTT: ${rtt}ms, Delivery rate: ${deliveryRate} B/s`);
    

        const headers = new Headers(request.headers);
        headers.set("X-Client-RTT", String(rtt));
        headers.set("X-Delivery-Rate", String(deliveryRate));
    

        return fetch(new Request(request, { headers }));
      },
    };

    For more information, refer to Workers Runtime APIs: Request.

  1. New RFC 9440 mTLS certificate fields in Workers

    Workers

    Four new fields are now available on request.cf.tlsClientAuth in Workers for requests that include a mutual TLS (mTLS) client certificate. These fields encode the client certificate and its intermediate chain in RFC 9440 ↗ format — the same standard format used by the Client-Cert and Client-Cert-Chain HTTP headers — so your Worker can forward them directly to your origin without any custom parsing or encoding logic.

    New fields

    FieldTypeDescription
    certRFC9440StringThe client leaf certificate in RFC 9440 format (:base64-DER:). Empty if no client certificate was presented.
    certRFC9440TooLargeBooleantrue if the leaf certificate exceeded 10 KB and was omitted from certRFC9440.
    certChainRFC9440StringThe intermediate certificate chain in RFC 9440 format as a comma-separated list. Empty if no intermediates were sent or if the chain exceeded 16 KB.
    certChainRFC9440TooLargeBooleantrue if the intermediate chain exceeded 16 KB and was omitted from certChainRFC9440.

    Example: forwarding client certificate headers to your origin

    JavaScript
    export default {
      async fetch(request) {
        const tls = request.cf.tlsClientAuth;
    

        // Only forward if cert was verified and chain is complete
        if (!tls || !tls.certVerified || tls.certRevoked || tls.certChainRFC9440TooLarge) {
          return new Response("Unauthorized", { status: 401 });
        }
    

        const headers = new Headers(request.headers);
        headers.set("Client-Cert", tls.certRFC9440);
        headers.set("Client-Cert-Chain", tls.certChainRFC9440);
    

        return fetch(new Request(request, { headers }));
      },
    };

    For more information, refer to Client certificate variables and Mutual TLS authentication.

  1. Declare required secrets in your Wrangler configuration

    Workers

    The new secrets configuration property lets you declare the secret names your Worker requires in your Wrangler configuration file. Required secrets are validated during local development and deploy, and used as the source of truth for type generation.

    JSONC
    {
      "secrets": {
        "required": ["API_KEY", "DB_PASSWORD"],
      },
    }

    Local development

    When secrets is defined, wrangler dev and vite dev load only the keys listed in secrets.required from .dev.vars or .env/process.env. Additional keys in those files are excluded. If any required secrets are missing, a warning is logged listing the missing names.

    Type generation

    wrangler types generates typed bindings from secrets.required instead of inferring names from .dev.vars or .env. This lets you run type generation in CI or other environments where those files are not present. Per-environment secrets are supported — the aggregated Env type marks secrets that only appear in some environments as optional.

    Deploy

    wrangler deploy and wrangler versions upload validate that all secrets in secrets.required are configured on the Worker before the operation succeeds. If any required secrets are missing, the command fails with an error listing which secrets need to be set.

    For more information, refer to the secrets configuration property reference.

  1. Dynamic Workers, now in open beta

    Workers

    Dynamic Workers are now in open beta ↗ for all paid Workers users. You can now have a Worker spin up other Workers, called Dynamic Workers, at runtime to execute code on-demand in a secure, sandboxed environment. Dynamic Workers start in milliseconds, making them well suited for fast, secure code execution at scale.

    Use Dynamic Workers for

    • Code Mode: LLMs are trained to write code. Run tool-calling logic written in code instead of stepping through many tool calls, which can save up to 80% in inference tokens and cost.
    • AI agents executing code: Run code for tasks like data analysis, file transformation, API calls, and chained actions.
    • Running AI-generated code: Run generated code for prototypes, projects, and automations in a secure, isolated sandboxed environment.
    • Fast development and previews: Load prototypes, previews, and playgrounds in milliseconds.
    • Custom automations: Create custom tools on the fly that execute a task, call an integration, or automate a workflow.

    Executing Dynamic Workers

    Dynamic Workers support two loading modes:

    • load(code) — for one-time code execution (equivalent to calling get() with a null ID).
    • get(id, callback) — caches a Dynamic Worker by ID so it can stay warm across requests. Use this when the same code will receive subsequent requests.
    JavaScript
    export default {
      async fetch(request, env) {
        const worker = env.LOADER.load({
          compatibilityDate: "2026-01-01",
          mainModule: "src/index.js",
          modules: {
            "src/index.js": `
              export default {
                fetch() {
                  return new Response("Hello from a dynamic Worker");
                },
              };
            `,
          },
          // Block all outbound network access from the Dynamic Worker.
          globalOutbound: null,
        });
    

        return worker.getEntrypoint().fetch(request);
      },
    };

    Helper libraries for Dynamic Workers

    Here are 3 new libraries to help you build with Dynamic Workers:

    • @cloudflare/codemode ↗: Replace individual tool calls with a single code() tool, so LLMs write and execute TypeScript that orchestrates multiple API calls in one pass.

    • @cloudflare/worker-bundler ↗: Resolve npm dependencies and bundle source files into ready-to-load modules for Dynamic Workers, all at runtime.

    • @cloudflare/shell ↗: Give your agent a virtual filesystem inside a Dynamic Worker with persistent storage backed by SQLite and R2.

    Try it out

    Dynamic Workers Starter

    Deploy to Workers

    Use this starter ↗ to deploy a Worker that can load and execute Dynamic Workers.

    Dynamic Workers Playground

    Deploy to Workers

    Deploy the Dynamic Workers Playground ↗ to write or import code, bundle it at runtime with @cloudflare/worker-bundler, execute it through a Dynamic Worker, and see real-time responses and execution logs.

    For the full API reference and configuration options, refer to the Dynamic Workers documentation.

    Pricing

    Dynamic Workers pricing is based on three dimensions: Dynamic Workers created daily, requests, and CPU time.

    IncludedAdditional usage
    Dynamic Workers created daily1,000 unique Dynamic Workers per month+$0.002 per Dynamic Worker per day
    Requests ¹10 million per month+$0.30 per million requests
    CPU time ¹30 million CPU milliseconds per month+$0.02 per million CPU milliseconds

    ¹ Uses Workers Standard rates and will appear as part of your existing Workers bill, not as separate Dynamic Workers charges.

    Note: Dynamic Workers requests and CPU time are already billed as part of your Workers plan and will count toward your Workers requests and CPU usage. The Dynamic Workers created daily charge is not yet active — you will not be billed for the number of Dynamic Workers created at this time. Pricing information is shared in advance so you can estimate future costs.

  1. Workflow instances now support pause(), resume(), restart(), and terminate() methods in local development

    Workflows Workers

    Workflow instance methods pause(), resume(), restart(), and terminate() are now available in local development when using wrangler dev.

    You can now test the full Workflow instance lifecycle locally:

    TypeScript
    const instance = await env.MY_WORKFLOW.create({
      id: "my-instance-id",
    });
    

    await instance.pause(); // pauses a running workflow instance
    await instance.resume(); // resumes a paused instance
    await instance.restart(); // restarts the instance from the beginning
    await instance.terminate(); // terminates the instance immediately

  1. Agents SDK v0.8.0: readable state, idempotent schedules, typed AgentClient, and Zod 4

    Agents Workers

    The latest release of the Agents SDK ↗ exposes agent state as a readable property, prevents duplicate schedule rows across Durable Object restarts, brings full TypeScript inference to AgentClient, and migrates to Zod 4.

    Readable state on useAgent and AgentClient

    Both useAgent (React) and AgentClient (vanilla JS) now expose a state property that reflects the current agent state. Previously, reading state required manually tracking it through the onStateUpdate callback.

    React (useAgent)

    JavaScript
    const agent = useAgent({
      agent: "game-agent",
      name: "room-123",
    });
    

    // Read state directly — no separate useState + onStateUpdate needed
    return <div>Score: {agent.state?.score}</div>;
    

    // Spread for partial updates
    agent.setState({ ...agent.state, score: (agent.state?.score ?? 0) + 10 });

    agent.state is reactive — the component re-renders when state changes from either the server or a client-side setState() call.

    Vanilla JS (AgentClient)

    JavaScript
    const client = new AgentClient({
      agent: "game-agent",
      name: "room-123",
      host: "your-worker.workers.dev",
    });
    

    client.setState({ score: 100 });
    console.log(client.state); // { score: 100 }

    State starts as undefined and is populated when the server sends the initial state on connect (from initialState) or when setState() is called. Use optional chaining (agent.state?.field) for safe access. The onStateUpdate callback continues to work as before — the new state property is additive.

    Idempotent schedule()

    schedule() now supports an idempotent option that deduplicates by (type, callback, payload), preventing duplicate rows from accumulating when called in places that run on every Durable Object restart such as onStart().

    Cron schedules are idempotent by default. Calling schedule("0 * * * *", "tick") multiple times with the same callback, expression, and payload returns the existing schedule row instead of creating a new one. Pass { idempotent: false } to override.

    Delayed and date-scheduled types support opt-in idempotency:

    JavaScript
    import { Agent } from "agents";
    

    class MyAgent extends Agent {
      async onStart() {
        // Safe across restarts — only one row is created
        await this.schedule(60, "maintenance", undefined, { idempotent: true });
      }
    }

    Two new warnings help catch common foot-guns:

    • Calling schedule() inside onStart() without { idempotent: true } emits a console.warn with actionable guidance (once per callback; skipped for cron and when idempotent is set explicitly).
    • If an alarm cycle processes 10 or more stale one-shot rows for the same callback, the SDK emits a console.warn and a schedule:duplicate_warning diagnostics channel event.

    Typed AgentClient with call inference and stub proxy

    AgentClient now accepts an optional agent type parameter for full type inference on RPC calls, matching the typed experience already available with useAgent.

    JavaScript
    const client = new AgentClient({
      agent: "my-agent",
      host: window.location.host,
    });
    

    // Typed call — method name autocompletes, args and return type inferred
    const value = await client.call("getValue");
    

    // Typed stub — direct RPC-style proxy
    await client.stub.getValue();
    await client.stub.add(1, 2);

    State is automatically inferred from the agent type, so onStateUpdate is also typed:

    JavaScript
    const client = new AgentClient({
      agent: "my-agent",
      host: window.location.host,
      onStateUpdate: (state) => {
        // state is typed as MyAgent's state type
      },
    });

    Existing untyped usage continues to work without changes. The RPC type utilities (AgentMethods, AgentStub, RPCMethods) are now exported from agents/client for advanced typing scenarios. agents, @cloudflare/ai-chat, and @cloudflare/codemode now require zod ^4.0.0. Zod v3 is no longer supported.

    @cloudflare/ai-chat fixes

    • Turn serialization — onChatMessage() and _reply() work is now queued so user requests, tool continuations, and saveMessages() never stream concurrently.
    • Duplicate messages on stop — Clicking stop during an active stream no longer splits the assistant message into two entries.
    • Duplicate messages after tool calls — Orphaned client IDs no longer leak into persistent storage.

    keepAlive() and keepAliveWhile() are no longer experimental

    keepAlive() now uses a lightweight in-memory ref count instead of schedule rows. Multiple concurrent callers share a single alarm cycle. The @experimental tag has been removed from both keepAlive() and keepAliveWhile().

    @cloudflare/codemode: TanStack AI integration

    A new entry point @cloudflare/codemode/tanstack-ai adds support for TanStack AI's ↗ chat() as an alternative to the Vercel AI SDK's streamText():

    JavaScript
    import {
      createCodeTool,
      tanstackTools,
    } from "@cloudflare/codemode/tanstack-ai";
    import { chat } from "@tanstack/ai";
    

    const codeTool = createCodeTool({
      tools: [tanstackTools(myServerTools)],
      executor,
    });
    

    const stream = chat({ adapter, tools: [codeTool], messages });

    Upgrade

    To update to the latest version:

    Terminal window
    npm i agents@latest @cloudflare/ai-chat@latest

  1. Manage Cloudflare Tunnels with Wrangler

    Cloudflare Tunnel Workers

    You can now manage Cloudflare Tunnels directly from Wrangler, the CLI for the Cloudflare Developer Platform. The new wrangler tunnel commands let you create, run, and manage tunnels without leaving your terminal.

    Wrangler tunnel commands demo

    Available commands:

    • wrangler tunnel create — Create a new remotely managed tunnel.
    • wrangler tunnel list — List all tunnels in your account.
    • wrangler tunnel info — Display details about a specific tunnel.
    • wrangler tunnel delete — Delete a tunnel.
    • wrangler tunnel run — Run a tunnel using the cloudflared daemon.
    • wrangler tunnel quick-start — Start a free, temporary tunnel without an account using Quick Tunnels.

    Wrangler handles downloading and managing the cloudflared binary automatically. On first use, you will be prompted to download cloudflared to a local cache directory.

    These commands are currently experimental and may change without notice.

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

  1. @cloudflare/codemode v0.2.1: MCP barrel export, zero-dependency main entry point, and custom sandbox modules

    Agents Workers

    The latest releases of @cloudflare/codemode ↗ add a new MCP barrel export, remove ai and zod as required peer dependencies from the main entry point, and give you more control over the sandbox.

    New @cloudflare/codemode/mcp export

    A new @cloudflare/codemode/mcp entry point provides two functions that wrap MCP servers with Code Mode:

    • codeMcpServer({ server, executor }) — wraps an existing MCP server with a single code tool where each upstream tool becomes a typed codemode.* method.
    • openApiMcpServer({ spec, executor, request }) — creates search and execute MCP tools from an OpenAPI spec with host-side request proxying and automatic $ref resolution.
    JavaScript
    import { codeMcpServer } from "@cloudflare/codemode/mcp";
    import { DynamicWorkerExecutor } from "@cloudflare/codemode";
    

    const executor = new DynamicWorkerExecutor({ loader: env.LOADER });
    

    // Wrap an existing MCP server — all its tools become
    // typed methods the LLM can call from generated code
    const server = await codeMcpServer({ server: upstreamMcp, executor });

    Zero-dependency main entry point

    Breaking change in v0.2.0: generateTypes and the ToolDescriptor / ToolDescriptors types have moved to @cloudflare/codemode/ai:

    JavaScript
    // Before
    import { generateTypes } from "@cloudflare/codemode";
    

    // After
    import { generateTypes } from "@cloudflare/codemode/ai";

    The main entry point (@cloudflare/codemode) no longer requires the ai or zod peer dependencies. It now exports:

    ExportDescription
    sanitizeToolNameSanitize tool names into valid JS identifiers
    normalizeCodeNormalize LLM-generated code into async arrow functions
    generateTypesFromJsonSchemaGenerate TypeScript type definitions from plain JSON Schema
    jsonSchemaToTypeConvert a single JSON Schema to a TypeScript type string
    DynamicWorkerExecutorSandboxed code execution via Dynamic Worker Loader
    ToolDispatcherRPC target for dispatching tool calls from sandbox to host

    The ai and zod peer dependencies are now optional — only required when importing from @cloudflare/codemode/ai.

    Custom sandbox modules

    DynamicWorkerExecutor now accepts an optional modules option to inject custom ES modules into the sandbox:

    JavaScript
    const executor = new DynamicWorkerExecutor({
      loader: env.LOADER,
      modules: {
        "utils.js": `export function add(a, b) { return a + b; }`,
      },
    });
    

    // Sandbox code can then: import { add } from "utils.js"

    Internal normalization and sanitization

    DynamicWorkerExecutor now normalizes code and sanitizes tool names internally. You no longer need to call normalizeCode() or sanitizeToolName() before passing code and functions to execute().

    Upgrade

    Terminal window
    npm i @cloudflare/codemode@latest

    See the Code Mode documentation for the full API reference.

  1. Access Durable Object name via `ctx.id.name`

    Durable Objects Workers

    When your Worker accesses a Durable Object via idFromName() or getByName(), the same name is now available on ctx.id.name inside the object — no need to pass it through method arguments or persist it in storage. This brings the runtime behavior in line with the Workers runtime types.

    This is especially useful for alarms, where there is no calling client to pass the name as an argument. When an alarm handler runs, ctx.id.name will hold the same name the object was originally accessed with.

    JavaScript
    import { DurableObject } from "cloudflare:workers";
    

    export class ChatRoom extends DurableObject {
      async getRoomName() {
        // ctx.id.name returns the name passed to getByName() or idFromName()
        return this.ctx.id.name;
      }
    }
    

    // Worker
    export default {
      async fetch(request, env) {
        const stub = env.CHAT_ROOM.getByName("general");
        const roomName = await stub.getRoomName();
        return new Response(`Welcome to ${roomName}!`);
      },
    };

    ctx.id.name is undefined in the following cases:

    • For Durable Objects created with newUniqueId().
    • When accessed via idFromString(), even if the ID was originally created from a name.
    • For names longer than 1,024 bytes.

    This works the same way in local development with wrangler dev as it does in production. Run npm update wrangler to ensure you are on a version with this support.

    For more information, refer to the Durable Object ID documentation.

  1. Workflow steps now expose retry attempt number via step context

    Workflows Workers

    Cloudflare Workflows allows you to configure specific retry logic for each step in your workflow execution. Now, you can access which retry attempt is currently executing for calls to step.do():

    TypeScript
    await step.do("my-step", async (ctx) => {
      // ctx.attempt is 1 on first try, 2 on first retry, etc.
      console.log(`Attempt ${ctx.attempt}`);
    });

    You can use the step context for improved logging & observability, progressive backoff, or conditional logic in your workflow definition.

    Note that the current attempt number is 1-indexed. For more information on retry behavior, refer to Sleeping and Retrying.

  1. Workflows step limit increased to 25,000 steps per instance

    Workflows Workers

    Each Workflow on Workers Paid now supports 10,000 steps by default, configurable up to 25,000 steps in your wrangler.jsonc file:

    {
      "workflows": [
        {
          "name": "my-workflow",
          "binding": "MY_WORKFLOW",
          "class_name": "MyWorkflow",
          "limits": {
            "steps": 25000
          }
        }
      ]
    }

    Previously, each instance was limited to 1,024 steps. Now, Workflows can support more complex, long-running executions without the additional complexity of recursive or child workflow calls.

    Note that the maximum persisted state limit per Workflow instance remains 100 MB for Workers Free and 1 GB for Workers Paid. Refer to Workflows limits for more information.