---
title: Workers Changelog
image: https://edgetunnel-b2h.pages.dev/cf-twitter-card.png
---

> Documentation Index  
> Fetch the complete documentation index at: https://edgetunnel-b2h.pages.dev/changelog/llms.txt  
> Use this file to discover all available pages before exploring further. 

[Skip to content](#%5Ftop) 

# Changelog

New updates and improvements at Cloudflare.

[ Subscribe to RSS ](https://edgetunnel-b2h.pages.dev/changelog/rss/index.xml) [ View RSS feeds ](https://edgetunnel-b2h.pages.dev/fundamentals/new-features/available-rss-feeds/) 

Workers

![hero image](https://edgetunnel-b2h.pages.dev/_astro/hero.CVYJHPAd_26AMqX.svg) 

Jun 30, 2025
1. ### [Remote bindings (beta) now works with Next.js — connect to remote resources (D1, KV, R2, etc.) during local development](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-25-getplatformproxy-support-remote-bindings/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
We [recently announced ↗](https://github.com/cloudflare/workers-sdk/discussions/9660) our public beta for [remote bindings](https://edgetunnel-b2h.pages.dev/workers/local-development/#remote-bindings), which allow you to connect to deployed resources running on your Cloudflare account (like [R2 buckets](https://edgetunnel-b2h.pages.dev/r2) or [D1 databases](https://edgetunnel-b2h.pages.dev/d1)) while running a local development session.  
Now, you can use remote bindings with your Next.js applications through the [@opennextjs/cloudflare adaptor ↗](https://opennext.js.org/cloudflare/bindings#remote-bindings) by enabling the experimental feature in your `next.config.ts`:  
```diff  
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 ](#tab-panel-3093)
  * [  wrangler.toml ](#tab-panel-3094)

**JSONC**  
```jsonc  
{  
  "r2_buckets": [  
    {  
      "bucket_name": "testing-bucket",  
      "binding": "MY_BUCKET",  
      "experimental_remote": true,  
    },  
  ],  
}  
```

**TOML**  
```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](https://edgetunnel-b2h.pages.dev/workers/local-development/#bindings-during-local-development).  
#### Remote bindings & ISR  
Remote bindings are also used during the build process, which comes with significant benefits for pages using [Incremental Static Regeneration (ISR) ↗](https://opennext.js.org/aws/inner%5Fworkings/components/server/node#isrssg). 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](https://edgetunnel-b2h.pages.dev/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 ↗](https://opennext.js.org/cloudflare/bindings#remote-bindings).

**Have feedback?** Join the discussion in our [beta announcement ↗](https://github.com/cloudflare/workers-sdk/discussions/9660) to share feedback or report any issues.

Jun 26, 2025
1. ### [Run and connect Workers in separate dev commands with the Cloudflare Vite plugin](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-26-vite-plugin-cross-commands-binding/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
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:  
```sh  
# 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](https://edgetunnel-b2h.pages.dev/workers/local-development/multi-workers) guide to learn more about the different approaches and when to use each one.

Jun 25, 2025
1. ### [Run AI-generated code on-demand with Code Sandboxes (new)](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-24-announcing-sandboxes/)  
[ Agents ](https://edgetunnel-b2h.pages.dev/agents/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)[ Workflows ](https://edgetunnel-b2h.pages.dev/workflows/)  
AI is supercharging app development for everyone, but we need a safe way to run untrusted, LLM-written code. We’re introducing [Sandboxes ↗](https://www.npmjs.com/package/@cloudflare/sandbox), which let your Worker run actual processes in a secure, container-based environment.

**TypeScript**  
```ts  
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.

Jun 25, 2025
1. ### [@cloudflare/actors library - SDK for Durable Objects in beta](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-25-actors-package-alpha/)  
[ Durable Objects ](https://edgetunnel-b2h.pages.dev/durable-objects/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The new [@cloudflare/actors ↗](https://www.npmjs.com/package/@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](https://edgetunnel-b2h.pages.dev/durable-objects/concepts/what-are-durable-objects/#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 ↗](https://edgetunnel-b2h.pages.dev/durable-objects/api/base/) is always available for your application as needed  
Storage and alarm helper methods can be combined with [any Javascript class ↗](https://github.com/cloudflare/actors?tab=readme-ov-file#storage--alarms-with-durableobject-class) that defines your Durable Object, i.e, ones that extend `DurableObject` including the `Actor` class.

**JavaScript**  
```js  
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".

**JavaScript**  
```js  
export class MyActor extends Actor<Env> {  
    async fetch(request: Request): Promise<Response> {  
        return new Response('Hello, World!')  
    }  
}  
export default handler(MyActor);  
```  
You can [route](https://edgetunnel-b2h.pages.dev/durable-objects/get-started/#3-instantiate-and-communicate-with-a-durable-object) to different Durable Objects by name within your `Actor` class using [nameFromRequest ↗](https://github.com/cloudflare/actors?tab=readme-ov-file#actor-with-custom-name).

**JavaScript**  
```js  
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 ↗](https://github.com/cloudflare/actors?tab=readme-ov-file#getting-started). `@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 ↗](https://discord.com/channels/595317990191398933/773219443911819284).

Jun 20, 2025
1. ### [Increased blob size limits in Workers Analytics Engine](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-20-increased-blob-size-limits-in-workers-analytics/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
We’ve increased the total allowed size of [blob](https://edgetunnel-b2h.pages.dev/analytics/analytics-engine/get-started/#2-write-data-points-from-your-worker) fields on data points written to [Workers Analytics Engine](https://edgetunnel-b2h.pages.dev/analytics/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](https://edgetunnel-b2h.pages.dev/analytics/analytics-engine/limits/).

  * [  JavaScript ](#tab-panel-3107)
  * [  TypeScript ](#tab-panel-3108)

**JavaScript**  
```js  
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**  
```ts  
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"],  
    });  
  }  
};  
```

Jun 19, 2025
1. ### [Automate Worker deployments with a simplified SDK and more reliable Terraform provider](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-17-workers-terraform-sdk-api-fixes/)  
[ D1 ](https://edgetunnel-b2h.pages.dev/d1/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)[ Workers for Platforms ](https://edgetunnel-b2h.pages.dev/cloudflare-for-platforms/workers-for-platforms/)  
#### Simplified Worker Deployments with our SDKs  
We've simplified the programmatic deployment of Workers via our [Cloudflare SDKs](https://edgetunnel-b2h.pages.dev/fundamentals/api/reference/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 ↗](https://github.com/cloudflare/cloudflare-typescript) (4.4.1)
  * [cloudflare-python ↗](https://github.com/cloudflare/cloudflare-python) (4.3.1)  
For complete examples, see our guide on [programmatic Worker deployments](https://edgetunnel-b2h.pages.dev/workers/platform/infrastructure-as-code).  
#### 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:  
```bash  
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 ↗](https://github.com/cloudflare/cloudflare-typescript)

  * [  JavaScript ](#tab-panel-3109)
  * [  TypeScript ](#tab-panel-3110)

**JavaScript**  
```js  
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**  
```ts  
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 ↗](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 ↗](https://github.com/cloudflare/terraform-provider-cloudflare):

  * Fixed the [cloudflare\_workers\_script ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/workers%5Fscript) 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 ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/workers%5Ffor%5Fplatforms%5Fdispatch%5Fnamespace), 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 ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/workers%5Froute) 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](https://edgetunnel-b2h.pages.dev/workers/configuration/routing/routes)). 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 ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/d1%5Fdatabase) 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](https://edgetunnel-b2h.pages.dev/api/resources/workers/subresources/scripts/subresources/script%5Fand%5Fversion%5Fsettings) in our public OpenAPI spec and SDKs.

Jun 18, 2025
1. ### [Remote bindings public beta - Connect to remote resources (D1, KV, R2, etc.) during local development](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-18-remote-bindings-beta/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
Today [we announced the public beta ↗](https://github.com/cloudflare/workers-sdk/discussions/9660) of [remote bindings](https://edgetunnel-b2h.pages.dev/workers/local-development/#remote-bindings) for local development. With remote bindings, you can now connect to deployed resources like [R2 buckets](https://edgetunnel-b2h.pages.dev/r2/) and [D1 databases](https://edgetunnel-b2h.pages.dev/d1/) 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 ](#tab-panel-3095)
  * [  wrangler.toml ](#tab-panel-3096)

**JSONC**  
```jsonc  
{  
  "name": "my-worker",  
  // Set this to today's date  
  "compatibility_date": "2026-07-20",  
  "r2_buckets": [  
    {  
      "bucket_name": "screenshots-bucket",  
      "binding": "screenshots_bucket",  
      "experimental_remote": true,  
    },  
  ],  
}  
```

**TOML**  
```toml  
name = "my-worker"  
# Set this to today's date  
compatibility_date = "2026-07-20"  
[[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](https://edgetunnel-b2h.pages.dev/workers/local-development/#remote-bindings): Use the `wrangler dev --x-remote-bindings` command.
  * The [Cloudflare Vite Plugin](https://edgetunnel-b2h.pages.dev/workers/local-development/#remote-bindings): Refer to the documentation for how to enable in your Vite config.
  * The [Cloudflare Vitest Plugin](https://edgetunnel-b2h.pages.dev/workers/local-development/#remote-bindings): Refer to the documentation for how to enable in your Vitest config.

**Have feedback?**Join the discussion in our [beta announcement ↗](https://github.com/cloudflare/workers-sdk/discussions/9660) to share feedback or report any issues.

Jun 17, 2025
1. ### [Control which routes invoke your Worker script for Single Page Applications](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-17-advanced-routing/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
For those building [Single Page Applications (SPAs) on Workers](https://edgetunnel-b2h.pages.dev/workers/static-assets/routing/single-page-application/#advanced-routing-control), you can now explicitly define which routes invoke your Worker script in Wrangler configuration. The [run\_worker\_first config option](https://edgetunnel-b2h.pages.dev/workers/static-assets/binding/#run%5Fworker%5Ffirst) 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 ](#tab-panel-3097)
  * [  wrangler.toml ](#tab-panel-3098)

**JSONC**  
```jsonc  
{  
  "name": "my-spa-worker",  
  // Set this to today's date  
  "compatibility_date": "2026-07-20",  
  "main": "./src/index.ts",  
  "assets": {  
    "directory": "./dist/",  
    "not_found_handling": "single-page-application",  
    "binding": "ASSETS",  
    "run_worker_first": ["/api/*", "!/api/docs/*"]  
  }  
}  
```

**TOML**  
```toml  
name = "my-spa-worker"  
# Set this to today's date  
compatibility_date = "2026-07-20"  
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 ↗](https://github.com/cloudflare/workers-sdk/discussions/9143). 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](https://edgetunnel-b2h.pages.dev/workers/wrangler/install-and-update/) v4.20.0 and above
  * [Cloudflare Vite plugin](https://edgetunnel-b2h.pages.dev/workers/vite-plugin/get-started/) v1.7.0 and above

Jun 17, 2025
1. ### [SSRF vulnerability in @opennextjs/cloudflare proactively mitigated for all Cloudflare customers](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-17-open-next-ssrf/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
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://www.cve.org/cverecord?id=CVE-2025-6087), [https://github.com/opennextjs/opennextjs-cloudflare/security/advisories/GHSA-rvpw-p7vw-wj3m ↗](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 ↗](https://github.com/opennextjs/opennextjs-cloudflare/pull/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 ↗](https://github.com/cloudflare/workers-sdk/pull/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 ↗](https://nextjs.org/docs/pages/api-reference/components/image#remotepatterns) filter in Next config if they need to allow-list external urls with images assets.

Jun 16, 2025
1. ### [Grant account members read-only access to the Workers Platform](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-16-workers-platform-admin-role/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
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](https://edgetunnel-b2h.pages.dev/workers/), [Pages](https://edgetunnel-b2h.pages.dev/pages/), [Durable Objects](https://edgetunnel-b2h.pages.dev/durable-objects/), [KV](https://edgetunnel-b2h.pages.dev/kv/), [R2](https://edgetunnel-b2h.pages.dev/r2/), Zones, [Zone Analytics](https://edgetunnel-b2h.pages.dev/analytics/account-and-zone-analytics/zone-analytics/) and [Page Rules](https://edgetunnel-b2h.pages.dev/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](https://edgetunnel-b2h.pages.dev/fundamentals/manage-members/roles/).

Jun 10, 2025
1. ### [Access git commit sha and branch name as environment variables in Workers Builds](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-10-default-env-vars/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
[Workers Builds](https://edgetunnel-b2h.pages.dev/workers/ci-cd/builds/) connects your Worker to a [Git repository](https://edgetunnel-b2h.pages.dev/workers/ci-cd/builds/git-integration/), 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](https://edgetunnel-b2h.pages.dev/workers/ci-cd/builds/configuration/#environment-variables) into your build process (much like the defaults in [Cloudflare Pages projects](https://edgetunnel-b2h.pages.dev/pages/configuration/build-configuration/#environment-variables)). 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](https://edgetunnel-b2h.pages.dev/workers/ci-cd/builds/configuration/#environment-variables).

Jun 09, 2025
1. ### [Workers native integrations were removed from the Cloudflare dashboard](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-09-workers-integrations-changes/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
Workers native integrations were [originally launched in May 2023 ↗](https://blog.cloudflare.com/announcing-database-integrations/) 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](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/general/#secret).  
#### 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](https://edgetunnel-b2h.pages.dev/workers/observability/logs/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 ↗](https://dash.cloudflare.com) to modify connections created by our removed native integrations feature.  
If you have previously set up an observability integration with [Sentry ↗](https://sentry.io), 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](https://edgetunnel-b2h.pages.dev/workers/observability/third-party-integrations/sentry), [Turso](https://edgetunnel-b2h.pages.dev/workers/databases/third-party-integrations/turso/), [Neon](https://edgetunnel-b2h.pages.dev/workers/databases/third-party-integrations/neon/), [Supabase](https://edgetunnel-b2h.pages.dev/workers/databases/third-party-integrations/supabase/), [PlanetScale](https://edgetunnel-b2h.pages.dev/workers/databases/third-party-integrations/planetscale/), [Upstash](https://edgetunnel-b2h.pages.dev/workers/databases/third-party-integrations/upstash/), [Xata](https://edgetunnel-b2h.pages.dev/workers/databases/third-party-integrations/xata/).

Jun 05, 2025
1. ### [Performance and size optimization for the Cloudflare adapter for Open Next](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-05-open-next-size/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/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 ↗](https://blog.cloudflare.com/deploying-nextjs-apps-to-cloudflare-workers-with-the-opennext-adapter/#1-0-and-the-road-ahead).  
`@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 ↗](https://github.com/opennextjs/opennextjs-cloudflare/security/advisories/GHSA-rvpw-p7vw-wj3m) 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
1. ### [View an architecture diagram of your Worker directly in the Cloudflare dashboard](https://edgetunnel-b2h.pages.dev/changelog/post/2025-06-03-visualize-your-worker-architecture/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/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](https://edgetunnel-b2h.pages.dev/d1), [Durable Objects](https://edgetunnel-b2h.pages.dev/durable-objects), [KV namespaces](https://edgetunnel-b2h.pages.dev/kv), and [more](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/bindings/).  
![Bindings canvas](https://edgetunnel-b2h.pages.dev/_astro/bindings-canvas.CszRUVlh_1ytnrB.webp)  
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 ↗](https://dash.cloudflare.com/?to=/:account/workers-and-pages) and open the **Bindings** tab of any Workers application.

May 30, 2025
1. ### [Debug, profile, and view logs for your Worker in Chrome Devtools — now supported in the Cloudflare Vite plugin](https://edgetunnel-b2h.pages.dev/changelog/post/2025-05-21-vite-plugin-chrome-devtools/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now [debug, profile, view logs, and analyze memory usage for your Worker ↗](https://edgetunnel-b2h.pages.dev/workers/observability/dev-tools/) using [Chrome Devtools ↗](https://developer.chrome.com/docs/devtools) when your Worker runs locally using the [Cloudflare Vite plugin ↗](https://edgetunnel-b2h.pages.dev/workers/vite-plugin/).  
Previously, this was only possible if your Worker ran locally using the [Wrangler CLI ↗](https://edgetunnel-b2h.pages.dev/workers/wrangler/), and now you can do all the same things if your Worker uses [Vite ↗](https://vite.dev/).  
When you run `vite`, you'll now see a debug URL in your console:  
```plaintext  
  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:  
![CPU Profile](https://edgetunnel-b2h.pages.dev/_astro/profile.Dz8PUp_K_Z16J4tW.webp)  
For more information on how to get the most out of Chrome Devtools, refer to the following docs:

  * [Debug code by setting breakpoints](https://edgetunnel-b2h.pages.dev/workers/observability/dev-tools/breakpoints/)
  * [Profile CPU usage](https://edgetunnel-b2h.pages.dev/workers/observability/dev-tools/cpu-usage/)
  * [Observe memory usage and debug memory leaks](https://edgetunnel-b2h.pages.dev/workers/observability/dev-tools/memory-usage/)

May 29, 2025
1. ### [50-500ms Faster D1 REST API Requests](https://edgetunnel-b2h.pages.dev/changelog/post/2025-05-30-d1-rest-api-latency/)  
[ D1 ](https://edgetunnel-b2h.pages.dev/d1/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
Users using Cloudflare's [REST API](https://edgetunnel-b2h.pages.dev/api/resources/d1/) 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](https://edgetunnel-b2h.pages.dev/d1/configuration/data-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
1. ### [Handle incoming request cancellation in Workers with Request.signal](https://edgetunnel-b2h.pages.dev/changelog/post/2025-05-22-handle-request-cancellation/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
In Cloudflare Workers, you can now attach an event listener to [Request](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/request/) objects, using the [signal property ↗](https://developer.mozilla.org/en-US/docs/Web/API/Request/signal). 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](https://edgetunnel-b2h.pages.dev/workers/configuration/compatibility-flags/#enable-requestsignal-for-incoming-requests) 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 ](#tab-panel-3111)
  * [  TypeScript ](#tab-panel-3112)

**index.js**  
```js  
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);  
  }  
}  
```

**index.ts**  
```ts  
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](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/request).

May 16, 2025
1. ### [Durable Objects are now supported in Python Workers](https://edgetunnel-b2h.pages.dev/changelog/post/2025-05-14-python-worker-durable-object/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)[ Durable Objects ](https://edgetunnel-b2h.pages.dev/durable-objects/)  
You can now create [Durable Objects](https://edgetunnel-b2h.pages.dev/durable-objects/) using [Python Workers](https://edgetunnel-b2h.pages.dev/workers/languages/python/). 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](https://edgetunnel-b2h.pages.dev/durable-objects/concepts/what-are-durable-objects/).  
You can define a Durable Object in Python in a similar way to JavaScript:

**Python**  
```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 ](#tab-panel-3099)
  * [  wrangler.toml ](#tab-panel-3100)

**JSONC**  
```jsonc  
{  
  "durable_objects": {  
    "bindings": [  
      {  
        "name": "MY_DURABLE_OBJECT",  
        "class_name": "MyDurableObject"  
      }  
    ]  
  }  
}  
```

**TOML**  
```toml  
[[durable_objects.bindings]]  
name = "MY_DURABLE_OBJECT"  
class_name = "MyDurableObject"  
```  
Then define the storage backend for your Durable Object:

  * [  wrangler.jsonc ](#tab-panel-3101)
  * [  wrangler.toml ](#tab-panel-3102)

**JSONC**  
```jsonc  
{  
  "migrations": [  
    {  
      "tag": "v1", // Should be unique for each entry  
      "new_sqlite_classes": [ // Array of new classes  
        "MyDurableObject"  
      ]  
    }  
  ]  
}  
```

**TOML**  
```toml  
[[migrations]]  
tag = "v1"  
new_sqlite_classes = [ "MyDurableObject" ]  
```  
Then test your new Durable Object locally by running `wrangler dev`:  
```bash  
npx wrangler dev  
```  
Consult the [Durable Objects documentation](https://edgetunnel-b2h.pages.dev/durable-objects/) for more details.

May 08, 2025
1. ### [Improved memory efficiency for WebAssembly Workers](https://edgetunnel-b2h.pages.dev/changelog/post/2025-05-08-finalization-registry/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
[FinalizationRegistry ↗](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global%5FObjects/FinalizationRegistry) is now available in Workers. You can opt-in using the [enable\_weak\_ref](https://edgetunnel-b2h.pages.dev/workers/configuration/compatibility-flags/#enable-finalizationregistry-and-weakref) compatibility flag.  
This can reduce memory leaks when using WebAssembly-based Workers, which includes [Python Workers](https://edgetunnel-b2h.pages.dev/workers/languages/python/) and [Rust Workers](https://edgetunnel-b2h.pages.dev/workers/languages/rust/). The FinalizationRegistry works by enabling toolchains such as [Emscripten ↗](https://emscripten.org/) and [wasm-bindgen ↗](https://wasm-bindgen.github.io/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](https://edgetunnel-b2h.pages.dev/workers/observability/dev-tools/memory-usage/), you may want to enable the FinalizationRegistry.  
For more information refer to the [enable\_weak\_ref](https://edgetunnel-b2h.pages.dev/workers/configuration/compatibility-flags/#enable-finalizationregistry-and-weakref) compatibility flag documentation.

Apr 24, 2025
1. ### [Cron triggers are now supported in Python Workers](https://edgetunnel-b2h.pages.dev/changelog/post/2025-04-22-python-worker-cron-triggers/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/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:

**Python**  
```python  
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 ](#tab-panel-3103)
  * [  wrangler.toml ](#tab-panel-3104)

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

**TOML**  
```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=*+*+*+*+*`:  
```sh  
npx wrangler dev --test-scheduled  
curl "http://localhost:8787/cdn-cgi/handler/scheduled?cron=*+*+*+*+*"  
```  
Consult the [Workers Cron Triggers page](https://edgetunnel-b2h.pages.dev/workers/configuration/cron-triggers/) for full details on cron triggers in Workers.

Apr 15, 2025
1. ### [Fixed and documented Workers Routes and Secrets API](https://edgetunnel-b2h.pages.dev/changelog/post/2025-04-15-workers-api-fixes/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)[ Workers for Platforms ](https://edgetunnel-b2h.pages.dev/cloudflare-for-platforms/workers-for-platforms/)  
#### Workers Routes API  
Previously, a request to the Workers [Create Route API](https://edgetunnel-b2h.pages.dev/api/resources/workers/subresources/routes/methods/create/) always returned `null` for "script" and an empty string for "pattern" even if the request was successful.

**Example request**  
```bash  
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**  
```json  
{  
  "result": {  
    "id": "bf153a27ba2b464bb9f04dcf75de1ef9",  
    "pattern": "",  
    "script": null,  
    "request_limit_fail_open": false  
  },  
  "success": true,  
  "errors": [],  
  "messages": []  
}  
```  
Now, it properly returns all values!

**Example good response**  
```json  
{  
  "result": {  
    "id": "bf153a27ba2b464bb9f04dcf75de1ef9",  
    "pattern": "example.com/*",  
    "script": "hello-world-script",  
    "request_limit_fail_open": false  
  },  
  "success": true,  
  "errors": [],  
  "messages": []  
}  
```  
#### Workers Secrets API  
The [Workers](https://edgetunnel-b2h.pages.dev/api/resources/workers/subresources/scripts/subresources/secrets/) and [Workers for Platforms](https://edgetunnel-b2h.pages.dev/api/resources/workers%5Ffor%5Fplatforms/subresources/dispatch/subresources/namespaces/subresources/scripts/subresources/secrets/) 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 ↗](https://github.com/cloudflare/cloudflare-typescript) (>4.2.0) and [cloudflare-python ↗](https://github.com/cloudflare/cloudflare-python) (>4.1.0).  
Note the `cloudflare_workers_secret` and `cloudflare_workers_for_platforms_script_secret` [Terraform resources ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs) are being removed in a future release. This resource is not recommended for managing secrets. Users should instead use the:

  * [Secrets Store](https://edgetunnel-b2h.pages.dev/api/resources/secrets%5Fstore/) with the "Secrets Store Secret" binding on Workers and Workers for Platforms Script Upload
  * "Secret Text" Binding on [Workers Script Upload](https://edgetunnel-b2h.pages.dev/api/resources/workers/subresources/scripts/methods/update/) and [Workers for Platforms Script Upload](https://edgetunnel-b2h.pages.dev/api/resources/workers%5Ffor%5Fplatforms/subresources/dispatch/subresources/namespaces/subresources/scripts/methods/update/)
  * Workers (and WFP) Secrets API

Apr 10, 2025
1. ### [D1 Read Replication Public Beta](https://edgetunnel-b2h.pages.dev/changelog/post/2025-04-10-d1-read-replication-beta/)  
[ D1 ](https://edgetunnel-b2h.pages.dev/d1/)[ Workers ](https://edgetunnel-b2h.pages.dev/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](https://edgetunnel-b2h.pages.dev/d1/best-practices/read-replication). 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](https://edgetunnel-b2h.pages.dev/d1/best-practices/read-replication/#replica-lag-and-consistency-model) to avoid data consistency pitfalls. D1 [bookmarks](https://edgetunnel-b2h.pages.dev/d1/reference/time-travel/#bookmarks) can be used from a previous session to ensure logical consistency between sessions.

**TypeScript**  
```ts  
// 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](https://edgetunnel-b2h.pages.dev/d1/best-practices/read-replication/#read-replica-locations)), 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.  
[![Deploy to Cloudflare](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/templates/tree/main/d1-starter-sessions-api)  
To learn more about how read replication was implemented, go to our [blog post ↗](https://blog.cloudflare.com/d1-read-replication-beta).

Apr 10, 2025
1. ### [Cloudflare Pipelines now available in beta](https://edgetunnel-b2h.pages.dev/changelog/post/2025-04-10-launching-pipelines/)  
[ Pipelines ](https://edgetunnel-b2h.pages.dev/pipelines/)[ R2 ](https://edgetunnel-b2h.pages.dev/r2/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
[Cloudflare Pipelines](https://edgetunnel-b2h.pages.dev/pipelines) is now available in beta, to all users with a [Workers Paid](https://edgetunnel-b2h.pages.dev/workers/platform/pricing) 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](https://edgetunnel-b2h.pages.dev/workers). Ingested data is automatically batched, written to output files, and delivered to an [R2 bucket](https://edgetunnel-b2h.pages.dev/r2) 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:

**Create a pipeline**  
```bash  
$ 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](https://edgetunnel-b2h.pages.dev/pipelines/getting-started) for an in-depth tutorial to building with Pipelines.

Apr 09, 2025
1. ### [Investigate your Workers with the Query Builder in the new Observability dashboard](https://edgetunnel-b2h.pages.dev/changelog/post/2025-04-09-qb-workers-logs-ga/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The [Workers Observability dashboard ↗](https://dash.cloudflare.com/?to=/:account/workers-and-pages/observability/) offers a single place to investigate and explore your [Workers Logs](https://edgetunnel-b2h.pages.dev/workers/observability/logs/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.  
![Workers Observability Overview Tab](https://edgetunnel-b2h.pages.dev/_astro/2025-04-09-workers-observability-overview.BKVvdscp_Z2bR5zE.webp)  
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?  
![Workers Observability Overview Tab](https://edgetunnel-b2h.pages.dev/_astro/2025-04-09-query-builder.CaW9IZza_ZBBKf9.webp)  
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](https://edgetunnel-b2h.pages.dev/workers/observability/logs/workers-logs) is now Generally Available. With a [small change](https://edgetunnel-b2h.pages.dev/workers/observability/logs/workers-logs/#enable-workers-logs) 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 ↗](https://edgetunnel-b2h.pages.dev/api/resources/workers/subresources/observability/) 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 ↗](https://edgetunnel-b2h.pages.dev/api/resources/workers/subresources/observability/).  
Visit the [docs](https://edgetunnel-b2h.pages.dev/workers/observability/query-builder) 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 ](#tab-panel-3105)
  * [  wrangler.toml ](#tab-panel-3106)

**JSONC**  
```jsonc  
{  
  "observability": {  
    "enabled": true,  
    "logs": {  
      "invocation_logs": true,  
      "head_sampling_rate": 1 // optional. default = 1.  
    }  
  }  
}  
```

**TOML**  
```toml  
[observability]  
enabled = true  
  [observability.logs]  
  invocation_logs = true  
  head_sampling_rate = 1  
```

Apr 09, 2025
1. ### [CPU time and Wall time now published for Workers Invocations](https://edgetunnel-b2h.pages.dev/changelog/post/2025-04-09-workers-timing/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now observe and investigate the CPU time and Wall time for every Workers Invocations.

  * For [Workers Logs](https://edgetunnel-b2h.pages.dev/workers/observability/logs/workers-logs), CPU time and Wall time are surfaced in the [Invocation Log](https://edgetunnel-b2h.pages.dev/workers/observability/logs/workers-logs/#invocation-logs)..
  * For [Tail Workers](https://edgetunnel-b2h.pages.dev/workers/observability/logs/tail-workers), CPU time and Wall time are surfaced at the top level of the [Workers Trace Events object](https://edgetunnel-b2h.pages.dev/logs/logpush/logpush-job/datasets/account/workers%5Ftrace%5Fevents).
  * For [Workers Logpush](https://edgetunnel-b2h.pages.dev/workers/observability/logs/logpush), CPU and Wall time are surfaced at the top level of the [Workers Trace Events object](https://edgetunnel-b2h.pages.dev/logs/logpush/logpush-job/datasets/account/workers%5Ftrace%5Fevents). 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.  
![Workers Logs Wall Time Filter](https://edgetunnel-b2h.pages.dev/_astro/2025-04-09-wall-time-filter.CT-VQyTS_Z97Aoe.webp)  
You can also use the Workers Observability [Query Builder ↗](https://dash.cloudflare.com/?to=/:account/workers-and-pages/observability/investigate) to find the median CPU time and median Wall time for all of your Workers.  
![Query Builder filter](https://edgetunnel-b2h.pages.dev/_astro/2025-04-09-query-builder.CaW9IZza_ZBBKf9.webp)

```json
{"@context":"https://schema.org","@type":"BlogPosting","@id":"https://edgetunnel-b2h.pages.dev/changelog/product/workers/7/#page","headline":"Workers Changelog | Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/changelog/product/workers/7/","inLanguage":"en","image":"https://edgetunnel-b2h.pages.dev/cf-twitter-card.png","publisher":{"@type":"Organization","name":"Cloudflare","url":"https://www.cloudflare.com/"},"isPartOf":{"@type":"WebSite","@id":"https://edgetunnel-b2h.pages.dev/#website","name":"Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/"}}
```