Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
All products
hero image

  1. Routing Section Expansion on Cloudflare Radar

    Radar

    Radar now features an expanded Routing section ↗ with dedicated sub-pages, providing a more organized and in-depth view of the global routing ecosystem. This restructuring lays the groundwork for additional routing features and widgets coming in the near future.

    Dedicated sub-pages

    The single Routing page has been split into three focused sub-pages:

    • Overview ↗ — Routing statistics, IP address space trends, BGP announcements, and the new Top 100 ASes ranking.
    • RPKI ↗ — RPKI validation status, ASPA deployment trends, and per-ASN ASPA provider details.
    • Anomalies ↗ — BGP route leaks, origin hijacks, and Multi-Origin AS (MOAS) conflicts.
    Screenshot of the routing section menu

    New widgets

    The routing overview now includes a Top 100 ASes table ranking autonomous systems by customer cone size, IPv4 address space, or IPv6 address space. Users can switch between rankings using a segmented control.

    Screenshot of the top-100 ASes table

    The RPKI sub-page introduces a RPKI validation view for per-ASN pages, showing prefixes grouped by RPKI validation status (Valid, Invalid, Unknown) with visibility scores.

    Screenshot of the RPKI validation view

    Improved IP address space chart

    The IP address space ↗ chart now displays both IPv4 and IPv6 trends stacked vertically and is available on global, country, and AS views.

    Screenshot of the IPv4 and IPv6 combined IP space chart

    Check out the Radar routing section ↗ to explore the data, and stay tuned for more routing insights coming soon.

  1. New QUIC RTT and delivery rate fields

    Rules

    Two new fields are now available in rule expressions that surface Layer 4 transport telemetry from the client connection. Together with the existing cf.timings.client_tcp_rtt_msec field, these fields give you a complete picture of connection quality for both TCP and QUIC traffic — enabling transport-aware rules without requiring any client-side changes.

    Previously, QUIC RTT and delivery rate data was only available via the Server-Timing: cfL4 response header. These new fields make the same data available directly in rule expressions, so you can use them in Transform Rules, WAF Custom Rules, and other phases that support dynamic fields.

    New fields

    FieldTypeDescription
    cf.timings.client_quic_rtt_msecIntegerThe smoothed QUIC round-trip time (RTT) between Cloudflare and the client in milliseconds. Only populated for QUIC (HTTP/3) connections. Returns 0 for TCP connections.
    cf.edge.l4.delivery_rateIntegerThe most recent data delivery rate estimate for the client connection, in bytes per second. Returns 0 when L4 statistics are not available for the request.

    Example: Route slow connections to a lightweight origin

    Use a request header transform rule to tag requests from high-latency connections, so your origin can serve a lighter page variant:

    Rule expression:

    cf.timings.client_tcp_rtt_msec > 200 or cf.timings.client_quic_rtt_msec > 200

    Header modifications:

    OperationHeader nameValue
    SetX-High-Latencytrue

    Example: Match low-bandwidth connections

    cf.edge.l4.delivery_rate > 0 and cf.edge.l4.delivery_rate < 100000

    For more information, refer to Request Header Transform Rules and the fields reference.

  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. Internal DNS - now in open beta

    DNS

    Internal DNS is now in open beta.

    Who can use it?

    Internal DNS is bundled as a part of Cloudflare Gateway and is now available to every Enterprise customer with one of the following subscriptions:

    • Cloudflare Zero Trust Enterprise
    • Cloudflare Gateway Enterprise

    To learn more and get started, refer to the Internal DNS documentation.

  1. WAF Release - 2026-03-30

    WAF

    This week's release introduces new detections for a critical authentication bypass vulnerability in Fortinet products (CVE-2025-59718), alongside three new generic detection rules designed to identify and block HTTP Parameter Pollution attempts. Additionally, this release includes targeted protection for a high-impact unrestricted file upload vulnerability in Magento and Adobe Commerce.

    Key Findings

    • CVE-2025-59718: An improper cryptographic signature verification vulnerability in Fortinet FortiOS, FortiProxy, and FortiSwitchManager. This may allow an unauthenticated attacker to bypass the FortiCloud SSO login authentication using a maliciously crafted SAML message, if that feature is enabled on the device.

    • Magento 2 - Unrestricted File Upload: A critical flaw in Magento and Adobe Commerce allows unauthenticated attackers to bypass security checks and upload malicious files to the server, potentially leading to Remote Code Execution (RCE).

    Impact

    Successful exploitation of the Fortinet and Magento vulnerabilities could allow unauthenticated attackers to gain administrative control or deploy webshells, leading to complete server compromise and data theft.



    RulesetRule IDLegacy Rule IDDescriptionPrevious ActionNew ActionComments
    Cloudflare Managed Ruleset N/AGeneric Rules - Parameter Pollution - BodyLogDisabledThis is a new detection.
    Cloudflare Managed Ruleset N/A Generic Rules - Parameter Pollution - Header - Form Log Disabled This is a new detection.
    Cloudflare Managed Ruleset N/A Generic Rules - Parameter Pollution - URI Log Disabled This is a new detection.
    Cloudflare Managed Ruleset N/AMagento 2 - Unrestricted file uploadLogBlockThis is a new detection.
    Cloudflare Managed Ruleset N/AFortinet FortiCloud SSO - Authentication Bypass - CVE:CVE-2025-59718LogBlockThis is a new detection.

  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. Easily connect Containers and Sandboxes to Workers

    Containers

    Containers and Sandboxes now support connecting directly to Workers over HTTP. This allows you to call Workers functions and bindings, like KV or R2, from within the container at specific hostnames.

    Run Worker code

    Define an outbound handler to capture any HTTP request or use outboundByHost to capture requests to individual hostnames and IPs.

    JavaScript
    export class MyApp extends Sandbox {}
    

    MyApp.outbound = async (request, env, ctx) => {
      // you can run arbitrary functions defined in your Worker on any HTTP request
      return await someWorkersFunction(request.body);
    };
    

    MyApp.outboundByHost = {
      "my.worker": async (request, env, ctx) => {
        return await anotherFunction(request.body);
      },
    };

    In this example, requests from the container to http://my.worker will run the function defined within outboundByHost, and any other HTTP requests will run the outbound handler. These handlers run entirely inside the Workers runtime, outside of the container sandbox.

    Access Workers bindings

    Each handler has access to env, so it can call any binding set in Wrangler config. Code inside the container makes a standard HTTP request to that hostname and the outbound Worker translates it into a binding call.

    JavaScript
    export class MyApp extends Sandbox {}
    

    MyApp.outboundByHost = {
      "my.kv": async (request, env, ctx) => {
        const key = new URL(request.url).pathname.slice(1);
        const value = await env.KV.get(key);
        return new Response(value ?? "", { status: value ? 200 : 404 });
      },
      "my.r2": async (request, env, ctx) => {
        const key = new URL(request.url).pathname.slice(1);
        const object = await env.BUCKET.get(key);
        return new Response(object?.body ?? "", { status: object ? 200 : 404 });
      },
    };

    Now, from inside the container sandbox, curl http://my.kv/some-key will access Workers KV and curl http://my.r2/some-object will access R2.

    Access Durable Object state

    Use ctx.containerId to reference the container's automatically provisioned Durable Object.

    JavaScript
    export class MyContainer extends Container {}
    

    MyContainer.outboundByHost = {
      "get-state.do": async (request, env, ctx) => {
        const id = env.MY_CONTAINER.idFromString(ctx.containerId);
        const stub = env.MY_CONTAINER.get(id);
        return stub.getStateForKey(request.body);
      },
    };

    This provides an easy way to associate state with any container instance, and includes a built-in SQLite database.

    Get Started Today

    Upgrade to @cloudflare/containers version 0.2.0 or later, or @cloudflare/sandbox version 0.8.0 or later to use outbound Workers.

    Refer to Containers outbound traffic and Sandboxes outbound traffic for more details and examples.

  1. URL Scanner improvements on Cloudflare Radar

    Radar

    Radar ships several improvements to the URL Scanner ↗ that make scan reports more informative and easier to share:

    • Live screenshots — the summary card now includes an option to capture a live screenshot of the scanned URL on demand using the Browser Rendering API.
    • Save as PDF — a new button generates a print-optimized document aggregating all tab contents (Summary, Security, Network, Behavior, and Indicators) into a single file.
    • Download as JSON — raw scan data is available as a JSON download for programmatic use.
    • Redesigned summary layout — page information and security details are now displayed side by side with the screenshot, with a layout that adapts to narrower viewports.
    • File downloads — downloads are separated into a dedicated card with expandable rows showing each file's source URL and SHA256 hash.
    • Detailed IP address data — the Network tab now includes additional detail per IP address observed during the scan.
    Screenshot of the redesigned URL Scanner summary on Radar

    Explore these improvements on the Cloudflare Radar URL Scanner ↗.

  1. Logpush — More granular timestamps

    Logpush Logs

    Logpush now supports higher-precision timestamp formats for log output. You can configure jobs to output timestamps at millisecond or nanosecond precision. This is available in both the Logpush UI in the Cloudflare dashboard and the Logpush API.

    To use the new formats, set timestamp_format in your Logpush job's output_options:

    • rfc3339ms — 2024-02-17T23:52:01.123Z
    • rfc3339ns — 2024-02-17T23:52:01.123456789Z

    Default timestamp formats apply unless explicitly set. The dashboard defaults to rfc3339 and the API defaults to unixnano.

    For more information, refer to the Log output options documentation.

  1. New mTLS certificate fields for Transform Rules

    Rules

    Cloudflare now exposes four new fields in the Transform Rules phase that encode client certificate data in RFC 9440 ↗ format. Previously, forwarding client certificate information to your origin required custom parsing of PEM-encoded fields or non-standard HTTP header formats. These new fields produce output in the standardized Client-Cert and Client-Cert-Chain header format defined by RFC 9440, so your origin can consume them directly without any additional decoding logic.

    Each certificate is DER-encoded, Base64-encoded, and wrapped in colons. For example, :MIIDsT...Vw==:. A chain of intermediates is expressed as a comma-separated list of such values.

    New fields

    FieldTypeDescription
    cf.tls_client_auth.cert_rfc9440StringThe client leaf certificate in RFC 9440 format. Empty if no client certificate was presented.
    cf.tls_client_auth.cert_rfc9440_too_largeBooleantrue if the leaf certificate exceeded 10 KB and was omitted. In practice this will almost always be false.
    cf.tls_client_auth.cert_chain_rfc9440StringThe intermediate certificate chain in RFC 9440 format as a comma-separated list. Empty if no intermediate certificates were sent or if the chain exceeded 16 KB.
    cf.tls_client_auth.cert_chain_rfc9440_too_largeBooleantrue if the intermediate chain exceeded 16 KB and was omitted.

    The chain encoding follows the same ordering as the TLS handshake: the certificate closest to the leaf appears first, working up toward the trust anchor. The root certificate is not included.

    Example: Forwarding client certificate headers to your origin server

    Add a request header transform rule to set the Client-Cert and Client-Cert-Chain headers on requests forwarded to your origin server. For example, to forward headers for verified, non-revoked certificates:

    Rule expression:

    cf.tls_client_auth.cert_verified and not cf.tls_client_auth.cert_revoked

    Header modifications:

    OperationHeader nameValue
    SetClient-Certcf.tls_client_auth.cert_rfc9440
    SetClient-Cert-Chaincf.tls_client_auth.cert_chain_rfc9440

    To get the most out of these fields, upload your client CA certificate to Cloudflare so that Cloudflare validates the client certificate at the edge and populates cf.tls_client_auth.cert_verified and cf.tls_client_auth.cert_revoked.

    For more information, refer to Mutual TLS authentication, Request Header Transform Rules, and the fields reference.

  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. Advanced WAF customization for AI Crawl Control blocks

    AI Crawl Control

    AI Crawl Control now supports extending the underlying WAF rule with custom modifications. Any changes you make directly in the WAF custom rules editor — such as adding path-based exceptions, extra user agents, or additional expression clauses — are preserved when you update crawler actions in AI Crawl Control.

    If the WAF rule expression has been modified in a way AI Crawl Control cannot parse, a warning banner appears on the Crawlers page with a link to view the rule directly in WAF.

    For more information, refer to WAF rule management.

  1. Cache Response Rules

    Cache / CDN

    You can now control how Cloudflare handles origin responses without changing your origin. Cache Response Rules let you modify Cache-Control directives, manage cache tags, and strip headers like Set-Cookie from origin responses before they reach Cloudflare's cache. Whether traffic is cached or passed through dynamically, these rules give you control over origin response behavior that was previously out of reach.

    What changed

    Cache Rules previously only operated on request attributes. Cache Response Rules introduce a new response phase that evaluates origin responses and lets you act on them before caching. You can now:

    • Modify Cache-Control directives: Set or remove individual directives like no-store, no-cache, max-age, s-maxage, stale-while-revalidate, immutable, and more. For example, remove a no-cache directive your origin sends so Cloudflare can cache the asset, or set an s-maxage to control how long Cloudflare stores it.
    • Set a different browser Cache-Control: Send a different Cache-Control header downstream to browsers and other clients than what Cloudflare uses internally, giving you independent control over edge and browser caching strategies.
    • Manage cache tags: Add, set, or remove cache tags on responses, including converting tags from another CDN's header format into Cloudflare's Cache-Tag header. This is especially useful if you are migrating from a CDN that uses a different tag header or delimiter.
    • Strip headers that block caching: Remove Set-Cookie, ETag, or Last-Modified headers from origin responses before caching, so responses that would otherwise be treated as uncacheable can be stored and served from cache.

    Benefits

    • No origin changes required: Fix caching behavior entirely from Cloudflare, even when your origin configuration is locked down or managed by a different team.
    • Simpler CDN migration: Match caching behavior from other CDN providers without rewriting your origin. Translate cache tag formats and override directives that do not align with Cloudflare's defaults.
    • Native support, fewer workarounds: Functionality that previously required workarounds is now built into Cache Rules with full Tiered Cache compatibility.
    • Fine-grained control: Use expressions to match on request and response attributes, then apply precise cache settings per rule. Rules are stackable and composable with existing Cache Rules.

    Get started

    Configure Cache Response Rules in the Cloudflare dashboard ↗ under Caching > Cache Rules, or via the Rulesets API ↗. For more details, refer to the Cache Rules documentation ↗.

  1. Use Docker Hub images with Containers

    Containers

    Containers now support Docker Hub ↗ images. You can use a fully qualified Docker Hub image reference in your Wrangler configuration ↗ instead of first pushing the image to Cloudflare Registry.

    JSONC
    {
      "containers": [
        {
          // Example: docker.io/cloudflare/sandbox:0.7.18
          "image": "docker.io/<NAMESPACE>/<REPOSITORY>:<TAG>",
        },
      ],
    }

    Containers also support private Docker Hub images. To configure credentials, refer to Use private Docker Hub images.

    For more information, refer to Image management.

  1. OIDC Claims filtering now available in Gateway Firewall, Resolver, and Egress policies

    Gateway

    Cloudflare Gateway now supports OIDC Claims as a selector in Firewall, Resolver, and Egress policies. Administrators can use custom OIDC claims from their identity provider to build fine-grained, identity-based traffic policies across all Gateway policy types.

    With this update, you can:

    • Filter traffic in DNS, HTTP, and Network firewall policies based on OIDC claim values.
    • Apply custom resolver policies to route DNS queries to specific resolvers depending on a user's OIDC claims.
    • Control egress policies to assign dedicated egress IPs based on OIDC claim attributes.

    For example, you can create a policy that routes traffic differently for users with department=engineering in their OIDC claims, or restrict access to certain destinations based on a user's role claim.

    To get started, configure custom OIDC claims on your identity provider and use the OIDC Claims selector in the Gateway policy builder.

    For more information, refer to Identity-based policies.

  1. Interconnects moved to Connectors

    Network Interconnect

    The top-level Interconnects page in the Cloudflare dashboard has been removed. Interconnects are now located under Connectors > Interconnects.

    Your existing configurations and functionality remain the same.

  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. New AI Search REST API endpoints for /search and /chat/completions

    AI Search

    AI Search now offers new REST API endpoints for search and chat that use an OpenAI compatible format. This means you can use the familiar messages array structure that works with existing OpenAI SDKs and tools. The messages array also lets you pass previous messages within a session, so the model can maintain context across multiple turns.

    EndpointPath
    Chat CompletionsPOST /accounts/{account_id}/ai-search/instances/{name}/chat/completions
    SearchPOST /accounts/{account_id}/ai-search/instances/{name}/search

    Here is an example request to the Chat Completions endpoint using the new messages array format:

    Terminal window
    curl https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai-search/instances/{NAME}/chat/completions \
      -H "Content-Type: application/json" \
      -H "Authorization: Bearer {API_TOKEN}" \
      -d '{
        "messages": [
          {
            "role": "system",
            "content": "You are a helpful documentation assistant."
          },
          {
            "role": "user",
            "content": "How do I get started?"
          }
        ]
      }'

    For more details, refer to the AI Search REST API guide.

    If you are using the previous AutoRAG API endpoints (/autorag/rags/), we recommend migrating to the new endpoints. The previous AutoRAG API endpoints will continue to be fully supported.

    Refer to the migration guide for step-by-step instructions.

  1. AI Search UI snippets and MCP support

    AI Search

    AI Search now supports public endpoints, UI snippets, and MCP, making it easy to add search to your website or connect AI agents.

    Public endpoints allow you to expose AI Search capabilities without requiring API authentication. To enable public endpoints:

    1. Go to AI Search in the Cloudflare dashboard. Go to AI Search
    2. Select your instance, and turn on Public Endpoint in Settings. For more details, refer to Public endpoint configuration.

    UI snippets

    UI snippets are pre-built search and chat components you can embed in your website. Visit search.ai.cloudflare.com ↗ to configure and preview components for your AI Search instance.

    Example of the search-modal-snippet component

    To add a search modal to your page:

    <script
      type="module"
      src="https://<INSTANCE_ID>.search.ai.cloudflare.com/assets/v0.0.25/search-snippet.es.js"
    ></script>
    

    <search-modal-snippet
      api-url="https://<INSTANCE_ID>.search.ai.cloudflare.com/"
      placeholder="Search..."
    >
    </search-modal-snippet>

    For more details, refer to the UI snippets documentation.

    MCP

    The MCP endpoint allows AI agents to search your content via the Model Context Protocol. Connect your MCP client to:

    https://<INSTANCE_ID>.search.ai.cloudflare.com/mcp

    For more details, refer to the MCP documentation.

  1. Custom metadata filtering for AI Search

    AI Search

    AI Search now supports custom metadata filtering, allowing you to define your own metadata fields and filter search results based on attributes like category, version, or any custom field you define.

    Define a custom metadata schema

    You can define up to 5 custom metadata fields per AI Search instance. Each field has a name and data type (text, number, or boolean):

    Terminal window
    curl -X POST https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai-search/instances \
      -H "Content-Type: application/json" \
      -H "Authorization: Bearer {API_TOKEN}" \
      -d '{
        "id": "my-instance",
        "type": "r2",
        "source": "my-bucket",
        "custom_metadata": [
          { "field_name": "category", "data_type": "text" },
          { "field_name": "version", "data_type": "number" },
          { "field_name": "is_public", "data_type": "boolean" }
        ]
      }'

    Add metadata to your documents

    How you attach metadata depends on your data source:

    • R2 bucket: Set metadata using S3-compatible custom headers (x-amz-meta-*) when uploading objects. Refer to R2 custom metadata for examples.
    • Website: Add <meta> tags to your HTML pages. Refer to Website custom metadata for details.

    Filter search results

    Use custom metadata fields in your search queries alongside built-in attributes like folder and timestamp:

    Terminal window
    curl https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai-search/instances/{NAME}/search \
      -H "Content-Type: application/json" \
      -H "Authorization: Bearer {API_TOKEN}" \
      -d '{
        "messages": [
          {
            "content": "How do I configure authentication?",
            "role": "user"
          }
        ],
        "ai_search_options": {
          "retrieval": {
            "filters": {
              "category": "documentation",
              "version": { "$gte": 2.0 }
            }
          }
        }
      }'

    Learn more in the metadata filtering documentation.

  1. Web Assets fields now available in GraphQL Analytics API

    API Shield

    Two new fields are now available in the httpRequestsAdaptive and httpRequestsAdaptiveGroups GraphQL Analytics API datasets:

    • webAssetsOperationId — the ID of the saved endpoint that matched the incoming request.
    • webAssetsLabelsManaged — the managed labels mapped to the matched operation at the time of the request (for example, cf-llm, cf-log-in). At most 10 labels are returned per request.

    Both fields are empty when no operation matched. webAssetsLabelsManaged is also empty when no managed labels are assigned to the matched operation.

    These fields allow you to determine, per request, which Web Assets operation was matched and which managed labels were active. This is useful for troubleshooting downstream security detection verdicts — for example, understanding why AI Security for Apps did or did not flag a request.

    Refer to Endpoint labeling service for GraphQL query examples.

  1. R2 SQL now supports over 190 new functions, expressions, and complex types

    R2 SQL

    R2 SQL now supports an expanded SQL grammar so you can write richer analytical queries without exporting data. This release adds CASE expressions, column aliases, arithmetic in clauses, 163 scalar functions, 33 aggregate functions, EXPLAIN, Common Table Expressions (CTEs),and full struct/array/map access. R2 SQL is Cloudflare's serverless, distributed, analytics query engine for querying Apache Iceberg ↗ tables stored in R2 Data Catalog. This page documents the supported SQL syntax.

    Highlights

    • Column aliases — SELECT col AS alias now works in all clauses
    • CASE expressions — conditional logic directly in SQL (searched and simple forms)
    • Scalar functions — 163 new functions across math, string, datetime, regex, crypto, encoding, and type inspection categories
    • Aggregate functions — statistical (variance, stddev, correlation, regression), bitwise, boolean, and positional aggregates join the existing basic and approximate functions
    • Complex types — query struct fields with bracket notation, use 46 array functions, and extract map keys/values
    • Common table expressions (CTEs) — use WITH ... AS to define named temporary result sets. Chained CTEs are supported. All CTEs must reference the same single table.
    • Full expression support — arithmetic, type casting (CAST, TRY_CAST, :: shorthand), and EXTRACT in SELECT, WHERE, GROUP BY, HAVING, and ORDER BY

    Examples

    CASE expressions with statistical aggregates

    SELECT source,
        CASE
            WHEN AVG(price) > 30 THEN 'premium'
            WHEN AVG(price) > 10 THEN 'mid-tier'
            ELSE 'budget'
        END AS tier,
        round(stddev(price), 2) AS price_volatility,
        approx_percentile_cont(price, 0.95) AS p95_price
    FROM my_namespace.sales_data
    GROUP BY source

    Struct and array access

    SELECT product_name,
        pricing['price'] AS price,
        array_to_string(tags, ', ') AS tag_list
    FROM my_namespace.products
    WHERE array_has(tags, 'Action')
    ORDER BY pricing['price'] DESC
    LIMIT 10

    Chained CTEs with time-series analysis

    WITH monthly AS (
        SELECT date_trunc('month', sale_timestamp) AS month,
            department,
            COUNT(*) AS transactions,
            round(AVG(total_amount), 2) AS avg_amount
        FROM my_namespace.sales_data
        WHERE sale_timestamp BETWEEN '2025-01-01T00:00:00Z' AND '2025-12-31T23:59:59Z'
        GROUP BY date_trunc('month', sale_timestamp), department
    ),
    ranked AS (
        SELECT month, department, transactions, avg_amount,
            CASE
                WHEN avg_amount > 1000 THEN 'high-value'
                WHEN avg_amount > 500 THEN 'mid-value'
                ELSE 'standard'
            END AS tier
        FROM monthly
        WHERE transactions > 100
    )
    SELECT * FROM ranked
    ORDER BY month, avg_amount DESC

    For the full function reference and syntax details, refer to the SQL reference. For limitations and best practices, refer to Limitations and best practices.

Search all changelog entries