Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds

All products

Mar 29, 2026

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.

   
   
   
   

   Ruleset	Rule ID	Legacy Rule ID	Description	Previous Action	New Action	Comments
   Cloudflare Managed Ruleset	...2f7f95e9	N/A	Generic Rules - Parameter Pollution - Body	Log	Disabled	This is a new detection.
   Cloudflare Managed Ruleset	...319731a4	N/A	Generic Rules - Parameter Pollution - Header - Form	Log	Disabled	This is a new detection.
   Cloudflare Managed Ruleset	...def262dd	N/A	Generic Rules - Parameter Pollution - URI	Log	Disabled	This is a new detection.
   Cloudflare Managed Ruleset	...70a36147	N/A	Magento 2 - Unrestricted file upload	Log	Block	This is a new detection.
   Cloudflare Managed Ruleset	...2ffcca9f	N/A	Fortinet FortiCloud SSO - Authentication Bypass - CVE:CVE-2025-59718	Log	Block	This is a new detection.

Mar 26, 2026

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

   Field	Type	Description
   certRFC9440	String	The client leaf certificate in RFC 9440 format (:base64-DER:). Empty if no client certificate was presented.
   certRFC9440TooLarge	Boolean	true if the leaf certificate exceeded 10 KB and was omitted from certRFC9440.
   certChainRFC9440	String	The 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.
   certChainRFC9440TooLarge	Boolean	true 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.

Mar 25, 2026

1. Code mode for MCP server portals

   Access

   MCP server portals support code mode, a technique that reduces context window usage by replacing individual tool definitions with a single code execution tool. Code mode is turned on by default on all portals.

   To turn it off, edit the portal in Access controls > AI controls and turn off Code mode under Basic information.

   When code mode is active, the portal exposes a single code tool instead of listing every tool from every upstream MCP server. The connected AI agent writes JavaScript that calls typed codemode.* methods for each upstream tool. The generated code runs in an isolated Dynamic Worker environment, keeping authentication credentials and environment variables out of the model context.

   To use code mode, append ?codemode=search_and_execute to your portal URL when connecting from an MCP client:

   https://<subdomain>.<domain>/mcp?codemode=search_and_execute

   For more information, refer to code mode.

Mar 25, 2026

1. Context optimization for MCP server portals

   Access

   MCP server portals support two context optimization options that reduce how many tokens tool definitions consume in the model's context window. Both options are activated by appending the optimize_context query parameter to the portal URL.

   minimize_tools

   Strips tool descriptions and input schemas from all upstream tools, leaving only their names. The portal exposes a special query tool that agents use to retrieve full definitions on demand. This provides up to 5x savings in token usage.

   https://<subdomain>.<domain>/mcp?optimize_context=minimize_tools

   search_and_execute

   Hides all upstream tools and exposes only two tools: query and execute. The query tool searches and retrieves tool definitions. The execute tool runs the upstream tools in an isolated Dynamic Worker environment. This reduces the initial token cost to a small constant, regardless of how many tools are available through the portal.

   https://<subdomain>.<domain>/mcp?optimize_context=search_and_execute

   For more information, refer to Optimize context.

Mar 25, 2026

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.

Mar 25, 2026

1. Streaming ZIP file scanning removes per-file size limits

   Data Loss Prevention

   DLP now processes ZIP files using a streaming handler that scans archive contents element-by-element as data arrives. This removes previous file size limitations and improves memory efficiency when scanning large archives.

   Microsoft Office documents (DOCX, XLSX, PPTX) also benefit from this improvement, as they use ZIP as a container format.

   This improvement is automatic — no configuration changes are required.

Mar 25, 2026

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

   Durable Objects Workers

   ctx.id.jurisdiction inside a Durable Object now reports the jurisdiction the object was created in — for example "eu" when accessed through env.MY_DURABLE_OBJECT.jurisdiction("eu") — so you can make region-aware decisions without passing the jurisdiction through method arguments or persisting it in storage. For the full list of ID-construction paths that preserve jurisdiction, refer to the Durable Object ID documentation.

   JavaScript

   export class RegionalRoom extends DurableObject {
     async fetch(request) {
       // "eu" when accessed through env.MY_DURABLE_OBJECT.jurisdiction("eu")
       const region = this.ctx.id.jurisdiction;
       return new Response(`Hello from ${region ?? "the default region"}!`);
     }
   }
   
   // Worker
   export default {
     async fetch(request, env) {
       const stub = env.MY_DURABLE_OBJECT.jurisdiction("eu").getByName("general");
       return stub.fetch(request);
     },
   };

   ctx.id.jurisdiction is undefined for Durable Objects that were not created in a jurisdiction-restricted namespace. Alarms scheduled before 2026-03-15 also do not have jurisdiction stored; to backfill the value, reschedule the alarm from a fetch() or RPC handler.

Mar 25, 2026

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.
   

   Explore these improvements on the Cloudflare Radar URL Scanner ↗.

Mar 24, 2026

1. Detect and sanitize HAR files

   Data Loss Prevention

   HTTP Archive (HAR) files are used by engineering and support teams to capture and share web traffic logs for troubleshooting. However, these files routinely contain highly sensitive data — including session cookies, authorization headers, and other credentials — that can pose a significant risk if uploaded to third-party services without being reviewed or cleaned first.

   Gateway now includes a predefined DLP profile called Unsanitized HAR that detects HAR files in HTTP traffic. You can use this profile in a Gateway HTTP policy to either block HAR file uploads entirely or redirect users to a sanitization tool before allowing the upload to proceed.

   How to configure a HAR file policy

   In the Cloudflare dashboard ↗, go to Zero Trust > Traffic policies > Firewall Policies > HTTP and create a new HTTP policy using the DLP Profile selector:

   Selector	Operator	Value	Action
   DLP Profile	in	Unsanitized HAR

   Then choose one of the following actions:

   • Block: Prevents the upload of any HAR file that has not been sanitized by Cloudflare's sanitizer. Use this for strict environments where HAR file sharing must be disallowed entirely.
   • Block with Gateway Redirect: Intercepts the upload and redirects the user to https://har-sanitizer.pages.dev/, where they can sanitize the file. Once sanitized, the user can re-upload the clean file and proceed with their workflow.

   Sanitized HAR recognition

   HAR files processed by the Cloudflare HAR sanitizer receive a tamper-evident sanitized marker. DLP recognizes this marker and will not re-trigger the policy on a file that has already been sanitized and has not been modified since. If a previously sanitized file is edited, it will be treated as unsanitized and flagged again.

   Visibility in Gateway logs

   Gateway logs will reflect whether a detected HAR file was classified as Unsanitized or Sanitized, giving your security team full visibility into HAR file activity across your organization.

   For more information, refer to predefined DLP profiles.

Mar 24, 2026

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.

Mar 24, 2026

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

   Field	Type	Description
   cf.tls_client_auth.cert_rfc9440	String	The client leaf certificate in RFC 9440 format. Empty if no client certificate was presented.
   cf.tls_client_auth.cert_rfc9440_too_large	Boolean	true if the leaf certificate exceeded 10 KB and was omitted. In practice this will almost always be false.
   cf.tls_client_auth.cert_chain_rfc9440	String	The 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_large	Boolean	true 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:

   Operation	Header name	Value
   Set	Client-Cert	cf.tls_client_auth.cert_rfc9440
   Set	Client-Cert-Chain	cf.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.

   Prevent header injection

   You should ensure that Client-Cert and Client-Cert-Chain headers received by your origin server can only originate from this transform rule — any client could send these headers directly.

   • If you use WAF custom rules to block requests with invalid mTLS connections: The transform rule is sufficient. For all requests that reach your origin server, the rule will overwrite any existing Client-Cert and Client-Cert-Chain headers.
   • If you do not enforce mTLS at the WAF: Add another transform rule that removes any incoming Client-Cert and Client-Cert-Chain headers from all requests (use expression true), ordered before the rule above. This ensures your origin server cannot receive client-supplied values for these HTTP headers.

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

Mar 24, 2026

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.

   wrangler.jsonc

   JSONC

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

   wrangler.toml

   TOML

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

Mar 23, 2026

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.

Mar 23, 2026

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

Mar 23, 2026

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.

   wrangler.jsonc

   JSONC

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

   wrangler.toml

   TOML

   [[containers]]
   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.

Mar 23, 2026

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.

Mar 23, 2026

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.

Mar 23, 2026

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

   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);
     },
   };

   TypeScript

   TypeScript

   export default {
     async fetch(request: Request, env: Env): Promise<Response> {
       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

   

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

   Dynamic Workers Playground

   

   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.

   	Included	Additional usage
   Dynamic Workers created daily	1,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.

Mar 23, 2026

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

Mar 22, 2026

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

   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 });

   TypeScript

   TypeScript

   const agent = useAgent<GameAgent, GameState>({
     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

   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 }

   TypeScript

   TypeScript

   const client = new AgentClient<GameAgent>({
     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

   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 });
     }
   }

   TypeScript

   TypeScript

   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

   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);

   TypeScript

   TypeScript

   const client = new AgentClient<MyAgent>({
     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

   JavaScript

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

   TypeScript

   TypeScript

   const client = new AgentClient<MyAgent>({
     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

   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 });

   TypeScript

   TypeScript

   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:

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

Mar 22, 2026

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.

   Endpoint	Path
   Chat Completions	POST /accounts/{account_id}/ai-search/instances/{name}/chat/completions
   Search	POST /accounts/{account_id}/ai-search/instances/{name}/search

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

   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.

   Migration from existing AutoRAG API (recommended)

   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.

Mar 22, 2026

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.

   

   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.

Mar 22, 2026

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):

   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:

   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.

Mar 22, 2026

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.

Mar 22, 2026

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.

← Prev

1 … 8910 … 38

Next →