Cloudflare changelogs | Workers

Workflows, Workers - All Wrangler commands for Workflows now support local development

Wed, 01 Apr 2026 12:00:00 GMT

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:

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.

Workers - Deploy Hooks are now available for Workers Builds

Wed, 01 Apr 2026 00:00:00 GMT

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.

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

TypeScript

export default {
  async scheduled(event: ScheduledEvent, env: Env, ctx: ExecutionContext): Promise<void> {
    ctx.waitUntil(fetch(env.DEPLOY_HOOK_URL, { method: "POST" }));
  },
} satisfies ExportedHandler<Env>;

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.

Workers - New L4 transport telemetry fields in Workers

Wed, 01 Apr 2026 00:00:00 GMT

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

Property	Type	Description
`clientTcpRtt`	number \| undefined	The 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`.
`clientQuicRtt`	number \| undefined	The smoothed QUIC round-trip time (RTT) between Cloudflare and the client in milliseconds. Only present for QUIC connections (HTTP/3). For example, `42`.
`edgeL4`	Object \| undefined	Layer 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

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.

Workers - New RFC 9440 mTLS certificate fields in Workers

Fri, 27 Mar 2026 00:00:00 GMT

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

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.

Workers - Declare required secrets in your Wrangler configuration

Wed, 25 Mar 2026 00:00:00 GMT

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

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

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

Workers - Dynamic Workers, now in open beta

Tue, 24 Mar 2026 00:00:00 GMT

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

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.

Workflows, Workers - Workflow instances now support pause(), resume(), restart(), and terminate() methods in local development

Mon, 23 Mar 2026 12:00:00 GMT

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:

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

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

Mon, 23 Mar 2026 00:00:00 GMT

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

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

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

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

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

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

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

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

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

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

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

Cloudflare Tunnel, Workers - Manage Cloudflare Tunnels with Wrangler

Thu, 19 Mar 2026 00:00:00 GMT

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.

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.

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

Tue, 17 Mar 2026 00:00:00 GMT

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

TypeScript

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

TypeScript

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

Export	Description
`sanitizeToolName`	Sanitize tool names into valid JS identifiers
`normalizeCode`	Normalize LLM-generated code into async arrow functions
`generateTypesFromJsonSchema`	Generate TypeScript type definitions from plain JSON Schema
`jsonSchemaToType`	Convert a single JSON Schema to a TypeScript type string
`DynamicWorkerExecutor`	Sandboxed code execution via Dynamic Worker Loader
`ToolDispatcher`	RPC 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"

TypeScript

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

npm i @cloudflare/codemode@latest

See the Code Mode documentation for the full API reference.

Workflows, Workers - Workflow steps now expose retry attempt number via step context

Fri, 06 Mar 2026 12:00:00 GMT

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

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.

Workflows, Workers - Workflows step limit increased to 25,000 steps per instance

Tue, 03 Mar 2026 12:00:00 GMT

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.

Agents, Workers - Agents SDK v0.7.0: Observability rewrite, keepAlive, and waitForMcpConnections

Mon, 02 Mar 2026 00:00:00 GMT

The latest release of the Agents SDK rewrites observability from scratch with diagnostics_channel, adds keepAlive() to prevent Durable Object eviction during long-running work, and introduces waitForMcpConnections so MCP tools are always available when onChatMessage runs.

Observability rewrite

The previous observability system used console.log() with a custom Observability.emit() interface. v0.7.0 replaces it with structured events published to diagnostics channels — silent by default, zero overhead when nobody is listening.

Every event has a type, payload, and timestamp. Events are routed to seven named channels:

Channel	Event types
`agents:state`	`state:update`
`agents:rpc`	`rpc`, `rpc:error`
`agents:message`	`message:request`, `message:response`, `message:clear`, `message:cancel`, `message:error`, `tool:result`, `tool:approval`
`agents:schedule`	`schedule:create`, `schedule:execute`, `schedule:cancel`, `schedule:retry`, `schedule:error`, `queue:retry`, `queue:error`
`agents:lifecycle`	`connect`, `destroy`
`agents:workflow`	`workflow:start`, `workflow:event`, `workflow:approved`, `workflow:rejected`, `workflow:terminated`, `workflow:paused`, `workflow:resumed`, `workflow:restarted`
`agents:mcp`	`mcp:client:preconnect`, `mcp:client:connect`, `mcp:client:authorize`, `mcp:client:discover`

Use the typed subscribe() helper from agents/observability for type-safe access:

JavaScript

import { subscribe } from "agents/observability";

const unsub = subscribe("rpc", (event) => {
  if (event.type === "rpc") {
    console.log(`RPC call: ${event.payload.method}`);
  }
  if (event.type === "rpc:error") {
    console.error(
      `RPC failed: ${event.payload.method} — ${event.payload.error}`,
    );
  }
});

// Clean up when done
unsub();

TypeScript

import { subscribe } from "agents/observability";

const unsub = subscribe("rpc", (event) => {
  if (event.type === "rpc") {
    console.log(`RPC call: ${event.payload.method}`);
  }
  if (event.type === "rpc:error") {
    console.error(
      `RPC failed: ${event.payload.method} — ${event.payload.error}`,
    );
  }
});

// Clean up when done
unsub();

In production, all diagnostics channel messages are automatically forwarded to Tail Workers — no subscription code needed in the agent itself:

JavaScript

export default {
  async tail(events) {
    for (const event of events) {
      for (const msg of event.diagnosticsChannelEvents) {
        // msg.channel is "agents:rpc", "agents:workflow", etc.
        console.log(msg.timestamp, msg.channel, msg.message);
      }
    }
  },
};

TypeScript

export default {
  async tail(events) {
    for (const event of events) {
      for (const msg of event.diagnosticsChannelEvents) {
        // msg.channel is "agents:rpc", "agents:workflow", etc.
        console.log(msg.timestamp, msg.channel, msg.message);
      }
    }
  },
};

The custom Observability override interface is still supported for users who need to filter or forward events to external services.

For the full event reference, refer to the Observability documentation.

`keepAlive()` and `keepAliveWhile()`

Durable Objects are evicted after a period of inactivity (typically 70-140 seconds with no incoming requests, WebSocket messages, or alarms). During long-running operations — streaming LLM responses, waiting on external APIs, running multi-step computations — the agent can be evicted mid-flight.

keepAlive() prevents this by creating a 30-second heartbeat schedule. The alarm firing resets the inactivity timer. Returns a disposer function that cancels the heartbeat when called.

JavaScript

const dispose = await this.keepAlive();
try {
  const result = await longRunningComputation();
  await sendResults(result);
} finally {
  dispose();
}

TypeScript

const dispose = await this.keepAlive();
try {
  const result = await longRunningComputation();
  await sendResults(result);
} finally {
  dispose();
}

keepAliveWhile() wraps an async function with automatic cleanup — the heartbeat starts before the function runs and stops when it completes:

JavaScript

const result = await this.keepAliveWhile(async () => {
  const data = await longRunningComputation();
  return data;
});

TypeScript

const result = await this.keepAliveWhile(async () => {
  const data = await longRunningComputation();
  return data;
});

Key details:

Multiple concurrent callers — Each keepAlive() call returns an independent disposer. Disposing one does not affect others.
AIChatAgent built-in — AIChatAgent automatically calls keepAlive() during streaming responses. You do not need to add it yourself.
Uses the scheduling system — The heartbeat does not conflict with your own schedules. It shows up in getSchedules() if you need to inspect it.

For the full API reference and when-to-use guidance, refer to Schedule tasks — Keeping the agent alive.

`waitForMcpConnections`

AIChatAgent now waits for MCP server connections to settle before calling onChatMessage. This ensures this.mcp.getAITools() returns the full set of tools, especially after Durable Object hibernation when connections are being restored in the background.

JavaScript

export class ChatAgent extends AIChatAgent {
  // Default — waits up to 10 seconds
  // waitForMcpConnections = { timeout: 10_000 };

  // Wait forever
  waitForMcpConnections = true;

  // Disable waiting
  waitForMcpConnections = false;
}

TypeScript

export class ChatAgent extends AIChatAgent {
  // Default — waits up to 10 seconds
  // waitForMcpConnections = { timeout: 10_000 };

  // Wait forever
  waitForMcpConnections = true;

  // Disable waiting
  waitForMcpConnections = false;
}

Value	Behavior
`{ timeout: 10_000 }`	Wait up to 10 seconds (default)
`{ timeout: N }`	Wait up to `N` milliseconds
`true`	Wait indefinitely until all connections ready
`false`	Do not wait (old behavior before 0.2.0)

For lower-level control, call this.mcp.waitForConnections() directly inside onChatMessage instead.

Other improvements

MCP deduplication by name and URL — addMcpServer with HTTP transport now deduplicates on both server name and URL. Calling it with the same name but a different URL creates a new connection. URLs are normalized before comparison (trailing slashes, default ports, hostname case).
callbackHost optional for non-OAuth servers — addMcpServer no longer requires callbackHost when connecting to MCP servers that do not use OAuth.
MCP URL security — Server URLs are validated before connection to prevent SSRF. Private IP ranges, loopback addresses, link-local addresses, and cloud metadata endpoints are blocked.
Custom denial messages — addToolOutput now supports state: "output-error" with errorText for custom denial messages in human-in-the-loop tool approval flows.
requestId in chat options — onChatMessage options now include a requestId for logging and correlating events.

Upgrade

To update to the latest version:

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

Agents, Workers - Agents SDK v0.6.0: RPC transport for MCP, optional OAuth, hardened schema conversion, and @cloudflare/ai-chat fixes

Wed, 25 Feb 2026 00:00:00 GMT

The latest release of the Agents SDK lets you define an Agent and an McpAgent in the same Worker and connect them over RPC — no HTTP, no network overhead. It also makes OAuth opt-in for simple MCP connections, hardens the schema converter for production workloads, and ships a batch of @cloudflare/ai-chat reliability fixes.

RPC transport for MCP

You can now connect an Agent to an McpAgent in the same Worker using a Durable Object binding instead of an HTTP URL. The connection stays entirely within the Cloudflare runtime — no network round-trips, no serialization overhead.

Pass the Durable Object namespace directly to addMcpServer:

JavaScript

import { Agent } from "agents";

export class MyAgent extends Agent {
  async onStart() {
    // Connect via DO binding — no HTTP, no network overhead
    await this.addMcpServer("counter", env.MY_MCP);

    // With props for per-user context
    await this.addMcpServer("counter", env.MY_MCP, {
      props: { userId: "user-123", role: "admin" },
    });
  }
}

TypeScript

import { Agent } from "agents";

export class MyAgent extends Agent {
  async onStart() {
    // Connect via DO binding — no HTTP, no network overhead
    await this.addMcpServer("counter", env.MY_MCP);

    // With props for per-user context
    await this.addMcpServer("counter", env.MY_MCP, {
      props: { userId: "user-123", role: "admin" },
    });
  }
}

The addMcpServer method now accepts string | DurableObjectNamespace as the second parameter with full TypeScript overloads, so HTTP and RPC paths are type-safe and cannot be mixed.

Key capabilities:

Hibernation support — RPC connections survive Durable Object hibernation automatically. The binding name and props are persisted to storage and restored on wake-up, matching the behavior of HTTP MCP connections.
Deduplication — Calling addMcpServer with the same server name returns the existing connection instead of creating duplicates. Connection IDs are stable across hibernation restore.
Smaller surface area — The RPC transport internals have been rewritten and reduced from 609 lines to 245 lines. RPCServerTransport now uses JSONRPCMessageSchema from the MCP SDK for validation instead of hand-written checks.

Optional OAuth for MCP connections

addMcpServer() no longer eagerly creates an OAuth provider for every connection. For servers that do not require authentication, a simple call is all you need:

JavaScript

// No callbackHost, no OAuth config — just works
await this.addMcpServer("my-server", "https://mcp.example.com");

TypeScript

// No callbackHost, no OAuth config — just works
await this.addMcpServer("my-server", "https://mcp.example.com");

If the server responds with a 401, the SDK throws a clear error: "This MCP server requires OAuth authentication. Provide callbackHost in addMcpServer options to enable the OAuth flow." The restore-from-storage flow also handles missing callback URLs gracefully, skipping auth provider creation for non-OAuth servers.

Hardened JSON Schema to TypeScript converter

The schema converter used by generateTypes() and getAITools() now handles edge cases that previously caused crashes in production:

Depth and circular reference guards — Prevents stack overflows on recursive or deeply nested schemas
$ref resolution — Supports internal JSON Pointers (#/definitions/..., #/$defs/..., #)
Tuple support — prefixItems (JSON Schema 2020-12) and array items (draft-07)
OpenAPI 3.0 nullable: true — Supported across all schema branches
Per-tool error isolation — One malformed schema cannot crash the full pipeline in generateTypes() or getAITools()
Missing inputSchema fallback — getAITools() falls back to { type: "object" } instead of throwing

`@cloudflare/ai-chat` fixes

Tool denial flow — Denied tool approvals (approved: false) now transition to output-denied with a tool_result, fixing Anthropic provider compatibility. Custom denial messages are supported via state: "output-error" and errorText.
Abort/cancel support — Streaming responses now properly cancel the reader loop when the abort signal fires and send a done signal to the client.
Duplicate message persistence — persistMessages() now reconciles assistant messages by content and order, preventing duplicate rows when clients resend full history.
requestId in OnChatMessageOptions — Handlers can now send properly-tagged error responses for pre-stream failures.
redacted_thinking preservation — The message sanitizer no longer strips Anthropic redacted_thinking blocks.
/get-messages reliability — Endpoint handling moved from a prototype onRequest() override to a constructor wrapper, so it works even when users override onRequest without calling super.onRequest().
Client tool APIs undeprecated — createToolsFromClientSchemas, clientTools, AITool, extractClientToolSchemas, and the tools option on useAgentChat are restored for SDK use cases where tools are defined dynamically at runtime.
jsonSchema initialization — Fixed jsonSchema not initialized error when calling getAITools() in onChatMessage.

Upgrade

To update to the latest version:

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

Workers - Better Windows support for Python Workers

Wed, 25 Feb 2026 00:00:00 GMT

Pywrangler, the CLI tool for managing Python Workers and packages, now supports Windows, allowing you to develop and deploy Python Workers from Windows environments. Previously, Pywrangler was only available on macOS and Linux.

You can install and use Pywrangler on Windows the same way you would on other platforms. Specify your Worker's Python dependencies in your pyproject.toml file, then use the following commands to develop and deploy:

uvx --from workers-py pywrangler dev
uvx --from workers-py pywrangler deploy

All existing Pywrangler functionality, including package management, local development, and deployment, works on Windows without any additional configuration.

Requirements

This feature requires the following minimum versions:

wrangler >= 4.64.0
workers-py >= 1.72.0
uv >= 0.29.8

To upgrade workers-py (which includes Pywrangler) in your project, run:

uv tool upgrade workers-py

To upgrade wrangler, run:

npm install -g wrangler@latest

To upgrade uv, run:

uv self update

To get started with Python Workers on Windows, refer to the Python packages documentation for full details on Pywrangler.

Workers - Write structured queries to filter and search your Workers logs and traces

Wed, 25 Feb 2026 00:00:00 GMT

Workers Observability now includes a query language that lets you write structured queries directly in the search bar to filter your logs and traces. The search bar doubles as a free text search box — type any term to search across all metadata and attributes, or write field-level queries for precise filtering.

Queries written in the search bar sync with the Query Builder sidebar, so you can write a query by hand and then refine it visually, or build filters in the Query Builder and see the corresponding query syntax. The search bar provides autocomplete suggestions for metadata fields and operators as you type.

The query language supports:

Free text search — search everywhere with a keyword like error, or match an exact phrase with "exact phrase"
Field queries — filter by specific fields using comparison operators (for example, status = 500 or $workers.wallTimeMs > 100)
Operators — =, !=, >, >=, <, <=, and : (contains)
Functions — contains(field, value), startsWith(field, prefix), regex(field, pattern), and exists(field)
Boolean logic — add conditions with AND, OR, and NOT

Select the help icon next to the search bar to view the full syntax reference, including all supported operators, functions, and keyboard shortcuts.

Go to the Workers Observability dashboard to try the query language.

Workers - No config? No problem. Just `wrangler deploy`

Wed, 25 Feb 2026 00:00:00 GMT

You can now deploy any existing project to Cloudflare Workers — even without a Wrangler configuration file — and wrangler deploy will just work.

Starting with Wrangler 4.68.0, running wrangler deploy automatically configures your project by detecting your framework, installing required adapters, and deploying it to Cloudflare Workers.

Using Wrangler locally

npx wrangler deploy

When you run wrangler deploy in a project without a configuration file, Wrangler:

Detects your framework from package.json
Prompts you to confirm the detected settings
Installs any required adapters
Generates a wrangler.jsonc configuration file
Deploys your project to Cloudflare Workers

You can also use wrangler setup to configure without deploying, or pass --yes to skip prompts.

Using the Cloudflare dashboard

When you connect a repository through the Workers dashboard, a pull request is generated for you with all necessary files, and a preview deployment to check before merging.

Background

In December 2025, we introduced automatic configuration as an experimental feature. It is now generally available and the default behavior.

If you have questions or run into issues, join the GitHub discussion.

Durable Objects, Workers - deleteAll() now deletes Durable Object alarm

Tue, 24 Feb 2026 00:00:00 GMT

deleteAll() now deletes a Durable Object alarm in addition to stored data for Workers with a compatibility date of 2026-02-24 or later. This change simplifies clearing a Durable Object's storage with a single API call.

Previously, deleteAll() only deleted user-stored data for an object. Alarm usage stores metadata in an object's storage, which required a separate deleteAlarm() call to fully clean up all storage for an object. The deleteAll() change applies to both KV-backed and SQLite-backed Durable Objects.

// Before: two API calls required to clear all storage
await this.ctx.storage.deleteAlarm();
await this.ctx.storage.deleteAll();

// Now: a single call clears both data and the alarm
await this.ctx.storage.deleteAll();

For more information, refer to the Storage API documentation.

Pipelines, Workers - Dropped event metrics, typed Pipelines bindings, and improved setup

Tue, 24 Feb 2026 00:00:00 GMT

Cloudflare Pipelines ingests streaming data via Workers or HTTP endpoints, transforms it with SQL, and writes it to R2 as Apache Iceberg tables. Today we're shipping three improvements to help you understand why streaming events get dropped, catch data quality issues early, and set up Pipelines faster.

Dropped event metrics

When stream events don't match the expected schema, Pipelines accepts them during ingestion but drops them when attempting to deliver them to the sink. To help you identify the root cause of these issues, we are introducing a new dashboard and metrics that surface dropped events with detailed error messages.

Dropped events can also be queried programmatically via the new pipelinesUserErrorsAdaptiveGroups GraphQL dataset. The dataset breaks down failures by specific error type (missing_field, type_mismatch, parse_failure, or null_value) so you can trace issues back to the source.

query GetPipelineUserErrors(
  $accountTag: String!
  $pipelineId: String!
  $datetimeStart: Time!
  $datetimeEnd: Time!
) {
  viewer {
    accounts(filter: { accountTag: $accountTag }) {
      pipelinesUserErrorsAdaptiveGroups(
        limit: 100
        filter: {
          pipelineId: $pipelineId
          datetime_geq: $datetimeStart
          datetime_leq: $datetimeEnd
        }
        orderBy: [count_DESC]
      ) {
        count
        dimensions {
          errorFamily
          errorType
        }
      }
    }
  }
}

For the full list of dimensions, error types, and additional query examples, refer to User error metrics.

Typed Pipelines bindings

Sending data to a Pipeline from a Worker previously used a generic Pipeline<PipelineRecord> type, which meant schema mismatches (wrong field names, incorrect types) were only caught at runtime as dropped events.

Running wrangler types now generates schema-specific TypeScript types for your Pipeline bindings. TypeScript catches missing required fields and incorrect field types at compile time, before your code is deployed.

declare namespace Cloudflare {
  type EcommerceStreamRecord = {
    user_id: string;
    event_type: string;
    product_id?: string;
    amount?: number;
  };
  interface Env {
    STREAM: import("cloudflare:pipelines").Pipeline<Cloudflare.EcommerceStreamRecord>;
  }
}

For more information, refer to Typed Pipeline bindings.

Improved Pipelines setup

Setting up a new Pipeline previously required multiple manual steps: creating an R2 bucket, enabling R2 Data Catalog, generating an API token, and configuring format, compression, and rolling policies individually.

The wrangler pipelines setup command now offers a Simple setup mode that applies recommended defaults and automatically creates the R2 bucket and enables R2 Data Catalog if they do not already exist. Validation errors during setup prompt you to retry inline rather than restarting the entire process.

For a full walkthrough, refer to the Getting started guide.

Agents, Workers - @cloudflare/codemode v0.1.0: a new runtime agnostic modular architecture

Fri, 20 Feb 2026 00:00:00 GMT

The @cloudflare/codemode package has been rewritten into a modular, runtime-agnostic SDK.

Code Mode enables LLMs to write and execute code that orchestrates your tools, instead of calling them one at a time. This can (and does) yield significant token savings, reduces context window pressure and improves overall model performance on a task.

The new Executor interface is runtime agnostic and comes with a prebuilt DynamicWorkerExecutor to run generated code in a Dynamic Worker Loader.

Breaking changes

Removed experimental_codemode() and CodeModeProxy — the package no longer owns an LLM call or model choice
New import path: createCodeTool() is now exported from @cloudflare/codemode/ai

New features

createCodeTool() — Returns a standard AI SDK Tool to use in your AI agents.
Executor interface — Minimal execute(code, fns) contract. Implement for any code sandboxing primitive or runtime.

`DynamicWorkerExecutor`

Runs code in a Dynamic Worker. It comes with the following features:

Network isolation — fetch() and connect() blocked by default (globalOutbound: null) when using DynamicWorkerExecutor
Console capture — console.log/warn/error captured and returned in ExecuteResult.logs
Execution timeout — Configurable via timeout option (default 30s)

Usage

JavaScript

import { createCodeTool } from "@cloudflare/codemode/ai";
import { DynamicWorkerExecutor } from "@cloudflare/codemode";
import { streamText } from "ai";

const executor = new DynamicWorkerExecutor({ loader: env.LOADER });
const codemode = createCodeTool({ tools: myTools, executor });

const result = streamText({
  model,
  tools: { codemode },
  messages,
});

TypeScript

import { createCodeTool } from "@cloudflare/codemode/ai";
import { DynamicWorkerExecutor } from "@cloudflare/codemode";
import { streamText } from "ai";

const executor = new DynamicWorkerExecutor({ loader: env.LOADER });
const codemode = createCodeTool({ tools: myTools, executor });

const result = streamText({
  model,
  tools: { codemode },
  messages,
});

Wrangler configuration

wrangler.jsonc

{
  "worker_loaders": [{ "binding": "LOADER" }],
}

wrangler.toml
```
[[worker_loaders]]
binding = "LOADER"
```

See the Code Mode documentation for full API reference and examples.

Upgrade

npm i @cloudflare/codemode@latest

Agents, Workers - Agents SDK v0.5.0: Protocol message control, retry utilities, data parts, and @cloudflare/ai-chat v0.1.0

Tue, 17 Feb 2026 00:00:00 GMT

The latest release of the Agents SDK adds built-in retry utilities, per-connection protocol message control, and a fully rewritten @cloudflare/ai-chat with data parts, tool approval persistence, and zero breaking changes.

Retry utilities

A new this.retry() method lets you retry any async operation with exponential backoff and jitter. You can pass an optional shouldRetry predicate to bail early on non-retryable errors.

JavaScript

class MyAgent extends Agent {
  async onRequest(request) {
    const data = await this.retry(() => callUnreliableService(), {
      maxAttempts: 4,
      shouldRetry: (err) => !(err instanceof PermanentError),
    });
    return Response.json(data);
  }
}

TypeScript

class MyAgent extends Agent {
  async onRequest(request: Request) {
    const data = await this.retry(() => callUnreliableService(), {
      maxAttempts: 4,
      shouldRetry: (err) => !(err instanceof PermanentError),
    });
    return Response.json(data);
  }
}

Retry options are also available per-task on queue(), schedule(), scheduleEvery(), and addMcpServer():

JavaScript

// Per-task retry configuration, persisted in SQLite alongside the task
await this.schedule(
  Date.now() + 60_000,
  "sendReport",
  { userId: "abc" },
  {
    retry: { maxAttempts: 5 },
  },
);

// Class-level retry defaults
class MyAgent extends Agent {
  static options = {
    retry: { maxAttempts: 3 },
  };
}

TypeScript

// Per-task retry configuration, persisted in SQLite alongside the task
await this.schedule(Date.now() + 60_000, "sendReport", { userId: "abc" }, {
  retry: { maxAttempts: 5 },
});

// Class-level retry defaults
class MyAgent extends Agent {
  static options = {
    retry: { maxAttempts: 3 },
  };
}

Retry options are validated eagerly at enqueue/schedule time, and invalid values throw immediately. Internal retries have also been added for workflow operations (terminateWorkflow, pauseWorkflow, and others) with Durable Object-aware error detection.

Per-connection protocol message control

Agents automatically send JSON text frames (identity, state, MCP server lists) to every WebSocket connection. You can now suppress these per-connection for clients that cannot handle them — binary-only devices, MQTT clients, or lightweight embedded systems.

JavaScript

class MyAgent extends Agent {
  shouldSendProtocolMessages(connection, ctx) {
    // Suppress protocol messages for MQTT clients
    const subprotocol = ctx.request.headers.get("Sec-WebSocket-Protocol");
    return subprotocol !== "mqtt";
  }
}

TypeScript

class MyAgent extends Agent {
  shouldSendProtocolMessages(connection: Connection, ctx: ConnectionContext) {
    // Suppress protocol messages for MQTT clients
    const subprotocol = ctx.request.headers.get("Sec-WebSocket-Protocol");
    return subprotocol !== "mqtt";
  }
}

Connections with protocol messages disabled still fully participate in RPC and regular messaging. Use isConnectionProtocolEnabled(connection) to check a connection's status at any time. The flag persists across Durable Object hibernation.

See Protocol messages for full documentation.

`@cloudflare/ai-chat` v0.1.0

The first stable release of @cloudflare/ai-chat ships alongside this release with a major refactor of AIChatAgent internals — new ResumableStream class, WebSocket ChatTransport, and simplified SSE parsing — with zero breaking changes. Existing code using AIChatAgent and useAgentChat works as-is.

Key new features:

Data parts — Attach typed JSON blobs (data-*) to messages alongside text. Supports reconciliation (type+id updates in-place), append, and transient parts (ephemeral via onData callback). See Data parts.
Tool approval persistence — The needsApproval approval UI now survives page refresh and DO hibernation. The streaming message is persisted to SQLite when a tool enters approval-requested state.
maxPersistedMessages — Cap SQLite message storage with automatic oldest-message deletion.
body option on useAgentChat — Send custom data with every request (static or dynamic).
Incremental persistence — Hash-based cache to skip redundant SQL writes.
Row size guard — Automatic two-pass compaction when messages approach the SQLite 2 MB limit.
autoContinueAfterToolResult defaults to true — Client-side tool results and tool approvals now automatically trigger a server continuation, matching server-executed tool behavior. Set autoContinueAfterToolResult: false in useAgentChat to restore the previous behavior.

Notable bug fixes:

Resolved stream resumption race conditions
Resolved an issue where setMessages functional updater sent empty arrays
Resolved an issue where client tool schemas were lost after DO hibernation
Resolved InvalidPromptError after tool approval (approval.id was dropped)
Resolved an issue where message metadata was not propagated on broadcast/resume paths
Resolved an issue where clearAll() did not clear in-memory chunk buffers
Resolved an issue where reasoning-delta silently dropped data when reasoning-start was missed during stream resumption

Synchronous queue and schedule getters

getQueue(), getQueues(), getSchedule(), dequeue(), dequeueAll(), and dequeueAllByCallback() were unnecessarily async despite only performing synchronous SQL operations. They now return values directly instead of wrapping them in Promises. This is backward compatible — existing code using await on these methods will continue to work.

Other improvements

Fix TypeScript "excessively deep" error — A depth counter on CanSerialize and IsSerializableParam types bails out to true after 10 levels of recursion, preventing the "Type instantiation is excessively deep" error with deeply nested types like AI SDK CoreMessage[].
POST SSE keepalive — The POST SSE handler now sends event: ping every 30 seconds to keep the connection alive, matching the existing GET SSE handler behavior. This prevents POST response streams from being silently dropped by proxies during long-running tool calls.
Widened peer dependency ranges — Peer dependency ranges across packages have been widened to prevent cascading major bumps during 0.x minor releases. @cloudflare/ai-chat and @cloudflare/codemode are now marked as optional peer dependencies.

Upgrade

To update to the latest version:

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

Workers - Quick Editor devtools replaced with log viewer

Mon, 16 Feb 2026 00:00:00 GMT

Cloudflare has deprecated the Workers Quick Editor dev tools inspector and replaced it with a lightweight log viewer.

This aligns our logging with wrangler tail and gives us the opportunity to focus our efforts on bringing benefits from the work we have invested in observability, which would not be possible otherwise.

We have made improvements to this logging viewer based on your feedback such that you can log object and array types, and easily clear the list of logs. This does not include class instances. Limitations are documented in the Workers Playground docs.

If you do need to develop your Worker with a remote inspector, you can still do this using Wrangler locally. Cloning a project from your quick editor to your computer for local development can be done with the wrangler init --from-dash command. For more information, refer to Wrangler commands.

Workers - New Best Practices guide for Workers

Sun, 15 Feb 2026 00:00:00 GMT

A new Workers Best Practices guide provides opinionated recommendations for building fast, reliable, observable, and secure Workers. The guide draws on production patterns, Cloudflare internal usage, and best practices observed from developers building on Workers.

Key guidance includes:

Keep your compatibility date current and enable nodejs_compat — Ensure you have access to the latest runtime features and Node.js built-in modules.

wrangler.jsonc

{
  "name": "my-worker",
  "main": "src/index.ts",
  // Set this to today's date
  "compatibility_date": "2026-04-03",
  "compatibility_flags": ["nodejs_compat"],
}

wrangler.toml

name = "my-worker"
main = "src/index.ts"
# Set this to today's date
compatibility_date = "2026-04-03"
compatibility_flags = [ "nodejs_compat" ]

Generate binding types with wrangler types — Never hand-write your Env interface. Let Wrangler generate it from your actual configuration to catch mismatches at compile time.
Stream request and response bodies — Avoid buffering large payloads in memory. Use TransformStream and pipeTo to stay within the 128 MB memory limit and improve time-to-first-byte.
Use bindings, not REST APIs — Bindings to KV, R2, D1, Queues, and other Cloudflare services are direct, in-process references with no network hop and no authentication overhead.
Use Queues and Workflows for background work — Move long-running or retriable tasks out of the critical request path. Use Queues for simple fan-out and buffering, and Workflows for multi-step durable processes.
Enable Workers Logs and Traces — Configure observability before deploying to production so you have data when you need to debug.
Avoid global mutable state — Workers reuse isolates across requests. Storing request-scoped data in module-level variables causes cross-request data leaks.
Always await or waitUntil your Promises — Floating promises cause silent bugs and dropped work.
Use Web Crypto for secure token generation — Never use Math.random() for security-sensitive operations.

To learn more, refer to Workers Best Practices.

Workers, Agents, Workers AI - Introducing GLM-4.7-Flash on Workers AI, @cloudflare/tanstack-ai, and workers-ai-provider v3.1.1

Fri, 13 Feb 2026 00:00:00 GMT

We're excited to announce GLM-4.7-Flash on Workers AI, a fast and efficient text generation model optimized for multilingual dialogue and instruction-following tasks, along with the brand-new @cloudflare/tanstack-ai package and workers-ai-provider v3.1.1.

You can now run AI agents entirely on Cloudflare. With GLM-4.7-Flash's multi-turn tool calling support, plus full compatibility with TanStack AI and the Vercel AI SDK, you have everything you need to build agentic applications that run completely at the edge.

GLM-4.7-Flash — Multilingual Text Generation Model

@cf/zai-org/glm-4.7-flash is a multilingual model with a 131,072 token context window, making it ideal for long-form content generation, complex reasoning tasks, and multilingual applications.

Key Features and Use Cases:

Multi-turn Tool Calling for Agents: Build AI agents that can call functions and tools across multiple conversation turns
Multilingual Support: Built to handle content generation in multiple languages effectively
Large Context Window: 131,072 tokens for long-form writing, complex reasoning, and processing long documents
Fast Inference: Optimized for low-latency responses in chatbots and virtual assistants
Instruction Following: Excellent at following complex instructions for code generation and structured tasks

Use GLM-4.7-Flash through the Workers AI binding (env.AI.run()), the REST API at /run or /v1/chat/completions, AI Gateway, or via workers-ai-provider for the Vercel AI SDK.

Pricing is available on the model page or pricing page.

@cloudflare/tanstack-ai v0.1.1 — TanStack AI adapters for Workers AI and AI Gateway

We've released @cloudflare/tanstack-ai, a new package that brings Workers AI and AI Gateway support to TanStack AI. This provides a framework-agnostic alternative for developers who prefer TanStack's approach to building AI applications.

Workers AI adapters support four configuration modes — plain binding (env.AI), plain REST, AI Gateway binding (env.AI.gateway(id)), and AI Gateway REST — across all capabilities:

Chat (createWorkersAiChat) — Streaming chat completions with tool calling, structured output, and reasoning text streaming.
Image generation (createWorkersAiImage) — Text-to-image models.
Transcription (createWorkersAiTranscription) — Speech-to-text.
Text-to-speech (createWorkersAiTts) — Audio generation.
Summarization (createWorkersAiSummarize) — Text summarization.

AI Gateway adapters route requests from third-party providers — OpenAI, Anthropic, Gemini, Grok, and OpenRouter — through Cloudflare AI Gateway for caching, rate limiting, and unified billing.

To get started:

npm install @cloudflare/tanstack-ai @tanstack/ai

workers-ai-provider v3.1.1 — transcription, speech, reranking, and reliability

The Workers AI provider for the Vercel AI SDK now supports three new capabilities beyond chat and image generation:

Transcription (provider.transcription(model)) — Speech-to-text with automatic handling of model-specific input formats across binding and REST paths.
Text-to-speech (provider.speech(model)) — Audio generation with support for voice and speed options.
Reranking (provider.reranking(model)) — Document reranking for RAG pipelines and search result ordering.

import { createWorkersAI } from "workers-ai-provider";
import {
  experimental_transcribe,
  experimental_generateSpeech,
  rerank,
} from "ai";

const workersai = createWorkersAI({ binding: env.AI });

const transcript = await experimental_transcribe({
  model: workersai.transcription("@cf/openai/whisper-large-v3-turbo"),
  audio: audioData,
  mediaType: "audio/wav",
});

const speech = await experimental_generateSpeech({
  model: workersai.speech("@cf/deepgram/aura-1"),
  text: "Hello world",
  voice: "asteria",
});

const ranked = await rerank({
  model: workersai.reranking("@cf/baai/bge-reranker-base"),
  query: "What is machine learning?",
  documents: ["ML is a branch of AI.", "The weather is sunny."],
});

This release also includes a comprehensive reliability overhaul (v3.0.5):

Fixed streaming — Responses now stream token-by-token instead of buffering all chunks, using a proper TransformStream pipeline with backpressure.
Fixed tool calling — Resolved issues with tool call ID sanitization, conversation history preservation, and a heuristic that silently fell back to non-streaming mode when tools were defined.
Premature stream termination detection — Streams that end unexpectedly now report finishReason: "error" instead of silently reporting "stop".
AI Search support — Added createAISearch as the canonical export (renamed from AutoRAG). createAutoRAG still works with a deprecation warning.

To upgrade:

npm install workers-ai-provider@latest ai

Resources

Workers - Workers are no longer limited to 1000 subrequests

Wed, 11 Feb 2026 00:00:00 GMT

Workers no longer have a limit of 1000 subrequests per invocation, allowing you to make more fetch() calls or requests to Cloudflare services on every incoming request. This is especially important for long-running Workers requests, such as open websockets on Durable Objects or long-running Workflows, as these could often exceed this limit and error.

By default, Workers on paid plans are now limited to 10,000 subrequests per invocation, but this limit can be increased up to 10 million by setting the new subrequests limit in your Wrangler configuration file.

wrangler.jsonc

{
  "limits": {
    "subrequests": 50000,
  },
}

wrangler.toml
```
[limits]
subrequests = 50_000
```

Workers on the free plan remain limited to 50 external subrequests and 1000 subrequests to Cloudflare services per invocation.

To protect against runaway code or unexpected costs, you can also set a lower limit for both subrequests and CPU usage.

wrangler.jsonc

{
  "limits": {
    "subrequests": 10,
    "cpu_ms": 1000,
  },
}

wrangler.toml
```
[limits]
subrequests = 10
cpu_ms = 1_000
```

For more information, refer to the Wrangler configuration documentation for limits and subrequest limits.

Workers - Improved React Server Components support in the Cloudflare Vite plugin

Wed, 11 Feb 2026 00:00:00 GMT

The Cloudflare Vite plugin now integrates seamlessly @vitejs/plugin-rsc, the official Vite plugin for React Server Components.

A childEnvironments option has been added to the plugin config to enable using multiple environments within a single Worker. The parent environment can then import modules from a child environment in order to access a separate module graph. For a typical RSC use case, the plugin might be configured as in the following example:

export default defineConfig({
  plugins: [
    cloudflare({
      viteEnvironment: {
        name: "rsc",
        childEnvironments: ["ssr"],
      },
    }),
  ],
});

@vitejs/plugin-rsc provides the lower level functionality that frameworks, such as React Router, build upon. The GitHub repository includes a basic Cloudflare example.

Agents, Workers - Agents SDK v0.4.0: Readonly connections, MCP security improvements, x402 v2 migration, and custom MCP OAuth providers

Mon, 09 Feb 2026 00:00:00 GMT

The latest release of the Agents SDK brings readonly connections, MCP protocol and security improvements, x402 payment protocol v2 migration, and the ability to customize OAuth for MCP server connections.

Readonly connections

Agents can now restrict WebSocket clients to read-only access, preventing them from modifying agent state. This is useful for dashboards, spectator views, or any scenario where clients should observe but not mutate.

New hooks: shouldConnectionBeReadonly, setConnectionReadonly, isConnectionReadonly. Readonly connections block both client-side setState() and mutating @callable() methods, and the readonly flag survives hibernation.

JavaScript

class MyAgent extends Agent {
  shouldConnectionBeReadonly(connection) {
    // Make spectators readonly
    return connection.url.includes("spectator");
  }
}

TypeScript

class MyAgent extends Agent {
  shouldConnectionBeReadonly(connection) {
    // Make spectators readonly
    return connection.url.includes("spectator");
  }
}

Custom MCP OAuth providers

The new createMcpOAuthProvider method on the Agent class allows subclasses to override the default OAuth provider used when connecting to MCP servers. This enables custom authentication strategies such as pre-registered client credentials or mTLS, beyond the built-in dynamic client registration.

JavaScript

class MyAgent extends Agent {
  createMcpOAuthProvider(callbackUrl) {
    return new MyCustomOAuthProvider(this.ctx.storage, this.name, callbackUrl);
  }
}

TypeScript

class MyAgent extends Agent {
  createMcpOAuthProvider(callbackUrl: string): AgentMcpOAuthProvider {
    return new MyCustomOAuthProvider(this.ctx.storage, this.name, callbackUrl);
  }
}

MCP SDK upgrade to 1.26.0

Upgraded the MCP SDK to 1.26.0 to prevent cross-client response leakage. Stateless MCP Servers should now create a new McpServer instance per request instead of sharing a single instance. A guard is added in this version of the MCP SDK which will prevent connection to a Server instance that has already been connected to a transport. Developers will need to modify their code if they declare their McpServer instance as a global variable.

MCP OAuth callback URL security fix

Added callbackPath option to addMcpServer to prevent instance name leakage in MCP OAuth callback URLs. When sendIdentityOnConnect is false, callbackPath is now required — the default callback URL would expose the instance name, undermining the security intent. Also fixes callback request detection to match via the state parameter instead of a loose /callback URL substring check, enabling custom callback paths.

Deprecate `onStateUpdate` in favor of `onStateChanged`

onStateChanged is a drop-in rename of onStateUpdate (same signature, same behavior). onStateUpdate still works but emits a one-time console warning per class. validateStateChange rejections now propagate a CF_AGENT_STATE_ERROR message back to the client.

x402 v2 migration

Migrated the x402 MCP payment integration from the legacy x402 package to @x402/core and @x402/evm v2.

Breaking changes for x402 users:

Peer dependencies changed: replace x402 with @x402/core and @x402/evm
PaymentRequirements type now uses v2 fields (e.g. amount instead of maxAmountRequired)
X402ClientConfig.account type changed from viem.Account to ClientEvmSigner (structurally compatible with privateKeyToAccount())

npm uninstall x402
npm install @x402/core @x402/evm

Network identifiers now accept both legacy names and CAIP-2 format:

// Legacy name (auto-converted)
{
  network: "base-sepolia",
}

// CAIP-2 format (preferred)
{
  network: "eip155:84532",
}

Other x402 changes:

X402ClientConfig.network is now optional — the client auto-selects from available payment requirements
Server-side lazy initialization: facilitator connection is deferred until the first paid tool invocation
Payment tokens support both v2 (PAYMENT-SIGNATURE) and v1 (X-PAYMENT) HTTP headers
Added normalizeNetwork export for converting legacy network names to CAIP-2 format
Re-exports PaymentRequirements, PaymentRequired, Network, FacilitatorConfig, and ClientEvmSigner from agents/x402

Other improvements

Fix useAgent and AgentClient crashing when using basePath routing
CORS handling delegated to partyserver's native support (simpler, more reliable)
Client-side onStateUpdateError callback for handling rejected state updates

Upgrade

To update to the latest version:

npm i agents@latest

Workers - Visualize data, share links, and create exports with the new Workers Observability dashboard

Fri, 06 Feb 2026 00:00:00 GMT

The Workers Observability dashboard has some major updates to make it easier to debug your application's issues and share findings with your team.

You can now:

Create visualizations — Build charts from your Worker data directly in a Worker's Observability tab
Export data as JSON or CSV — Download logs and traces for offline analysis or to share with teammates
Share events and traces — Generate direct URLs to specific events, invocations, and traces that open standalone pages with full context
Customize table columns — Improved field picker to add, remove, and reorder columns in the events table
Expandable event details — Expand events inline to view full details without leaving the table
Keyboard shortcuts — Navigate the dashboard with hotkey support

These updates are now live in the Cloudflare dashboard, both in a Worker's Observability tab and in the account-level Observability dashboard for a unified experience. To get started, go to Workers & Pages > select your Worker > Observability.

Workflows, Workers - Visualize your Workflows in the Cloudflare dashboard

Wed, 04 Feb 2026 00:00:00 GMT

Cloudflare Workflows now automatically generates visual diagrams from your code

Your Workflow is parsed to provide a visual map of the Workflow structure, allowing you to:

Understand how steps connect and execute
Visualize loops and nested logic
Follow branching paths for conditional logic

You can collapse loops and nested logic to see the high-level flow, or expand them to see every step.

Workflow diagrams are available in beta for all JavaScript and TypeScript Workflows. Find your Workflows in the Cloudflare dashboard to see their diagrams.

Workers - New Placement Hints for Workers

Thu, 22 Jan 2026 00:00:00 GMT

You can now configure Workers to run close to infrastructure in legacy cloud regions to minimize latency to existing services and databases. This is most useful when your Worker makes multiple round trips.

To set a placement hint, set the placement.region property in your Wrangler configuration file:

wrangler.jsonc

{
  "placement": {
    "region": "aws:us-east-1",
  },
}

wrangler.toml
```
[placement]
region = "aws:us-east-1"
```

Placement hints support Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure region identifiers. Workers run in the Cloudflare data center with the lowest latency to the specified cloud region.

If your existing infrastructure is not in these cloud providers, expose it to placement probes with placement.host for layer 4 checks or placement.hostname for layer 7 checks. These probes are designed to locate single-homed infrastructure and are not suitable for anycasted or multicasted resources.

wrangler.jsonc

{
  "placement": {
    "host": "my_database_host.com:5432",
  },
}

wrangler.toml

[placement]
host = "my_database_host.com:5432"

wrangler.jsonc

{
  "placement": {
    "hostname": "my_api_server.com",
  },
}

wrangler.toml

[placement]
hostname = "my_api_server.com"

This is an extension of Smart Placement, which automatically places your Workers closer to back-end APIs based on measured latency. When you do not know the location of your back-end APIs or have multiple back-end APIs, set mode: "smart":

wrangler.jsonc

{
  "placement": {
    "mode": "smart",
  },
}

wrangler.toml
```
[placement]
mode = "smart"
```

Workers - Use auxiliary Workers alongside full-stack frameworks

Tue, 20 Jan 2026 00:00:00 GMT

Auxiliary Workers are now fully supported when using full-stack frameworks, such as React Router and TanStack Start, that integrate with the Cloudflare Vite plugin. They are included alongside the framework's build output in the build output directory. Note that this feature requires Vite 7 or above.

Auxiliary Workers are additional Workers that can be called via service bindings from your main (entry) Worker. They are defined in the plugin config, as in the example below:

import { defineConfig } from "vite";
import { tanstackStart } from "@tanstack/react-start/plugin/vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
  plugins: [
    tanstackStart(),
    cloudflare({
      viteEnvironment: { name: "ssr" },
      auxiliaryWorkers: [{ configPath: "./wrangler.aux.jsonc" }],
    }),
  ],
});

See the Vite plugin API docs for more info.

Workers - Import SQL files as additional modules by default

Tue, 20 Jan 2026 00:00:00 GMT

The .sql file extension is now automatically configured to be importable in your Worker code when using Wrangler or the Cloudflare Vite plugin. This is particular useful for importing migrations in Durable Objects and means you no longer need to configure custom rules when using Drizzle.

SQL files are imported as JavaScript strings:

// `example` will be a JavaScript string
import example from "./example.sql";

Workers - `wrangler types` now generates types for all environments

Tue, 13 Jan 2026 00:00:00 GMT

The wrangler types command now generates TypeScript types for bindings from all environments defined in your Wrangler configuration file by default.

Previously, wrangler types only generated types for bindings in the top-level configuration (or a single environment when using the --env flag). This meant that if you had environment-specific bindings — for example, a KV namespace only in production or an R2 bucket only in staging — those bindings would be missing from your generated types, causing TypeScript errors when accessing them.

Now, running wrangler types collects bindings from all environments and includes them in the generated Env type. This ensures your types are complete regardless of which environment you deploy to.

Generating types for a specific environment

If you want the previous behavior of generating types for only a specific environment, you can use the --env flag:

wrangler types --env production

Learn more about generating types for your Worker in the Wrangler documentation.

Workers - Validate your generated types with `wrangler types --check`

Mon, 12 Jan 2026 00:00:00 GMT

Wrangler now supports a --check flag for the wrangler types command. This flag validates that your generated types are up to date without writing any changes to disk.

This is useful in CI/CD pipelines where you want to ensure that developers have regenerated their types after making changes to their Wrangler configuration. If the types are out of date, the command will exit with a non-zero status code.

npx wrangler types --check

If your types are up to date, the command will succeed silently. If they are out of date, you'll see an error message indicating which files need to be regenerated.

For more information, see the Wrangler types documentation.

Workers, Queues - Get notified when your Workers builds succeed or fail

Fri, 09 Jan 2026 00:00:00 GMT

You can now receive notifications when your Workers' builds start, succeed, fail, or get cancelled using Event Subscriptions.

Workers Builds publishes events to a Queue that your Worker can read messages from, and then send notifications wherever you need — Slack, Discord, email, or any webhook endpoint.

You can deploy this Worker to your own Cloudflare account to send build notifications to Slack:

The template includes:

Build status with Preview/Live URLs for successful deployments
Inline error messages for failed builds
Branch, commit hash, and author name

For setup instructions, refer to the template README or the Event Subscriptions documentation.

Workers - Shell tab completions for Wrangler CLI

Fri, 09 Jan 2026 00:00:00 GMT

Wrangler now includes built-in shell tab completion support, making it faster and easier to navigate commands without memorizing every option. Press Tab as you type to autocomplete commands, subcommands, flags, and even option values like log levels.

Tab completions are supported for Bash, Zsh, Fish, and PowerShell.

Setup

Generate the completion script for your shell and add it to your configuration file:

# Bash
wrangler complete bash >> ~/.bashrc

# Zsh
wrangler complete zsh >> ~/.zshrc

# Fish
wrangler complete fish >> ~/.config/fish/config.fish

# PowerShell
wrangler complete powershell >> $PROFILE

After adding the script, restart your terminal or source your configuration file for the changes to take effect. Then you can simply press Tab to see available completions:

wrangler d<TAB>          # completes to 'deploy', 'dev', 'd1', etc.
wrangler kv <TAB>        # shows subcommands: namespace, key, bulk

Tab completions are dynamically generated from Wrangler's command registry, so they stay up-to-date as new commands and options are added. This feature is powered by @bomb.sh/tab.

See the wrangler complete documentation for more details.

Workers Analytics Engine, Workers - Workers Analytics Engine SQL now supports filtering using HAVING and LIKE

Wed, 07 Jan 2026 00:00:00 GMT

You can now use the HAVING clause and LIKE pattern matching operators in Workers Analytics Engine.

Workers Analytics Engine allows you to ingest and store high-cardinality data at scale and query your data through a simple SQL API.

Filtering using `HAVING`

The HAVING clause complements the WHERE clause by enabling you to filter groups based on aggregate values. While WHERE filters rows before aggregation, HAVING filters groups after aggregation is complete.

You can use HAVING to filter groups where the average exceeds a threshold:

SELECT
    blob1 AS probe_name,
    avg(double1) AS average_temp
FROM temperature_readings
GROUP BY probe_name
HAVING average_temp > 10

You can also filter groups based on aggregates such as the number of items in the group:

SELECT
    blob1 AS probe_name,
    count() AS num_readings
FROM temperature_readings
GROUP BY probe_name
HAVING num_readings > 100

Pattern matching using `LIKE`

The new pattern matching operators enable you to search for strings that match specific patterns using wildcard characters:

LIKE - case-sensitive pattern matching
NOT LIKE - case-sensitive pattern exclusion
ILIKE - case-insensitive pattern matching
NOT ILIKE - case-insensitive pattern exclusion

Pattern matching supports two wildcard characters: % (matches zero or more characters) and _ (matches exactly one character).

You can match strings starting with a prefix:

SELECT *
FROM logs
WHERE blob1 LIKE 'error%'

You can also match file extensions (case-insensitive):

SELECT *
FROM requests
WHERE blob2 ILIKE '%.jpg'

Another example is excluding strings containing specific text:

SELECT *
FROM events
WHERE blob3 NOT ILIKE '%debug%'

Ready to get started?

Learn more about the HAVING clause or pattern matching operators in the Workers Analytics Engine SQL reference documentation.

Workers - Build microfrontend applications on Workers

Thu, 01 Jan 2026 00:00:00 GMT

You can now deploy microfrontends to Cloudflare, splitting a single application into smaller, independently deployable units that render as one cohesive application. This lets different teams using different frameworks develop, test, and deploy each microfrontend without coordinating releases.

Microfrontends solve several challenges for large-scale applications:

Independent deployments: Teams deploy updates on their own schedule without redeploying the entire application
Framework flexibility: Build multi-framework applications (for example, Astro, Remix, and Next.js in one app)
Gradual migration: Migrate from a monolith to a distributed architecture incrementally

Create a microfrontend project:

This template automatically creates a router worker with pre-configured routing logic, and lets you configure Service bindings to Workers you have already deployed to your Cloudflare account. The router Worker analyzes incoming requests, matches them against configured routes, and forwards requests to the appropriate microfrontend via service bindings. The router automatically rewrites HTML, CSS, and headers to ensure assets load correctly from each microfrontend's mount path. The router includes advanced features like preloading for faster navigation between microfrontends, smooth page transitions using the View Transitions API, and automatic path rewriting for assets, redirects, and cookies.

Each microfrontend can be a full-framework application, a static site with Workers Static Assets, or any other Worker-based application.

Get started with the microfrontends template, or read the microfrontends documentation for implementation details.

Agents, Workers - Agents SDK v0.3.0, workers-ai-provider v3.0.0, and ai-gateway-provider v3.0.0 with AI SDK v6 support

Mon, 22 Dec 2025 00:00:00 GMT

We've shipped a new release for the Agents SDK v0.3.0 bringing full compatibility with AI SDK v6 and introducing the unified tool pattern, dynamic tool approval, and enhanced React hooks with improved tool handling.

This release includes improved streaming and tool support, dynamic tool approval (for "human in the loop" systems), enhanced React hooks with onToolCall callback, improved error handling for streaming responses, and seamless migration from v5 patterns.

This makes it ideal for building production AI chat interfaces with Cloudflare Workers AI models, agent workflows, human-in-the-loop systems, or any application requiring reliable tool execution and approval workflows.

Additionally, we've updated workers-ai-provider v3.0.0, the official provider for Cloudflare Workers AI models, and ai-gateway-provider v3.0.0, the provider for Cloudflare AI Gateway, to be compatible with AI SDK v6.

Agents SDK v0.3.0

Unified Tool Pattern

AI SDK v6 introduces a unified tool pattern where all tools are defined on the server using the tool() function. This replaces the previous client-side AITool pattern.

Server-Side Tool Definition

import { tool } from "ai";
import { z } from "zod";

// Server: Define ALL tools on the server
const tools = {
  // Server-executed tool
  getWeather: tool({
    description: "Get weather for a city",
    inputSchema: z.object({ city: z.string() }),
    execute: async ({ city }) => fetchWeather(city)
  }),

  // Client-executed tool (no execute = client handles via onToolCall)
  getLocation: tool({
    description: "Get user location from browser",
    inputSchema: z.object({})
    // No execute function
  }),

  // Tool requiring approval (dynamic based on input)
  processPayment: tool({
    description: "Process a payment",
    inputSchema: z.object({ amount: z.number() }),
    needsApproval: async ({ amount }) => amount > 100,
    execute: async ({ amount }) => charge(amount)
  })
};

Client-Side Tool Handling

// Client: Handle client-side tools via onToolCall callback
import { useAgentChat } from "agents/ai-react";

const { messages, sendMessage, addToolOutput } = useAgentChat({
  agent,
  onToolCall: async ({ toolCall, addToolOutput }) => {
    if (toolCall.toolName === "getLocation") {
      const position = await new Promise((resolve, reject) => {
        navigator.geolocation.getCurrentPosition(resolve, reject);
      });
      addToolOutput({
        toolCallId: toolCall.toolCallId,
        output: {
          lat: position.coords.latitude,
          lng: position.coords.longitude
        }
      });
    }
  }
});

Key benefits of the unified tool pattern:

Server-defined tools: All tools are defined in one place on the server
Dynamic approval: Use needsApproval to conditionally require user confirmation
Cleaner client code: Use onToolCall callback instead of managing tool configs
Type safety: Full TypeScript support with proper tool typing

useAgentChat(options)

Creates a new chat interface with enhanced v6 capabilities.

// Basic chat setup with onToolCall
const { messages, sendMessage, addToolOutput } = useAgentChat({
  agent,
  onToolCall: async ({ toolCall, addToolOutput }) => {
    // Handle client-side tool execution
    await addToolOutput({
      toolCallId: toolCall.toolCallId,
      output: { result: "success" }
    });
  }
});

Dynamic Tool Approval

Use needsApproval on server tools to conditionally require user confirmation:

const paymentTool = tool({
  description: "Process a payment",
  inputSchema: z.object({
    amount: z.number(),
    recipient: z.string()
  }),
  needsApproval: async ({ amount }) => amount > 1000,
  execute: async ({ amount, recipient }) => {
    return await processPayment(amount, recipient);
  }
});

Tool Confirmation Detection

The isToolUIPart and getToolName functions now check both static and dynamic tool parts:

import { isToolUIPart, getToolName } from "ai";

const pendingToolCallConfirmation = messages.some((m) =>
  m.parts?.some(
    (part) => isToolUIPart(part) && part.state === "input-available",
  ),
);

// Handle tool confirmation
if (pendingToolCallConfirmation) {
  await addToolOutput({
    toolCallId: part.toolCallId,
    output: "User approved the action"
  });
}

If you need the v5 behavior (static-only checks), use the new functions:

import { isStaticToolUIPart, getStaticToolName } from "ai";

convertToModelMessages() is now async

The convertToModelMessages() function is now asynchronous. Update all calls to await the result:

import { convertToModelMessages } from "ai";

const result = streamText({
  messages: await convertToModelMessages(this.messages),
  model: openai("gpt-4o")
});

ModelMessage type

The CoreMessage type has been removed. Use ModelMessage instead:

import { convertToModelMessages, type ModelMessage } from "ai";

const modelMessages: ModelMessage[] = await convertToModelMessages(messages);

generateObject mode option removed

The mode option for generateObject has been removed:

// Before (v5)
const result = await generateObject({
  mode: "json",
  model,
  schema,
  prompt
});

// After (v6)
const result = await generateObject({
  model,
  schema,
  prompt
});

Structured Output with generateText

While generateObject and streamObject are still functional, the recommended approach is to use generateText/streamText with the Output.object() helper:

import { generateText, Output, stepCountIs } from "ai";

const { output } = await generateText({
  model: openai("gpt-4"),
  output: Output.object({
    schema: z.object({ name: z.string() })
  }),
  stopWhen: stepCountIs(2),
  prompt: "Generate a name"
});

Note: When using structured output with generateText, you must configure multiple steps with stopWhen because generating the structured output is itself a step.

workers-ai-provider v3.0.0

Seamless integration with Cloudflare Workers AI models through the updated workers-ai-provider v3.0.0 with AI SDK v6 support.

Model Setup with Workers AI

Use Cloudflare Workers AI models directly in your agent workflows:

import { createWorkersAI } from "workers-ai-provider";
import { useAgentChat } from "agents/ai-react";

// Create Workers AI model (v3.0.0 - enhanced v6 internals)
const model = createWorkersAI({
  binding: env.AI,
})("@cf/meta/llama-3.2-3b-instruct");

Enhanced File and Image Support

Workers AI models now support v6 file handling with automatic conversion:

// Send images and files to Workers AI models
sendMessage({
  role: "user",
  parts: [
    { type: "text", text: "Analyze this image:" },
    {
      type: "file",
      data: imageBuffer,
      mediaType: "image/jpeg",
    },
  ],
});

// Workers AI provider automatically converts to proper format

Streaming with Workers AI

Enhanced streaming support with automatic warning detection:

// Streaming with Workers AI models
const result = await streamText({
  model: createWorkersAI({ binding: env.AI })("@cf/meta/llama-3.2-3b-instruct"),
  messages: await convertToModelMessages(messages),
  onChunk: (chunk) => {
    // Enhanced streaming with warning handling
    console.log(chunk);
  },
});

ai-gateway-provider v3.0.0

The ai-gateway-provider v3.0.0 now supports AI SDK v6, enabling you to use Cloudflare AI Gateway with multiple AI providers including Anthropic, Azure, AWS Bedrock, Google Vertex, and Perplexity.

AI Gateway Setup

Use Cloudflare AI Gateway to add analytics, caching, and rate limiting to your AI applications:

import { createAIGateway } from "ai-gateway-provider";

// Create AI Gateway provider (v3.0.0 - enhanced v6 internals)
const model = createAIGateway({
  gatewayUrl: "https://gateway.ai.cloudflare.com/v1/your-account-id/gateway",
  headers: {
    "Authorization": `Bearer ${env.AI_GATEWAY_TOKEN}`
  }
})({
  provider: "openai",
  model: "gpt-4o"
});

Migration from v5

Deprecated APIs

The following APIs are deprecated in favor of the unified tool pattern:

Deprecated	Replacement
`AITool` type	Use AI SDK's `tool()` function on server
`extractClientToolSchemas()`	Define tools on server, no client schemas needed
`createToolsFromClientSchemas()`	Define tools on server with `tool()`
`toolsRequiringConfirmation` option	Use `needsApproval` on server tools
`experimental_automaticToolResolution`	Use `onToolCall` callback
`tools` option in `useAgentChat`	Use `onToolCall` for client-side execution
`addToolResult()`	Use `addToolOutput()`

Breaking Changes Summary

Unified Tool Pattern: All tools must be defined on the server using tool()
convertToModelMessages() is async: Add await to all calls
CoreMessage removed: Use ModelMessage instead
generateObject mode removed: Remove mode option
isToolUIPart behavior changed: Now checks both static and dynamic tool parts

Installation

Update your dependencies to use the latest versions:

npm install agents@^0.3.0 workers-ai-provider@^3.0.0 ai-gateway-provider@^3.0.0 ai@^6.0.0 @ai-sdk/react@^3.0.0 @ai-sdk/openai@^3.0.0

Resources

Migration Guide - Comprehensive migration documentation from v5 to v6
AI SDK v6 Documentation - Official AI SDK migration guide
AI SDK v6 Announcement - Learn about new features in v6
AI SDK Documentation - Complete AI SDK reference
GitHub Issues - Report bugs or request features

Feedback Welcome

We'd love your feedback! We're particularly interested in feedback on:

Migration experience - How smooth was the upgrade from v5 to v6?
Unified tool pattern - How does the new server-defined tool pattern work for you?
Dynamic tool approval - Does the needsApproval feature meet your needs?
AI Gateway integration - How well does the new provider work with your setup?

Workers - Static prerendering support for TanStack Start

Fri, 19 Dec 2025 00:00:00 GMT

TanStack Start apps can now prerender routes to static HTML at build time with access to build time environment variables and bindings, and serve them as static assets. To enable prerendering, configure the prerender option of the TanStack Start plugin in your Vite config:

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";
import { tanstackStart } from "@tanstack/react-start/plugin/vite";

export default defineConfig({
  plugins: [
    cloudflare({ viteEnvironment: { name: "ssr" } }),
    tanstackStart({
      prerender: {
        enabled: true,
      },
    }),
  ],
});

This feature requires @tanstack/react-start v1.138.0 or later. See the TanStack Start framework guide for more details.

Workers - Build image policies for Workers Builds and Cloudflare Pages

Thu, 18 Dec 2025 00:00:00 GMT

We've published build image policies for Workers Builds and Cloudflare Pages, which establish:

Minor version updates: We typically update preinstalled software to the latest available minor version without notice. For tools that don't follow semantic versioning (e.g., Bun or Hugo), we provide 3 months’ notice.
Major version updates: Before preinstalled software reaches end-of-life, we update to the next stable LTS version with 3 months’ notice.
Build image version deprecation (Pages only): We provide 6 months’ notice before deprecation. Projects on v1 or v2 will be automatically moved to v3 on their specified deprecation dates.

To prepare for updates, monitor the Cloudflare Changelog, dashboard notifications, and email. You can also override default versions to maintain specific versions.

Workers - Retrieve your authentication token with `wrangler auth token`

Thu, 18 Dec 2025 00:00:00 GMT

Wrangler now includes a new wrangler auth token command that retrieves your current authentication token or credentials for use with other tools and scripts.

wrangler auth token

The command returns whichever authentication method is currently configured, in priority order: API token from CLOUDFLARE_API_TOKEN, or OAuth token from wrangler login (automatically refreshed if expired).

Use the --json flag to get structured output including the token type:

wrangler auth token --json

The JSON output includes the authentication type:

// API token
{ "type": "api_token", "token": "..." }

// OAuth token
{ "type": "oauth", "token": "..." }

// API key/email (only available with --json)
{ "type": "api_key", "key": "...", "email": "..." }

API key/email credentials from CLOUDFLARE_API_KEY and CLOUDFLARE_EMAIL require the --json flag since this method uses two values instead of a single token.

Workers - Support for ctx.exports in @cloudflare/vitest-pool-workers

Tue, 16 Dec 2025 00:00:00 GMT

The @cloudflare/vitest-pool-workers package now supports the ctx.exports API, allowing you to access your Worker's top-level exports during tests.

You can access ctx.exports in unit tests by calling createExecutionContext():

import { createExecutionContext } from "cloudflare:test";
import { it, expect } from "vitest";

it("can access ctx.exports", async () => {
  const ctx = createExecutionContext();
  const result = await ctx.exports.MyEntryPoint.myMethod();
  expect(result).toBe("expected value");
});

Alternatively, you can import exports directly from cloudflare:workers:

import { exports } from "cloudflare:workers";
import { it, expect } from "vitest";

it("can access imported exports", async () => {
  const result = await exports.MyEntryPoint.myMethod();
  expect(result).toBe("expected value");
});

See the context-exports fixture for a complete example.

Workers - Configure your framework for Cloudflare automatically

Tue, 16 Dec 2025 00:00:00 GMT

Wrangler now supports automatic configuration for popular web frameworks in experimental mode, making it even easier to deploy to Cloudflare Workers.

Previously, if you wanted to deploy an application using a popular web framework like Next.js or Astro, you had to follow tutorials to set up your application for deployment to Cloudflare Workers. This usually involved creating a Wrangler file, installing adapters, or changing configuration options.

Now wrangler deploy does this for you. Starting with Wrangler 4.55, you can use npx wrangler deploy --x-autoconfig in the directory of any web application using one of the supported frameworks. Wrangler will then proceed to configure and deploy it to your Cloudflare account.

You can also configure your application without deploying it by using the new npx wrangler setup command. This enables you to easily review what changes we are making so your application is ready for Cloudflare Workers.

The following application frameworks are supported starting today:

Next.js
Astro
Nuxt
TanStack Start
SolidStart
React Router
SvelteKit
Docusaurus
Qwik
Analog

Automatic configuration also supports static sites by detecting the assets directory and build command. From a single index.html file to the output of a generator like Jekyll or Hugo, you can just run npx wrangler deploy --x-autoconfig to upload to Cloudflare.

We're really excited to bring you automatic configuration so you can do more with Workers. Please let us know if you run into challenges using this experimentally. We’ve opened a GitHub discussion and would love to hear your feedback.

Durable Objects, Workers - New Best Practices guide for Durable Objects

Mon, 15 Dec 2025 00:00:00 GMT

A new Rules of Durable Objects guide is now available, providing opinionated best practices for building effective Durable Objects applications. This guide covers design patterns, storage strategies, concurrency, and common anti-patterns to avoid.

Key guidance includes:

Design around your "atom" of coordination — Create one Durable Object per logical unit (chat room, game session, user) instead of a global singleton that becomes a bottleneck.
Use SQLite storage with RPC methods — SQLite-backed Durable Objects with typed RPC methods provide the best developer experience and performance.
Understand input and output gates — Learn how Cloudflare's runtime prevents data races by default, how write coalescing works, and when to use blockConcurrencyWhile().
Leverage Hibernatable WebSockets — Reduce costs for real-time applications by allowing Durable Objects to sleep while maintaining WebSocket connections.

The testing documentation has also been updated with modern patterns using @cloudflare/vitest-pool-workers, including examples for testing SQLite storage, alarms, and direct instance access:

JavaScript

import { env, runDurableObjectAlarm } from "cloudflare:test";
import { it, expect } from "vitest";

it("can test Durable Objects with isolated storage", async () => {
  const stub = env.COUNTER.getByName("test");

  // Call RPC methods directly on the stub
  await stub.increment();
  expect(await stub.getCount()).toBe(1);

  // Trigger alarms immediately without waiting
  await runDurableObjectAlarm(stub);
});

TypeScript

import { env, runDurableObjectAlarm } from "cloudflare:test";
import { it, expect } from "vitest";

it("can test Durable Objects with isolated storage", async () => {
  const stub = env.COUNTER.getByName("test");

  // Call RPC methods directly on the stub
  await stub.increment();
  expect(await stub.getCount()).toBe(1);

  // Trigger alarms immediately without waiting
  await runDurableObjectAlarm(stub);
});

Durable Objects, Workers - Billing for SQLite Storage

Fri, 12 Dec 2025 00:00:00 GMT

Storage billing for SQLite-backed Durable Objects will be enabled in January 2026, with a target date of January 7, 2026 (no earlier).

To view your SQLite storage usage, go to the Durable Objects page

Go to Durable Objects

If you do not want to incur costs, please take action such as optimizing queries or deleting unnecessary stored data in order to reduce your SQLite storage usage ahead of the January 7th target. Only usage on and after the billing target date will incur charges.

Developers on the Workers Paid plan with Durable Object's SQLite storage usage beyond included limits will incur charges according to SQLite storage pricing announced in September 2024 with the public beta. Developers on the Workers Free plan will not be charged.

Compute billing for SQLite-backed Durable Objects has been enabled since the initial public beta. SQLite-backed Durable Objects currently incur charges for requests and duration, and no changes are being made to compute billing.

For more information about SQLite storage pricing and limits, refer to the Durable Objects pricing documentation.

Workers - Python cold start improvements

Mon, 08 Dec 2025 00:00:00 GMT

Python Workers now feature improved cold start performance, reducing initialization time for new Worker instances. This improvement is particularly noticeable for Workers with larger dependency sets or complex initialization logic.

Every time you deploy a Python Worker, a memory snapshot is captured after the top level of the Worker is executed. This snapshot captures all imports, including package imports that are often costly to load. The memory snapshot is loaded when the Worker is first started, avoiding the need to reload the Python runtime and all dependencies on each cold start.

We set up a benchmark that imports common packages (httpx, fastapi and pydantic) to see how Python Workers stack up against other platforms:

Platform	Mean Cold Start (ms)
Cloudflare Python Workers	1027
AWS Lambda	2502
Google Cloud Run	3069

These benchmarks run continuously. You can view the results and the methodology on our benchmark page.

In additional testing, we have found that without any memory snapshot, the cold start for this benchmark takes around 10 seconds, so this change improves cold start performance by roughly a factor of 10.

To get started with Python Workers, check out our Python Workers overview.

Workers - Easy Python package management with Pywrangler

Mon, 08 Dec 2025 00:00:00 GMT

We are introducing a brand new tool called Pywrangler, which simplifies package management in Python Workers by automatically installing Workers-compatible Python packages into your project.

With Pywrangler, you specify your Worker's Python dependencies in your pyproject.toml file:

[project]
name = "python-beautifulsoup-worker"
version = "0.1.0"
description = "A simple Worker using beautifulsoup4"
requires-python = ">=3.12"
dependencies = [
    "beautifulsoup4"
]

[dependency-groups]
dev = [
  "workers-py",
  "workers-runtime-sdk"
]

You can then develop and deploy your Worker using the following commands:

uv run pywrangler dev
uv run pywrangler deploy

Pywrangler automatically downloads and vendors the necessary packages for your Worker, and these packages are bundled with the Worker when you deploy.

Consult the Python packages documentation for full details on Pywrangler and Python package management in Workers.

Workers - Wrangler config is optional when using Vite plugin

Mon, 08 Dec 2025 00:00:00 GMT

When using the Cloudflare Vite plugin to build and deploy Workers, a Wrangler configuration file is now optional for assets-only (static) sites. If no wrangler.toml, wrangler.json, or wrangler.jsonc file is found, the plugin generates sensible defaults for an assets-only site. The name is based on the package.json or the project directory name, and the compatibility_date uses the latest date supported by your installed Miniflare version.

This allows easier setup for static sites using Vite. Note that SPAs will still need to set assets.not_found_handling to single-page-application in order to function correctly.

Workers - Configure Workers programmatically using the Vite plugin

Mon, 08 Dec 2025 00:00:00 GMT

The Cloudflare Vite plugin now supports programmatic configuration of Workers without a Wrangler configuration file. You can use the config option to define Worker settings directly in your Vite configuration, or to modify existing configuration loaded from a Wrangler config file. This is particularly useful when integrating with other build tools or frameworks, as it allows them to control Worker configuration without needing users to manage a separate config file.

The `config` option

The Vite plugin's new config option accepts either a partial configuration object or a function that receives the current configuration and returns overrides. This option is applied after any config file is loaded, allowing the plugin to override specific values or define Worker configuration entirely in code.

Example usage

Setting config to an object to provide configuration values that merge with defaults and config file settings:

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
  plugins: [
    cloudflare({
      config: {
        name: "my-worker",
        compatibility_flags: ["nodejs_compat"],
        send_email: [
          {
            name: "EMAIL",
          },
        ],
      },
    }),
  ],
});

Use a function to modify the existing configuration:

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";
export default defineConfig({
  plugins: [
    cloudflare({
      config: (userConfig) => {
        delete userConfig.compatibility_flags;
      },
    }),
  ],
});

Return an object with values to merge:

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
  plugins: [
    cloudflare({
      config: (userConfig) => {
        if (!userConfig.compatibility_flags.includes("no_nodejs_compat")) {
          return { compatibility_flags: ["nodejs_compat"] };
        }
      },
    }),
  ],
});

Auxiliary Workers

Auxiliary Workers also support the config option, enabling multi-Worker architectures without config files.

Define auxiliary Workers without config files using config inside the auxiliaryWorkers array:

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
  plugins: [
    cloudflare({
      config: {
        name: "entry-worker",
        main: "./src/entry.ts",
        services: [{ binding: "API", service: "api-worker" }],
      },
      auxiliaryWorkers: [
        {
          config: {
            name: "api-worker",
            main: "./src/api.ts",
          },
        },
      ],
    }),
  ],
});

For more details and examples, see Programmatic configuration.

Workers - One-click Access protection for Workers now creates reusable Cloudflare Access policies

Thu, 04 Dec 2025 00:00:00 GMT

Workers applications now use reusable Cloudflare Access policies to reduce duplication and simplify access management across multiple Workers.

Previously, enabling Cloudflare Access on a Worker created per-application policies, unique to each application. Now, we create reusable policies that can be shared across applications:

Preview URLs: All Workers preview URLs share a single "Cloudflare Workers Preview URLs" policy across your account. This policy is automatically created the first time you enable Access on any preview URL. By sharing a single policy across all preview URLs, you can configure access rules once and have them apply company-wide to all Workers which protect preview URLs. This makes it much easier to manage who can access preview environments without having to update individual policies for each Worker.
Production workers.dev URLs: When enabled, each Worker gets its own reusable policy (named <worker-name> - Production) by default. We recognize production services often have different access requirements and having individual policies here makes it easier to configure service-to-service authentication or protect internal dashboards or applications with specific user groups. Keeping these policies separate gives you the flexibility to configure exactly the right access rules for each production service. When you disable Access on a production Worker, the associated policy is automatically cleaned up if it's not being used by other applications.

This change reduces policy duplication, simplifies cross-company access management for preview environments, and provides the flexibility needed for production services. You can still customize access rules by editing the reusable policies in the Zero Trust dashboard.

To enable Cloudflare Access on your Worker:

In the Cloudflare dashboard, go to Workers & Pages.
Select your Worker.
Go to Settings > Domains & Routes.
For workers.dev or Preview URLs, click Enable Cloudflare Access.
Optionally, click Manage Cloudflare Access to customize the policy.

For more information on configuring Cloudflare Access for Workers, refer to the Workers Access documentation.

Agents, Workers - Agents SDK v0.2.24 with resumable streaming, MCP improvements, and schedule fixes

Wed, 26 Nov 2025 00:00:00 GMT

The latest release of @cloudflare/agents brings resumable streaming, significant MCP client improvements, and critical fixes for schedules and Durable Object lifecycle management.

Resumable streaming

AIChatAgent now supports resumable streaming, allowing clients to reconnect and continue receiving streamed responses without losing data. This is useful for:

Long-running AI responses
Users on unreliable networks
Users switching between devices mid-conversation
Background tasks where users navigate away and return
Real-time collaboration where multiple clients need to stay in sync

Streams are maintained across page refreshes, broken connections, and syncing across open tabs and devices.

Other improvements

Default JSON schema validator added to MCP client
Schedules can now safely destroy the agent

MCP client API improvements

The MCPClientManager API has been redesigned for better clarity and control:

New registerServer() method: Register MCP servers without immediately connecting
New connectToServer() method: Establish connections to registered servers
Improved reconnect logic: restoreConnectionsFromStorage() now properly handles failed connections

// Register a server to Agent
const { id } = await this.mcp.registerServer({
  name: "my-server",
  url: "https://my-mcp-server.example.com",
});

// Connect when ready
await this.mcp.connectToServer(id);

// Discover tools, prompts and resources
await this.mcp.discoverIfConnected(id);

The SDK now includes a formalized MCPConnectionState enum with states: idle, connecting, authenticating, connected, discovering, and ready.

Enhanced MCP discovery

MCP discovery fetches the available tools, prompts, and resources from an MCP server so your agent knows what capabilities are available. The MCPClientConnection class now includes a dedicated discover() method with improved reliability:

Supports cancellation via AbortController
Configurable timeout (default 15s)
Discovery failures now throw errors immediately instead of silently continuing

Bug fixes

Fixed a bug where schedules meant to fire immediately with this.schedule(0, ...) or this.schedule(new Date(), ...) would not fire
Fixed an issue where schedules that took longer than 30 seconds would occasionally time out
Fixed SSE transport now properly forwards session IDs and request headers
Fixed AI SDK stream events convertion to UIMessageStreamPart

Upgrade

To update to the latest version:

npm i agents@latest

Workers - Environment variable limits increase for Workers Builds

Fri, 21 Nov 2025 00:00:00 GMT

Workers Builds now supports up to 64 environment variables, and each environment variable can be up to 5 KB in size. The previous limit was 5 KB total across all environment variables.

This change enables better support for complex build configurations, larger application settings, and more flexible CI/CD workflows.

For more details, refer to the build limits documentation.

Workers - Better local deployment flow for Cloudflare Workers

Fri, 21 Nov 2025 00:00:00 GMT

Until now, if a Worker had been previously deployed via the Cloudflare Dashboard, a subsequent deployment done via the Cloudflare Workers CLI, Wrangler (through the deploy command), would allow the user to override the Worker's dashboard settings without providing details on what dashboard settings would be lost.

Now instead, wrangler deploy presents a helpful representation of the differences between the local configuration and the remote dashboard settings, and offers to update your local configuration file for you.

See example below showing a before and after for wrangler deploy when a local configuration is expected to override a Worker's dashboard settings:

Before

After

Also, if instead Wrangler detects that a deployment would override remote dashboard settings but in an additive way, without modifying or removing any of them, it will simply proceed with the deployment without requesting any user interaction.

Update to Wrangler v4.50.0 or greater to take advantage of this improved deploy flow.

Workers Analytics Engine, Workers - More SQL aggregate, date and time functions available in Workers Analytics Engine

Wed, 12 Nov 2025 00:00:00 GMT

You can now perform more powerful queries directly in Workers Analytics Engine with a major expansion of our SQL function library.

Workers Analytics Engine allows you to ingest and store high-cardinality data at scale (such as custom analytics) and query your data through a simple SQL API.

Today, we've expanded Workers Analytics Engine's SQL capabilities with several new functions:

New aggregate functions:

countIf() - count the number of rows which satisfy a provided condition
sumIf() - calculate a sum from rows which satisfy a provided condition
avgIf() - calculate an average from rows which satisfy a provided condition

New date and time functions:

toYear()
toMonth()
toDayOfMonth()
toDayOfWeek()
toHour()
toMinute()
toSecond()
toStartOfYear()
toStartOfMonth()
toStartOfWeek()
toStartOfDay()
toStartOfHour()
toStartOfFifteenMinutes()
toStartOfTenMinutes()
toStartOfFiveMinutes()
toStartOfMinute()
today()
toYYYYMM()

Ready to get started?

Whether you're building usage-based billing systems, customer analytics dashboards, or other custom analytics, these functions let you get the most out of your data. Get started with Workers Analytics Engine and explore all available functions in our SQL reference documentation.

Workers - Select Wrangler environments using the CLOUDFLARE_ENV environment variable

Sun, 09 Nov 2025 00:00:00 GMT

Wrangler now supports using the CLOUDFLARE_ENV environment variable to select the active environment for your Worker commands. This provides a more flexible way to manage environments, especially when working with build tools and CI/CD pipelines.

What's new

Environment selection via environment variable:

Set CLOUDFLARE_ENV to specify which environment to use for Wrangler commands
Works with all Wrangler commands that support the --env flag
The --env command line argument takes precedence over the CLOUDFLARE_ENV environment variable

Example usage

# Deploy to the production environment using CLOUDFLARE_ENV
CLOUDFLARE_ENV=production wrangler deploy

# Upload a version to the staging environment
CLOUDFLARE_ENV=staging wrangler versions upload

# The --env flag takes precedence over CLOUDFLARE_ENV
CLOUDFLARE_ENV=dev wrangler deploy --env production
# This will deploy to production, not dev

Use with build tools

The CLOUDFLARE_ENV environment variable is particularly useful when working with build tools like Vite. You can set the environment once during the build process, and it will be used for both building and deploying your Worker:

# Set the environment for both build and deploy
CLOUDFLARE_ENV=production npm run build & wrangler deploy

When using @cloudflare/vite-plugin, the build process generates a "redirected deploy config" that is flattened to only contain the active environment. Wrangler will validate that the environment specified matches the environment used during the build to prevent accidentally deploying a Worker built for one environment to a different environment.

Learn more

Workers - Workers automatic tracing, now in open beta

Fri, 07 Nov 2025 00:00:00 GMT

Enable automatic tracing on your Workers, giving you detailed metadata and timing information for every operation your Worker performs.

Tracing helps you identify performance bottlenecks, resolve errors, and understand how your Worker interacts with other services on the Workers platform. You can now answer questions like:

Which calls are slowing down my application?
Which queries to my database take the longest?
What happened within a request that resulted in an error?

You can now:

View traces alongside your logs in the Workers Observability dashboard
Export traces (and correlated logs) to any OTLP-compatible destination, such as Honeycomb, Sentry or Grafana, by configuring a tracing destination in the Cloudflare dashboard
Analyze and query across span attributes (operation type, status, duration, errors)

To get started, set:

{
  "observability": {
    "tracing": {
      "enabled": true,
    },
  },
}

Want to learn more?

D1, Workers - D1 can restrict data localization with jurisdictions

Wed, 05 Nov 2025 00:00:00 GMT

You can now set a jurisdiction when creating a D1 database to guarantee where your database runs and stores data. Jurisdictions can help you comply with data localization regulations such as GDPR. Supported jurisdictions include eu and fedramp.

A jurisdiction can only be set at database creation time via wrangler, REST API or the UI and cannot be added/updated after the database already exists.

npx wrangler@latest d1 create db-with-jurisdiction --jurisdiction eu

curl -X POST "https://api.cloudflare.com/client/v4/accounts/<account_id>/d1/database" \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     --data '{"name": "db-wth-jurisdiction", "jurisdiction": "eu" }'

To learn more, visit D1's data location documentation.

Workers - Capture Wrangler command output in structured format

Mon, 03 Nov 2025 00:00:00 GMT

You can now capture Wrangler command output in a structured ND-JSON format by setting the WRANGLER_OUTPUT_FILE_PATH or WRANGLER_OUTPUT_FILE_DIRECTORY environment variables. This feature is particularly useful for CI/CD pipelines and automation tools that need programmatic access to deployment information such as worker names, version IDs, deployment URLs, and error details. Commands that support this feature include wrangler deploy, wrangler versions upload, wrangler versions deploy, and wrangler pages deploy.

Workers, Durable Objects, Browser Rendering - Workers WebSocket message size limit increased from 1 MiB to 32 MiB

Fri, 31 Oct 2025 00:00:00 GMT

Workers, including those using Durable Objects and Browser Rendering, may now process WebSocket messages up to 32 MiB in size. Previously, this limit was 1 MiB.

This change allows Workers to handle use cases requiring large message sizes, such as processing Chrome Devtools Protocol messages.

For more information, please see the Durable Objects startup limits.

Workflows, Workers - Increased Workflows instance and concurrency limits

Fri, 31 Oct 2025 00:00:00 GMT

We've raised the Cloudflare Workflows account-level limits for all accounts on the Workers paid plan:

Instance creation rate increased from 100 workflow instances per 10 seconds to 100 instances per second
Concurrency limit increased from 4,500 to 10,000 workflow instances per account

These increases mean you can create new instances up to 10x faster, and have more workflow instances concurrently executing. To learn more and get started with Workflows, refer to the getting started guide.

If your application requires a higher limit, fill out the Limit Increase Request Form or contact your account team. Please refer to Workflows pricing for more information.

Workers - Access Workers preview URLs from the Build details page

Thu, 30 Oct 2025 00:00:00 GMT

You can now access preview URLs directly from the build details page, making it easier to test your changes when reviewing builds in the dashboard.

What's new

A Preview button now appears in the top-right corner of the build details page for successful builds
Click it to instantly open the latest preview URL
Matches the same experience you're familiar with from Pages

Workers - Automatic resource provisioning for KV, R2, and D1

Fri, 24 Oct 2025 00:00:00 GMT

Previously, if you wanted to develop or deploy a worker with attached resources, you'd have to first manually create the desired resources. Now, if your Wrangler configuration file includes a KV namespace, D1 database, or R2 bucket that does not yet exist on your account, you can develop locally and deploy your application seamlessly, without having to run additional commands.

Automatic provisioning is launching as an open beta, and we'd love to hear your feedback to help us make improvements! It currently works for KV, R2, and D1 bindings. You can disable the feature using the --no-x-provision flag.

To use this feature, update to wrangler@4.45.0 and add bindings to your config file without resource IDs e.g.:

{
  "kv_namespaces": [{ "binding": "MY_KV" }],
  "d1_databases": [{ "binding": "MY_DB" }],
  "r2_buckets": [{ "binding": "MY_R2" }],
}

wrangler dev will then automatically create these resources for you locally, and on your next run of wrangler deploy, Wrangler will call the Cloudflare API to create the requested resources and link them to your Worker.

Though resource IDs will be automatically written back to your Wrangler config file after resource creation, resources will stay linked across future deploys even without adding the resource IDs to the config file. This is especially useful for shared templates, which now no longer need to include account-specific resource IDs when adding a binding.

Workers - Build TanStack Start apps with the Cloudflare Vite plugin

Fri, 24 Oct 2025 00:00:00 GMT

The Cloudflare Vite plugin now supports TanStack Start apps. Get started with new or existing projects.

New projects

Create a new TanStack Start project that uses the Cloudflare Vite plugin via the create-cloudflare CLI:

npm create cloudflare@latest -- my-tanstack-start-app --framework=tanstack-start

yarn create cloudflare my-tanstack-start-app --framework=tanstack-start

pnpm create cloudflare@latest my-tanstack-start-app --framework=tanstack-start

Existing projects

Migrate an existing TanStack Start project to use the Cloudflare Vite plugin:

Install @cloudflare/vite-plugin and wrangler

npm i -D @cloudflare/vite-plugin wrangler

yarn add -D @cloudflare/vite-plugin wrangler

pnpm add -D @cloudflare/vite-plugin wrangler

bun add -d @cloudflare/vite-plugin wrangler

Add the Cloudflare plugin to your Vite config

import { defineConfig } from "vite";
import { tanstackStart } from "@tanstack/react-start/plugin/vite";
import viteReact from "@vitejs/plugin-react";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
  plugins: [
    cloudflare({ viteEnvironment: { name: "ssr" } }),
    tanstackStart(),
    viteReact(),
  ],
});

Add your Worker config file

wrangler.jsonc

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "my-tanstack-start-app",
  // Set this to today's date
  "compatibility_date": "2026-04-03",
  "compatibility_flags": [
    "nodejs_compat"
  ],
  "main": "@tanstack/react-start/server-entry"
}

wrangler.toml

"$schema" = "./node_modules/wrangler/config-schema.json"
name = "my-tanstack-start-app"
# Set this to today's date
compatibility_date = "2026-04-03"
compatibility_flags = [ "nodejs_compat" ]
main = "@tanstack/react-start/server-entry"

Modify the scripts in your package.json

{
  "scripts": {
    "dev": "vite dev",
    "build": "vite build && tsc --noEmit",
    "start": "node .output/server/index.mjs",
    "preview": "vite preview",
    "deploy": "npm run build && wrangler deploy",
    "cf-typegen": "wrangler types"
  }
}

See the TanStack Start framework guide for more info.

Workers - Workers Preview URL default behavior now matches your workers.dev setting

Thu, 23 Oct 2025 00:00:00 GMT

We have updated the default behavior for Cloudflare Workers Preview URLs. Going forward, if a preview URL setting is not explicitly configured during deployment, its default behavior will automatically match the setting of your workers.dev subdomain.

This change is intended to provide a more intuitive and secure experience by aligning your preview URL's default state with your workers.dev configuration to prevent cases where a preview URL might remain public even after you disabled your workers.dev route.

What this means for you:

If neither setting is configured: both the workers.dev route and the preview URL will default to enabled
If your workers.dev route is enabled and you do not explicitly set Preview URLs to enabled or disabled: Preview URLs will default to enabled
If your workers.dev route is disabled and you do not explicitly set Preview URLs to enabled or disabled: Preview URLs will default to disabled

You can override the default setting by explicitly enabling or disabling the preview URL in your Worker's configuration through the API, Dashboard, or Wrangler.

Wrangler Version Behavior

The default behavior depends on the version of Wrangler you are using. This new logic applies to the latest version. Here is a summary of the behavior across different versions:

Before v4.34.0: Preview URLs defaulted to enabled, regardless of the workers.dev setting.
v4.34.0 up to (but not including) v4.44.0: Preview URLs defaulted to disabled, regardless of the workers.dev setting.
v4.44.0 or later: Preview URLs now default to matching your workers.dev setting.

Why we’re making this change

In July, we introduced preview URLs to Workers, which let you preview code changes before deploying to production. This made disabling your Worker’s workers.dev URL an ambiguous action — the preview URL, served as a subdomain of workers.dev (ex: preview-id-worker-name.account-name.workers.dev) would still be live even if you had disabled your Worker’s workers.dev route. If you misinterpreted what it meant to disable your workers.dev route, you might unintentionally leave preview URLs enabled when you didn’t mean to, and expose them to the public Internet.

To address this, we made a one-time update to disable preview URLs on existing Workers that had their workers.dev route disabled and changed the default behavior to be disabled for all new deployments where a preview URL setting was not explicitly configured.

While this change helped secure many customers, it was disruptive for customers who keep their workers.dev route enabled and actively use the preview functionality, as it now required them to explicitly enable preview URLs on every redeployment.This new, more intuitive behavior ensures that your preview URL settings align with your workers.dev configuration by default, providing a more secure and predictable experience.

Securing access to workers.dev and preview URL endpoints

To further secure your workers.dev subdomain and preview URL, you can enable Cloudflare Access with a single click in your Worker's settings to limit access to specific users or groups.

Durable Objects, Workers - View and edit Durable Object data in UI with Data Studio (Beta)

Thu, 16 Oct 2025 00:00:00 GMT

You can now view and write to each Durable Object's storage using a UI editor on the Cloudflare dashboard. Only Durable Objects using SQLite storage can use Data Studio.

Go to Durable Objects

Data Studio unlocks easier data access with Durable Objects for prototyping application data models to debugging production storage usage. Before, querying your Durable Objects data required deploying a Worker.

To access a Durable Object, you can provide an object's unique name or ID generated by Cloudflare. Data Studio requires you to have at least the Workers Platform Admin role, and all queries are captured with audit logging for your security and compliance needs. Queries executed by Data Studio send requests to your remote, deployed objects and incur normal usage billing.

To learn more, visit the Data Studio documentation. If you have feedback or suggestions for the new Data Studio, please share your experience on Discord

Workers - Worker startup time limit increased to 1 second

Fri, 10 Oct 2025 00:00:00 GMT

You can now upload a Worker that takes up 1 second to parse and execute its global scope. Previously, startup time was limited to 400 ms.

This allows you to run Workers that import more complex packages and execute more code prior to requests being handled.

For more information, see the documentation on Workers startup limits.

Workers - You can now deploy full-stack apps on Workers using Terraform

Thu, 09 Oct 2025 00:00:00 GMT

You can now upload Workers with static assets (like HTML, CSS, JavaScript, images) with the Cloudflare Terraform provider v5.11.0, making it even easier to deploy and manage full-stack apps with IaC.

Previously, you couldn't use Terraform to upload static assets without writing custom scripts to handle generating an asset manifest, calling the Cloudflare API to upload assets in chunks, and handling change detection.

Now, you simply define the directory where your assets are built, and we handle the rest. Check out the examples for what this looks like in Terraform configuration.

You can get started today with the Cloudflare Terraform provider (v5.11.0), using either the existing cloudflare_workers_script resource, or the beta cloudflare_worker_version resource.

Examples

With `cloudflare_workers_script`

Here's how you can use the existing cloudflare_workers_script resource to upload your Worker code and assets in one shot.

resource "cloudflare_workers_script" "my_app" {
  account_id  = var.account_id
  script_name = "my-app"

  content_file   = "./dist/worker/index.js"
  content_sha256 = filesha256("./dist/worker/index.js")
  main_module    = "index.js"

  # Just point to your assets directory - that's it!
  assets = {
    directory = "./dist/static"
  }
}

With `cloudflare_worker`, `cloudflare_worker_version`, and `cloudflare_workers_deployment`

And here's an example using the beta cloudflare_worker_version resource, alongside the cloudflare_worker and cloudflare_workers_deployment resources:

# This tracks the existence of your Worker, so that you
# can upload code and assets separately from tracking Worker state.

resource "cloudflare_worker" "my_app" {
  account_id = var.account_id
  name       = "my-app"
}

resource "cloudflare_worker_version" "my_app_version" {
  account_id = var.account_id
  worker_id  = cloudflare_worker.my_app.id

  # Just point to your assets directory - that's it!
  assets = {
    directory = "./dist/static"
  }

  modules = [{
    name         = "index.js"
    content_file = "./dist/worker/index.js"
    content_type = "application/javascript+module"
  }]
}

resource "cloudflare_workers_deployment" "my_app_deployment" {
  account_id  = var.account_id
  script_name = cloudflare_worker.my_app.name

  strategy = "percentage"
  versions = [{
    version_id = cloudflare_worker_version.my_app_version.id
    percentage = 100
  }]
}

What's changed

Under the hood, the Cloudflare Terraform provider now handles the same logic that Wrangler uses for static asset uploads. This includes scanning your assets directory, computing hashes for each file, generating a manifest with file metadata, and calling the Cloudflare API to upload any missing files in chunks. We support large directories with parallel uploads and chunking, and when the asset manifest hash changes, we detect what's changed and trigger an upload for only those changed files.

Try it out

Get started with the Cloudflare Terraform provider (v5.11.0)
You can use either the existing cloudflare_workers_script resource to upload your Worker code and assets in one resource.
Or you can use the new beta cloudflare_worker_version resource (along with the cloudflare_worker and cloudflare_workers_deployment) resources to more granularly control the lifecycle of each Worker resource.

Workers - You can now deploy and manage Workflows in Terraform

Thu, 09 Oct 2025 00:00:00 GMT

You can now create and manage Workflows using Terraform, now supported in the Cloudflare Terraform provider v5.11.0. Workflows allow you to build durable, multi-step applications -- without needing to worry about retrying failed tasks or managing infrastructure.

Now, you can deploy and manage Workflows through Terraform using the new cloudflare_workflow resource:

resource "cloudflare_workflow" "my_workflow" {
  account_id    = var.account_id
  workflow_name = "my-workflow"
  class_name    = "MyWorkflow"
  script_name   = "my-worker"
}

Examples

Here are full examples of how to configure cloudflare_workflow in Terraform, using the existing cloudflare_workers_script resource, and the beta cloudflare_worker_version resource.

With `cloudflare_workflow` and `cloudflare_workers_script`

resource "cloudflare_workers_script" "workflow_worker" {
  account_id  = var.cloudflare_account_id
  script_name = "my-workflow-worker"

  content_file   = "${path.module}/../dist/worker/index.js"
  content_sha256 = filesha256("${path.module}/../dist/worker/index.js")
  main_module    = "index.js"
}

resource "cloudflare_workflow" "workflow" {
  account_id    = var.cloudflare_account_id
  workflow_name = "my-workflow"
  class_name    = "MyWorkflow"
  script_name   = cloudflare_workers_script.workflow_worker.script_name
}

With `cloudflare_workflow`, and the new beta resources

You can more granularly control the lifecycle of each Worker resource using the beta cloudflare_worker_version resource, alongside the cloudflare_worker and cloudflare_workers_deployment resources.

resource "cloudflare_worker" "workflow_worker" {
  account_id = var.cloudflare_account_id
  name       = "my-workflow-worker"
}

resource "cloudflare_worker_version" "workflow_worker_version" {
  account_id = var.cloudflare_account_id
  worker_id  = cloudflare_worker.workflow_worker.id

  main_module         = "index.js"

  modules = [{
    name         = "index.js"
    content_file = "${path.module}/../dist/worker/index.js"
    content_type = "application/javascript+module"
  }]
}

resource "cloudflare_workers_deployment" "workflow_deployment" {
  account_id  = var.cloudflare_account_id
  script_name = cloudflare_worker.workflow_worker.name

  strategy = "percentage"
  versions = [{
    version_id = cloudflare_worker_version.workflow_worker_version.id
    percentage = 100
  }]
}

resource "cloudflare_workflow" "my_workflow" {
  account_id    = var.cloudflare_account_id
  workflow_name = "my-workflow"
  class_name    = "MyWorkflow"
  script_name   = cloudflare_worker.workflow_worker.name
}

Try it out

Get started with the Cloudflare Terraform provider (v5.11.0) and the new cloudflare_workflow resource.

Workers - New Overview Page for Cloudflare Workers

Tue, 07 Oct 2025 00:00:00 GMT

Each of your Workers now has a new overview page in the Cloudflare dashboard.

The goal is to make it easier to understand your Worker without digging through multiple tabs. Think of it as a new home base, a place to get a high-level overview on what's going on.

It's the first place you land when you open a Worker in the dashboard, and it gives you an immediate view of what’s going on. You can see requests, errors, and CPU time at a glance. You can view and add bindings, and see recent versions of your app, including who published them.

Navigation is also simpler, with visually distinct tabs at the top of the page. At the bottom right you'll find guided steps for what to do next that are based on the state of your Worker, such as adding a binding or connecting a custom domain.

We plan to add more here over time. Better insights, more controls, and ways to manage your Worker from one page.

If you have feedback or suggestions for the new Overview page or your Cloudflare Workers experience in general, we'd love to hear from you. Join the Cloudflare developer community on Discord.

Workers - One-click Cloudflare Access for Workers

Fri, 03 Oct 2025 00:00:00 GMT

You can now enable Cloudflare Access for your workers.dev and Preview URLs in a single click.

Access allows you to limit access to your Workers to specific users or groups. You can limit access to yourself, your teammates, your organization, or anyone else you specify in your Access policy.

To enable Cloudflare Access:

In the Cloudflare dashboard, go to the Workers & Pages page.
Go to Workers & Pages
In Overview, select your Worker.
Go to Settings > Domains & Routes.
For workers.dev or Preview URLs, click Enable Cloudflare Access.
Optionally, to configure the Access application, click Manage Cloudflare Access. There, you can change the email addresses you want to authorize. View Access policies to learn about configuring alternate rules.

To fully secure your application, it is important that you validate the JWT that Cloudflare Access adds to the Cf-Access-Jwt-Assertion header on the incoming request.

The following code will validate the JWT using the jose NPM package:

import { jwtVerify, createRemoteJWKSet } from "jose";

export default {
  async fetch(request, env, ctx) {
    // Verify the POLICY_AUD environment variable is set
    if (!env.POLICY_AUD) {
      return new Response("Missing required audience", {
        status: 403,
        headers: { "Content-Type": "text/plain" },
      });
    }

    // Get the JWT from the request headers
    const token = request.headers.get("cf-access-jwt-assertion");

    // Check if token exists
    if (!token) {
      return new Response("Missing required CF Access JWT", {
        status: 403,
        headers: { "Content-Type": "text/plain" },
      });
    }

    try {
      // Create JWKS from your team domain
      const JWKS = createRemoteJWKSet(
        new URL(`${env.TEAM_DOMAIN}/cdn-cgi/access/certs`),
      );

      // Verify the JWT
      const { payload } = await jwtVerify(token, JWKS, {
        issuer: env.TEAM_DOMAIN,
        audience: env.POLICY_AUD,
      });

      // Token is valid, proceed with your application logic
      return new Response(`Hello ${payload.email || "authenticated user"}!`, {
        headers: { "Content-Type": "text/plain" },
      });
    } catch (error) {
      // Token verification failed
      return new Response(`Invalid token: ${error.message}`, {
        status: 403,
        headers: { "Content-Type": "text/plain" },
      });
    }
  },
};

Required environment variables

Add these environment variables to your Worker:

POLICY_AUD: Your application's AUD tag
TEAM_DOMAIN: https://<your-team-name>.cloudflareaccess.com

Both of these appear in the modal that appears when you enable Cloudflare Access.

You can set these variables by adding them to your Worker's Wrangler configuration file, or via the Cloudflare dashboard under Workers & Pages > your-worker > Settings > Environment Variables.

Workers Analytics Engine, Workers - Workers Analytics Engine adds supports for new SQL functions

Thu, 02 Oct 2025 00:00:00 GMT

You can now perform more powerful queries directly in Workers Analytics Engine with a major expansion of our SQL function library.

Workers Analytics Engine allows you to ingest and store high-cardinality data at scale (such as custom analytics) and query your data through a simple SQL API.

Today, we've expanded Workers Analytics Engine's SQL capabilities with several new functions:

New aggregate functions:

argMin() - Returns the value associated with the minimum in a group
argMax() - Returns the value associated with the maximum in a group
topK() - Returns an array of the most frequent values in a group
topKWeighted() - Returns an array of the most frequent values in a group using weights
first_value() - Returns the first value in an ordered set of values within a partition
last_value() - Returns the last value in an ordered set of values within a partition

New bit functions:

bitAnd() - Returns the bitwise AND of two expressions
bitCount() - Returns the number of bits set to one in the binary representation of a number
bitHammingDistance() - Returns the number of bits that differ between two numbers
bitNot() - Returns a number with all bits flipped
bitOr() - Returns the inclusive bitwise OR of two expressions
bitRotateLeft() - Rotates all bits in a number left by specified positions
bitRotateRight() - Rotates all bits in a number right by specified positions
bitShiftLeft() - Shifts all bits in a number left by specified positions
bitShiftRight() - Shifts all bits in a number right by specified positions
bitTest() - Returns the value of a specific bit in a number
bitXor() - Returns the bitwise exclusive-or of two expressions

New mathematical functions:

abs() - Returns the absolute value of a number
log() - Computes the natural logarithm of a number
round() - Rounds a number to a specified number of decimal places
ceil() - Rounds a number up to the nearest integer
floor() - Rounds a number down to the nearest integer
pow() - Returns a number raised to the power of another number

New string functions:

lowerUTF8() - Converts a string to lowercase using UTF-8 encoding
upperUTF8() - Converts a string to uppercase using UTF-8 encoding

New encoding functions:

hex() - Converts a number to its hexadecimal representation
bin() - Converts a string to its binary representation

New type conversion functions:

toUInt8() - Converts any numeric expression, or expression resulting in a string representation of a decimal, into an unsigned 8 bit integer

Ready to get started?

Workers - Automatic loopback bindings via ctx.exports

Fri, 26 Sep 2025 00:00:00 GMT

The ctx.exports API contains automatically-configured bindings corresponding to your Worker's top-level exports. For each top-level export extending WorkerEntrypoint, ctx.exports will contain a Service Binding by the same name, and for each export extending DurableObject (and for which storage has been configured via a migration), ctx.exports will contain a Durable Object namespace binding. This means you no longer have to configure these bindings explicitly in wrangler.jsonc/wrangler.toml.

Example:

import { WorkerEntrypoint } from "cloudflare:workers";

export class Greeter extends WorkerEntrypoint {
  greet(name) {
    return `Hello, ${name}!`;
  }
}

export default {
  async fetch(request, env, ctx) {
    let greeting = await ctx.exports.Greeter.greet("World")
    return new Response(greeting);
  }
}

At present, you must use the enable_ctx_exports compatibility flag to enable this API, though it will be on by default in the future.

See the API reference for more information.

Workers - Improved support for running multiple Workers with `wrangler dev`

Tue, 23 Sep 2025 00:00:00 GMT

You can run multiple Workers in a single dev command by passing multiple config files to wrangler dev:

wrangler dev --config ./web/wrangler.jsonc --config ./api/wrangler.jsonc

Previously, if you ran the command above and then also ran wrangler dev for a different Worker, the Workers running in separate wrangler dev sessions could not communicate with each other. This prevented you from being able to use Service Bindings and Tail Workers in local development, when running separate wrangler dev sessions.

Now, the following works as expected:

# Terminal 1: Run your application that includes both Web and API workers
wrangler dev --config ./web/wrangler.jsonc --config ./api/wrangler.jsonc

# Terminal 2: Run your auth worker separately
wrangler dev --config ./auth/wrangler.jsonc

These Workers can now communicate with each other across separate dev commands, regardless of your development setup.

export default {
  async fetch(request, env) {
    // This service binding call now works across dev commands
    const authorized = await env.AUTH.isAuthorized(request);

    if (!authorized) {
      return new Response('Unauthorized', { status: 401 });
    }

    return new Response('Hello from API Worker!', { status: 200 });
  },
};

Check out the Developing with multiple Workers guide to learn more about the different approaches and when to use each one.

Workers - Rate Limiting in Workers is now GA

Fri, 19 Sep 2025 00:00:00 GMT

Rate Limiting within Cloudflare Workers is now Generally Available (GA).

The ratelimit binding is now stable and recommended for all production workloads. Existing deployments using the unsafe binding will continue to function to allow for a smooth transition.

For more details, refer to Workers Rate Limiting documentation.

Workers - Panic Recovery for Rust Workers

Fri, 19 Sep 2025 00:00:00 GMT

In workers-rs, Rust panics were previously non-recoverable. A panic would put the Worker into an invalid state, and further function calls could result in memory overflows or exceptions.

Now, when a panic occurs, in-flight requests will throw 500 errors, but the Worker will automatically and instantly recover for future requests.

This ensures more reliable deployments. Automatic panic recovery is enabled for all new workers-rs deployments as of version 0.6.5, with no configuration required.

Fixing Rust Panics with Wasm Bindgen

Rust Workers are built with Wasm Bindgen, which treats panics as non-recoverable. After a panic, the entire Wasm application is considered to be in an invalid state.

We now attach a default panic handler in Rust:

std::panic::set_hook(Box::new(move |panic_info| {
  hook_impl(panic_info);
}));

Which is registered by default in the JS initialization:

import { setPanicHook } from "./index.js";
setPanicHook(function (err) {
  console.error("Panic handler!", err);
});

When a panic occurs, we reset the Wasm state to revert the Wasm application to how it was when the application started.

Resetting VM State in Wasm Bindgen

We worked upstream on the Wasm Bindgen project to implement a new --experimental-reset-state-function compilation option which outputs a new __wbg_reset_state function.

This function clears all internal state related to the Wasm VM, and updates all function bindings in place to reference the new WebAssembly instance.

One other necessary change here was associating Wasm-created JS objects with an instance identity. If a JS object created by an earlier instance is then passed into a new instance later on, a new "stale object" error is specially thrown when using this feature.

Layered Solution

Building on this new Wasm Bindgen feature, layered with our new default panic handler, we also added a proxy wrapper to ensure all top-level exported class instantiations (such as for Rust Durable Objects) are tracked and fully reinitialized when resetting the Wasm instance. This was necessary because the workerd runtime will instantiate exported classes, which would then be associated with the Wasm instance.

This approach now provides full panic recovery for Rust Workers on subsequent requests.

Of course, we never want panics, but when they do happen they are isolated and can be investigated further from the error logs - avoiding broader service disruption.

WebAssembly Exception Handling

In the future, full support for recoverable panics could be implemented without needing reinitialization at all, utilizing the WebAssembly Exception Handling proposal, part of the newly announced WebAssembly 3.0 specification. This would allow unwinding panics as normal JS errors, and concurrent requests would no longer fail.

We're making significant improvements to the reliability of Rust Workers. Join us in #rust-on-workers on the Cloudflare Developers Discord to stay updated.

Workers - Increased vCPU for Workers Builds on paid plans

Thu, 18 Sep 2025 00:00:00 GMT

We recently increased the available disk space from 8 GB to 20 GB for all plans. Building on that improvement, we’re now doubling the CPU power available for paid plans — from 2 vCPU to 4 vCPU.

These changes continue our focus on making Workers Builds faster and more reliable.

Metric	Free Plan	Paid Plans
CPU	2 vCPU	4 vCPU

Performance Improvements

Fast build times: Even single-threaded workloads benefit from having more vCPUs
2x faster multi-threaded builds: Tools like esbuild and webpack can now utilize additional cores, delivering near-linear performance scaling

All other build limits — including memory, build minutes, and timeout remain unchanged.

Workers - Preview URLs now default to opt-in

Wed, 17 Sep 2025 00:00:00 GMT

To prevent the accidental exposure of applications, we've updated how Worker preview URLs (<PREVIEW>-<WORKER_NAME>.<SUBDOMAIN>.workers.dev) are handled. We made this change to ensure preview URLs are only active when intentionally configured, improving the default security posture of your Workers.

One-Time Update for Workers with workers.dev Disabled

We performed a one-time update to disable preview URLs for existing Workers where the workers.dev subdomain was also disabled.

Because preview URLs were historically enabled by default, users who had intentionally disabled their workers.dev route may not have realized their Worker was still accessible at a separate preview URL. This update was performed to ensure that using a preview URL is always an intentional, opt-in choice.

If your Worker was affected, its preview URL (<PREVIEW>-<WORKER_NAME>.<SUBDOMAIN>.workers.dev) will now direct to an informational page explaining this change.

How to Re-enable Your Preview URL

If your preview URL was disabled, you can re-enable it via the Cloudflare dashboard by navigating to your Worker's Settings page and toggling on the Preview URL.

Alternatively, you can use Wrangler by adding the preview_urls = true setting to your Wrangler file and redeploying the Worker.

wrangler.jsonc
```
{
  "preview_urls": true
}
```
wrangler.toml
```
preview_urls = true
```

Note: You can set preview_urls = true with any Wrangler version that supports the preview URL flag (v3.91.0+). However, we recommend updating to v4.34.0 or newer, as this version defaults preview_urls to false, ensuring preview URLs are always enabled by explicit choice.

Workers - Remote bindings GA - Connect to remote resources (D1, KV, R2, etc.) during local development

Tue, 16 Sep 2025 00:00:00 GMT

Three months ago we announced the public beta of remote bindings for local development. Now, we're excited to say that it's available for everyone in Wrangler, Vite, and Vitest without using an experimental flag!

With remote bindings, you can now connect to deployed resources like R2 buckets and D1 databases while running Worker code on your local machine. This means you can test your local code changes against real data and services, without the overhead of deploying for each iteration.

Example configuration

To enable remote bindings, add "remote" : true to each binding that you want to rely on a remote resource running on Cloudflare:

wrangler.jsonc

{
  "name": "my-worker",
  // Set this to today's date
  "compatibility_date": "2026-04-03",

  "r2_buckets": [
    {
      "bucket_name": "screenshots-bucket",
      "binding": "screenshots_bucket",
      "remote": true,
    },
  ],
}

wrangler.toml

name = "my-worker"
# Set this to today's date
compatibility_date = "2026-04-03"

[[r2_buckets]]
bucket_name = "screenshots-bucket"
binding = "screenshots_bucket"
remote = true

When remote bindings are configured, your Worker still executes locally, but all binding calls are proxied to the deployed resource that runs on Cloudflare's network.

You can try out remote bindings for local development today with:

D1, Workers - D1 automatically retries read-only queries

Thu, 11 Sep 2025 00:00:00 GMT

D1 now detects read-only queries and automatically attempts up to two retries to execute those queries in the event of failures with retryable errors. You can access the number of execution attempts in the returned response metadata property total_attempts.

At the moment, only read-only queries are retried, that is, queries containing only the following SQLite keywords: SELECT, EXPLAIN, WITH. Queries containing any SQLite keyword that leads to database writes are not retried.

The retry success ratio among read-only retryable errors varies from 5% all the way up to 95%, depending on the underlying error and its duration (like network errors or other internal errors).

The retry success ratio among all retryable errors is lower, indicating that there are write-queries that could be retried. Therefore, we recommend D1 users to continue applying retries in their own code for queries that are not read-only but are idempotent according to the business logic of the application.

D1 ensures that any retry attempt does not cause database writes, making the automatic retries safe from side-effects, even if a query causing changes slips through the read-only detection. D1 achieves this by checking for modifications after every query execution, and if any write occurred due to a retry attempt, the query is rolled back.

The read-only query detection heuristics are simple for now, and there is room for improvement to capture more cases of queries that can be retried, so this is just the beginning.

Workers - Worker version rollback limit increased from 10 to 100

Thu, 11 Sep 2025 00:00:00 GMT

The number of recent versions available for a Worker rollback has been increased from 10 to 100.

This allows you to:

Promote any of the 100 most recent versions to be the active deployment.
Split traffic using gradual deployments between your latest code and any of the 100 most recent versions.

You can do this through the Cloudflare dashboard or with Wrangler's rollback command

Learn more about versioned deployments and rollbacks.

Agents, Workers - Agents SDK v0.1.0 and workers-ai-provider v2.0.0 with AI SDK v5 support

Wed, 10 Sep 2025 00:00:00 GMT

We've shipped a new release for the Agents SDK bringing full compatibility with AI SDK v5 and introducing automatic message migration that handles all legacy formats transparently.

This release includes improved streaming and tool support, tool confirmation detection (for "human in the loop" systems), enhanced React hooks with automatic tool resolution, improved error handling for streaming responses, and seamless migration utilities that work behind the scenes.

Additionally, we've updated workers-ai-provider v2.0.0, the official provider for Cloudflare Workers AI models, to be compatible with AI SDK v5.

useAgentChat(options)

Creates a new chat interface with enhanced v5 capabilities.

// Basic chat setup
const { messages, sendMessage, addToolResult } = useAgentChat({
  agent,
  experimental_automaticToolResolution: true,
  tools,
});

// With custom tool confirmation
const chat = useAgentChat({
  agent,
  experimental_automaticToolResolution: true,
  toolsRequiringConfirmation: ["dangerousOperation"],
});

Automatic Tool Resolution

Tools are automatically categorized based on their configuration:

const tools = {
  // Auto-executes (has execute function)
  getLocalTime: {
    description: "Get current local time",
    inputSchema: z.object({}),
    execute: async () => new Date().toLocaleString(),
  },

  // Requires confirmation (no execute function)
  deleteFile: {
    description: "Delete a file from the system",
    inputSchema: z.object({
      filename: z.string(),
    }),
  },

  // Server-executed (no client confirmation)
  analyzeData: {
    description: "Analyze dataset on server",
    inputSchema: z.object({ data: z.array(z.number()) }),
    serverExecuted: true,
  },
} satisfies Record<string, AITool>;

Message Handling

Send messages using the new v5 format with parts array:

// Text message
sendMessage({
  role: "user",
  parts: [{ type: "text", text: "Hello, assistant!" }],
});

// Multi-part message with file
sendMessage({
  role: "user",
  parts: [
    { type: "text", text: "Analyze this image:" },
    { type: "image", image: imageData },
  ],
});

Tool Confirmation Detection

Simplified logic for detecting pending tool confirmations:

const pendingToolCallConfirmation = messages.some((m) =>
  m.parts?.some(
    (part) => isToolUIPart(part) && part.state === "input-available",
  ),
);

// Handle tool confirmation
if (pendingToolCallConfirmation) {
  await addToolResult({
    toolCallId: part.toolCallId,
    tool: getToolName(part),
    output: "User approved the action",
  });
}

Automatic Message Migration

Seamlessly handle legacy message formats without code changes.

// All these formats are automatically converted:

// Legacy v4 string content
const legacyMessage = {
  role: "user",
  content: "Hello world",
};

// Legacy v4 with tool calls
const legacyWithTools = {
  role: "assistant",
  content: "",
  toolInvocations: [
    {
      toolCallId: "123",
      toolName: "weather",
      args: { city: "SF" },
      state: "result",
      result: "Sunny, 72°F",
    },
  ],
};

// Automatically becomes v5 format:
// {
//   role: "assistant",
//   parts: [{
//     type: "tool-call",
//     toolCallId: "123",
//     toolName: "weather",
//     args: { city: "SF" },
//     state: "result",
//     result: "Sunny, 72°F"
//   }]
// }

Tool Definition Updates

Migrate tool definitions to use the new inputSchema property.

// Before (AI SDK v4)
const tools = {
  weather: {
    description: "Get weather information",
    parameters: z.object({
      city: z.string(),
    }),
    execute: async (args) => {
      return await getWeather(args.city);
    },
  },
};

// After (AI SDK v5)
const tools = {
  weather: {
    description: "Get weather information",
    inputSchema: z.object({
      city: z.string(),
    }),
    execute: async (args) => {
      return await getWeather(args.city);
    },
  },
};

Cloudflare Workers AI Integration

Seamless integration with Cloudflare Workers AI models through the updated workers-ai-provider v2.0.0.

Model Setup with Workers AI

Use Cloudflare Workers AI models directly in your agent workflows:

import { createWorkersAI } from "workers-ai-provider";
import { useAgentChat } from "agents/ai-react";

// Create Workers AI model (v2.0.0 - same API, enhanced v5 internals)
const model = createWorkersAI({
  binding: env.AI,
})("@cf/meta/llama-3.2-3b-instruct");

Enhanced File and Image Support

Workers AI models now support v5 file handling with automatic conversion:

// Send images and files to Workers AI models
sendMessage({
  role: "user",
  parts: [
    { type: "text", text: "Analyze this image:" },
    {
      type: "file",
      data: imageBuffer,
      mediaType: "image/jpeg",
    },
  ],
});

// Workers AI provider automatically converts to proper format

Streaming with Workers AI

Enhanced streaming support with automatic warning detection:

// Streaming with Workers AI models
const result = await streamText({
  model: createWorkersAI({ binding: env.AI })("@cf/meta/llama-3.2-3b-instruct"),
  messages,
  onChunk: (chunk) => {
    // Enhanced streaming with warning handling
    console.log(chunk);
  },
});

Import Updates

Update your imports to use the new v5 types:

// Before (AI SDK v4)
import type { Message } from "ai";
import { useChat } from "ai/react";

// After (AI SDK v5)
import type { UIMessage } from "ai";
// or alias for compatibility
import type { UIMessage as Message } from "ai";
import { useChat } from "@ai-sdk/react";

Resources

Migration Guide - Comprehensive migration documentation
AI SDK v5 Documentation - Official AI SDK migration guide
An Example PR showing the migration from AI SDK v4 to v5
GitHub Issues - Report bugs or request features

Feedback Welcome

We'd love your feedback! We're particularly interested in feedback on:

Migration experience - How smooth was the upgrade process?
Tool confirmation workflow - Does the new automatic detection work as expected?
Message format handling - Any edge cases with legacy message conversion?

Workers - Built with Cloudflare button

Wed, 10 Sep 2025 00:00:00 GMT

We've updated our "Built with Cloudflare" button to make it easier to share that you're building on Cloudflare with the world. Embed it in your project's README, blog post, or wherever you want to let people know.

Check out the documentation for usage information.

Workers - Deploy static sites to Workers without a configuration file

Tue, 09 Sep 2025 00:00:00 GMT

Deploying static site to Workers is now easier. When you run wrangler deploy [directory] or wrangler deploy --assets [directory] without an existing configuration file, Wrangler CLI now guides you through the deployment process with interactive prompts.

Before and after

Before: Required remembering multiple flags and parameters

wrangler deploy --assets ./dist --compatibility-date 2025-09-09 --name my-project

After: Simple directory deployment with guided setup

wrangler deploy dist
# Interactive prompts handle the rest as shown in the example flow below

What's new

Interactive prompts for missing configuration:

Wrangler detects when you're trying to deploy a directory of static assets
Prompts you to confirm the deployment type
Asks for a project name (with smart defaults)
Automatically sets the compatibility date to today

Automatic configuration generation:

Creates a wrangler.jsonc file with your deployment settings
Stores your choices for future deployments
Eliminates the need to remember complex command-line flags

Example workflow

# Deploy your built static site
wrangler deploy dist

# Wrangler will prompt:
✔ It looks like you are trying to deploy a directory of static assets only. Is this correct? … yes
✔ What do you want to name your project? … my-astro-site

# Automatically generates a wrangler.jsonc file and adds it to your project:
{
  "name": "my-astro-site",
  "compatibility_date": "2025-09-09",
  "assets": {
    "directory": "dist"
  }
}

# Next time you run wrangler deploy, this will use the configuration in your newly generated wrangler.jsonc file
wrangler deploy

Requirements

You must use Wrangler version 4.24.4 or later in order to use this feature

Workers, Workers for Platforms - Increased static asset limits for Workers

Thu, 04 Sep 2025 00:00:00 GMT

You can now upload up to 100,000 static assets per Worker version

Paid and Workers for Platforms users can now upload up to 100,000 static assets per Worker version, a 5x increase from the previous limit of 20,000.
Customers on the free plan still have the same limit as before — 20,000 static assets per version of your Worker
The individual file size limit of 25 MiB remains unchanged for all customers.

This increase allows you to build larger applications with more static assets without hitting limits.

Wrangler

To take advantage of the increased limits, you must use Wrangler version 4.34.0 or higher. Earlier versions of Wrangler will continue to enforce the previous 20,000 file limit.

Learn more

For more information about Workers static assets, see the Static Assets documentation and Platform Limits.

Workers - A new, simpler REST API for Cloudflare Workers (Beta)

Thu, 04 Sep 2025 00:00:00 GMT

You can now manage Workers, Versions, and Deployments as separate resources with a new, resource-oriented API (Beta).

This new API is supported in the Cloudflare Terraform provider and the Cloudflare Typescript SDK, allowing platform teams to manage a Worker's infrastructure in Terraform, while development teams handle code deployments from a separate repository or workflow. We also designed this API with AI agents in mind, as a clear, predictable structure is essential for them to reliably build, test, and deploy applications.

Try it out

New beta API endpoints
Cloudflare TypeScript SDK v5.0.0
Cloudflare Go SDK v6.0.0
Terraform provider v5.9.0: cloudflare_worker , cloudflare_worker_version, and cloudflare_workers_deployments resources.
See full examples in our Infrastructure as Code (IaC) guide

Before: Eight+ endpoints with mixed responsibilities

The existing API was originally designed for simple, one-shot script uploads:

curl -X PUT "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/scripts/$SCRIPT_NAME" \
    -H "X-Auth-Email: $CLOUDFLARE_EMAIL" \
    -H "X-Auth-Key: $CLOUDFLARE_API_KEY" \
    -H "Content-Type: multipart/form-data" \
    -F 'metadata={
      "main_module": "worker.js",
      "compatibility_date": "$today$"
    }' \
    -F "worker.js=@worker.js;type=application/javascript+module"

This API worked for creating a basic Worker, uploading all of its code, and deploying it immediately — but came with challenges:

A Worker couldn't exist without code: To create a Worker, you had to upload its code in the same API request. This meant platform teams couldn't provision Workers with the proper settings, and then hand them off to development teams to deploy the actual code.
Several endpoints implicitly created deployments: Simple updates like adding a secret or changing a script's content would implicitly create a new version and immediately deploy it.
Updating a setting was confusing: Configuration was scattered across eight endpoints with overlapping responsibilities. This ambiguity made it difficult for human developers (and even more so for AI agents) to reliably update a Worker via API.
Scripts used names as primary identifiers: This meant simple renames could turn into a risky migration, requiring you to create a brand new Worker and update every reference. If you were using Terraform, this could inadvertently destroy your Worker altogether.

After: Three resources with clear boundaries

All endpoints now use simple JSON payloads, with script content embedded as base64-encoded strings -- a more consistent and reliable approach than the previous multipart/form-data format.

Worker: The parent resource representing your application. It has a stable UUID and holds persistent settings like name, tags, and logpush. You can now create a Worker to establish its identity and settings before any code is uploaded.
Version: An immutable snapshot of your code and its specific configuration, like bindings and compatibility_date. Creating a new version is a safe action that doesn't affect live traffic.
Deployment: An explicit action that directs traffic to a specific version.

Why this matters

You can now create Workers before uploading code

Workers are now standalone resources that can be created and configured without any code. Platform teams can provision Workers with the right settings, then hand them off to development teams for implementation.

Example: Typescript SDK

// Step 1: Platform team creates the Worker resource (no code needed)
const worker = await client.workers.beta.workers.create({
  name: "payment-service",
  account_id: "...",
  observability: {
    enabled: true,
  },
});

// Step 2: Development team adds code and creates a version later
const version = await client.workers.beta.workers.versions.create(worker.id, {
  account_id: "...",
  main_module: "worker.js",
  compatibility_date: "$today",
  bindings: [ /*...*/ ],
  modules: [
    {
      name: "worker.js",
      content_type: "application/javascript+module",
      content_base64: Buffer.from(scriptContent).toString("base64"),
    },
  ],
});

// Step 3: Deploy explicitly when ready
const deployment = await client.workers.scripts.deployments.create(worker.name, {
  account_id: "...",
  strategy: "percentage",
  versions: [
    {
      percentage: 100,
      version_id: version.id,
    },
  ],
});

Example: Terraform

If you use Terraform, you can now declare the Worker in your Terraform configuration and manage configuration outside of Terraform in your Worker's wrangler.jsonc file and deploy code changes using Wrangler.

resource "cloudflare_worker" "my_worker" {
  account_id = "..."
  name = "my-important-service"
}
# Manage Versions and Deployments here or outside of Terraform
# resource "cloudflare_worker_version" "my_worker_version" {}
# resource "cloudflare_workers_deployment" "my_worker_deployment" {}

Deployments are always explicit, never implicit

Creating a version and deploying it are now always explicit, separate actions - never implicit side effects. To update version-specific settings (like bindings), you create a new version with those changes. The existing deployed version remains unchanged until you explicitly deploy the new one.

# Step 1: Create a new version with updated settings (doesn't affect live traffic)
POST /workers/workers/{id}/versions
{
  "compatibility_date": "$today",
  "bindings": [
    {
      "name": "MY_NEW_ENV_VAR",
      "text": "new_value",
      "type": "plain_text"
    }
  ],
  "modules": [...]
}

# Step 2: Explicitly deploy when ready (now affects live traffic)
POST /workers/scripts/{script_name}/deployments
{
  "strategy": "percentage",
  "versions": [
    {
      "percentage": 100,
      "version_id": "new_version_id"
    }
  ]
}

Settings are clearly organized by scope

Configuration is now logically divided: Worker settings (like name and tags) persist across all versions, while Version settings (like bindings and compatibility_date) are specific to each code snapshot.

# Worker settings (the parent resource)
PUT /workers/workers/{id}
{
  "name": "payment-service",
  "tags": ["production"],
  "logpush": true,
}

# Version settings (the "code")
POST /workers/workers/{id}/versions
{
  "compatibility_date": "$today",
  "bindings": [...],
  "modules": [...]
}

`/workers` API endpoints now support UUIDs (in addition to names)

The /workers/workers/ path now supports addressing a Worker by both its immutable UUID and its mutable name.

# Both work for the same Worker
GET /workers/workers/29494978e03748669e8effb243cf2515  # UUID (stable for automation)
GET /workers/workers/payment-service                  # Name (convenient for humans)

This dual approach means:

Developers can use readable names for debugging.
Automation can rely on stable UUIDs to prevent errors when Workers are renamed.
Terraform can rename Workers without destroying and recreating them.

Learn more

Technical notes

The pre-existing Workers REST API remains fully supported. Once the new API exits beta, we'll provide a migration timeline with ample notice and comprehensive migration guides.
Existing Terraform resources and SDK methods will continue to be fully supported through the current major version.
While the Deployments API currently remains on the /scripts/ endpoint, we plan to introduce a new Deployments endpoint under /workers/ to match the new API structure.

Workers - Content type returned in Workers Assets for Javascript files is now `text/javascript`

Mon, 25 Aug 2025 00:00:00 GMT

JavaScript asset responses have been updated to use the text/javascript Content-Type header instead of application/javascript. While both MIME types are widely supported by browsers, the HTML Living Standard explicitly recommends text/javascript as the preferred type going forward.

This change improves:

Standards alignment: Ensures consistency with the HTML spec and modern web platform guidance.
Interoperability: Some developer tools, validators, and proxies expect text/javascript and may warn or behave inconsistently with application/javascript.
Future-proofing: By following the spec-preferred MIME type, we reduce the risk of deprecation warnings or unexpected behavior in evolving browser environments.
Consistency: Most frameworks, CDNs, and hosting providers now default to text/javascript, so this change matches common ecosystem practice.

Because all major browsers accept both MIME types, this update is backwards compatible and should not cause breakage.

Users will see this change on the next deployment of their assets.

Workflows, Workers - Build durable multi-step applications in Python with Workflows (now in beta)

Fri, 22 Aug 2025 00:00:00 GMT

You can now build Workflows using Python. With Python Workflows, you get automatic retries, state persistence, and the ability to run multi-step operations that can span minutes, hours, or weeks using Python’s familiar syntax and the Python Workers runtime.

Python Workflows use the same step-based execution model as JavaScript Workflows, but with Python syntax and access to Python’s ecosystem. Python Workflows also enable DAG (Directed Acyclic Graph) workflows, where you can define complex dependencies between steps using the depends parameter.

Here’s a simple example:

from workers import Response, WorkflowEntrypoint

class PythonWorkflowStarter(WorkflowEntrypoint):
    async def run(self, event, step):
        @step.do("my first step")
        async def my_first_step():
            # do some work
            return "Hello Python!"

        await my_first_step()

        await step.sleep("my-sleep-step", "10 seconds")

        @step.do("my second step")
        async def my_second_step():
            # do some more work
            return "Hello again!"

        await my_second_step()

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        await self.env.MY_WORKFLOW.create()
        return Response("Hello Workflow creation!")

Python Workflows support the same core capabilities as JavaScript Workflows, including sleep scheduling, event-driven workflows, and built-in error handling with configurable retry policies.

To learn more and get started, refer to Python Workflows documentation.

Durable Objects, Workers - New getByName() API to access Durable Objects

Thu, 21 Aug 2025 00:00:00 GMT

You can now create a client (a Durable Object stub) to a Durable Object with the new getByName method, removing the need to convert Durable Object names to IDs and then create a stub.

// Before: (1) translate name to ID then (2) get a client
const objectId = env.MY_DURABLE_OBJECT.idFromName("foo"); // or .newUniqueId()
const stub = env.MY_DURABLE_OBJECT.get(objectId);

// Now: retrieve client to Durable Object directly via its name
const stub = env.MY_DURABLE_OBJECT.getByName("foo");

// Use client to send request to the remote Durable Object
const rpcResponse = await stub.sayHello();

Each Durable Object has a globally-unique name, which allows you to send requests to a specific object from anywhere in the world. Thus, a Durable Object can be used to coordinate between multiple clients who need to work together. You can have billions of Durable Objects, providing isolation between application tenants.

To learn more, visit the Durable Objects API Documentation or the getting started guide.

Workers - Easier debugging in Workers with improved Wrangler error screen

Tue, 19 Aug 2025 00:00:00 GMT

Wrangler's error screen has received several improvements to enhance your debugging experience!

The error screen now features a refreshed design thanks to youch, with support for both light and dark themes, improved source map resolution logic that handles missing source files more reliably, and better error cause display.

Before	After (Light)	After (Dark)

Try it out now with npx wrangler@latest dev in your Workers project.

Workers - The Node.js and Web File System APIs in Workers

Fri, 15 Aug 2025 00:00:00 GMT

Implementations of the node:fs module and the Web File System API are now available in Workers.

Using the `node:fs` module

The node:fs module provides access to a virtual file system in Workers. You can use it to read and write files, create directories, and perform other file system operations.

The virtual file system is ephemeral with each individual request havig its own isolated temporary file space. Files written to the file system will not persist across requests and will not be shared across requests or across different Workers.

Workers running with the nodejs_compat compatibility flag will have access to the node:fs module by default when the compatibility date is set to 2025-09-01 or later. Support for the API can also be enabled using the enable_nodejs_fs_module compatibility flag together with the nodejs_compat flag. The node:fs module can be disabled using the disable_nodejs_fs_module compatibility flag.

import fs from "node:fs";

const config = JSON.parse(fs.readFileSync("/bundle/config.json", "utf-8"));

export default {
  async fetch(request) {
    return new Response(`Config value: ${config.value}`);
  },
};

There are a number of initial limitations to the node:fs implementation:

The glob APIs (e.g. fs.globSync(...)) are not implemented.
The file watching APIs (e.g. fs.watch(...)) are not implemented.
The file timestamps (modified time, access time, etc) are only partially supported. For now, these will always return the Unix epoch.

Refer to the Node.js documentation for more information on the node:fs module and its APIs.

The Web File System API

The Web File System API provides access to the same virtual file system as the node:fs module, but with a different API surface. The Web File System API is only available in Workers running with the enable_web_file_system compatibility flag. The nodejs_compat compatibility flag is not required to use the Web File System API.

const root = navigator.storage.getDirectory();

export default {
  async fetch(request) {
    const tmp = await root.getDirectoryHandle("/tmp");
    const file = await tmp.getFileHandle("data.txt", { create: true });
    const writable = await file.createWritable();
    const writer = writable.getWriter();
    await writer.write("Hello, World!");
    await writer.close();

    return new Response("File written successfully!");
  },
};

As there are still some parts of the Web File System API tht are not fully standardized, there may be some differences between the Workers implementation and the implementations in browsers.

Workers - Workers Static Assets: Corrected handling of double slashes in redirect rule paths

Fri, 15 Aug 2025 00:00:00 GMT

Static Assets: Fixed a bug in how redirect rules defined in your Worker's _redirects file are processed.

If you're serving Static Assets with a _redirects file containing a rule like /ja/* /:splat, paths with double slashes were previously misinterpreted as external URLs. For example, visiting /ja//example.com would incorrectly redirect to https://example.com instead of /example.com on your domain. This has been fixed and double slashes now correctly resolve as local paths. Note: Cloudflare Pages was not affected by this issue.

Workers - Workers per-branch preview URLs now support long branch names

Thu, 14 Aug 2025 01:00:00 GMT

We've updated preview URLs for Cloudflare Workers to support long branch names.

Previously, branch and Worker names exceeding the 63-character DNS limit would cause alias generation to fail, leaving pull requests without aliased preview URLs. This particularly impacted teams relying on descriptive branch naming.

Now, Cloudflare automatically truncates long branch names and appends a unique hash, ensuring every pull request gets a working preview link.

How it works

63 characters or less: <branch-name>-<worker-name> → Uses actual branch name as is
64 characters or more: <truncated-branch-name>--<hash>-<worker-name> → Uses truncated name with 4-character hash
Hash generation: The hash is derived from the full branch name to ensure uniqueness
Stable URLs: The same branch always generates the same hash across all commits

Requirements and compatibility

Wrangler 4.30.0 or later: This feature requires updating to wrangler@4.30.0+
No configuration needed: Works automatically with existing preview URL setups

Workers - Python Workers handlers now live in an entrypoint class

Thu, 14 Aug 2025 00:00:00 GMT

We are changing how Python Workers are structured by default. Previously, handlers were defined at the top-level of a module as on_fetch, on_scheduled, etc. methods, but now they live in an entrypoint class.

Here's an example of how to now define a Worker with a fetch handler:

from workers import Response, WorkerEntrypoint

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        return Response("Hello World!")

To keep using the old-style handlers, you can specify the disable_python_no_global_handlers compatibility flag in your wrangler file:

wrangler.jsonc

{
  "compatibility_flags": [
    "disable_python_no_global_handlers"
  ]
}

wrangler.toml

compatibility_flags = [ "disable_python_no_global_handlers" ]

Consult the Python Workers documentation for more details.

Workers - Terraform provider improvements — Python Workers support, smaller plan diffs, and API SDK fixes

Thu, 14 Aug 2025 00:00:00 GMT

The recent Cloudflare Terraform Provider and SDK releases (such as cloudflare-typescript) bring significant improvements to the Workers developer experience. These updates focus on reliability, performance, and adding Python Workers support.

Terraform Improvements

Fixed Unwarranted Plan Diffs

Resolved several issues with the cloudflare_workers_script resource that resulted in unwarranted plan diffs, including:

Using Durable Objects migrations
Using some bindings such as secret_text
Using smart placement

A resource should never show a plan diff if there isn't an actual change. This fix reduces unnecessary noise in your Terraform plan and is available in Cloudflare Terraform Provider 5.8.0.

Improved File Management

You can now specify content_file and content_sha256 instead of content. This prevents the Workers script content from being stored in the state file which greatly reduces plan diff size and noise. If your workflow synced plans remotely, this should now happen much faster since there is less data to sync. This is available in Cloudflare Terraform Provider 5.7.0.

resource "cloudflare_workers_script" "my_worker" {
  account_id      = "123456789"
  script_name     = "my_worker"
  main_module     = "worker.mjs"
  content_file    = "worker.mjs"
  content_sha256  = filesha256("worker.mjs")
}

Assets Headers and Redirects Support

Fixed the cloudflare_workers_script resource to properly support headers and redirects for Assets:

resource "cloudflare_workers_script" "my_worker" {
  account_id      = "123456789"
  script_name     = "my_worker"
  main_module     = "worker.mjs"
  content_file    = "worker.mjs"
  content_sha256  = filesha256("worker.mjs")
  assets = {
    config = {
      headers = file("_headers")
      redirects = file("_redirects")
    }
    # Completion jwt from:
    # https://developers.cloudflare.com/api/resources/workers/subresources/assets/subresources/upload/
    jwt = "jwt"
  }
}

Available in Cloudflare Terraform Provider 5.8.0.

Python Workers Support

Added support for uploading Python Workers (beta) in Terraform. You can now deploy Python Workers with:

resource "cloudflare_workers_script" "my_worker" {
  account_id       = "123456789"
  script_name      = "my_worker"
  content_file     = "worker.py"
  content_sha256   = filesha256("worker.py")
  content_type     = "text/x-python"
}

Available in Cloudflare Terraform Provider 5.8.0.

SDK Enhancements

Improved File Upload API

Fixed an issue where Workers script versions in the SDK did not allow uploading files. This now works, and also has an improved files upload interface:

const scriptContent = `
  export default {
    async fetch(request, env, ctx) {
      return new Response('Hello World!', { status: 200 });
    }
  };
`;

client.workers.scripts.versions.create('my-worker', {
  account_id: '123456789',
  metadata: {
    main_module: 'my-worker.mjs',
  },
  files: [
    await toFile(
      Buffer.from(scriptContent),
      'my-worker.mjs',
      {
        type: "application/javascript+module",
      }
    )
  ]
});

Will be available in cloudflare-typescript 4.6.0. A similar change will be available in cloudflare-python 4.4.0.

Fixed updating KV values

Previously when creating a KV value like this:

await cf.kv.namespaces.values.update("my-kv-namespace", "key1", {
  account_id: "123456789",
  metadata: "my metadata",
  value: JSON.stringify({
    hello: "world"
  })
});

...and recalling it in your Worker like this:

const value = await c.env.KV.get<{hello: string}>("key1", "json");

You'd get back this: {metadata:'my metadata', value:"{'hello':'world'}"} instead of the correct value of {hello: 'world'}

This is fixed in cloudflare-typescript 4.5.0 and will be fixed in cloudflare-python 4.4.0.

Workers - MessageChannel and MessagePort

Mon, 11 Aug 2025 01:00:00 GMT

A minimal implementation of the MessageChannel API is now available in Workers. This means that you can use MessageChannel to send messages between different parts of your Worker, but not across different Workers.

The MessageChannel and MessagePort APIs will be available by default at the global scope with any worker using a compatibility date of 2025-08-15 or later. It is also available using the expose_global_message_channel compatibility flag, or can be explicitly disabled using the no_expose_global_message_channel compatibility flag.

const { port1, port2 } = new MessageChannel();

port2.onmessage = (event) => {
  console.log('Received message:', event.data);
};

port2.postMessage('Hello from port2!');

Any value that can be used with the structuredClone(...) API can be sent over the port.

Differences

There are a number of key limitations to the MessageChannel API in Workers:

Transfer lists are currently not supported. This means that you will not be able to transfer ownership of objects like ArrayBuffer or MessagePort between ports.
The MessagePort is not yet serializable. This means that you cannot send a MessagePort object through the postMessage method or via JSRPC calls.
The 'messageerror' event is only partially supported. If the 'onmessage' handler throws an error, the 'messageerror' event will be triggered, however, it will not be triggered when there are errors serializing or deserializing the message data. Instead, the error will be thrown when the postMessage method is called on the sending port.
The 'close' event will be emitted on both ports when one of the ports is closed, however it will not be emitted when the Worker is terminated or when one of the ports is garbage collected.

Workers - Wrangler and the Cloudflare Vite plugin support `.env` files in local development

Fri, 08 Aug 2025 01:00:00 GMT

Now, you can use .env files to provide secrets and override environment variables on the env object during local development with Wrangler and the Cloudflare Vite plugin.

Previously in local development, if you wanted to provide secrets or environment variables during local development, you had to use .dev.vars files. This is still supported, but you can now also use .env files, which are more familiar to many developers.

Using `.env` files in local development

You can create a .env file in your project root to define environment variables that will be used when running wrangler dev or vite dev. The .env file should be formatted like a dotenv file, such as KEY="VALUE":

TITLE="My Worker"
API_TOKEN="dev-token"

When you run wrangler dev or vite dev, the environment variables defined in the .env file will be available in your Worker code via the env object:

export default {
  async fetch(request, env) {
    const title = env.TITLE; // "My Worker"
    const apiToken = env.API_TOKEN; // "dev-token"
    const response = await fetch(
      `https://api.example.com/data?token=${apiToken}`,
    );
    return new Response(`Title: ${title} - ` + (await response.text()));
  },
};

Multiple environments with `.env` files

If your Worker defines multiple environments, you can set different variables for each environment (ex: production or staging) by creating files named .env.<environment-name>.

When you use wrangler <command> --env <environment-name> or CLOUDFLARE_ENV=<environment-name> vite dev, the corresponding environment-specific file will also be loaded and merged with the .env file.

For example, if you want to set different environment variables for the staging environment, you can create a file named .env.staging:

API_TOKEN="staging-token"

When you run wrangler dev --env staging or CLOUDFLARE_ENV=staging vite dev, the environment variables from .env.staging will be merged onto those from .env.

export default {
  async fetch(request, env) {
    const title = env.TITLE; // "My Worker" (from `.env`)
    const apiToken = env.API_TOKEN; // "staging-token" (from `.env.staging`, overriding the value from `.env`)
    const response = await fetch(
      `https://api.example.com/data?token=${apiToken}`,
    );
    return new Response(`Title: ${title} - ` + (await response.text()));
  },
};

Find out more

For more information on how to use .env files with Wrangler and the Cloudflare Vite plugin, see the following documentation:

Workers - Directly import `waitUntil` in Workers for easily spawning background tasks

Fri, 08 Aug 2025 00:00:00 GMT

You can now import waitUntil from cloudflare:workers to extend your Worker's execution beyond the request lifecycle from anywhere in your code.

Previously, waitUntil could only be accessed through the execution context (ctx) parameter passed to your Worker's handler functions. This meant that if you needed to schedule background tasks from deeply nested functions or utility modules, you had to pass the ctx object through multiple function calls to access waitUntil.

Now, you can import waitUntil directly and use it anywhere in your Worker without needing to pass ctx as a parameter:

import { waitUntil } from "cloudflare:workers";

export function trackAnalytics(eventData) {
  const analyticsPromise = fetch("https://analytics.example.com/track", {
    method: "POST",
    body: JSON.stringify(eventData),
  });

  // Extend execution to ensure analytics tracking completes
  waitUntil(analyticsPromise);
}

This is particularly useful when you want to:

Schedule background tasks from utility functions or modules
Extend execution for analytics, logging, or cleanup operations
Avoid passing the execution context through multiple layers of function calls

import { waitUntil } from "cloudflare:workers";

export default {
  async fetch(request, env, ctx) {
    // Background task that should complete even after response is sent
    cleanupTempData(env.KV_NAMESPACE);
    return new Response("Hello, World!");
  }
};

function cleanupTempData(kvNamespace) {
  // This function can now use waitUntil without needing ctx
  const deletePromise = kvNamespace.delete("temp-key");
  waitUntil(deletePromise);
}

For more information, see the waitUntil documentation.

Workers - Requests made from Cloudflare Workers can now force a revalidation of their cache with the origin

Thu, 07 Aug 2025 00:00:00 GMT

By setting the value of the cache property to no-cache, you can force Cloudflare's cache to revalidate its contents with the origin when making subrequests from Cloudflare Workers.

JavaScript

export default {
  async fetch(req, env, ctx) {
    const request = new Request("https://cloudflare.com", {
      cache: "no-cache",
    });
    const response = await fetch(request);
    return response;
  },
};

TypeScript

export default {
  async fetch(req, env, ctx): Promise<Response> {
    const request = new Request("https://cloudflare.com", { cache: 'no-cache'});
    const response = await fetch(request);
    return response;
  }
} satisfies ExportedHandler<Environment>

When no-cache is set, the Worker request will first look for a match in Cloudflare's cache, then:

If there is a match, a conditional request is sent to the origin, regardless of whether or not the match is fresh or stale. If the resource has not changed, the cached version is returned. If the resource has changed, it will be downloaded from the origin, updated in the cache, and returned.
If there is no match, Workers will make a standard request to the origin and cache the response.

This increases compatibility with NPM packages and JavaScript frameworks that rely on setting the cache property, which is a cross-platform standard part of the Request interface. Previously, if you set the cache property on Request to 'no-cache', the Workers runtime threw an exception.

Learn how the Cache works with Cloudflare Workers
Enable Node.js compatibility for your Cloudflare Worker
Explore Runtime APIs and Bindings available in Cloudflare Workers

Agents, Workers - Agents SDK adds MCP Elicitation support, http-streamable suppport, task queues, email integration and more

Tue, 05 Aug 2025 00:00:00 GMT

The latest releases of @cloudflare/agents brings major improvements to MCP transport protocols support and agents connectivity. Key updates include:

MCP elicitation support

MCP servers can now request user input during tool execution, enabling interactive workflows like confirmations, forms, and multi-step processes. This feature uses durable storage to preserve elicitation state even during agent hibernation, ensuring seamless user interactions across agent lifecycle events.

// Request user confirmation via elicitation
const confirmation = await this.elicitInput({
  message: `Are you sure you want to increment the counter by ${amount}?`,
  requestedSchema: {
    type: "object",
    properties: {
      confirmed: {
        type: "boolean",
        title: "Confirm increment",
        description: "Check to confirm the increment",
      },
    },
    required: ["confirmed"],
  },
});

Check out our demo to see elicitation in action.

HTTP streamable transport for MCP

MCP now supports HTTP streamable transport which is recommended over SSE. This transport type offers:

Better performance: More efficient data streaming and reduced overhead
Improved reliability: Enhanced connection stability and error recover- Automatic fallback: If streamable transport is not available, it gracefully falls back to SSE

export default MyMCP.serve("/mcp", {
  binding: "MyMCP",
});

The SDK automatically selects the best available transport method, gracefully falling back from streamable-http to SSE when needed.

Enhanced MCP connectivity

Significant improvements to MCP server connections and transport reliability:

Auto transport selection: Automatically determines the best transport method, falling back from streamable-http to SSE as needed
Improved error handling: Better connection state management and error reporting for MCP servers
Reliable prop updates: Centralized agent property updates ensure consistency across different contexts

Lightweight .queue for fast task deferral

You can use .queue() to enqueue background work — ideal for tasks like processing user messages, sending notifications etc.

class MyAgent extends Agent {
  doSomethingExpensive(payload) {
    // a long running process that you want to run in the background
  }

  queueSomething() {
    await this.queue("doSomethingExpensive", somePayload); // this will NOT block further execution, and runs in the background
    await this.queue("doSomethingExpensive", someOtherPayload); // the callback will NOT run until the previous callback is complete
    // ... call as many times as you want
  }
}

Want to try it yourself? Just define a method like processMessage in your agent, and you’re ready to scale.

New email adapter

Want to build an AI agent that can receive and respond to emails automatically? With the new email adapter and onEmail lifecycle method, now you can.

export class EmailAgent extends Agent {
  async onEmail(email: AgentEmail) {
    const raw = await email.getRaw();
    const parsed = await PostalMime.parse(raw);

    // create a response based on the email contents
    // and then send a reply

    await this.replyToEmail(email, {
      fromName: "Email Agent",
      body: `Thanks for your email! You've sent us "${parsed.subject}". We'll process it shortly.`,
    });
  }
}

You route incoming mail like this:

export default {
  async email(email, env) {
    await routeAgentEmail(email, env, {
      resolver: createAddressBasedEmailResolver("EmailAgent"),
    });
  },
};

You can find a full example here.

Automatic context wrapping for custom methods

Custom methods are now automatically wrapped with the agent's context, so calling getCurrentAgent() should work regardless of where in an agent's lifecycle it's called. Previously this would not work on RPC calls, but now just works out of the box.

export class MyAgent extends Agent {
  async suggestReply(message) {
    // getCurrentAgent() now correctly works, even when called inside an RPC method
    const { agent } = getCurrentAgent()!;
    return generateText({
      prompt: `Suggest a reply to: "${message}" from "${agent.name}"`,
      tools: [replyWithEmoji],
    });
  }
}

Try it out and tell us what you build!

Agents, Workers - Cloudflare Sandbox SDK adds streaming, code interpreter, Git support, process control and more

Tue, 05 Aug 2025 00:00:00 GMT

We’ve shipped a major release for the @cloudflare/sandbox SDK, turning it into a full-featured, container-based execution platform that runs securely on Cloudflare Workers.

This update adds live streaming of output, persistent Python and JavaScript code interpreters with rich output support (charts, tables, HTML, JSON), file system access, Git operations, full background process control, and the ability to expose running services via public URLs.

This makes it ideal for building AI agents, CI runners, cloud REPLs, data analysis pipelines, or full developer tools — all without managing infrastructure.

Code interpreter (Python, JS, TS)

Create persistent code contexts with support for rich visual + structured outputs.

createCodeContext(options)

Creates a new code execution context with persistent state.

// Create a Python context
const pythonCtx = await sandbox.createCodeContext({ language: "python" });

// Create a JavaScript context
const jsCtx = await sandbox.createCodeContext({ language: "javascript" });

Options:

language: Programming language ('python' | 'javascript' | 'typescript')
cwd: Working directory (default: /workspace)
envVars: Environment variables for the context

runCode(code, options)

Executes code with optional streaming callbacks.

// Simple execution
const execution = await sandbox.runCode('print("Hello World")', {
  context: pythonCtx,
});

// With streaming callbacks
await sandbox.runCode(
  `
for i in range(5):
    print(f"Step {i}")
    time.sleep(1)
`,
  {
    context: pythonCtx,
    onStdout: (output) => console.log("Real-time:", output.text),
    onResult: (result) => console.log("Result:", result),
  },
);

Options:

language: Programming language ('python' | 'javascript' | 'typescript')
cwd: Working directory (default: /workspace)
envVars: Environment variables for the context

Real-time streaming output

Returns a streaming response for real-time processing.

const stream = await sandbox.runCodeStream(
  "import time; [print(i) for i in range(10)]",
);
// Process the stream as needed

Rich output handling

Interpreter outputs are auto-formatted and returned in multiple formats:

text
html (e.g., Pandas tables)
png, svg (e.g., Matplotlib charts)
json (structured data)
chart (parsed visualizations)

const result = await sandbox.runCode(
  `
import seaborn as sns
import matplotlib.pyplot as plt

data = sns.load_dataset("flights")
pivot = data.pivot("month", "year", "passengers")
sns.heatmap(pivot, annot=True, fmt="d")
plt.title("Flight Passengers")
plt.show()

pivot.to_dict()
`,
  { context: pythonCtx },
);

if (result.png) {
  console.log("Chart output:", result.png);
}

Preview URLs from Exposed Ports

Start background processes and expose them with live URLs.

await sandbox.startProcess("python -m http.server 8000");
const preview = await sandbox.exposePort(8000);

console.log("Live preview at:", preview.url);

Full process lifecycle control

Start, inspect, and terminate long-running background processes.

const process = await sandbox.startProcess("node server.js");
console.log(`Started process ${process.id} with PID ${process.pid}`);

// Monitor the process
const logStream = await sandbox.streamProcessLogs(process.id);
for await (const log of parseSSEStream<LogEvent>(logStream)) {
  console.log(`Server: ${log.data}`);
}

listProcesses() - List all running processes
getProcess(id) - Get detailed process status
killProcess(id, signal) - Terminate specific processes
killAllProcesses() - Kill all processes
streamProcessLogs(id, options) - Stream logs from running processes
getProcessLogs(id) - Get accumulated process output

Git integration

Clone Git repositories directly into the sandbox.

await sandbox.gitCheckout("https://github.com/user/repo", {
  branch: "main",
  targetDir: "my-project",
});

Sandboxes are still experimental. We're using them to explore how isolated, container-like workloads might scale on Cloudflare — and to help define the developer experience around them.

Workers - Increased disk space for Workers Builds

Mon, 04 Aug 2025 01:00:00 GMT

As part of the ongoing open beta for Workers Builds, we’ve increased the available disk space for builds from 8 GB to 20 GB for both Free and Paid plans.

This provides more space for larger projects, dependencies, and build artifacts while improving overall build reliability.

Metric	Free Plan	Paid Plans
Disk Space	20 GB	20 GB

All other build limits — including CPU, memory, build minutes, and timeout remain unchanged.

Workers - Develop locally with Containers and the Cloudflare Vite plugin

Fri, 01 Aug 2025 00:00:00 GMT

You can now configure and run Containers alongside your Worker during local development when using the Cloudflare Vite plugin. Previously, you could only develop locally when using Wrangler as your local development server.

Configuration

You can simply configure your Worker and your Container(s) in your Wrangler configuration file:

wrangler.jsonc

{
  "name": "container-starter",
  "main": "src/index.js",
  "containers": [
    {
      "class_name": "MyContainer",
      "image": "./Dockerfile",
      "instances": 5
    }
  ],
  "durable_objects": {
    "bindings": [
      {
        "class_name": "MyContainer",
        "name": "MY_CONTAINER"
      }
    ]
  },
  "migrations": [
    {
      "new_sqlite_classes": [
        "MyContainer"
      ],
      "tag": "v1"
    }
  ],
}

wrangler.toml

name = "container-starter"
main = "src/index.js"

[[containers]]
class_name = "MyContainer"
image = "./Dockerfile"
instances = 5

[[durable_objects.bindings]]
class_name = "MyContainer"
name = "MY_CONTAINER"

[[migrations]]
new_sqlite_classes = [ "MyContainer" ]
tag = "v1"

Worker Code

Once your Worker and Containers are configured, you can access the Container instances from your Worker code:

import { Container, getContainer } from "@cloudflare/containers";

export class MyContainer extends Container {
  defaultPort = 4000; // Port the container is listening on
  sleepAfter = "10m"; // Stop the instance if requests not sent for 10 minutes
}

async fetch(request, env) {
  const { "session-id": sessionId } = await request.json();
  // Get the container instance for the given session ID
  const containerInstance = getContainer(env.MY_CONTAINER, sessionId)
  // Pass the request to the container instance on its default port
  return containerInstance.fetch(request);
}

Local development

To develop your Worker locally, start a local dev server by running

vite dev

in your terminal.

Resources

Learn more about Cloudflare Containers or the Cloudflare Vite plugin in our developer docs.

Workers, Secrets Store - Deploy to Cloudflare buttons now support Worker environment variables, secrets, and Secrets Store secrets

Tue, 29 Jul 2025 01:00:00 GMT

Any template which uses Worker environment variables, secrets, or Secrets Store secrets can now be deployed using a Deploy to Cloudflare button.

Define environment variables and secrets store bindings in your Wrangler configuration file as normal:

wrangler.jsonc

{
  "name": "my-worker",
  "main": "./src/index.ts",
  // Set this to today's date
  "compatibility_date": "2026-04-03",
  "vars": {
    "API_HOST": "https://example.com",
  },
  "secrets_store_secrets": [
    {
      "binding": "API_KEY",
      "store_id": "demo",
      "secret_name": "api-key"
    }
  ]
}

wrangler.toml

name = "my-worker"
main = "./src/index.ts"
# Set this to today's date
compatibility_date = "2026-04-03"

[vars]
API_HOST = "https://example.com"

[[secrets_store_secrets]]
binding = "API_KEY"
store_id = "demo"
secret_name = "api-key"

Add secrets to a .dev.vars.example or .env.example file:

COOKIE_SIGNING_KEY=my-secret # comment

And optionally, you can add a description for these bindings in your template's package.json to help users understand how to configure each value:

{
  "name": "my-worker",
  "private": true,
  "cloudflare": {
    "bindings": {
      "API_KEY": {
        "description": "Select your company's API key for connecting to the example service."
      },
      "COOKIE_SIGNING_KEY": {
        "description": "Generate a random string using `openssl rand -hex 32`."
      }
    }
  }
}

These secrets and environment variables will be presented to users in the dashboard as they deploy this template, allowing them to configure each value. Additional information about creating templates and Deploy to Cloudflare buttons can be found in our documentation.

Workers - Test out code changes before shipping with per-branch preview deployments for Cloudflare Workers

Tue, 22 Jul 2025 01:00:00 GMT

Now, when you connect your Cloudflare Worker to a git repository on GitHub or GitLab, each branch of your repository has its own stable preview URL, that you can use to preview code changes before merging the pull request and deploying to production.

This works the same way that Cloudflare Pages does — every time you create a pull request, you'll automatically get a shareable preview link where you can see your changes running, without affecting production. The link stays the same, even as you add commits to the same branch. These preview URLs are named after your branch and are posted as a comment to each pull request. The URL stays the same with every commit and always points to the latest version of that branch.

Preview URL types

Each comment includes two preview URLs as shown above:

Commit Preview URL: Unique to the specific version/commit (e.g., <version-prefix>-<worker-name>.<subdomain>.workers.dev)
Branch Preview URL: A stable alias based on the branch name (e.g., <branch-name>-<worker-name>.<subdomain>.workers.dev)

How it works

When you create a pull request:

A preview alias is automatically created based on the Git branch name (e.g., <branch-name> becomes <branch-name>-<worker-name>.<subdomain>.workers.dev)
No configuration is needed, the alias is generated for you
The link stays the same even as you add commits to the same branch
Preview URLs are posted directly to your pull request as comments (just like they are in Cloudflare Pages)

Custom alias name

You can also assign a custom preview alias using the Wrangler CLI, by passing the --preview-alias flag when uploading a version of your Worker:

wrangler versions upload --preview-alias staging

Limitations while in beta

Only available on the workers.dev subdomain (custom domains not yet supported)
Requires Wrangler v4.21.0+
Preview URLs are not generated for Workers that use Durable Objects
Not yet supported for Workers for Platforms

Workers - The Cloudflare Vite plugin now supports Vite 7

Thu, 17 Jul 2025 01:00:00 GMT

Vite 7 is now supported in the Cloudflare Vite plugin. See the Vite changelog for a list of changes.

Note that the minimum Node.js versions supported by Vite 7 are 20.19 and 22.12. We continue to support Vite 6 so you do not need to immediately upgrade.

Workers - Workers now supports JavaScript debug terminals in VSCode, Cursor and Windsurf IDEs

Fri, 04 Jul 2025 00:00:00 GMT

Workers now support breakpoint debugging using VSCode's built-in JavaScript Debug Terminals. All you have to do is open a JS debug terminal (Cmd + Shift + P and then type javascript debug) and run wrangler dev (or vite dev) from within the debug terminal. VSCode will automatically connect to your running Worker (even if you're running multiple Workers at once!) and start a debugging session.

In 2023 we announced breakpoint debugging support for Workers, which meant that you could easily debug your Worker code in Wrangler's built-in devtools (accessible via the [d] hotkey) as well as multiple other devtools clients, including VSCode. For most developers, breakpoint debugging via VSCode is the most natural flow, but until now it's required manually configuring a launch.json file, running wrangler dev, and connecting via VSCode's built-in debugger. Now it's much more seamless!

Workers - Enhanced support for static assets with the Cloudflare Vite plugin

Tue, 01 Jul 2025 00:00:00 GMT

You can now use any of Vite's static asset handling features in your Worker as well as in your frontend. These include importing assets as URLs, importing as strings and importing from the public directory as well as inlining assets.

Additionally, assets imported as URLs in your Worker are now automatically moved to the client build output.

Here is an example that fetches an imported asset using the assets binding and modifies the response.

// Import the asset URL
// This returns the resolved path in development and production
import myImage from "./my-image.png";

export default {
  async fetch(request, env) {
    // Fetch the asset using the binding
    const response = await env.ASSETS.fetch(new URL(myImage, request.url));
    // Create a new `Response` object that can be modified
    const modifiedResponse = new Response(response.body, response);
    // Add an additional header
    modifiedResponse.headers.append("my-header", "imported-asset");

    // Return the modfied response
    return modifiedResponse;
  },
};

Refer to Static Assets in the Cloudflare Vite plugin docs for more info.

Workers - Remote bindings (beta) now works with Next.js — connect to remote resources (D1, KV, R2, etc.) during local development

Mon, 30 Jun 2025 00:00:00 GMT

We recently announced our public beta for remote bindings, which allow you to connect to deployed resources running on your Cloudflare account (like R2 buckets or D1 databases) while running a local development session.

Now, you can use remote bindings with your Next.js applications through the @opennextjs/cloudflare adaptor by enabling the experimental feature in your next.config.ts:

initOpenNextCloudflareForDev();
initOpenNextCloudflareForDev({
 experimental: { remoteBindings: true }
});

Then, all you have to do is specify which bindings you want connected to the deployed resource on your Cloudflare account via the experimental_remote flag in your binding definition:

wrangler.jsonc

{
  "r2_buckets": [
    {
      "bucket_name": "testing-bucket",
      "binding": "MY_BUCKET",
      "experimental_remote": true,
    },
  ],
}

wrangler.toml

[[r2_buckets]]
bucket_name = "testing-bucket"
binding = "MY_BUCKET"
experimental_remote = true

You can then run next dev to start a local development session (or start a preview with opennextjs-cloudflare preview), and all requests to env.MY_BUCKET will be proxied to the remote testing-bucket — rather than the default local binding simulations.

Remote bindings & ISR

Remote bindings are also used during the build process, which comes with significant benefits for pages using Incremental Static Regeneration (ISR). During the build step for an ISR page, your server executes the page's code just as it would for normal user requests. If a page needs data to display (like fetching user info from KV), those requests are actually made. The server then uses this fetched data to render the final HTML.

Data fetching is a critical part of this process, as the finished HTML is only as good as the data it was built with. If the build process can't fetch real data, you end up with a pre-rendered page that's empty or incomplete.

With remote bindings support in OpenNext, your pre-rendered pages are built with real data from the start. The build process uses any configured remote bindings, and any data fetching occurs against the deployed resources on your Cloudflare account.

Want to learn more? Get started with remote bindings and OpenNext.

Have feedback? Join the discussion in our beta announcement to share feedback or report any issues.

Workers - Run and connect Workers in separate dev commands with the Cloudflare Vite plugin

Thu, 26 Jun 2025 00:00:00 GMT

Workers can now talk to each other across separate dev commands using service bindings and tail consumers, whether started with vite dev or wrangler dev.

Simply start each Worker in its own terminal:

# Terminal 1
vite dev

# Terminal 2
wrangler dev

This is useful when different teams maintain different Workers, or when each Worker has its own build setup or tooling.

Check out the Developing with multiple Workers guide to learn more about the different approaches and when to use each one.

Agents, Workers, Workflows - Run AI-generated code on-demand with Code Sandboxes (new)

Wed, 25 Jun 2025 00:00:00 GMT

AI is supercharging app development for everyone, but we need a safe way to run untrusted, LLM-written code. We’re introducing Sandboxes, which let your Worker run actual processes in a secure, container-based environment.

import { getSandbox } from "@cloudflare/sandbox";
export { Sandbox } from "@cloudflare/sandbox";

export default {
  async fetch(request: Request, env: Env) {
    const sandbox = getSandbox(env.Sandbox, "my-sandbox");
    return sandbox.exec("ls", ["-la"]);
  },
};

Methods

exec(command: string, args: string[], options?: { stream?: boolean }):Execute a command in the sandbox.
gitCheckout(repoUrl: string, options: { branch?: string; targetDir?: string; stream?: boolean }): Checkout a git repository in the sandbox.
mkdir(path: string, options: { recursive?: boolean; stream?: boolean }): Create a directory in the sandbox.
writeFile(path: string, content: string, options: { encoding?: string; stream?: boolean }): Write content to a file in the sandbox.
readFile(path: string, options: { encoding?: string; stream?: boolean }): Read content from a file in the sandbox.
deleteFile(path: string, options?: { stream?: boolean }): Delete a file from the sandbox.
renameFile(oldPath: string, newPath: string, options?: { stream?: boolean }): Rename a file in the sandbox.
moveFile(sourcePath: string, destinationPath: string, options?: { stream?: boolean }): Move a file from one location to another in the sandbox.
ping(): Ping the sandbox.

Sandboxes are still experimental. We're using them to explore how isolated, container-like workloads might scale on Cloudflare — and to help define the developer experience around them.

You can try it today from your Worker, with just a few lines of code. Let us know what you build.

Durable Objects, Workers - @cloudflare/actors library - SDK for Durable Objects in beta

Wed, 25 Jun 2025 00:00:00 GMT

The new @cloudflare/actors library is now in beta!

The @cloudflare/actors library is a new SDK for Durable Objects and provides a powerful set of abstractions for building real-time, interactive, and multiplayer applications on top of Durable Objects. With beta usage and feedback, @cloudflare/actors will become the recommended way to build on Durable Objects and draws upon Cloudflare's experience building products/features on Durable Objects.

The name "actors" originates from the actor programming model, which closely ties to how Durable Objects are modelled.

The @cloudflare/actors library includes:

Storage helpers for querying embeddeded, per-object SQLite storage
Storage helpers for managing SQL schema migrations
Alarm helpers for scheduling multiple alarms provided a date, delay in seconds, or cron expression
Actor class for using Durable Objects with a defined pattern
Durable Objects Workers API is always available for your application as needed

Storage and alarm helper methods can be combined with any Javascript class that defines your Durable Object, i.e, ones that extend DurableObject including the Actor class.

import { Storage } from "@cloudflare/actors/storage";

export class ChatRoom extends DurableObject<Env> {
    storage: Storage;

    constructor(ctx: DurableObjectState, env: Env) {
        super(ctx, env)
        this.storage = new Storage(ctx.storage);
        this.storage.migrations = [{
            idMonotonicInc: 1,
            description: "Create users table",
            sql: "CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY)"
        }]
    }
    async fetch(request: Request): Promise<Response> {
        // Run migrations before executing SQL query
        await this.storage.runMigrations();

        // Query with SQL template
        let userId = new URL(request.url).searchParams.get("userId");
        const query = this.storage.sql`SELECT * FROM users WHERE id = ${userId};`
        return new Response(`${JSON.stringify(query)}`);
    }
}

@cloudflare/actors library introduces the Actor class pattern. Actor lets you access Durable Objects without writing the Worker that communicates with your Durable Object (the Worker is created for you). By default, requests are routed to a Durable Object named "default".

export class MyActor extends Actor<Env> {
    async fetch(request: Request): Promise<Response> {
        return new Response('Hello, World!')
    }
}

export default handler(MyActor);

You can route to different Durable Objects by name within your Actor class using nameFromRequest.

export class MyActor extends Actor<Env> {
    static nameFromRequest(request: Request): string {
        let url = new URL(request.url);
        return url.searchParams.get("userId") ?? "foo";
    }

    async fetch(request: Request): Promise<Response> {
        return new Response(`Actor identifier (Durable Object name): ${this.identifier}`);
    }
}

export default handler(MyActor);

For more examples, check out the library README. @cloudflare/actors library is a place for more helpers and built-in patterns, like retry handling and Websocket-based applications, to reduce development overhead for common Durable Objects functionality. Please share feedback and what more you would like to see on our Discord channel.

Workers - Increased blob size limits in Workers Analytics Engine

Fri, 20 Jun 2025 00:00:00 GMT

We’ve increased the total allowed size of blob fields on data points written to Workers Analytics Engine from 5 KB to 16 KB.

This change gives you more flexibility when logging rich observability data — such as base64-encoded payloads, AI inference traces, or custom metadata — without hitting request size limits.

You can find full details on limits for queries, filters, payloads, and more here in the Workers Analytics Engine limits documentation.

JavaScript

export default {
  async fetch(request, env) {
    env.analyticsDataset.writeDataPoint({
      // The sum of all of the blob's sizes can now be 16 KB
      blobs: [
        // The URL of the request to the Worker
        request.url,
        // Some metadata about your application you'd like to store
        JSON.stringify(metadata),
        // The version of your Worker this datapoint was collected from
        env.versionMetadata.tag,
      ],
      indexes: ["sample-index"],
    });
  },
};

TypeScript

export default {
  async fetch(request, env) {
    env.analyticsDataset.writeDataPoint({
      // The sum of all of the blob's sizes can now be 16 KB
      blobs: [
        // The URL of the request to the Worker
        request.url,
        // Some metadata about your application you'd like to store
        JSON.stringify(metadata),
        // The version of your Worker this datapoint was collected from
        env.versionMetadata.tag,
      ],
      indexes: ["sample-index"],
    });
  }
};

D1, Workers, Workers for Platforms - Automate Worker deployments with a simplified SDK and more reliable Terraform provider

Thu, 19 Jun 2025 00:00:00 GMT

Simplified Worker Deployments with our SDKs

We've simplified the programmatic deployment of Workers via our Cloudflare SDKs. This update abstracts away the low-level complexities of the multipart/form-data upload process, allowing you to focus on your code while we handle the deployment mechanics.

This new interface is available in:

cloudflare-typescript (4.4.1)
cloudflare-python (4.3.1)

For complete examples, see our guide on programmatic Worker deployments.

The Old way: Manual API calls

Previously, deploying a Worker programmatically required manually constructing a multipart/form-data HTTP request, packaging your code and a separate metadata.json file. This was more complicated and verbose, and prone to formatting errors.

For example, here's how you would upload a Worker script previously with cURL:

curl https://api.cloudflare.com/client/v4/accounts/<account_id>/workers/scripts/my-hello-world-script \
  -X PUT \
  -H 'Authorization: Bearer <api_token>' \
  -F 'metadata={
        "main_module": "my-hello-world-script.mjs",
        "bindings": [
          {
            "type": "plain_text",
            "name": "MESSAGE",
            "text": "Hello World!"
          }
        ],
        "compatibility_date": "$today"
      };type=application/json' \
  -F 'my-hello-world-script.mjs=@-;filename=my-hello-world-script.mjs;type=application/javascript+module' <<EOF
export default {
  async fetch(request, env, ctx) {
    return new Response(env.MESSAGE, { status: 200 });
  }
};
EOF

After: SDK interface

With the new SDK interface, you can now define your entire Worker configuration using a single, structured object.

This approach allows you to specify metadata like main_module, bindings, and compatibility_date as clearer properties directly alongside your script content. Our SDK takes this logical object and automatically constructs the complex multipart/form-data API request behind the scenes.

Here's how you can now programmatically deploy a Worker via the cloudflare-typescript SDK

JavaScript

import Cloudflare from "cloudflare";
import { toFile } from "cloudflare/index";

// ... client setup, script content, etc.

const script = await client.workers.scripts.update(scriptName, {
  account_id: accountID,
  metadata: {
    main_module: scriptFileName,
    bindings: [],
  },
  files: {
    [scriptFileName]: await toFile(Buffer.from(scriptContent), scriptFileName, {
      type: "application/javascript+module",
    }),
  },
});

TypeScript

import Cloudflare from 'cloudflare';
import { toFile } from 'cloudflare/index';

// ... client setup, script content, etc.

const script = await client.workers.scripts.update(scriptName, {
  account_id: accountID,
  metadata: {
    main_module: scriptFileName,
    bindings: [],
  },
  files: {
    [scriptFileName]: await toFile(Buffer.from(scriptContent), scriptFileName, {
      type: 'application/javascript+module',
    }),
  },
});

View the complete example here: https://github.com/cloudflare/cloudflare-typescript/blob/main/examples/workers/script-upload.ts

Terraform provider improvements

We've also made several fixes and enhancements to the Cloudflare Terraform provider:

Fixed the cloudflare_workers_script resource in Terraform, which previously was producing a diff even when there were no changes. Now, your terraform plan outputs will be cleaner and more reliable.
Fixed the cloudflare_workers_for_platforms_dispatch_namespace, where the provider would attempt to recreate the namespace on a terraform apply. The resource now correctly reads its remote state, ensuring stability for production environments and CI/CD workflows.
The cloudflare_workers_route resource now allows for the script property to be empty, null, or omitted to indicate that pattern should be negated for all scripts (see routes docs). You can now reserve a pattern or temporarily disable a Worker on a route without deleting the route definition itself.
Using primary_location_hint in the cloudflare_d1_database resource will no longer always try to recreate. You can now safely change the location hint for a D1 database without causing a destructive operation.

API improvements

We've also properly documented the Workers Script And Version Settings in our public OpenAPI spec and SDKs.

Workers - Remote bindings public beta - Connect to remote resources (D1, KV, R2, etc.) during local development

Wed, 18 Jun 2025 00:00:00 GMT

Today we announced the public beta of remote bindings for local development. With remote bindings, you can now connect to deployed resources like R2 buckets and D1 databases while running Worker code on your local machine. This means you can test your local code changes against real data and services, without the overhead of deploying for each iteration.

Example configuration

To enable remote mode, add "experimental_remote" : true to each binding that you want to rely on a remote resource running on Cloudflare:

wrangler.jsonc

{
  "name": "my-worker",
  // Set this to today's date
  "compatibility_date": "2026-04-03",

  "r2_buckets": [
    {
      "bucket_name": "screenshots-bucket",
      "binding": "screenshots_bucket",
      "experimental_remote": true,
    },
  ],
}

wrangler.toml

name = "my-worker"
# Set this to today's date
compatibility_date = "2026-04-03"

[[r2_buckets]]
bucket_name = "screenshots-bucket"
binding = "screenshots_bucket"
experimental_remote = true

When remote bindings are configured, your Worker still executes locally, but all binding calls are proxied to the deployed resource that runs on Cloudflare's network.

You can try out remote bindings for local development today with:

Wrangler v4.20.3: Use the wrangler dev --x-remote-bindings command.
The Cloudflare Vite Plugin: Refer to the documentation for how to enable in your Vite config.
The Cloudflare Vitest Plugin: Refer to the documentation for how to enable in your Vitest config.

Have feedback? Join the discussion in our beta announcement to share feedback or report any issues.

Workers - Control which routes invoke your Worker script for Single Page Applications

Tue, 17 Jun 2025 00:00:00 GMT

For those building Single Page Applications (SPAs) on Workers, you can now explicitly define which routes invoke your Worker script in Wrangler configuration. The run_worker_first config option has now been expanded to accept an array of route patterns, allowing you to more granularly specify when your Worker script runs.

Configuration example:

wrangler.jsonc

{
  "name": "my-spa-worker",
  // Set this to today's date
  "compatibility_date": "2026-04-03",
  "main": "./src/index.ts",
  "assets": {
    "directory": "./dist/",
    "not_found_handling": "single-page-application",
    "binding": "ASSETS",
    "run_worker_first": ["/api/*", "!/api/docs/*"]
  }
}

wrangler.toml

name = "my-spa-worker"
# Set this to today's date
compatibility_date = "2026-04-03"
main = "./src/index.ts"

[assets]
directory = "./dist/"
not_found_handling = "single-page-application"
binding = "ASSETS"
run_worker_first = [ "/api/*", "!/api/docs/*" ]

This new routing control was done in partnership with our community and customers who provided great feedback on our public proposal. Thank you to everyone who brought forward use-cases and feedback on the design!

Prerequisites

To use advanced routing control with run_worker_first, you'll need:

Wrangler v4.20.0 and above
Cloudflare Vite plugin v1.7.0 and above

Workers - SSRF vulnerability in @opennextjs/cloudflare proactively mitigated for all Cloudflare customers

Tue, 17 Jun 2025 00:00:00 GMT

Mitigations have been put in place for all existing and future deployments of sites with the Cloudflare adapter for Open Next in response to an identified Server-Side Request Forgery (SSRF) vulnerability in the @opennextjs/cloudflare package.

The vulnerability stemmed from an unimplemented feature in the Cloudflare adapter for Open Next, which allowed users to proxy arbitrary remote content via the /_next/image endpoint.

This issue allowed attackers to load remote resources from arbitrary hosts under the victim site's domain for any site deployed using the Cloudflare adapter for Open Next. For example: https://victim-site.com/_next/image?url=https://attacker.com. In this example, attacker-controlled content from attacker.com is served through the victim site's domain (victim-site.com), violating the same-origin policy and potentially misleading users or other services.

References: https://www.cve.org/cverecord?id=CVE-2025-6087, https://github.com/opennextjs/opennextjs-cloudflare/security/advisories/GHSA-rvpw-p7vw-wj3m

Impact

SSRF via unrestricted remote URL loading
Arbitrary remote content loading
Potential internal service exposure or phishing risks through domain abuse

Mitigation

The following mitigations have been put in place:

Server side updates to Cloudflare's platform to restrict the content loaded via the /_next/image endpoint to images. The update automatically mitigates the issue for all existing and any future sites deployed to Cloudflare using the affected version of the Cloudflare adapter for Open Next

Root cause fix: Pull request #727 to the Cloudflare adapter for Open Next. The patched version of the adapter has been released as @opennextjs/cloudflare@1.3.0

Package dependency update: Pull request cloudflare/workers-sdk#9608 to create-cloudflare (c3) to use the fixed version of the Cloudflare adapter for Open Next. The patched version of create-cloudflare has been published as create-cloudflare@2.49.3.

In addition to the automatic mitigation deployed on Cloudflare's platform, we encourage affected users to upgrade to @opennext/cloudflare v1.3.0 and use the remotePatterns filter in Next config if they need to allow-list external urls with images assets.

Workers - Grant account members read-only access to the Workers Platform

Mon, 16 Jun 2025 00:00:00 GMT

You can now grant members of your Cloudflare account read-only access to the Workers Platform.

The new "Workers Platform (Read-only)" role grants read-only access to all products typically used as part of Cloudflare's Developer Platform, including Workers, Pages, Durable Objects, KV, R2, Zones, Zone Analytics and Page Rules. When Cloudflare introduces new products to the Workers platform, we will add additional read-only permissions to this role.

Additionally, the role previously named "Workers Admin" has been renamed to "Workers Platform Admin". This change ensures that the name more accurately reflects the permissions granted — this role has always granted access to more than just Workers — it grants read and write access to the products mentioned above, and similarly, as new products are added to the Workers platform, we will add additional read and write permissions to this role.

You can review the updated roles in the developer docs.

Workers - Access git commit sha and branch name as environment variables in Workers Builds

Tue, 10 Jun 2025 00:00:00 GMT

Workers Builds connects your Worker to a Git repository, and automates building and deploying your code on each pushed change.

To make CI/CD pipelines even more flexible, Workers Builds now automatically injects default environment variables into your build process (much like the defaults in Cloudflare Pages projects). You can use these variables to customize your build process based on the deployment context, such as the branch or commit.

The following environment variables are injected by default:

Environment Variable	Injected value	Example use-case
`CI`	`true`	Changing build behavior when run on CI versus locally
`WORKERS_CI`	`1`	Changing build behavior when run on Workers Builds versus locally
`WORKERS_CI_BUILD_UUID`	`<build-uuid-of-current-build>`	Passing the Build UUID along to custom workflows
`WORKERS_CI_COMMIT_SHA`	`<sha1-hash-of-current-commit>`	Passing current commit ID to error reporting, for example, Sentry
`WORKERS_CI_BRANCH`	`<branch-name-from-push-event`	Customizing build based on branch, for example, disabling debug logging on `production`

You can override these default values and add your own custom environment variables by navigating to your Worker > Settings > Environment variables.

Learn more in the Build configuration documentation.

Workers - Workers native integrations were removed from the Cloudflare dashboard

Mon, 09 Jun 2025 00:00:00 GMT

Workers native integrations were originally launched in May 2023 to connect to popular database and observability providers with your Worker in just a few clicks. We are changing how developers connect Workers to these external services. The Integrations tab in the dashboard has been removed in favor of a more direct, command-line-based approach using Wrangler secrets.

What's changed

Integrations tab removed: The integrations setup flow is no longer available in the Workers dashboard.
Manual secret configuration: New connections should be configured by adding credentials as secrets to your Workers using npx wrangler secret put commands.

Impact on existing integrations

Existing integrations will continue to work without any changes required. If you have integrations that were previously created through the dashboard, they will remain functional.

Updating existing integrations

If you'd like to modify your existing integration, you can update the secrets, environment variables, or Tail Workers that were created from the original integration setup.

Update secrets: Use npx wrangler secret put <SECRET_NAME> to update credential values.
Modify environment variables: Update variables through the dashboard or Wrangler configuration.
Dashboard management: Access your Worker's settings in the Cloudflare dashboard to modify connections created by our removed native integrations feature.

If you have previously set up an observability integration with Sentry, the following environment variables were set and are still modifiable:

BLOCKED_HEADERS: headers to exclude sending to Sentry
EXCEPTION_SAMPLING_RATE: number from 0 - 100, where 0 = no events go through to Sentry, and 100 = all events go through to Sentry
STATUS_CODES_TO_SAMPLING_RATES: a map of status codes -- like 400 or with wildcards like 4xx -- to sampling rates described above

Setting up new database and observability connections

For new connections, refer to our step-by-step guides on connecting to popular database and observability providers including: Sentry, Turso, Neon, Supabase, PlanetScale, Upstash, Xata.

Workers - Performance and size optimization for the Cloudflare adapter for Open Next

Thu, 05 Jun 2025 19:00:00 GMT

With the release of the Cloudflare adapter for Open Next v1.0.0 in May 2025, we already had followups plans to improve performance and size.

@opennextjs/cloudflare v1.2 released on June 5, 2025 delivers on these enhancements. By removing babel from the app code and dropping a dependency on @ampproject/toolbox-optimizer, we were able to reduce generated bundle sizes. Additionally, by stopping preloading of all app routes, we were able to improve the cold start time.

This means that users will now see a decrease from 14 to 8MiB (2.3 to 1.6MiB gzipped) in generated bundle size for a Next app created via create-next-app, and typically 100ms faster startup times for their medium-sized apps.

Users only need to update to the latest version of @opennextjs/cloudflare to automatically benefit from these improvements.

Note that we published CVE-2005-6087 for a SSRF vulnerability in the @opennextjs/cloudflare package. The vulnerability has been fixed from @opennextjs/cloudflare v1.3.0 onwards. Please update to any version after this one.

Workers - View an architecture diagram of your Worker directly in the Cloudflare dashboard

Tue, 03 Jun 2025 00:00:00 GMT

You can now visualize, explore and modify your Worker’s architecture directly in the Cloudflare dashboard, making it easier to understand how your application connects to Cloudflare resources like D1 databases, Durable Objects, KV namespaces, and more.

With this new view, you can easily:

Explore existing bindings in a visual, architecture-style diagram
Add and manage bindings directly from the same interface
Discover the full range of compute, storage, AI, and media resources you can attach to your Workers application.

To get started, head to the Cloudflare dashboard and open the Bindings tab of any Workers application.

Workers - Debug, profile, and view logs for your Worker in Chrome Devtools — now supported in the Cloudflare Vite plugin

Fri, 30 May 2025 00:00:00 GMT

You can now debug, profile, view logs, and analyze memory usage for your Worker using Chrome Devtools when your Worker runs locally using the Cloudflare Vite plugin.

Previously, this was only possible if your Worker ran locally using the Wrangler CLI, and now you can do all the same things if your Worker uses Vite.

When you run vite, you'll now see a debug URL in your console:

  VITE v6.3.5  ready in 461 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  Debug:   http://localhost:5173/__debug
  ➜  press h + enter to show help

Open the URL in Chrome, and an instance of Chrome Devtools will open and connect to your Worker running locally. You can then use Chrome Devtools to debug and introspect performance issues. For example, you can navigate to the Performance tab to understand where CPU time is spent in your Worker:

For more information on how to get the most out of Chrome Devtools, refer to the following docs:

D1, Workers - 50-500ms Faster D1 REST API Requests

Thu, 29 May 2025 00:00:00 GMT

Users using Cloudflare's REST API to query their D1 database can see lower end-to-end request latency now that D1 authentication is performed at the closest Cloudflare network data center that received the request. Previously, authentication required D1 REST API requests to proxy to Cloudflare's core, centralized data centers, which added network round trips and latency.

Latency improvements range from 50-500 ms depending on request location and database location and only apply to the REST API. REST API requests and databases outside the United States see a bigger benefit since Cloudflare's primary core data centers reside in the United States.

D1 query endpoints like /query and /raw have the most noticeable improvements since they no longer access Cloudflare's core data centers. D1 control plane endpoints such as those to create and delete databases see smaller improvements, since they still require access to Cloudflare's core data centers for other control plane metadata.

Workers - Handle incoming request cancellation in Workers with Request.signal

Thu, 22 May 2025 00:00:00 GMT

In Cloudflare Workers, you can now attach an event listener to Request objects, using the signal property. This allows you to perform tasks when the request to your Worker is canceled by the client. To use this feature, you must set the enable_request_signal compatibility flag.

You can use a listener to perform cleanup tasks or write to logs before your Worker's invocation ends. For example, if you run the Worker below, and then abort the request from the client, a log will be written:

JavaScript

export default {
  async fetch(request, env, ctx) {
    // This sets up an event listener that will be called if the client disconnects from your
    // worker.
    request.signal.addEventListener("abort", () => {
      console.log("The request was aborted!");
    });

    const { readable, writable } = new IdentityTransformStream();
    sendPing(writable);
    return new Response(readable, {
      headers: { "Content-Type": "text/plain" },
    });
  },
};

async function sendPing(writable) {
  const writer = writable.getWriter();
  const enc = new TextEncoder();

  for (;;) {
    // Send 'ping' every second to keep the connection alive
    await writer.write(enc.encode("ping\r\n"));
    await scheduler.wait(1000);
  }
}

TypeScript

export default {
  async fetch(request, env, ctx): Promise<Response> {
    // This sets up an event listener that will be called if the client disconnects from your
    // worker.
    request.signal.addEventListener('abort', () => {
      console.log('The request was aborted!');
    });

    const { readable, writable } = new IdentityTransformStream();
    sendPing(writable);
    return new Response(readable, { headers: { 'Content-Type': 'text/plain' } });
  },
} satisfies ExportedHandler<Env>;

async function sendPing(writable: WritableStream): Promise<void> {
  const writer = writable.getWriter();
  const enc = new TextEncoder();

  for (;;) {
    // Send 'ping' every second to keep the connection alive
    await writer.write(enc.encode('ping\r\n'));
    await scheduler.wait(1000);
  }
}

For more information see the Request documentation.

Workers, Durable Objects - Durable Objects are now supported in Python Workers

Fri, 16 May 2025 00:00:00 GMT

You can now create Durable Objects using Python Workers. A Durable Object is a special kind of Cloudflare Worker which uniquely combines compute with storage, enabling stateful long-running applications which run close to your users. For more info see here.

You can define a Durable Object in Python in a similar way to JavaScript:

from workers import DurableObject, Response, WorkerEntrypoint

from urllib.parse import urlparse

class MyDurableObject(DurableObject):
    def __init__(self, ctx, env):
        self.ctx = ctx
        self.env = env

    def fetch(self, request):
        result = self.ctx.storage.sql.exec("SELECT 'Hello, World!' as greeting").one()
        return Response(result.greeting)

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        url = urlparse(request.url)
        id = env.MY_DURABLE_OBJECT.idFromName(url.path)
        stub = env.MY_DURABLE_OBJECT.get(id)
        greeting = await stub.fetch(request.url)
        return greeting

Define the Durable Object in your Wrangler configuration file:

wrangler.jsonc

{
  "durable_objects": {
    "bindings": [
      {
        "name": "MY_DURABLE_OBJECT",
        "class_name": "MyDurableObject"
      }
    ]
  }
}

wrangler.toml

[[durable_objects.bindings]]
name = "MY_DURABLE_OBJECT"
class_name = "MyDurableObject"

Then define the storage backend for your Durable Object:

wrangler.jsonc

{
  "migrations": [
    {
      "tag": "v1", // Should be unique for each entry
      "new_sqlite_classes": [ // Array of new classes
        "MyDurableObject"
      ]
    }
  ]
}

wrangler.toml

[[migrations]]
tag = "v1"
new_sqlite_classes = [ "MyDurableObject" ]

Then test your new Durable Object locally by running wrangler dev:

npx wrangler dev

Consult the Durable Objects documentation for more details.

Workers - Improved memory efficiency for WebAssembly Workers

Thu, 08 May 2025 00:00:00 GMT

FinalizationRegistry is now available in Workers. You can opt-in using the enable_weak_ref compatibility flag.

This can reduce memory leaks when using WebAssembly-based Workers, which includes Python Workers and Rust Workers. The FinalizationRegistry works by enabling toolchains such as Emscripten and wasm-bindgen to automatically free WebAssembly heap allocations. If you are using WASM and seeing Exceeded Memory errors and cannot determine a cause using memory profiling, you may want to enable the FinalizationRegistry.

For more information refer to the enable_weak_ref compatibility flag documentation.

Workers - Cron triggers are now supported in Python Workers

Thu, 24 Apr 2025 00:00:00 GMT

You can now create Python Workers which are executed via a cron trigger.

This is similar to how it's done in JavaScript Workers, simply define a scheduled event listener in your Worker:

from workers import handler

@handler
async def on_scheduled(event, env, ctx):
  print("cron processed")

Define a cron trigger configuration in your Wrangler configuration file:

wrangler.jsonc

{
  "triggers": {
    // Schedule cron triggers:
    // - At every 3rd minute
    // - At 15:00 (UTC) on first day of the month
    // - At 23:59 (UTC) on the last weekday of the month
    "crons": [
      "*/3 * * * *",
      "0 15 1 * *",
      "59 23 LW * *"
    ]
  }
}

wrangler.toml

[triggers]
crons = [ "*/3 * * * *", "0 15 1 * *", "59 23 LW * *" ]

Then test your new handler by using Wrangler with the --test-scheduled flag and making a request to /cdn-cgi/handler/scheduled?cron=*+*+*+*+*:

npx wrangler dev --test-scheduled

curl "http://localhost:8787/cdn-cgi/handler/scheduled?cron=*+*+*+*+*"

Consult the Workers Cron Triggers page for full details on cron triggers in Workers.

Workers, Workers for Platforms - Fixed and documented Workers Routes and Secrets API

Tue, 15 Apr 2025 00:00:00 GMT

Workers Routes API

Previously, a request to the Workers Create Route API always returned null for "script" and an empty string for "pattern" even if the request was successful.

curl https://api.cloudflare.com/client/v4/zones/$CF_ACCOUNT_ID/workers/routes \
-X PUT \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H 'Content-Type: application/json' \
--data '{ "pattern": "example.com/*", "script": "hello-world-script" }'

{
  "result": {
    "id": "bf153a27ba2b464bb9f04dcf75de1ef9",
    "pattern": "",
    "script": null,
    "request_limit_fail_open": false
  },
  "success": true,
  "errors": [],
  "messages": []
}

Now, it properly returns all values!

{
  "result": {
    "id": "bf153a27ba2b464bb9f04dcf75de1ef9",
    "pattern": "example.com/*",
    "script": "hello-world-script",
    "request_limit_fail_open": false
  },
  "success": true,
  "errors": [],
  "messages": []
}

Workers Secrets API

The Workers and Workers for Platforms secrets APIs are now properly documented in the Cloudflare OpenAPI docs. Previously, these endpoints were not publicly documented, leaving users confused on how to directly manage their secrets via the API. Now, you can find the proper endpoints in our public documentation, as well as in our API Library SDKs such as cloudflare-typescript (>4.2.0) and cloudflare-python (>4.1.0).

Note the cloudflare_workers_secret and cloudflare_workers_for_platforms_script_secret Terraform resources are being removed in a future release. This resource is not recommended for managing secrets. Users should instead use the:

Secrets Store with the "Secrets Store Secret" binding on Workers and Workers for Platforms Script Upload
"Secret Text" Binding on Workers Script Upload and Workers for Platforms Script Upload
Workers (and WFP) Secrets API

D1, Workers - D1 Read Replication Public Beta

Thu, 10 Apr 2025 00:00:00 GMT

D1 read replication is available in public beta to help lower average latency and increase overall throughput for read-heavy applications like e-commerce websites or content management tools.

Workers can leverage read-only database copies, called read replicas, by using D1 Sessions API. A session encapsulates all the queries from one logical session for your application. For example, a session may correspond to all queries coming from a particular web browser session. With Sessions API, D1 queries in a session are guaranteed to be sequentially consistent to avoid data consistency pitfalls. D1 bookmarks can be used from a previous session to ensure logical consistency between sessions.

// retrieve bookmark from previous session stored in HTTP header
const bookmark = request.headers.get("x-d1-bookmark") ?? "first-unconstrained";

const session = env.DB.withSession(bookmark);
const result = await session
  .prepare(`SELECT * FROM Customers WHERE CompanyName = 'Bs Beverages'`)
  .run();
// store bookmark for a future session
response.headers.set("x-d1-bookmark", session.getBookmark() ?? "");

Read replicas are automatically created by Cloudflare (currently one in each supported D1 region), are active/inactive based on query traffic, and are transparently routed to by Cloudflare at no additional cost.

To checkout D1 read replication, deploy the following Worker code using Sessions API, which will prompt you to create a D1 database and enable read replication on said database.

To learn more about how read replication was implemented, go to our blog post.

Pipelines, R2, Workers - Cloudflare Pipelines now available in beta

Thu, 10 Apr 2025 00:00:00 GMT

Cloudflare Pipelines is now available in beta, to all users with a Workers Paid plan.

Pipelines let you ingest high volumes of real time data, without managing the underlying infrastructure. A single pipeline can ingest up to 100 MB of data per second, via HTTP or from a Worker. Ingested data is automatically batched, written to output files, and delivered to an R2 bucket in your account. You can use Pipelines to build a data lake of clickstream data, or to store events from a Worker.

Create your first pipeline with a single command:

$ npx wrangler@latest pipelines create my-clickstream-pipeline --r2-bucket my-bucket

🌀 Authorizing R2 bucket "my-bucket"
🌀 Creating pipeline named "my-clickstream-pipeline"
✅ Successfully created pipeline my-clickstream-pipeline

Id:    0e00c5ff09b34d018152af98d06f5a1xvc
Name:  my-clickstream-pipeline
Sources:
  HTTP:
    Endpoint:        https://0e00c5ff09b34d018152af98d06f5a1xvc.pipelines.cloudflare.com/
    Authentication:  off
    Format:          JSON
  Worker:
    Format:  JSON
Destination:
  Type:         R2
  Bucket:       my-bucket
  Format:       newline-delimited JSON
  Compression:  GZIP
Batch hints:
  Max bytes:     100 MB
  Max duration:  300 seconds
  Max records:   100,000

🎉 You can now send data to your pipeline!

Send data to your pipeline's HTTP endpoint:
curl "https://0e00c5ff09b34d018152af98d06f5a1xvc.pipelines.cloudflare.com/" -d '[{ ...JSON_DATA... }]'

To send data to your pipeline from a Worker, add the following configuration to your config file:
{
  "pipelines": [
    {
      "pipeline": "my-clickstream-pipeline",
      "binding": "PIPELINE"
    }
  ]
}

Head over to our getting started guide for an in-depth tutorial to building with Pipelines.

Workers - Investigate your Workers with the Query Builder in the new Observability dashboard

Wed, 09 Apr 2025 00:00:00 GMT

The Workers Observability dashboard offers a single place to investigate and explore your Workers Logs.

The Overview tab shows logs from all your Workers in one place. The Invocations view groups logs together by invocation, which refers to the specific trigger that started the execution of the Worker (i.e. fetch). The Events view shows logs in the order they were produced, based on timestamp. Previously, you could only view logs for a single Worker.

The Investigate tab presents a Query Builder, which helps you write structured queries to investigate and visualize your logs. The Query Builder can help answer questions such as:

Which paths are experiencing the most 5XX errors?
What is the wall time distribution by status code for my Worker?
What are the slowest requests, and where are they coming from?
Who are my top N users?

The Query Builder can use any field that you store in your logs as a key to visualize, filter, and group by. Use the Query Builder to quickly access your data, build visualizations, save queries, and share them with your team.

Workers Logs is now Generally Available

Workers Logs is now Generally Available. With a small change to your Wrangler configuration, Workers Logs ingests, indexes, and stores all logs emitted from your Workers for up to 7 days.

We've introduced a number of changes during our beta period, including:

Dashboard enhancements with customizable fields as columns in the Logs view and support for invocation-based grouping
Performance improvements to ensure no adverse impact
Public API endpoints for broader consumption

The API documents three endpoints: list the keys in the telemetry dataset, run a query, and list the unique values for a key. For more, visit our REST API documentation.

Visit the docs to learn more about the capabilities and methods exposed by the Query Builder. Start using Workers Logs and the Query Builder today by enabling observability for your Workers:

wrangler.jsonc

{
  "observability": {
    "enabled": true,
    "logs": {
      "invocation_logs": true,
      "head_sampling_rate": 1 // optional. default = 1.
    }
  }
}

wrangler.toml

[observability]
enabled = true

  [observability.logs]
  invocation_logs = true
  head_sampling_rate = 1

Workers - CPU time and Wall time now published for Workers Invocations

Wed, 09 Apr 2025 00:00:00 GMT

You can now observe and investigate the CPU time and Wall time for every Workers Invocations.

For Workers Logs, CPU time and Wall time are surfaced in the Invocation Log..
For Tail Workers, CPU time and Wall time are surfaced at the top level of the Workers Trace Events object.
For Workers Logpush, CPU and Wall time are surfaced at the top level of the Workers Trace Events object. All new jobs will have these new fields included by default. Existing jobs need to be updated to include CPU time and Wall time.

You can use a Workers Logs filter to search for logs where Wall time exceeds 100ms.

You can also use the Workers Observability Query Builder to find the median CPU time and median Wall time for all of your Workers.

Workers - Deploy a Workers application in seconds with one-click

Tue, 08 Apr 2025 00:00:00 GMT

You can now add a Deploy to Cloudflare button to the README of your Git repository containing a Workers application — making it simple for other developers to quickly set up and deploy your project!

The Deploy to Cloudflare button:

Creates a new Git repository on your GitHub/ GitLab account: Cloudflare will automatically clone and create a new repository on your account, so you can continue developing.
Automatically provisions resources the app needs: If your repository requires Cloudflare primitives like a Workers KV namespace, a D1 database, or an R2 bucket, Cloudflare will automatically provision them on your account and bind them to your Worker upon deployment.
Configures Workers Builds (CI/CD): Every new push to your production branch on your newly created repository will automatically build and deploy courtesy of Workers Builds.
Adds preview URLs to each pull request: If you'd like to test your changes before deploying, you can push changes to a non-production branch and preview URLs will be generated and posted back to GitHub as a comment.

To create a Deploy to Cloudflare button in your README, you can add the following snippet, including your Git repository URL:

[![Deploy to Cloudflare](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=<YOUR_GIT_REPO_URL>)

Check out our documentation for more information on how to set up a deploy button for your application and best practices to ensure a successful deployment for other developers.

Workers, Workers for Platforms - Full-stack frameworks are now Generally Available on Cloudflare Workers

Tue, 08 Apr 2025 00:00:00 GMT

The following full-stack frameworks now have Generally Available ("GA") adapters for Cloudflare Workers, and are ready for you to use in production:

The following frameworks are now in beta, with GA support coming very soon:

Next.js, supported through @opennextjs/cloudflare is now v1.0-beta.
Angular
SolidJS (SolidStart)

You can also build complete full-stack apps on Workers without a framework:

You can “just use Vite" and React together, and build a back-end API in the same Worker. Follow our React SPA with an API tutorial to learn how.

Get started building today with our framework guides, or read our Developer Week 2025 blog post about all the updates to building full-stack applications on Workers.

Workers - Improved support for Node.js Crypto and TLS APIs in Workers

Tue, 08 Apr 2025 00:00:00 GMT

When using a Worker with the nodejs_compat compatibility flag enabled, the following Node.js APIs are now available:

This make it easier to reuse existing Node.js code in Workers or use npm packages that depend on these APIs.

node:crypto

The full node:crypto API is now available in Workers.

You can use it to verify and sign data:

import { sign, verify } from "node:crypto";

const signature = sign("sha256", "-data to sign-", env.PRIVATE_KEY);
const verified = verify("sha256", "-data to sign-", env.PUBLIC_KEY, signature);

Or, to encrypt and decrypt data:

import { publicEncrypt, privateDecrypt } from "node:crypto";

const encrypted = publicEncrypt(env.PUBLIC_KEY, "some data");
const plaintext = privateDecrypt(env.PRIVATE_KEY, encrypted);

See the node:crypto documentation for more information.

node:tls

The following APIs from node:tls are now available:

This enables secure connections over TLS (Transport Layer Security) to external services.

import { connect } from "node:tls";

// ... in a request handler ...
const connectionOptions = { key: env.KEY, cert: env.CERT };
const socket = connect(url, connectionOptions, () => {
  if (socket.authorized) {
    console.log("Connection authorized");
  }
});

socket.on("data", (data) => {
  console.log(data);
});

socket.on("end", () => {
  console.log("server ends connection");
});

See the node:tls documentation for more information.

Workers - The Cloudflare Vite plugin is now Generally Available

Tue, 08 Apr 2025 00:00:00 GMT

The Cloudflare Vite plugin has reached v1.0 and is now Generally Available ("GA").

When you use @cloudflare/vite-plugin, you can use Vite's local development server and build tooling, while ensuring that while developing, your code runs in workerd, the open-source Workers runtime.

This lets you get the best of both worlds for a full-stack app — you can use Hot Module Replacement from Vite right alongside Durable Objects and other runtime APIs and bindings that are unique to Cloudflare Workers.

@cloudflare/vite-plugin is made possible by the new environment API in Vite, and was built in partnership with the Vite team.

Framework support

You can build any type of application with @cloudflare/vite-plugin, using any rendering mode, from single page applications (SPA) and static sites to server-side rendered (SSR) pages and API routes.

React Router v7 (Remix) is the first full-stack framework to provide full support for Cloudflare Vite plugin, allowing you to use all parts of Cloudflare's developer platform, without additional build steps.

You can also build complete full-stack apps on Workers without a framework — "just use Vite" and React together, and build a back-end API in the same Worker. Follow our React SPA with an API tutorial to learn how.

Configuration

If you're already using Vite in your build and development toolchain, you can start using our plugin with minimal changes to your vite.config.ts:

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
  plugins: [cloudflare()],
});

Take a look at the documentation for our Cloudflare Vite plugin for more information!

Agents, Workers - Build MCP servers with the Agents SDK

Mon, 07 Apr 2025 00:00:00 GMT

The Agents SDK now includes built-in support for building remote MCP (Model Context Protocol) servers directly as part of your Agent. This allows you to easily create and manage MCP servers, without the need for additional infrastructure or configuration.

The SDK includes a new MCPAgent class that extends the Agent class and allows you to expose resources and tools over the MCP protocol, as well as authorization and authentication to enable remote MCP servers.

JavaScript

export class MyMCP extends McpAgent {
  server = new McpServer({
    name: "Demo",
    version: "1.0.0",
  });

  async init() {
    this.server.resource(`counter`, `mcp://resource/counter`, (uri) => {
      // ...
    });

    this.server.tool(
      "add",
      "Add two numbers together",
      { a: z.number(), b: z.number() },
      async ({ a, b }) => {
        // ...
      },
    );
  }
}

TypeScript

export class MyMCP extends McpAgent<Env> {
  server = new McpServer({
    name: "Demo",
    version: "1.0.0",
  });

  async init() {
    this.server.resource(`counter`, `mcp://resource/counter`, (uri) => {
      // ...
    });

    this.server.tool(
      "add",
      "Add two numbers together",
      { a: z.number(), b: z.number() },
      async ({ a, b }) => {
        // ...
      },
    );
  }
}

See the example for the full code and as the basis for building your own MCP servers, and the client example for how to build an Agent that acts as an MCP client.

To learn more, review the announcement blog as part of Developer Week 2025.

Agents SDK updates

We've made a number of improvements to the Agents SDK, including:

Support for building MCP servers with the new MCPAgent class.
The ability to export the current agent, request and WebSocket connection context using import { context } from "agents", allowing you to minimize or avoid direct dependency injection when calling tools.
Fixed a bug that prevented query parameters from being sent to the Agent server from the useAgent React hook.
Automatically converting the agent name in useAgent or useAgentChat to kebab-case to ensure it matches the naming convention expected by routeAgentRequest.

To install or update the Agents SDK, run npm i agents@latest in an existing project, or explore the agents-starter project:

npm create cloudflare@latest -- --template cloudflare/agents-starter

See the full release notes and changelog on the Agents SDK repository and

Durable Objects, Workers - Durable Objects on Workers Free plan

Mon, 07 Apr 2025 00:00:00 GMT

Durable Objects can now be used with zero commitment on the Workers Free plan allowing you to build AI agents with Agents SDK, collaboration tools, and real-time applications like chat or multiplayer games.

Durable Objects let you build stateful, serverless applications with millions of tiny coordination instances that run your application code alongside (in the same thread!) your durable storage. Each Durable Object can access its own SQLite database through a Storage API. A Durable Object class is defined in a Worker script encapsulating the Durable Object's behavior when accessed from a Worker. To try the code below, click the button:

import { DurableObject } from "cloudflare:workers";

// Durable Object
export class MyDurableObject extends DurableObject {
  ...
  async sayHello(name) {
    return `Hello, ${name}!`;
  }
}

// Worker
export default {
  async fetch(request, env) {
    // Every unique ID refers to an individual instance of the Durable Object class
    const id = env.MY_DURABLE_OBJECT.idFromName("foo");

    // A stub is a client used to invoke methods on the Durable Object
    const stub = env.MY_DURABLE_OBJECT.get(id);

    // Methods on the Durable Object are invoked via the stub
    const response = await stub.sayHello("world");

    return response;
  },
};

Free plan limits apply to Durable Objects compute and storage usage. Limits allow developers to build real-world applications, with every Worker request able to call a Durable Object on the free plan.

For more information, checkout:

Durable Objects, Workers - SQLite in Durable Objects GA with 10GB storage per object

Mon, 07 Apr 2025 00:00:00 GMT

SQLite in Durable Objects is now generally available (GA) with 10GB SQLite database per Durable Object. Since the public beta in September 2024, we've added feature parity and robustness for the SQLite storage backend compared to the preexisting key-value (KV) storage backend for Durable Objects.

SQLite-backed Durable Objects are recommended for all new Durable Object classes, using new_sqlite_classes Wrangler configuration. Only SQLite-backed Durable Objects have access to Storage API's SQL and point-in-time recovery methods, which provide relational data modeling, SQL querying, and better data management.

export class MyDurableObject extends DurableObject {
  sql: SqlStorage
  constructor(ctx: DurableObjectState, env: Env) {
    super(ctx, env);
    this.sql = ctx.storage.sql;
  }

  async sayHello() {
    let result = this.sql
      .exec("SELECT 'Hello, World!' AS greeting")
      .one();
    return result.greeting;
  }
}

KV-backed Durable Objects remain for backwards compatibility, and a migration path from key-value storage to SQL storage for existing Durable Object classes will be offered in the future.

For more details on SQLite storage, checkout Zero-latency SQLite storage in every Durable Object blog.

Workers - Capture up to 256 KB of log events in each Workers Invocation

Mon, 07 Apr 2025 00:00:00 GMT

You can now capture a maximum of 256 KB of log events per Workers invocation, helping you gain better visibility into application behavior.

All console.log() statements, exceptions, request metadata, and headers are automatically captured during the Worker invocation and emitted as JSON object. Workers Logs deserializes this object before indexing the fields and storing them. You can also capture, transform, and export the JSON object in a Tail Worker.

256 KB is a 2x increase from the previous 128 KB limit. After you exceed this limit, further context associated with the request will not be recorded in your logs.

This limit is automatically applied to all Workers.

Workflows, Workers - Workflows is now Generally Available

Mon, 07 Apr 2025 00:00:00 GMT

Workflows is now Generally Available (or "GA"): in short, it's ready for production workloads. Alongside marking Workflows as GA, we've introduced a number of changes during the beta period, including:

A new waitForEvent API that allows a Workflow to wait for an event to occur before continuing execution.
Increased concurrency: you can run up to 4,500 Workflow instances concurrently — and this will continue to grow.
Improved observability, including new CPU time metrics that allow you to better understand which Workflow instances are consuming the most resources and/or contributing to your bill.
Support for vitest for testing Workflows locally and in CI/CD pipelines.

Workflows also supports the new increased CPU limits that apply to Workers, allowing you to run more CPU-intensive tasks (up to 5 minutes of CPU time per instance), not including the time spent waiting on network calls, AI models, or other I/O bound tasks.

Human-in-the-loop

The new step.waitForEvent API allows a Workflow instance to wait on events and data, enabling human-in-the-the-loop interactions, such as approving or rejecting a request, directly handling webhooks from other systems, or pushing event data to a Workflow while it's running.

Because Workflows are just code, you can conditionally execute code based on the result of a waitForEvent call, and/or call waitForEvent multiple times in a single Workflow based on what the Workflow needs.

For example, if you wanted to implement a human-in-the-loop approval process, you could use waitForEvent to wait for a user to approve or reject a request, and then conditionally execute code based on the result.

JavaScript

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

export class MyWorkflow extends WorkflowEntrypoint {
  async run(event, step) {
    // Other steps in your Workflow
    let stripeEvent = await step.waitForEvent(
      "receive invoice paid webhook from Stripe",
      { type: "stripe-webhook", timeout: "1 hour" },
    );
    // Rest of your Workflow
  }
}

TypeScript

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

export class MyWorkflow extends WorkflowEntrypoint<Env, Params> {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    // Other steps in your Workflow
    let stripeEvent = await step.waitForEvent<IncomingStripeWebhook>("receive invoice paid webhook from Stripe", { type: "stripe-webhook", timeout: "1 hour" })
    // Rest of your Workflow
  }
}

You can then send a Workflow an event from an external service via HTTP or from within a Worker using the Workers API for Workflows:

JavaScript

export default {
  async fetch(req, env) {
    const instanceId = new URL(req.url).searchParams.get("instanceId");
    const webhookPayload = await req.json();

    let instance = await env.MY_WORKFLOW.get(instanceId);
    // Send our event, with `type` matching the event type defined in
    // our step.waitForEvent call
    await instance.sendEvent({
      type: "stripe-webhook",
      payload: webhookPayload,
    });

    return Response.json({
      status: await instance.status(),
    });
  },
};

TypeScript

export default {
  async fetch(req: Request, env: Env) {
    const instanceId = new URL(req.url).searchParams.get("instanceId")
    const webhookPayload = await req.json<Payload>()

    let instance = await env.MY_WORKFLOW.get(instanceId);
    // Send our event, with `type` matching the event type defined in
    // our step.waitForEvent call
    await instance.sendEvent({type: "stripe-webhook", payload: webhookPayload})

    return Response.json({
      status: await instance.status(),
    });
  },
};

Read the GA announcement blog to learn more about what landed as part of the Workflows GA.

Workers - Run Workers for up to 5 minutes of CPU-time

Wed, 26 Mar 2025 00:00:00 GMT

You can now run a Worker for up to 5 minutes of CPU time for each request.

Previously, each Workers request ran for a maximum of 30 seconds of CPU time — that is the time that a Worker is actually performing a task (we still allowed unlimited wall-clock time, in case you were waiting on slow resources). This meant that some compute-intensive tasks were impossible to do with a Worker. For instance, you might want to take the cryptographic hash of a large file from R2. If this computation ran for over 30 seconds, the Worker request would have timed out.

By default, Workers are still limited to 30 seconds of CPU time. This protects developers from incurring accidental cost due to buggy code.

By changing the cpu_ms value in your Wrangler configuration, you can opt in to any value up to 300,000 (5 minutes).

wrangler.jsonc

{
  // ...rest of your configuration...
  "limits": {
    "cpu_ms": 300000,
  },
  // ...rest of your configuration...
}

wrangler.toml
```
[limits]
cpu_ms = 300_000
```

For more information on the updates limits, see the documentation on Wrangler configuration for cpu_ms and on Workers CPU time limits.

For building long-running tasks on Cloudflare, we also recommend checking out Workflows and Queues.

Workers - Source Maps are Generally Available

Tue, 25 Mar 2025 00:00:00 GMT

Source maps are now Generally Available (GA). You can now be uploaded with a maximum gzipped size of 15 MB. Previously, the maximum size limit was 15 MB uncompressed.

Source maps help map between the original source code and the transformed/minified code that gets deployed to production. By uploading your source map, you allow Cloudflare to map the stack trace from exceptions onto the original source code making it easier to debug.

With no source maps uploaded: notice how all the Javascript has been minified to one file, so the stack trace is missing information on file name, shows incorrect line numbers, and incorrectly references js instead of ts.

With source maps uploaded: all methods reference the correct files and line numbers.

Uploading source maps and stack trace remapping happens out of band from the Worker execution, so source maps do not affect upload speed, bundle size, or cold starts. The remapped stack traces are accessible through Tail Workers, Workers Logs, and Workers Logpush.

To enable source maps, add the following to your Pages Function's or Worker's wrangler configuration:

wrangler.jsonc
```
{
  "upload_source_maps": true
}
```
wrangler.toml
```
upload_source_maps = true
```

Workers, Pages, WAF - New Managed WAF rule for Next.js CVE-2025-29927.

Sat, 22 Mar 2025 00:00:00 GMT

Update: Mon Mar 24th, 11PM UTC: Next.js has made further changes to address a smaller vulnerability introduced in the patches made to its middleware handling. Users should upgrade to Next.js versions 15.2.4, 14.2.26, 13.5.10 or 12.3.6. If you are unable to immediately upgrade or are running an older version of Next.js, you can enable the WAF rule described in this changelog as a mitigation.

Update: Mon Mar 24th, 8PM UTC: Next.js has now backported the patch for this vulnerability to cover Next.js v12 and v13. Users on those versions will need to patch to 13.5.9 and 12.3.5 (respectively) to mitigate the vulnerability.

Update: Sat Mar 22nd, 4PM UTC: We have changed this WAF rule to opt-in only, as sites that use auth middleware with third-party auth vendors were observing failing requests.

We strongly recommend updating your version of Next.js (if eligible) to the patched versions, as your app will otherwise be vulnerable to an authentication bypass attack regardless of auth provider.

Enable the Managed Rule (strongly recommended)

This rule is opt-in only for sites on the Pro plan or above in the WAF managed ruleset.

To enable the rule:

Head to Security > WAF > Managed rules in the Cloudflare dashboard for the zone (website) you want to protect.
Click the three dots next to Cloudflare Managed Ruleset and choose Edit
Scroll down and choose Browse Rules
Search for CVE-2025-29927 (ruleId: 34583778093748cc83ff7b38f472013e)
Change the Status to Enabled and the Action to Block. You can optionally set the rule to Log, to validate potential impact before enabling it. Log will not block requests.
Click Next
Scroll down and choose Save

This will enable the WAF rule and block requests with the x-middleware-subrequest header regardless of Next.js version.

Create a WAF rule (manual)

For users on the Free plan, or who want to define a more specific rule, you can create a Custom WAF rule to block requests with the x-middleware-subrequest header regardless of Next.js version.

To create a custom rule:

Head to Security > WAF > Custom rules in the Cloudflare dashboard for the zone (website) you want to protect.
Give the rule a name - e.g. next-js-CVE-2025-29927
Set the matching parameters for the rule match any request where the x-middleware-subrequest header exists per the rule expression below.

(len(http.request.headers["x-middleware-subrequest"]) > 0)

Set the action to 'block'. If you want to observe the impact before blocking requests, set the action to 'log' (and edit the rule later).
Deploy the rule.

Next.js CVE-2025-29927

We've made a WAF (Web Application Firewall) rule available to all sites on Cloudflare to protect against the Next.js authentication bypass vulnerability (CVE-2025-29927) published on March 21st, 2025.

Note: This rule is not enabled by default as it blocked requests across sites for specific authentication middleware.

This managed rule protects sites using Next.js on Workers and Pages, as well as sites using Cloudflare to protect Next.js applications hosted elsewhere.
This rule has been made available (but not enabled by default) to all sites as part of our WAF Managed Ruleset and blocks requests that attempt to bypass authentication in Next.js applications.
The vulnerability affects almost all Next.js versions, and has been fully patched in Next.js 14.2.26 and 15.2.4. Earlier, interim releases did not fully patch this vulnerability.
Users on older versions of Next.js (11.1.4 to 13.5.6) did not originally have a patch available, but this the patch for this vulnerability and a subsequent additional patch have been backported to Next.js versions 12.3.6 and 13.5.10 as of Monday, March 24th. Users on Next.js v11 will need to deploy the stated workaround or enable the WAF rule.

The managed WAF rule mitigates this by blocking external user requests with the x-middleware-subrequest header regardless of Next.js version, but we recommend users using Next.js 14 and 15 upgrade to the patched versions of Next.js as an additional mitigation.

Workers, Pages - Smart Placement is smarter about running Workers and Pages Functions in the best locations

Sat, 22 Mar 2025 00:00:00 GMT

Smart Placement is a unique Cloudflare feature that can make decisions to move your Worker to run in a more optimal location (such as closer to a database). Instead of always running in the default location (the one closest to where the request is received), Smart Placement uses certain “heuristics” (rules and thresholds) to decide if a different location might be faster or more efficient.

Previously, if these heuristics weren't consistently met, your Worker would revert to running in the default location—even after it had been optimally placed. This meant that if your Worker received minimal traffic for a period of time, the system would reset to the default location, rather than remaining in the optimal one.

Now, once Smart Placement has identified and assigned an optimal location, temporarily dropping below the heuristic thresholds will not force a return to default locations. For example in the previous algorithm, a drop in requests for a few days might return to default locations and heuristics would have to be met again. This was problematic for workloads that made requests to a geographically located resource every few days or longer. In this scenario, your Worker would never get placed optimally. This is no longer the case.

Agents, Workers - npm i agents

Tue, 18 Mar 2025 00:00:00 GMT

`agents-sdk` -> `agents` Updated

📝 We've renamed the Agents package to agents!

If you've already been building with the Agents SDK, you can update your dependencies to use the new package name, and replace references to agents-sdk with agents:

# Install the new package
npm i agents

# Remove the old (deprecated) package
npm uninstall agents-sdk

# Find instances of the old package name in your codebase
grep -r 'agents-sdk' .
# Replace instances of the old package name with the new one
# (or use find-replace in your editor)
sed -i 's/agents-sdk/agents/g' $(grep -rl 'agents-sdk' .)

All future updates will be pushed to the new agents package, and the older package has been marked as deprecated.

Agents SDK updates New

We've added a number of big new features to the Agents SDK over the past few weeks, including:

You can now set cors: true when using routeAgentRequest to return permissive default CORS headers to Agent responses.
The regular client now syncs state on the agent (just like the React version).
useAgentChat bug fixes for passing headers/credentials, including properly clearing cache on unmount.
Experimental /schedule module with a prompt/schema for adding scheduling to your app (with evals!).
Changed the internal zod schema to be compatible with the limitations of Google's Gemini models by removing the discriminated union, allowing you to use Gemini models with the scheduling API.

We've also fixed a number of bugs with state synchronization and the React hooks.

JavaScript

// via https://github.com/cloudflare/agents/tree/main/examples/cross-domain
export default {
  async fetch(request, env) {
    return (
      // Set { cors: true } to enable CORS headers.
      (await routeAgentRequest(request, env, { cors: true })) ||
      new Response("Not found", { status: 404 })
    );
  },
};

TypeScript

// via https://github.com/cloudflare/agents/tree/main/examples/cross-domain
export default {
  async fetch(request: Request, env: Env) {
    return (
      // Set { cors: true } to enable CORS headers.
      (await routeAgentRequest(request, env, { cors: true })) ||
      new Response("Not found", { status: 404 })
    );
  },
} satisfies ExportedHandler<Env>;

Call Agent methods from your client code New

We've added a new @unstable_callable() decorator for defining methods that can be called directly from clients. This allows you call methods from within your client code: you can call methods (with arguments) and get native JavaScript objects back.

JavaScript

// server.ts
import { unstable_callable, Agent } from "agents";
export class Rpc extends Agent {
  // Use the decorator to define a callable method
  @unstable_callable({
    description: "rpc test",
  })
  async getHistory() {
    return this.sql`SELECT * FROM history ORDER BY created_at DESC LIMIT 10`;
  }
}

TypeScript

// server.ts
import { unstable_callable, Agent, type StreamingResponse } from "agents";
import type { Env } from "../server";

export class Rpc extends Agent<Env> {
  // Use the decorator to define a callable method
  @unstable_callable({
    description: "rpc test",
  })
  async getHistory() {
    return this.sql`SELECT * FROM history ORDER BY created_at DESC LIMIT 10`;
  }
}

agents-starter Updated

We've fixed a number of small bugs in the agents-starter project — a real-time, chat-based example application with tool-calling & human-in-the-loop built using the Agents SDK. The starter has also been upgraded to use the latest wrangler v4 release.

If you're new to Agents, you can install and run the agents-starter project in two commands:

# Install it
$ npm create cloudflare@latest agents-starter -- --template="cloudflare/agents-starter"
# Run it
$ npm run start

You can use the starter as a template for your own Agents projects: open up src/server.ts and src/client.tsx to see how the Agents SDK is used.

Workers - Import `env` to access bindings in your Worker's global scope

Mon, 17 Mar 2025 00:00:00 GMT

You can now access bindings from anywhere in your Worker by importing the env object from cloudflare:workers.

Previously, env could only be accessed during a request. This meant that bindings could not be used in the top-level context of a Worker.

Now, you can import env and access bindings such as secrets or environment variables in the initial setup for your Worker:

import { env } from "cloudflare:workers";
import ApiClient from "example-api-client";

// API_KEY and LOG_LEVEL now usable in top-level scope
const apiClient = ApiClient.new({ apiKey: env.API_KEY });
const LOG_LEVEL = env.LOG_LEVEL || "info";

export default {
  fetch(req) {
    // you can use apiClient or LOG_LEVEL, configured before any request is handled
  },
};

Additionally, env was normally accessed as a argument to a Worker's entrypoint handler, such as fetch. This meant that if you needed to access a binding from a deeply nested function, you had to pass env as an argument through many functions to get it to the right spot. This could be cumbersome in complex codebases.

Now, you can access the bindings from anywhere in your codebase without passing env as an argument:

// helpers.js
import { env } from "cloudflare:workers";

// env is *not* an argument to this function
export async function getValue(key) {
  let prefix = env.KV_PREFIX;
  return await env.KV.get(`${prefix}-${key}`);
}

For more information, see documentation on accessing env.

Workers, Pages - Retry Pages & Workers Builds Directly from GitHub

Mon, 17 Mar 2025 00:00:00 GMT

You can now retry your Cloudflare Pages and Workers builds directly from GitHub. No need to switch to the Cloudflare Dashboard for a simple retry!

Let\u2019s say you push a commit, but your build fails due to a spurious error like a network timeout. Instead of going to the Cloudflare Dashboard to manually retry, you can now rerun the build with just a few clicks inside GitHub, keeping you inside your workflow.

For Pages and Workers projects connected to a GitHub repository:

When a build fails, go to your GitHub repository or pull request
Select the failed Check Run for the build
Select "Details" on the Check Run
Select "Rerun" to trigger a retry build for that commit

Learn more about Pages Builds and Workers Builds.

Workers - Use the latest JavaScript features with Wrangler CLI v4

Thu, 13 Mar 2025 00:00:00 GMT

We've released the next major version of Wrangler, the CLI for Cloudflare Workers — wrangler@4.0.0. Wrangler v4 is a major release focused on updates to underlying systems and dependencies, along with improvements to keep Wrangler commands consistent and clear.

You can run the following command to install it in your projects:

npm i wrangler@latest

yarn add wrangler@latest

pnpm add wrangler@latest

bun add wrangler@latest

A detailed migration guide is available and if you find a bug or hit a roadblock when upgrading to Wrangler v4, open an issue on the cloudflare/workers-sdk repository on GitHub.

Going forward, we'll continue supporting Wrangler v3 with bug fixes and security updates until Q1 2026, and with critical security updates until Q1 2027, at which point it will be out of support.

Workers - Set breakpoints and debug your Workers tests with @cloudflare/vitest-pool-workers

Thu, 13 Mar 2025 00:00:00 GMT

You can now debug your Workers tests with our Vitest integration by running the following command:

vitest --inspect --no-file-parallelism

Attach a debugger to the port 9229 and you can start stepping through your Workers tests. This is available with @cloudflare/vitest-pool-workers v0.7.5 or later.

Learn more in our documentation.

Workers - Access your Worker's environment variables from process.env

Tue, 11 Mar 2025 00:00:00 GMT

You can now access environment variables and secrets on process.env when using the nodejs_compat compatibility flag.

const apiClient = ApiClient.new({ apiKey: process.env.API_KEY });
const LOG_LEVEL = process.env.LOG_LEVEL || "info";

In Node.js, environment variables are exposed via the global process.env object. Some libraries assume that this object will be populated, and many developers may be used to accessing variables in this way.

Previously, the process.env object was always empty unless written to in Worker code. This could cause unexpected errors or friction when developing Workers using code previously written for Node.js.

Now, environment variables, secrets, and version metadata can all be accessed on process.env.

To opt-in to the new process.env behaviour now, add the nodejs_compat_populate_process_env compatibility flag to your wrangler.json configuration:

wrangler.jsonc

{
  // Rest of your configuration
  // Add "nodejs_compat_populate_process_env" to your compatibility_flags array
  "compatibility_flags": ["nodejs_compat", "nodejs_compat_populate_process_env"],
  // Rest of your configuration

wrangler.toml

compatibility_flags = [ "nodejs_compat", "nodejs_compat_populate_process_env" ]

After April 1, 2025, populating process.env will become the default behavior when both nodejs_compat is enabled and your Worker's compatibility_date is after "2025-04-01".

Workers - Use the latest JavaScript features with Wrangler CLI v4.0.0-rc.0

Fri, 28 Feb 2025 00:00:00 GMT

We've released a release candidate of the next major version of Wrangler, the CLI for Cloudflare Workers — wrangler@4.0.0-rc.0.

You can run the following command to install it and be one of the first to try it out:

npm i wrangler@v4-rc

yarn add wrangler@v4-rc

pnpm add wrangler@v4-rc

bun add wrangler@v4-rc

Unlike previous major versions of Wrangler, which were foundational rewrites and rearchitectures — Version 4 of Wrangler includes a much smaller set of changes. If you use Wrangler today, your workflow is very unlikely to change. Before we release Wrangler v4 and advance past the release candidate stage, we'll share a detailed migration guide in the Workers developer docs. But for the vast majority of cases, you won't need to do anything to migrate — things will just work as they do today. We are sharing this release candidate in advance of the official release of v4, so that you can try it out early and share feedback.

New JavaScript language features that you can now use with Wrangler v4

Version 4 of Wrangler updates the version of esbuild that Wrangler uses internally, allowing you to use modern JavaScript language features, including:

The `using` keyword from Explicit Resource Management

The using keyword from the Explicit Resource Management standard makes it easier to work with the JavaScript-native RPC system built into Workers. This means that when you obtain a stub, you can ensure that it is automatically disposed when you exit scope it was created in:

function sendEmail(id, message) {
  using user = await env.USER_SERVICE.findUser(id);
  await user.sendEmail(message);

  // user[Symbol.dispose]() is implicitly called at the end of the scope.
}

Import attributes

Import attributes allow you to denote the type or other attributes of the module that your code imports. For example, you can import a JSON module, using the following syntax:

import data from "./data.json" with { type: "json" };

Other changes

`--local` is now the default for all CLI commands

All commands that access resources (for example, wrangler kv, wrangler r2, wrangler d1) now access local datastores by default, ensuring consistent behavior.

Clearer policy for the minimum required version of Node.js required to run Wrangler

Moving forward, the active, maintenance, and current versions of Node.js will be officially supported by Wrangler. This means the minimum officially supported version of Node.js you must have installed for Wrangler v4 will be Node.js v18 or later. This policy mirrors how many other packages and CLIs support older versions of Node.js, and ensures that as long as you are using a version of Node.js that the Node.js project itself supports, this will be supported by Wrangler as well.

Features previously deprecated in Wrangler v3 are now removed in Wrangler v4

All previously deprecated features in Wrangler v2 and in Wrangler v3 have now been removed. Additionally, the following features that were deprecated during the Wrangler v3 release have been removed:

Legacy Assets (using wrangler dev/deploy --legacy-assets or the legacy_assets config file property). Instead, we recommend you migrate to Workers assets.
Legacy Node.js compatibility (using wrangler dev/deploy --node-compat or the node_compat config file property). Instead, use the nodejs_compat compatibility flag. This includes the functionality from legacy node_compat polyfills and natively implemented Node.js APIs.
wrangler version. Instead, use wrangler --version to check the current version of Wrangler.
getBindingsProxy() (via import { getBindingsProxy } from "wrangler"). Instead, use the getPlatformProxy() API, which takes exactly the same arguments.
usage_model. This no longer has any effect, after the rollout of Workers Standard Pricing.

We'd love your feedback! If you find a bug or hit a roadblock when upgrading to Wrangler v4, open an issue on the cloudflare/workers-sdk repository on GitHub.

Agents, Workers - Introducing the Agents SDK

Tue, 25 Feb 2025 00:00:00 GMT

We've released the Agents SDK, a package and set of tools that help you build and ship AI Agents.

You can get up and running with a chat-based AI Agent (and deploy it to Workers) that uses the Agents SDK, tool calling, and state syncing with a React-based front-end by running the following command:

npm create cloudflare@latest agents-starter -- --template="cloudflare/agents-starter"
# open up README.md and follow the instructions

You can also add an Agent to any existing Workers application by installing the agents package directly

npm i agents

... and then define your first Agent:

import { Agent } from "agents";

export class YourAgent extends Agent<Env> {
  // Build it out
  // Access state on this.state or query the Agent's database via this.sql
  // Handle WebSocket events with onConnect and onMessage
  // Run tasks on a schedule with this.schedule
  // Call AI models
  // ... and/or call other Agents.
}

Head over to the Agents documentation to learn more about the Agents SDK, the SDK APIs, as well as how to test and deploying agents to production.

Workers - Autofix Worker name configuration errors at build time

Thu, 20 Feb 2025 00:00:00 GMT

Small misconfigurations shouldn’t break your deployments. Cloudflare is introducing automatic error detection and fixes in Workers Builds, identifying common issues in your wrangler.toml or wrangler.jsonc and proactively offering fixes, so you spend less time debugging and more time shipping.

Here's how it works:

Before running your build, Cloudflare checks your Worker's Wrangler configuration file (wrangler.toml or wrangler.jsonc) for common errors.
Once you submit a build, if Cloudflare finds an error it can fix, it will submit a pull request to your repository that fixes it.
Once you merge this pull request, Cloudflare will run another build.

We're starting with fixing name mismatches between your Wrangler file and the Cloudflare dashboard, a top cause of build failures.

This is just the beginning, we want your feedback on what other errors we should catch and fix next. Let us know in the Cloudflare Developers Discord, #workers-and-pages-feature-suggestions.

Agents, Workers, Workflows - Build AI Agents with Example Prompts

Fri, 14 Feb 2025 00:00:00 GMT

We've added an example prompt to help you get started with building AI agents and applications on Cloudflare Workers, including Workflows, Durable Objects, and Workers KV.

You can use this prompt with your favorite AI model, including Claude 3.5 Sonnet, OpenAI's o3-mini, Gemini 2.0 Flash, or Llama 3.3 on Workers AI. Models with large context windows will allow you to paste the prompt directly: provide your own prompt within the <user_prompt></user_prompt> tags.

{paste_prompt_here}
<user_prompt>
user: Build an AI agent using Cloudflare Workflows. The Workflow should run when a new GitHub issue is opened on a specific project with the label 'help' or 'bug', and attempt to help the user troubleshoot the issue by calling the OpenAI API with the issue title and description, and a clear, structured prompt that asks the model to suggest 1-3 possible solutions to the issue. Any code snippets should be formatted in Markdown code blocks. Documentation and sources should be referenced at the bottom of the response. The agent should then post the response to the GitHub issue. The agent should run as the provided GitHub bot account.
</user_prompt>

This prompt is still experimental, but we encourage you to try it out and provide feedback.

Workers - Create and deploy Workers from Git repositories

Fri, 07 Feb 2025 00:00:00 GMT

You can now create a Worker by:

Importing a Git repository: Choose an existing Git repo on your GitHub/GitLab account and set up Workers Builds to deploy your Worker.
Deploying a template with Git: Choose from a brand new selection of production ready examples to help you get started with popular frameworks like Astro, Remix and Next or build stateful applications with Cloudflare resources like D1 databases, Workers AI or Durable Objects! When you're ready to deploy, Cloudflare will set up your project by cloning the template to your GitHub/GitLab account, provisioning any required resources and deploying your Worker.

With every push to your chosen branch, Cloudflare will automatically build and deploy your Worker.

To get started, go to the Workers dashboard.

These new features are available today in the Cloudflare dashboard to a subset of Cloudflare customers, and will be coming to all customers in the next few weeks. Don't see it in your dashboard, but want early access? Add your Cloudflare Account ID to this form.

Workers - Revamped Workers Metrics

Mon, 03 Feb 2025 00:00:00 GMT

We've revamped the Workers Metrics dashboard.

Now you can easily compare metrics across Worker versions, understand the current state of a gradual deployment, and review key Workers metrics in a single view. This new interface enables you to:

Drag-and-select using a graphical timepicker for precise metric selection.

Use histograms to visualize cumulative metrics, allowing you to bucket and compare rates over time.
Focus on Worker versions by directly interacting with the version numbers in the legend.

Monitor and compare active gradual deployments.
Track error rates across versions with grouping both by version and by invocation status.
Measure how Smart Placement improves request duration.

Learn more about metrics.

Workers - Transform HTML quickly with streaming content

Fri, 31 Jan 2025 00:00:00 GMT

You can now transform HTML elements with streamed content using HTMLRewriter.

Methods like replace, append, and prepend now accept Response and ReadableStream values as Content.

This can be helpful in a variety of situations. For instance, you may have a Worker in front of an origin, and want to replace an element with content from a different source. Prior to this change, you would have to load all of the content from the upstream URL and convert it into a string before replacing the element. This slowed down overall response times.

Now, you can pass the Response object directly into the replace method, and HTMLRewriter will immediately start replacing the content as it is streamed in. This makes responses faster.

JavaScript

class ElementRewriter {
  async element(element) {
    // able to replace elements while streaming content
    // the fetched body is not buffered into memory as part
    // of the replace
    let res = await fetch("https://upstream-content-provider.example");
    element.replace(res);
  }
}

export default {
  async fetch(request, env, ctx) {
    let response = await fetch("https://site-to-replace.com");
    return new HTMLRewriter()
      .on("[data-to-replace]", new ElementRewriter())
      .transform(response);
  },
};

TypeScript

class ElementRewriter {
  async element(element: any) {
    // able to replace elements while streaming content
    // the fetched body is not buffered into memory as part
    // of the replace
    let res = await fetch('https://upstream-content-provider.example');
    element.replace(res);
  }
}

export default {
  async fetch(request, env, ctx): Promise<Response> {
    let response = await fetch('https://site-to-replace.com');
    return new HTMLRewriter().on('[data-to-replace]', new ElementRewriter()).transform(response);
  },
} satisfies ExportedHandler<Env>;

For more information, see the HTMLRewriter documentation.

Workers, Browser Rendering - Increased Browser Rendering limits!

Thu, 30 Jan 2025 00:00:00 GMT

Browser Rendering now supports 10 concurrent browser instances per account and 10 new instances per minute, up from the previous limits of 2.

This allows you to launch more browser tasks from Cloudflare Workers.

To manage concurrent browser sessions, you can use Queues or Workflows:

JavaScript

export default {
  async queue(batch, env) {
    for (const message of batch.messages) {
      const browser = await puppeteer.launch(env.BROWSER);
      const page = await browser.newPage();

      try {
        await page.goto(message.url, {
          waitUntil: message.waitUntil,
        });
        // Process page...
      } finally {
        await browser.close();
      }
    }
  },
};

TypeScript

interface QueueMessage {
  url: string;
  waitUntil: number;
}

export interface Env {
  BROWSER_QUEUE: Queue<QueueMessage>;
  BROWSER: Fetcher;
}

export default {
  async queue(batch: MessageBatch<QueueMessage>, env: Env): Promise<void> {
    for (const message of batch.messages) {
      const browser = await puppeteer.launch(env.BROWSER);
      const page = await browser.newPage();

      try {
        await page.goto(message.url, {
          waitUntil: message.waitUntil
        });
        // Process page...
      } finally {
        await browser.close();
      }
    }
  }
};

Workers - Support for Node.js DNS, Net, and Timer APIs in Workers

Tue, 28 Jan 2025 00:00:00 GMT

When using a Worker with the nodejs_compat compatibility flag enabled, you can now use the following Node.js APIs:

node:net

You can use node:net to create a direct connection to servers via a TCP sockets with net.Socket.

JavaScript

import net from "node:net";

const exampleIP = "127.0.0.1";

export default {
  async fetch(req) {
    const socket = new net.Socket();
    socket.connect(4000, exampleIP, function () {
      console.log("Connected");
    });

    socket.write("Hello, Server!");
    socket.end();

    return new Response("Wrote to server", { status: 200 });
  },
};

TypeScript

import net from "node:net";

const exampleIP = "127.0.0.1";

export default {
  async fetch(req): Promise<Response> {
    const socket = new net.Socket();
    socket.connect(4000, exampleIP, function () {
      console.log("Connected");
    });

    socket.write("Hello, Server!");
    socket.end();

    return new Response("Wrote to server", { status: 200 });
  },
} satisfies ExportedHandler;

Additionally, you can now use other APIs including net.BlockList and net.SocketAddress.

Note that net.Server is not supported.

node:dns

You can use node:dns for name resolution via DNS over HTTPS using Cloudflare DNS at 1.1.1.1.

JavaScript

import dns from "node:dns";

let response = await dns.promises.resolve4("cloudflare.com", "NS");

TypeScript

import dns from 'node:dns';

let response = await dns.promises.resolve4('cloudflare.com', 'NS');

All node:dns functions are available, except lookup, lookupService, and resolve which throw "Not implemented" errors when called.

node:timers

You can use node:timers to schedule functions to be called at some future period of time.

This includes setTimeout for calling a function after a delay, setInterval for calling a function repeatedly, and setImmediate for calling a function in the next iteration of the event loop.

JavaScript

import timers from "node:timers";

console.log("first");
timers.setTimeout(() => {
  console.log("last");
}, 10);

timers.setTimeout(() => {
  console.log("next");
});

TypeScript

import timers from "node:timers";

console.log("first");
timers.setTimeout(() => {
  console.log("last");
}, 10);

timers.setTimeout(() => {
  console.log("next");
});

Workers - Faster Workers Builds with Build Caching and Watch Paths

Sun, 29 Dec 2024 00:00:00 GMT

Workers Builds, the integrated CI/CD system for Workers (currently in beta), now lets you cache artifacts across builds, speeding up build jobs by eliminating repeated work, such as downloading dependencies at the start of each build.

Build Caching: Cache dependencies and build outputs between builds with a shared project-wide cache, ensuring faster builds for the entire team.
Build Watch Paths: Define paths to include or exclude from the build process, ideal for monorepos to target only the files that need to be rebuilt per Workers project.

To get started, select your Worker on the Cloudflare dashboard then go to Settings > Builds, and connect a GitHub or GitLab repository. Once connected, you'll see options to configure Build Caching and Build Watch Paths.

Workers - Bypass caching for subrequests made from Cloudflare Workers, with Request.cache

Mon, 11 Nov 2024 00:00:00 GMT

You can now use the cache property of the Request interface to bypass Cloudflare's cache when making subrequests from Cloudflare Workers, by setting its value to no-store.

JavaScript

export default {
  async fetch(req, env, ctx) {
    const request = new Request("https://cloudflare.com", {
      cache: "no-store",
    });
    const response = await fetch(request);
    return response;
  },
};

TypeScript

export default {
  async fetch(req, env, ctx): Promise<Response> {
    const request = new Request("https://cloudflare.com", { cache: 'no-store'});
    const response = await fetch(request);
    return response;
  }
} satisfies ExportedHandler<Environment>

When you set the value to no-store on a subrequest made from a Worker, the Cloudflare Workers runtime will not check whether a match exists in the cache, and not add the response to the cache, even if the response includes directives in the Cache-Control HTTP header that otherwise indicate that the response is cacheable.

If you've tried to use @planetscale/database, redis-js, stytch-node, supabase, axiom-js or have seen the error message The cache field on RequestInitializerDict is not implemented in fetch — you should try again, making sure that the Compatibility Date of your Worker is set to on or after 2024-11-11, or the cache_option_enabled compatibility flag is enabled for your Worker.

Learn how the Cache works with Cloudflare Workers
Enable Node.js compatibility for your Cloudflare Worker
Explore Runtime APIs and Bindings available in Cloudflare Workers

Workers, Workflows - Workflows is now in open beta

Thu, 24 Oct 2024 00:00:00 GMT

Workflows is now in open beta, and available to any developer a free or paid Workers plan.

Workflows allow you to build multi-step applications that can automatically retry, persist state and run for minutes, hours, days, or weeks. Workflows introduces a programming model that makes it easier to build reliable, long-running tasks, observe as they progress, and programmatically trigger instances based on events across your services.

Get started

You can get started with Workflows by following our get started guide and/or using npm create cloudflare to pull down the starter project:

npm create cloudflare@latest workflows-starter -- --template "cloudflare/workflows-starter"

You can open the src/index.ts file, extend it, and use wrangler deploy to deploy your first Workflow. From there, you can:

Learn the Workflows API
Trigger Workflows via your Workers apps.
Understand the Rules of Workflows and how to adopt best practices

Cloudflare changelogs | Workers

Workflows, Workers - All Wrangler commands for Workflows now support local development

Workers - Deploy Hooks are now available for Workers Builds

Built-in optimizations

Workers - New L4 transport telemetry fields in Workers

New properties

Example: Log connection quality metrics

Workers - New RFC 9440 mTLS certificate fields in Workers

New fields

Example: forwarding client certificate headers to your origin

Workers - Declare required secrets in your Wrangler configuration

Local development

Type generation

Deploy

Workers - Dynamic Workers, now in open beta

Use Dynamic Workers for

Executing Dynamic Workers

Helper libraries for Dynamic Workers

Try it out

Pricing

Workflows, Workers - Workflow instances now support pause(), resume(), restart(), and terminate() methods in local development

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

Readable state on useAgent and AgentClient

Idempotent schedule()

Typed AgentClient with call inference and stub proxy

@cloudflare/ai-chat fixes

keepAlive() and keepAliveWhile() are no longer experimental

@cloudflare/codemode: TanStack AI integration

Upgrade

Cloudflare Tunnel, Workers - Manage Cloudflare Tunnels with Wrangler

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

New @cloudflare/codemode/mcp export

Zero-dependency main entry point

Custom sandbox modules

Internal normalization and sanitization

Upgrade

Workflows, Workers - Workflow steps now expose retry attempt number via step context

Workflows, Workers - Workflows step limit increased to 25,000 steps per instance

Agents, Workers - Agents SDK v0.7.0: Observability rewrite, keepAlive, and waitForMcpConnections

Observability rewrite

keepAlive() and keepAliveWhile()

waitForMcpConnections

Other improvements

Upgrade

Agents, Workers - Agents SDK v0.6.0: RPC transport for MCP, optional OAuth, hardened schema conversion, and @cloudflare/ai-chat fixes

RPC transport for MCP

Optional OAuth for MCP connections

Hardened JSON Schema to TypeScript converter

@cloudflare/ai-chat fixes

Upgrade

Workers - Better Windows support for Python Workers

Requirements

Workers - Write structured queries to filter and search your Workers logs and traces

Workers - No config? No problem. Just `wrangler deploy`

Using Wrangler locally

Using the Cloudflare dashboard

Background

Durable Objects, Workers - deleteAll() now deletes Durable Object alarm

Pipelines, Workers - Dropped event metrics, typed Pipelines bindings, and improved setup

Dropped event metrics

Typed Pipelines bindings

Improved Pipelines setup

Agents, Workers - @cloudflare/codemode v0.1.0: a new runtime agnostic modular architecture

Breaking changes

New features

DynamicWorkerExecutor

Usage

Wrangler configuration

Upgrade

Agents, Workers - Agents SDK v0.5.0: Protocol message control, retry utilities, data parts, and @cloudflare/ai-chat v0.1.0

Retry utilities

Per-connection protocol message control

@cloudflare/ai-chat v0.1.0

Synchronous queue and schedule getters

Other improvements

Upgrade

Workers - Quick Editor devtools replaced with log viewer

Workers - New Best Practices guide for Workers

Workers, Agents, Workers AI - Introducing GLM-4.7-Flash on Workers AI, @cloudflare/tanstack-ai, and workers-ai-provider v3.1.1

GLM-4.7-Flash — Multilingual Text Generation Model

Readable `state` on `useAgent` and `AgentClient`

Idempotent `schedule()`

Typed `AgentClient` with `call` inference and `stub` proxy

`@cloudflare/ai-chat` fixes

`keepAlive()` and `keepAliveWhile()` are no longer experimental

`@cloudflare/codemode`: TanStack AI integration

New `@cloudflare/codemode/mcp` export

`keepAlive()` and `keepAliveWhile()`

`waitForMcpConnections`

`@cloudflare/ai-chat` fixes

`DynamicWorkerExecutor`

`@cloudflare/ai-chat` v0.1.0

Deprecate `onStateUpdate` in favor of `onStateChanged`

Filtering using `HAVING`

Pattern matching using `LIKE`

The `config` option