Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds

Workers

Jun 05, 2025

Performance and size optimization for the Cloudflare adapter for Open Next
Workers
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.

Jun 03, 2025

View an architecture diagram of your Worker directly in the Cloudflare dashboard
Workers
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.

May 30, 2025

Debug, profile, and view logs for your Worker in Chrome Devtools — now supported in the Cloudflare Vite plugin
Workers
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:

May 29, 2025

50-500ms Faster D1 REST API Requests
D1 Workers
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.

May 22, 2025

Handle incoming request cancellation in Workers with Request.signal

Workers

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
TypeScript

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

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.

May 16, 2025

Durable Objects are now supported in Python Workers
Workers Durable Objects
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:
Python
```
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
- wrangler.toml
JSONC
{ "durable_objects": { "bindings": [ { "name": "MY_DURABLE_OBJECT", "class_name": "MyDurableObject" } ] } }
TOML
[[durable_objects.bindings]] name = "MY_DURABLE_OBJECT" class_name = "MyDurableObject"
Then define the storage backend for your Durable Object:
- wrangler.jsonc
- wrangler.toml
JSONC
{ "migrations": [ { "tag": "v1", // Should be unique for each entry "new_sqlite_classes": [ // Array of new classes "MyDurableObject" ] } ] }
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.

May 08, 2025

Improved memory efficiency for WebAssembly Workers
Workers
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.

Apr 24, 2025

Cron triggers are now supported in Python Workers

Workers

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

{
  "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 * *"
    ]
  }
}

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

Apr 15, 2025

Fixed and documented Workers Routes and Secrets API
Workers Workers for Platforms
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.
Example request
```
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" }'
```
Example bad response
```
{
  "result": {
    "id": "bf153a27ba2b464bb9f04dcf75de1ef9",
    "pattern": "",
    "script": null,
    "request_limit_fail_open": false
  },
  "success": true,
  "errors": [],
  "messages": []
}
```
Now, it properly returns all values!
Example good response
```
{
  "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

Apr 10, 2025

D1 Read Replication Public Beta
D1 Workers
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.
TypeScript
```
// 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 ↗.

Apr 10, 2025

Cloudflare Pipelines now available in beta

Pipelines R2 Workers

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.

Apr 09, 2025

Investigate your Workers with the Query Builder in the new Observability dashboard
Workers
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
- wrangler.toml
JSONC
{ "observability": { "enabled": true, "logs": { "invocation_logs": true, "head_sampling_rate": 1 // optional. default = 1. } } }
TOML
[observability] enabled = true [observability.logs] invocation_logs = true head_sampling_rate = 1

Apr 09, 2025

CPU time and Wall time now published for Workers Invocations
Workers
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.

Apr 08, 2025

Deploy a Workers application in seconds with one-click
Workers
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:
1. 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.
2. 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.
3. 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.
4. 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.

Apr 08, 2025

Full-stack frameworks are now Generally Available on Cloudflare Workers
Workers Workers for Platforms

The following full-stack frameworks now have Generally Available ("GA") adapters for Cloudflare Workers, and are ready for you to use in production:
- React Router v7 (Remix)
- Astro
- Hono
- Vue.js
- Nuxt
- Svelte (SvelteKit)
- And more.
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.

Apr 08, 2025

Improved support for Node.js Crypto and TLS APIs in Workers

Workers

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.

Apr 08, 2025

The Cloudflare Vite plugin is now Generally Available
Workers
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:
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!

Apr 07, 2025

Build MCP servers with the Agents SDK
Agents Workers
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
- TypeScript
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:
Terminal window
```
npm create cloudflare@latest -- --template cloudflare/agents-starter
```
See the full release notes and changelog on the Agents SDK repository ↗ and

Apr 07, 2025

Durable Objects on Workers Free plan
Durable Objects Workers
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:
JavaScript
```
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:
- Documentation
- Zero-latency SQLite storage in every Durable Object blog ↗

Apr 07, 2025

SQLite in Durable Objects GA with 10GB storage per object
Durable Objects Workers
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.
JavaScript
```
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 ↗.

Apr 07, 2025

Capture up to 256 KB of log events in each Workers Invocation
Workers
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.

Apr 07, 2025

Workflows is now Generally Available

Workflows Workers

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
TypeScript

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

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
TypeScript

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

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.

Mar 26, 2025

Run Workers for up to 5 minutes of CPU-time
Workers
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
- wrangler.toml
JSONC
{ // ...rest of your configuration... "limits": { "cpu_ms": 300000, }, // ...rest of your configuration... }
TOML
[limits] cpu_ms = 300_000
CPU time is the amount of time the CPU actually spends doing work during a given request. If a Worker's request makes a sub-request and waits for that request to come back before doing additional work, this time spent waiting is not counted towards CPU time.
Worker requests could run for more than 30 seconds of total time prior to this change — only CPU time was limited.

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.

Mar 25, 2025

Source Maps are Generally Available
Workers
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
- wrangler.toml
JSONC
{ "upload_source_maps": true }
TOML
upload_source_maps = true

Mar 22, 2025

New Managed WAF rule for Next.js CVE-2025-29927.
Workers Pages WAF
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:
1. Head to Security > WAF > Managed rules in the Cloudflare dashboard for the zone (website) you want to protect.
2. Click the three dots next to Cloudflare Managed Ruleset and choose Edit
3. Scroll down and choose Browse Rules
4. Search for CVE-2025-29927 (ruleId: 34583778093748cc83ff7b38f472013e)
5. 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.
6. Click Next
7. 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:
1. Head to Security > WAF > Custom rules in the Cloudflare dashboard for the zone (website) you want to protect.
2. Give the rule a name - e.g. next-js-CVE-2025-29927
3. Set the matching parameters for the rule match any request where the x-middleware-subrequest header exists per the rule expression below.
Terminal window
```
(len(http.request.headers["x-middleware-subrequest"]) > 0)
```
1. 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).
2. 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.

Search all changelog entries

Changelog

Workers Routes API

Workers Secrets API

Workers Logs is now Generally Available

node:crypto

node:tls

Framework support

Configuration

Agents SDK updates

Human-in-the-loop

Enable the Managed Rule (strongly recommended)

Create a WAF rule (manual)

Next.js CVE-2025-29927