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

Nov 03, 2025
1. ### [Capture Wrangler command output in structured format](https://edgetunnel-b2h.pages.dev/changelog/post/2025-11-03-wrangler-output-file/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now capture Wrangler command output in a structured [ND-JSON ↗](https://github.com/ndjson/ndjson-spec) format by setting the [WRANGLER\_OUTPUT\_FILE\_PATH](https://edgetunnel-b2h.pages.dev/workers/wrangler/system-environment-variables/#supported-environment-variables) or [WRANGLER\_OUTPUT\_FILE\_DIRECTORY](https://edgetunnel-b2h.pages.dev/workers/wrangler/system-environment-variables/#supported-environment-variables) environment variables. This feature is particularly useful for CI/CD pipelines and automation tools that need programmatic access to deployment information such as worker names, version IDs, deployment URLs, and error details. Commands that support this feature include [wrangler deploy](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/#deploy), [wrangler versions upload](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/#versions), [wrangler versions deploy](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/#versions), and [wrangler pages deploy](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/#deploy-1).

Oct 31, 2025
1. ### [Workers WebSocket message size limit increased from 1 MiB to 32 MiB](https://edgetunnel-b2h.pages.dev/changelog/post/2025-10-31-increased-websocket-message-size-limit/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)[ Durable Objects ](https://edgetunnel-b2h.pages.dev/durable-objects/)[ Browser Run ](https://edgetunnel-b2h.pages.dev/browser-run/)  
Workers, including those using [Durable Objects](https://edgetunnel-b2h.pages.dev/durable-objects/) and [Browser Rendering](https://edgetunnel-b2h.pages.dev/browser-run/), may now process WebSocket messages up to 32 MiB in size. Previously, this limit was 1 MiB.  
This change allows Workers to handle use cases requiring large message sizes, such as processing Chrome Devtools Protocol messages.  
For more information, please see the [Durable Objects startup limits](https://edgetunnel-b2h.pages.dev/durable-objects/platform/limits/#sqlite-backed-durable-objects-general-limits).

Oct 31, 2025
1. ### [Increased Workflows instance and concurrency limits](https://edgetunnel-b2h.pages.dev/changelog/post/2025-10-28-raising-limits/)  
[ Workflows ](https://edgetunnel-b2h.pages.dev/workflows/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
We've raised the [Cloudflare Workflows](https://edgetunnel-b2h.pages.dev/workflows/) account-level limits for all accounts on the [Workers paid plan](https://edgetunnel-b2h.pages.dev/workers/platform/pricing/):

  * **Instance creation rate** increased from 100 workflow instances per 10 seconds to 100 instances per second
  * **Concurrency limit** increased from 4,500 to 10,000 workflow instances per account  
These increases mean you can create new instances up to 10x faster, and have more workflow instances concurrently executing. To learn more and get started with Workflows, refer to [the getting started guide](https://edgetunnel-b2h.pages.dev/workflows/get-started/guide/).  
If your application requires a higher limit, fill out the [Limit Increase Request Form](https://edgetunnel-b2h.pages.dev/workers/platform/limits/) or contact your account team. Please refer to [Workflows pricing](https://edgetunnel-b2h.pages.dev/workflows/reference/pricing/) for more information.

Oct 30, 2025
1. ### [Access Workers preview URLs from the Build details page](https://edgetunnel-b2h.pages.dev/changelog/post/2025-10-30-builds-preview/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now access [preview URLs](https://edgetunnel-b2h.pages.dev/workers/versions-and-deployments/preview-urls/) directly from the build details page, making it easier to test your changes when reviewing builds in the dashboard.  
![preview button](https://edgetunnel-b2h.pages.dev/_astro/builds-preview-button.CjGnhkt7_kOMMe.webp)  

**What's new**

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

Oct 24, 2025
1. ### [Automatic resource provisioning for KV, R2, and D1](https://edgetunnel-b2h.pages.dev/changelog/post/2025-10-24-automatic-resource-provisioning/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
Previously, if you wanted to develop or deploy a worker with attached resources, you'd have to first manually create the desired resources. Now, if your Wrangler configuration file includes a KV namespace, D1 database, or R2 bucket that does not yet exist on your account, you can develop locally and deploy your application seamlessly, without having to run additional commands.  
Automatic provisioning is launching as an open beta, and we'd love to hear your feedback to help us make improvements! It currently works for KV, R2, and D1 bindings. You can disable the feature using the `--no-x-provision` flag.  
To use this feature, update to wrangler@4.45.0 and add bindings to your config file _without_ resource IDs e.g.:

**JSONC**  
```jsonc  
{  
  "kv_namespaces": [{ "binding": "MY_KV" }],  
  "d1_databases": [{ "binding": "MY_DB" }],  
  "r2_buckets": [{ "binding": "MY_R2" }],  
}  
```  
`wrangler dev` will then automatically create these resources for you locally, and on your next run of `wrangler deploy`, Wrangler will call the Cloudflare API to create the requested resources and link them to your Worker.  
Though resource IDs will be automatically written back to your Wrangler config file after resource creation, resources will stay linked across future deploys even without adding the resource IDs to the config file. This is especially useful for shared templates, which now no longer need to include account-specific resource IDs when adding a binding.

Oct 24, 2025
1. ### [Build TanStack Start apps with the Cloudflare Vite plugin](https://edgetunnel-b2h.pages.dev/changelog/post/2025-10-24-tanstack-start/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The [Cloudflare Vite plugin](https://edgetunnel-b2h.pages.dev/workers/vite-plugin/) now supports [TanStack Start ↗](https://tanstack.com/start/) apps. Get started with new or existing projects.  
#### New projects  
Create a new TanStack Start project that uses the Cloudflare Vite plugin via the `create-cloudflare` CLI:  
 npm  yarn  pnpm  
```  
npm create cloudflare@latest -- my-tanstack-start-app --framework=tanstack-start  
```  
```  
yarn create cloudflare my-tanstack-start-app --framework=tanstack-start  
```  
```  
pnpm create cloudflare@latest my-tanstack-start-app --framework=tanstack-start  
```  
#### Existing projects  
Migrate an existing TanStack Start project to use the Cloudflare Vite plugin:

  1. Install `@cloudflare/vite-plugin` and `wrangler`  
 npm  yarn  pnpm  bun  
```  
npm i -D @cloudflare/vite-plugin wrangler  
```  
```  
yarn add -D @cloudflare/vite-plugin wrangler  
```  
```  
pnpm add -D @cloudflare/vite-plugin wrangler  
```  
```  
bun add -d @cloudflare/vite-plugin wrangler  
```

  1. Add the Cloudflare plugin to your Vite config

**vite.config.ts**  
```ts  
import { defineConfig } from "vite";  
import { tanstackStart } from "@tanstack/react-start/plugin/vite";  
import viteReact from "@vitejs/plugin-react";  
import { cloudflare } from "@cloudflare/vite-plugin";  
export default defineConfig({  
  plugins: [  
    cloudflare({ viteEnvironment: { name: "ssr" } }),  
    tanstackStart(),  
    viteReact(),  
  ],  
});  
```

  1. Add your Worker config file

  * [  wrangler.jsonc ](#tab-panel-3081)
  * [  wrangler.toml ](#tab-panel-3082)

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

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

  1. Modify the scripts in your `package.json`

**package.json**  
```json  
{  
  "scripts": {  
    "dev": "vite dev",  
    "build": "vite build && tsc --noEmit",  
    "start": "node .output/server/index.mjs",  
    "preview": "vite preview",  
    "deploy": "npm run build && wrangler deploy",  
    "cf-typegen": "wrangler types"  
  }  
}  
```  
See the [TanStack Start framework guide](https://edgetunnel-b2h.pages.dev/workers/framework-guides/web-apps/tanstack-start/) for more info.

Oct 23, 2025
1. ### [Workers Preview URL default behavior now matches your workers.dev setting](https://edgetunnel-b2h.pages.dev/changelog/post/2025-10-23-preview-url-default-behavior/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
We have updated the default behavior for Cloudflare Workers [Preview URLs](https://edgetunnel-b2h.pages.dev/workers/versions-and-deployments/preview-urls/). **Going forward, if a preview URL setting is not [explicitly configured](https://edgetunnel-b2h.pages.dev/workers/versions-and-deployments/preview-urls/#toggle-preview-urls-enable-or-disable) during deployment, its default behavior will automatically match the setting of your [workers.dev subdomain](https://edgetunnel-b2h.pages.dev/workers/configuration/routing/workers-dev/).**  
This change is intended to provide a more intuitive and secure experience by aligning your preview URL's default state with your `workers.dev` configuration to prevent cases where a preview URL might remain public even after you disabled your `workers.dev` route.

**What this means for you:**

  * **If neither setting is configured:** both the workers.dev route and the preview URL will default to enabled
  * **If your workers.dev route is enabled and you do not explicitly set Preview URLs to enabled or disabled:** Preview URLs will default to enabled
  * **If your workers.dev route is disabled and you do not explicitly set Preview URLs to enabled or disabled:** Preview URLs will default to disabled  
You can override the default setting by explicitly enabling or disabling the preview URL in your Worker's configuration through the [API](https://edgetunnel-b2h.pages.dev/api/resources/workers/subresources/scripts/subresources/subdomain/), [Dashboard](https://edgetunnel-b2h.pages.dev/workers/versions-and-deployments/preview-urls/#from-the-dashboard), or [Wrangler](https://edgetunnel-b2h.pages.dev/workers/versions-and-deployments/preview-urls/#from-the-wrangler-configuration-file).

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

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

**Why we’re making this change**  
In July, [we introduced preview URLs to Workers](https://edgetunnel-b2h.pages.dev/changelog/2025-07-23-workers-preview-urls/), which let you preview code changes before deploying to production. This made disabling your Worker’s workers.dev URL an ambiguous action — the preview URL, served as a subdomain of `workers.dev` (ex: `preview-id-worker-name.account-name.workers.dev`) would still be live even if you had disabled your Worker’s `workers.dev` route. If you misinterpreted what it meant to disable your `workers.dev` route, you might unintentionally leave preview URLs enabled when you didn’t mean to, and expose them to the public Internet.  
To address this, we made a [one-time update](https://edgetunnel-b2h.pages.dev/changelog/2025-09-17-update-preview-url-setting/) to disable preview URLs on existing Workers that had their workers.dev route disabled and changed the default behavior to be disabled for all new deployments where a preview URL setting was not explicitly configured.  
While this change helped secure many customers, it was disruptive for customers who keep their `workers.dev` route enabled and actively use the preview functionality, as it now required them to explicitly enable preview URLs on every redeployment.This new, more intuitive behavior ensures that your preview URL settings align with your `workers.dev` configuration by default, providing a more secure and predictable experience.

**Securing access to `workers.dev` and preview URL endpoints**  
To further secure your `workers.dev` subdomain and preview URL, you can [enable Cloudflare Access with a single click](https://edgetunnel-b2h.pages.dev/changelog/2025-10-03-one-click-access-for-workers/) in your Worker's settings to limit access to specific users or groups.

Oct 16, 2025
1. ### [View and edit Durable Object data in UI with Data Studio (Beta)](https://edgetunnel-b2h.pages.dev/changelog/post/2025-10-16-durable-objects-data-studio/)  
[ Durable Objects ](https://edgetunnel-b2h.pages.dev/durable-objects/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
![Screenshot of Durable Objects Data Studio](https://edgetunnel-b2h.pages.dev/_astro/do-data-studio.BfCcgtkq_Z4LLzm.webp)  
You can now view and write to each Durable Object's storage using a UI editor on the Cloudflare dashboard. Only Durable Objects using [SQLite storage](https://edgetunnel-b2h.pages.dev/durable-objects/best-practices/access-durable-objects-storage/#create-sqlite-backed-durable-object-class) can use Data Studio.  
[ Go to **Durable Objects** ](https://dash.cloudflare.com/?to=/:account/workers/durable-objects)  
Data Studio unlocks easier data access with Durable Objects for prototyping application data models to debugging production storage usage. Before, querying your Durable Objects data required deploying a Worker.  
To access a Durable Object, you can provide an object's unique name or ID generated by Cloudflare. Data Studio requires you to have at least the `Workers Platform Admin` role, and all queries are captured with audit logging for your security and compliance needs. Queries executed by Data Studio send requests to your remote, deployed objects and incur normal usage billing.  
To learn more, visit the Data Studio [documentation](https://edgetunnel-b2h.pages.dev/durable-objects/observability/data-studio/). If you have feedback or suggestions for the new Data Studio, please share your experience on [Discord ↗](https://discord.com/channels/595317990191398933/773219443911819284)

Oct 10, 2025
1. ### [Worker startup time limit increased to 1 second](https://edgetunnel-b2h.pages.dev/changelog/post/2025-10-10-increased-startup-time/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now upload a Worker that takes up 1 second to parse and execute its global scope. Previously, startup time was limited to 400 ms.  
This allows you to run Workers that import more complex packages and execute more code prior to requests being handled.  
For more information, see the documentation on [Workers startup limits](https://edgetunnel-b2h.pages.dev/workers/platform/limits/#worker-startup-time).

Oct 09, 2025
1. ### [You can now deploy full-stack apps on Workers using Terraform](https://edgetunnel-b2h.pages.dev/changelog/post/2025-10-09-assets-terraform/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now upload Workers with [static assets](https://edgetunnel-b2h.pages.dev/workers/static-assets/) (like HTML, CSS, JavaScript, images) with the [Cloudflare Terraform provider v5.11.0 ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/5.11.0/docs), making it even easier to deploy and manage full-stack apps with IaC.

**Previously**, you couldn't use Terraform to upload static assets without writing custom scripts to handle generating an [asset manifest](https://edgetunnel-b2h.pages.dev/workers/static-assets/direct-upload/#upload-manifest), calling the [Cloudflare API to upload assets in chunks](https://edgetunnel-b2h.pages.dev/workers/static-assets/direct-upload/#upload-static-assets), and handling change detection.

**Now**, you simply define the directory where your assets are built, and we handle the rest. Check out the [examples](https://edgetunnel-b2h.pages.dev/changelog/#examples) for what this looks like in Terraform configuration.  
You can get started today with [the Cloudflare Terraform provider (v5.11.0) ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/5.11.0/docs), using either the existing [cloudflare\_workers\_script resource ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/workers%5Fscript), or the beta [cloudflare\_worker\_version resource ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/worker%5Fversion).  
#### Examples  
#### With `cloudflare_workers_script`  
Here's how you can use the existing [cloudflare\_workers\_script ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/5.11.0/docs/resources/workers%5Fscript) resource to upload your Worker code and assets in one shot.  
```hcl  
resource "cloudflare_workers_script" "my_app" {  
  account_id  = var.account_id  
  script_name = "my-app"  
  content_file   = "./dist/worker/index.js"  
  content_sha256 = filesha256("./dist/worker/index.js")  
  main_module    = "index.js"  
  # Just point to your assets directory - that's it!  
  assets = {  
    directory = "./dist/static"  
  }  
}  
```  
#### With `cloudflare_worker`, `cloudflare_worker_version`, and `cloudflare_workers_deployment`  
And here's an example using the beta [cloudflare\_worker\_version ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/5.11.0/docs/resources/worker%5Fversion) resource, alongside the [cloudflare\_worker ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/worker) and [cloudflare\_workers\_deployment ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/5.11.0/docs/resources/workers%5Fdeployment) resources:  
```hcl  
# This tracks the existence of your Worker, so that you  
# can upload code and assets separately from tracking Worker state.  
resource "cloudflare_worker" "my_app" {  
  account_id = var.account_id  
  name       = "my-app"  
}  
resource "cloudflare_worker_version" "my_app_version" {  
  account_id = var.account_id  
  worker_id  = cloudflare_worker.my_app.id  
  # Just point to your assets directory - that's it!  
  assets = {  
    directory = "./dist/static"  
  }  
  modules = [{  
    name         = "index.js"  
    content_file = "./dist/worker/index.js"  
    content_type = "application/javascript+module"  
  }]  
}  
resource "cloudflare_workers_deployment" "my_app_deployment" {  
  account_id  = var.account_id  
  script_name = cloudflare_worker.my_app.name  
  strategy = "percentage"  
  versions = [{  
    version_id = cloudflare_worker_version.my_app_version.id  
    percentage = 100  
  }]  
}  
```  
#### What's changed  
Under the hood, the Cloudflare Terraform provider now handles the same logic that Wrangler uses for static asset uploads. This includes scanning your assets directory, computing hashes for each file, generating a manifest with file metadata, and calling the Cloudflare API to upload any missing files in chunks. We support large directories with parallel uploads and chunking, and when the asset manifest hash changes, we detect what's changed and trigger an upload for _only_ those changed files.  
#### Try it out

  * Get started with [the Cloudflare Terraform provider (v5.11.0) ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/5.11.0/docs)
  * You can use either the existing [cloudflare\_workers\_script resource ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/workers%5Fscript) to upload your Worker code and assets in one resource.
  * Or you can use the new beta [cloudflare\_worker\_version resource ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/worker%5Fversion) (along with the [cloudflare\_worker ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/worker) and [cloudflare\_workers\_deployment ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/5.11.0/docs/resources/workers%5Fdeployment)) resources to more granularly control the lifecycle of each Worker resource.

Oct 09, 2025
1. ### [You can now deploy and manage Workflows in Terraform](https://edgetunnel-b2h.pages.dev/changelog/post/2025-10-09-workflows-terraform/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now create and manage [Workflows](https://edgetunnel-b2h.pages.dev/workflows/) using Terraform, now supported in the [Cloudflare Terraform provider v5.11.0 ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/workflow). Workflows allow you to build durable, multi-step applications -- without needing to worry about retrying failed tasks or managing infrastructure.  
Now, you can deploy and manage Workflows through Terraform using the new [cloudflare\_workflow resource ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/workflow):  
```hcl  
resource "cloudflare_workflow" "my_workflow" {  
  account_id    = var.account_id  
  workflow_name = "my-workflow"  
  class_name    = "MyWorkflow"  
  script_name   = "my-worker"  
}  
```  
#### Examples  
Here are full examples of how to configure `cloudflare_workflow` in Terraform, using the existing [cloudflare\_workers\_script resource ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/workers%5Fscript), and the beta [cloudflare\_worker\_version resource ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/worker%5Fversion).  
#### With `cloudflare_workflow` and `cloudflare_workers_script`  
```hcl  
resource "cloudflare_workers_script" "workflow_worker" {  
  account_id  = var.cloudflare_account_id  
  script_name = "my-workflow-worker"  
  content_file   = "${path.module}/../dist/worker/index.js"  
  content_sha256 = filesha256("${path.module}/../dist/worker/index.js")  
  main_module    = "index.js"  
}  
resource "cloudflare_workflow" "workflow" {  
  account_id    = var.cloudflare_account_id  
  workflow_name = "my-workflow"  
  class_name    = "MyWorkflow"  
  script_name   = cloudflare_workers_script.workflow_worker.script_name  
}  
```  
#### With `cloudflare_workflow`, and the new beta resources  
You can more granularly control the lifecycle of each Worker resource using the beta [cloudflare\_worker\_version ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/5.11.0/docs/resources/worker%5Fversion) resource, alongside the [cloudflare\_worker ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/worker) and [cloudflare\_workers\_deployment ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/5.11.0/docs/resources/workers%5Fdeployment) resources.  
```hcl  
resource "cloudflare_worker" "workflow_worker" {  
  account_id = var.cloudflare_account_id  
  name       = "my-workflow-worker"  
}  
resource "cloudflare_worker_version" "workflow_worker_version" {  
  account_id = var.cloudflare_account_id  
  worker_id  = cloudflare_worker.workflow_worker.id  
  main_module         = "index.js"  
  modules = [{  
    name         = "index.js"  
    content_file = "${path.module}/../dist/worker/index.js"  
    content_type = "application/javascript+module"  
  }]  
}  
resource "cloudflare_workers_deployment" "workflow_deployment" {  
  account_id  = var.cloudflare_account_id  
  script_name = cloudflare_worker.workflow_worker.name  
  strategy = "percentage"  
  versions = [{  
    version_id = cloudflare_worker_version.workflow_worker_version.id  
    percentage = 100  
  }]  
}  
resource "cloudflare_workflow" "my_workflow" {  
  account_id    = var.cloudflare_account_id  
  workflow_name = "my-workflow"  
  class_name    = "MyWorkflow"  
  script_name   = cloudflare_worker.workflow_worker.name  
}  
```  
#### Try it out

  * Get started with [the Cloudflare Terraform provider (v5.11.0) ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/5.11.0/docs) and the new [cloudflare\_workflow resource ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/workflow).

Oct 07, 2025
1. ### [New Overview Page for Cloudflare Workers](https://edgetunnel-b2h.pages.dev/changelog/post/2025-10-06-new-worker-overview-page/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
![Screenshot of the Workers overview page in the Cloudflare dashboard](https://edgetunnel-b2h.pages.dev/_astro/workers-overview.BM_exs4R_IaSn9.webp)  
Each of your Workers now has a new overview page in the Cloudflare dashboard.  
The goal is to make it easier to understand your Worker without digging through multiple tabs. Think of it as a new home base, a place to get a high-level overview on what's going on.  
It's the first place you land when you open a Worker in the dashboard, and it gives you an immediate view of what’s going on. You can see requests, errors, and CPU time at a glance. You can view and add bindings, and see recent versions of your app, including who published them.  
Navigation is also simpler, with visually distinct tabs at the top of the page. At the bottom right you'll find guided steps for what to do next that are based on the state of your Worker, such as adding a [binding](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/bindings/) or connecting a custom domain.  
We plan to add more here over time. Better insights, more controls, and ways to manage your Worker from one page.  
If you have feedback or suggestions for the new Overview page or your Cloudflare Workers experience in general, we'd love to hear from you. Join the Cloudflare developer community on [Discord ↗](https://discord.com/channels/595317990191398933/1064502845061210152).

Oct 03, 2025
1. ### [One-click Cloudflare Access for Workers](https://edgetunnel-b2h.pages.dev/changelog/post/2025-10-03-one-click-access-for-workers/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now enable [Cloudflare Access](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) for your [workers.dev](https://edgetunnel-b2h.pages.dev/workers/configuration/routing/workers-dev/) and [Preview URLs](https://edgetunnel-b2h.pages.dev/workers/versions-and-deployments/preview-urls/) in a single click.  
![Screenshot of the Enable/Disable Cloudflare Access button on the workers.dev route settings page](https://edgetunnel-b2h.pages.dev/_astro/workers-access.DGGYThLx_1YsjKO.webp)  
Access allows you to limit access to your Workers to specific users or groups. You can limit access to yourself, your teammates, your organization, or anyone else you specify in your [Access policy](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/).  
To enable Cloudflare Access:

  1. In the Cloudflare dashboard, go to the **Workers & Pages** page.  
  [ Go to **Workers & Pages** ](https://dash.cloudflare.com/?to=/:account/workers-and-pages)
  2. In **Overview**, select your Worker.
  3. Go to **Settings** \> **Domains & Routes**.
  4. For `workers.dev` or Preview URLs, click **Enable Cloudflare Access**.
  5. Optionally, to configure the Access application, click **Manage Cloudflare Access**. There, you can change the email addresses you want to authorize. View [Access policies](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/#selectors) to learn about configuring alternate rules.  
To fully secure your application, it is important that you validate the JWT that Cloudflare Access adds to the `Cf-Access-Jwt-Assertion` header on the incoming request.  
The following code will validate the JWT using the [jose NPM package ↗](https://www.npmjs.com/package/jose):

**JavaScript**  
```javascript  
import { jwtVerify, createRemoteJWKSet } from "jose";  
export default {  
  async fetch(request, env, ctx) {  
    // Verify the POLICY_AUD environment variable is set  
    if (!env.POLICY_AUD) {  
      return new Response("Missing required audience", {  
        status: 403,  
        headers: { "Content-Type": "text/plain" },  
      });  
    }  
    // Get the JWT from the request headers  
    const token = request.headers.get("cf-access-jwt-assertion");  
    // Check if token exists  
    if (!token) {  
      return new Response("Missing required CF Access JWT", {  
        status: 403,  
        headers: { "Content-Type": "text/plain" },  
      });  
    }  
    try {  
      // Create JWKS from your team domain  
      const JWKS = createRemoteJWKSet(  
        new URL(`${env.TEAM_DOMAIN}/cdn-cgi/access/certs`),  
      );  
      // Verify the JWT  
      const { payload } = await jwtVerify(token, JWKS, {  
        issuer: env.TEAM_DOMAIN,  
        audience: env.POLICY_AUD,  
      });  
      // Token is valid, proceed with your application logic  
      return new Response(`Hello ${payload.email || "authenticated user"}!`, {  
        headers: { "Content-Type": "text/plain" },  
      });  
    } catch (error) {  
      // Token verification failed  
      return new Response(`Invalid token: ${error.message}`, {  
        status: 403,  
        headers: { "Content-Type": "text/plain" },  
      });  
    }  
  },  
};  
```  
#### Required environment variables  
Add these [environment variables](https://edgetunnel-b2h.pages.dev/workers/configuration/environment-variables/) to your Worker:

  * `POLICY_AUD`: Your application's AUD tag
  * `TEAM_DOMAIN`: `https://<your-team-name>.cloudflareaccess.com`  
Both of these appear in the modal that appears when you enable Cloudflare Access.  
You can set these variables by adding them to your Worker's [Wrangler configuration file](https://edgetunnel-b2h.pages.dev/workers/wrangler/configuration/), or via the Cloudflare dashboard under **Workers & Pages** \> **your-worker** \> **Settings** \> **Environment Variables**.

Oct 02, 2025
1. ### [Workers Analytics Engine adds supports for new SQL functions](https://edgetunnel-b2h.pages.dev/changelog/post/2025-09-26-analytics-engine-sql-enhancements/)  
[ Workers Analytics Engine ](https://edgetunnel-b2h.pages.dev/analytics/analytics-engine/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now perform more powerful queries directly in [Workers Analytics Engine ↗](https://edgetunnel-b2h.pages.dev/analytics/analytics-engine/) with a major expansion of our SQL function library.  
Workers Analytics Engine allows you to ingest and store high-cardinality data at scale (such as custom analytics) and query your data through a simple SQL API.  
Today, we've expanded Workers Analytics Engine's SQL capabilities with several new functions:  
[**New aggregate functions:** ↗](https://edgetunnel-b2h.pages.dev/analytics/analytics-engine/sql-reference/aggregate-functions/)

  * `argMin()` \- Returns the value associated with the minimum in a group
  * `argMax()` \- Returns the value associated with the maximum in a group
  * `topK()` \- Returns an array of the most frequent values in a group
  * `topKWeighted()` \- Returns an array of the most frequent values in a group using weights
  * `first_value()` \- Returns the first value in an ordered set of values within a partition
  * `last_value()` \- Returns the last value in an ordered set of values within a partition  
[**New bit functions:** ↗](https://edgetunnel-b2h.pages.dev/analytics/analytics-engine/sql-reference/bit-functions/)

  * `bitAnd()` \- Returns the bitwise AND of two expressions
  * `bitCount()` \- Returns the number of bits set to one in the binary representation of a number
  * `bitHammingDistance()` \- Returns the number of bits that differ between two numbers
  * `bitNot()` \- Returns a number with all bits flipped
  * `bitOr()` \- Returns the inclusive bitwise OR of two expressions
  * `bitRotateLeft()` \- Rotates all bits in a number left by specified positions
  * `bitRotateRight()` \- Rotates all bits in a number right by specified positions
  * `bitShiftLeft()` \- Shifts all bits in a number left by specified positions
  * `bitShiftRight()` \- Shifts all bits in a number right by specified positions
  * `bitTest()` \- Returns the value of a specific bit in a number
  * `bitXor()` \- Returns the bitwise exclusive-or of two expressions  
[**New mathematical functions:** ↗](https://edgetunnel-b2h.pages.dev/analytics/analytics-engine/sql-reference/mathematical-functions/)

  * `abs()` \- Returns the absolute value of a number
  * `log()` \- Computes the natural logarithm of a number
  * `round()` \- Rounds a number to a specified number of decimal places
  * `ceil()` \- Rounds a number up to the nearest integer
  * `floor()` \- Rounds a number down to the nearest integer
  * `pow()` \- Returns a number raised to the power of another number  
[**New string functions:** ↗](https://edgetunnel-b2h.pages.dev/analytics/analytics-engine/sql-reference/string-functions/)

  * `lowerUTF8()` \- Converts a string to lowercase using UTF-8 encoding
  * `upperUTF8()` \- Converts a string to uppercase using UTF-8 encoding  
[**New encoding functions:** ↗](https://edgetunnel-b2h.pages.dev/analytics/analytics-engine/sql-reference/encoding-functions/)

  * `hex()` \- Converts a number to its hexadecimal representation
  * `bin()` \- Converts a string to its binary representation  
[**New type conversion functions:** ↗](https://edgetunnel-b2h.pages.dev/analytics/analytics-engine/sql-reference/type-conversion-functions/)

  * `toUInt8()` \- Converts any numeric expression, or expression resulting in a string representation of a decimal, into an unsigned 8 bit integer  
#### Ready to get started?  
Whether you're building usage-based billing systems, customer analytics dashboards, or other custom analytics, these functions let you get the most out of your data. [Get started ](https://edgetunnel-b2h.pages.dev/analytics/analytics-engine/get-started/) with Workers Analytics Engine and explore all available functions in our [SQL reference documentation](https://edgetunnel-b2h.pages.dev/analytics/analytics-engine/sql-reference/).

Sep 26, 2025
1. ### [Automatic loopback bindings via ctx.exports](https://edgetunnel-b2h.pages.dev/changelog/post/2025-09-26-ctx-exports/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The [ctx.exports API](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/context/#exports) contains automatically-configured bindings corresponding to your Worker's top-level exports. For each top-level export extending `WorkerEntrypoint`, `ctx.exports` will contain a [Service Binding](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/bindings/service-bindings) by the same name, and for each export extending `DurableObject` (and for which storage has been configured via a [migration](https://edgetunnel-b2h.pages.dev/durable-objects/reference/durable-objects-migrations/)), `ctx.exports` will contain a [Durable Object namespace binding](https://edgetunnel-b2h.pages.dev/durable-objects/api/namespace/). This means you no longer have to configure these bindings explicitly in `wrangler.jsonc`/`wrangler.toml`.  
Example:

**JavaScript**  
```js  
import { WorkerEntrypoint } from "cloudflare:workers";  
export class Greeter extends WorkerEntrypoint {  
  greet(name) {  
    return `Hello, ${name}!`;  
  }  
}  
export default {  
  async fetch(request, env, ctx) {  
    let greeting = await ctx.exports.Greeter.greet("World")  
    return new Response(greeting);  
  }  
}  
```  
At present, you must use [the enable\_ctx\_exports compatibility flag](https://edgetunnel-b2h.pages.dev/workers/configuration/compatibility-flags#enable-ctxexports) to enable this API, though it will be on by default in the future.  
[See the API reference for more information.](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/context/#exports)

Sep 23, 2025
1. ### [Improved support for running multiple Workers with \`wrangler dev\`](https://edgetunnel-b2h.pages.dev/changelog/post/2025-09-23-wrangler-dev-multi-config-cross-command-support/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can run multiple Workers in a single dev command by passing multiple config files to `wrangler dev`:  
```sh  
wrangler dev --config ./web/wrangler.jsonc --config ./api/wrangler.jsonc  
```  
Previously, if you ran the command above and then also ran wrangler dev for a different Worker, the Workers running in separate wrangler dev sessions could not communicate with each other. This prevented you from being able to use [Service Bindings ↗](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/bindings/service-bindings/) and [Tail Workers ↗](https://edgetunnel-b2h.pages.dev/workers/observability/logs/tail-workers/) in local development, when running separate wrangler dev sessions.  
Now, the following works as expected:  
```sh  
# Terminal 1: Run your application that includes both Web and API workers  
wrangler dev --config ./web/wrangler.jsonc --config ./api/wrangler.jsonc  
# Terminal 2: Run your auth worker separately  
wrangler dev --config ./auth/wrangler.jsonc  
```  
These Workers can now communicate with each other across separate dev commands, regardless of your development setup.

**./api/src/index.ts**  
```js  
export default {  
  async fetch(request, env) {  
    // This service binding call now works across dev commands  
    const authorized = await env.AUTH.isAuthorized(request);  
    if (!authorized) {  
      return new Response("Unauthorized", { status: 401 });  
    }  
    return new Response("Hello from API Worker!", { status: 200 });  
  },  
};  
```  
Check out the [Developing with multiple Workers](https://edgetunnel-b2h.pages.dev/workers/local-development/multi-workers) guide to learn more about the different approaches and when to use each one.

Sep 19, 2025
1. ### [Rate Limiting in Workers is now GA](https://edgetunnel-b2h.pages.dev/changelog/post/2025-09-19-ratelimit-workers-ga/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
[Rate Limiting within Cloudflare Workers](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/bindings/rate-limit/) is now Generally Available (GA).  
The `ratelimit` binding is now stable and recommended for all production workloads. Existing deployments using the unsafe binding will continue to function to allow for a smooth transition.  
For more details, refer to [Workers Rate Limiting](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/bindings/rate-limit/) documentation.

Sep 19, 2025
1. ### [Panic Recovery for Rust Workers](https://edgetunnel-b2h.pages.dev/changelog/post/2025-09-19-workers-rs-panic-recovery/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
In [workers-rs ↗](https://github.com/cloudflare/workers-rs), Rust panics were previously non-recoverable. A panic would put the Worker into an invalid state, and further function calls could result in memory overflows or exceptions.  
Now, when a panic occurs, in-flight requests will throw 500 errors, but the Worker will automatically and instantly recover for future requests.  
This ensures more reliable deployments. Automatic panic recovery is enabled for all new workers-rs deployments as of version 0.6.5, with no configuration required.  
#### Fixing Rust Panics with Wasm Bindgen  
Rust Workers are built with Wasm Bindgen, which treats panics as non-recoverable. After a panic, the entire Wasm application is considered to be in an invalid state.  
We now attach a default panic handler in Rust:  
```rust  
std::panic::set_hook(Box::new(move |panic_info| {  
  hook_impl(panic_info);  
}));  
```  
Which is registered by default in the JS initialization:

**JavaScript**  
```js  
import { setPanicHook } from "./index.js";  
setPanicHook(function (err) {  
  console.error("Panic handler!", err);  
});  
```  
When a panic occurs, we reset the Wasm state to revert the Wasm application to how it was when the application started.  
#### Resetting VM State in Wasm Bindgen  
We worked upstream on the Wasm Bindgen project to implement a new [\--experimental-reset-state-function compilation option ↗](https://github.com/wasm-bindgen/wasm-bindgen/pull/4644) which outputs a new `__wbg_reset_state` function.  
This function clears all internal state related to the Wasm VM, and updates all function bindings in place to reference the new WebAssembly instance.  
One other necessary change here was associating Wasm-created JS objects with an instance identity. If a JS object created by an earlier instance is then passed into a new instance later on, a new "stale object" error is specially thrown when using this feature.  
#### Layered Solution  
Building on this new Wasm Bindgen feature, layered with our new default panic handler, we also added a proxy wrapper to ensure all top-level exported class instantiations (such as for Rust Durable Objects) are tracked and fully reinitialized when resetting the Wasm instance. This was necessary because the workerd runtime will instantiate exported classes, which would then be associated with the Wasm instance.  
This approach now provides full panic recovery for Rust Workers on subsequent requests.  
Of course, we never want panics, but when they do happen they are isolated and can be investigated further from the error logs - avoiding broader service disruption.  
#### WebAssembly Exception Handling  
In the future, full support for recoverable panics could be implemented without needing reinitialization at all, utilizing the [WebAssembly Exception Handling ↗](https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md)proposal, part of the newly announced [WebAssembly 3.0 ↗](https://webassembly.org/news/2025-09-17-wasm-3.0/) specification. This would allow unwinding panics as normal JS errors, and concurrent requests would no longer fail.

**We're making significant improvements to the reliability of [Rust Workers ↗](https://github.com/cloudflare/workers-rs). Join us in `#rust-on-workers` on the [Cloudflare Developers Discord ↗](https://discord.gg/cloudflaredev) to stay updated.**

Sep 18, 2025
1. ### [Increased vCPU for Workers Builds on paid plans](https://edgetunnel-b2h.pages.dev/changelog/post/2025-09-07-builds-increased-cpu-paid/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
We recently [increased the available disk space](https://edgetunnel-b2h.pages.dev/changelog/2025-08-04-builds-increased-disk-size/) from 8 GB to 20 GB for **all** plans. Building on that improvement, we’re now doubling the CPU power available for paid plans — from 2 vCPU to **4 vCPU**.  
These changes continue our focus on making [Workers Builds](https://edgetunnel-b2h.pages.dev/workers/ci-cd/builds/) faster and more reliable.

| Metric | Free Plan | Paid Plans |
| ------ | --------- | ---------- |
| CPU    | 2 vCPU    | **4 vCPU** |  
#### Performance Improvements

  * **Fast build times**: Even single-threaded workloads benefit from having more vCPUs
  * **2x faster multi-threaded builds**: Tools like [esbuild ↗](https://esbuild.github.io/) and [webpack ↗](https://webpack.js.org/) can now utilize additional cores, delivering near-linear performance scaling  
All other [build limits](https://edgetunnel-b2h.pages.dev/workers/ci-cd/builds/limits-and-pricing/) — including memory, build minutes, and timeout remain unchanged.

Sep 17, 2025
1. ### [Preview URLs now default to opt-in](https://edgetunnel-b2h.pages.dev/changelog/post/2025-09-17-update-preview-url-setting/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
To prevent the accidental exposure of applications, we've updated how [Worker preview URLs](https://edgetunnel-b2h.pages.dev/workers/versions-and-deployments/preview-urls/) (`<PREVIEW>-<WORKER_NAME>.<SUBDOMAIN>.workers.dev`) are handled. We made this change to ensure preview URLs are only active when intentionally configured, improving the default security posture of your Workers.  
#### One-Time Update for Workers with workers.dev Disabled  
We performed a one-time update to disable preview URLs for existing Workers where the [workers.dev subdomain](https://edgetunnel-b2h.pages.dev/workers/configuration/routing/workers-dev/) was also disabled.  
Because preview URLs were historically enabled by default, users who had intentionally disabled their workers.dev route may not have realized their Worker was still accessible at a separate preview URL. This update was performed to ensure that using a preview URL is always an intentional, opt-in choice.  
If your Worker was affected, its preview URL (`<PREVIEW>-<WORKER_NAME>.<SUBDOMAIN>.workers.dev`) will now direct to an informational page explaining this change.

**How to Re-enable Your Preview URL**  
If your preview URL was disabled, you can re-enable it [via the Cloudflare dashboard](https://edgetunnel-b2h.pages.dev/workers/versions-and-deployments/preview-urls/#toggle-preview-urls-enable-or-disable) by navigating to your Worker's Settings page and toggling on the Preview URL.  
Alternatively, you can use Wrangler by adding the `preview_urls = true` setting to your Wrangler file and redeploying the Worker.

  * [  wrangler.jsonc ](#tab-panel-3079)
  * [  wrangler.toml ](#tab-panel-3080)

**JSONC**  
```jsonc  
{  
  "preview_urls": true  
}  
```

**TOML**  
```toml  
preview_urls = true  
```

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

Sep 16, 2025
1. ### [Remote bindings GA - Connect to remote resources (D1, KV, R2, etc.) during local development](https://edgetunnel-b2h.pages.dev/changelog/post/2025-09-16-remote-bindings-ga/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
Three months ago [we announced the public beta](https://edgetunnel-b2h.pages.dev/changelog/2025-06-18-remote-bindings-beta/) of [remote bindings](https://edgetunnel-b2h.pages.dev/workers/local-development/#remote-bindings) for local development. Now, we're excited to say that it's available for everyone in Wrangler, Vite, and Vitest without using an experimental flag!  
With remote bindings, you can now connect to deployed resources like [R2 buckets](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 bindings, add `"remote" : true` to each binding that you want to rely on a remote resource running on Cloudflare:

  * [  wrangler.jsonc ](#tab-panel-3083)
  * [  wrangler.toml ](#tab-panel-3084)

**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",  
      "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"  
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](https://edgetunnel-b2h.pages.dev/workers/local-development/#remote-bindings) for local development today with:**

  * [Wrangler v4.37.0](https://edgetunnel-b2h.pages.dev/workers/wrangler/)
  * The [Cloudflare Vite Plugin](https://edgetunnel-b2h.pages.dev/workers/vite-plugin/)
  * The [Cloudflare Vitest Plugin](https://edgetunnel-b2h.pages.dev/workers/testing/vitest-integration/)

Sep 11, 2025
1. ### [D1 automatically retries read-only queries](https://edgetunnel-b2h.pages.dev/changelog/post/2025-09-11-d1-automatic-read-retries/)  
[ D1 ](https://edgetunnel-b2h.pages.dev/d1/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
D1 now detects read-only queries and automatically attempts up to two retries to execute those queries in the event of failures with retryable errors. You can access the number of execution attempts in the returned [response metadata](https://edgetunnel-b2h.pages.dev/d1/worker-api/return-object/#d1result) property `total_attempts`.  
At the moment, only read-only queries are retried, that is, queries containing only the following SQLite keywords: `SELECT`, `EXPLAIN`, `WITH`. Queries containing any [SQLite keyword ↗](https://sqlite.org/lang%5Fkeywords.html) that leads to database writes are not retried.  
The retry success ratio among read-only retryable errors varies from 5% all the way up to 95%, depending on the underlying error and its duration (like network errors or other internal errors).  
The retry success ratio among all retryable errors is lower, indicating that there are write-queries that could be retried. Therefore, we recommend D1 users to continue applying [retries in their own code](https://edgetunnel-b2h.pages.dev/d1/best-practices/retry-queries/) for queries that are not read-only but are idempotent according to the business logic of the application.  
![D1 automatically query retries success ratio](https://edgetunnel-b2h.pages.dev/_astro/d1-auto-retry-success-ratio.yPw8B0tB_1c6euA.webp)  
D1 ensures that any retry attempt does not cause database writes, making the automatic retries safe from side-effects, even if a query causing changes slips through the read-only detection. D1 achieves this by checking for modifications after every query execution, and if any write occurred due to a retry attempt, the query is rolled back.  
The read-only query detection heuristics are simple for now, and there is room for improvement to capture more cases of queries that can be retried, so this is just the beginning.

Sep 11, 2025
1. ### [Worker version rollback limit increased from 10 to 100](https://edgetunnel-b2h.pages.dev/changelog/post/2025-09-11-increased-version-rollback-limit/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The number of recent versions available for a Worker rollback has been increased from 10 to 100.  
This allows you to:

  * Promote any of the 100 most recent versions to be the active deployment.
  * Split traffic using [gradual deployments](https://edgetunnel-b2h.pages.dev/workers/versions-and-deployments/gradual-deployments/) between your latest code and any of the 100 most recent versions.  
You can do this through the Cloudflare dashboard or with [Wrangler's rollback command](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/general/#rollback)  
Learn more about [versioned deployments](https://edgetunnel-b2h.pages.dev/workers/versions-and-deployments/) and [rollbacks](https://edgetunnel-b2h.pages.dev/workers/versions-and-deployments/rollbacks/).

Sep 10, 2025
1. ### [Agents SDK v0.1.0 and workers-ai-provider v2.0.0 with AI SDK v5 support](https://edgetunnel-b2h.pages.dev/changelog/post/2025-09-03-agents-sdk-beta-v5/)  
[ Agents ](https://edgetunnel-b2h.pages.dev/agents/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
We've shipped a new release for the [Agents SDK ↗](https://github.com/cloudflare/agents) bringing full compatibility with [AI SDK v5 ↗](https://ai-sdk.dev/docs/introduction) and introducing automatic message migration that handles all legacy formats transparently.  
This release includes improved streaming and tool support, tool confirmation detection (for "human in the loop" systems), enhanced React hooks with automatic tool resolution, improved error handling for streaming responses, and seamless migration utilities that work behind the scenes.  
This makes it ideal for building production AI chat interfaces with Cloudflare Workers AI models, agent workflows, human-in-the-loop systems, or any application requiring reliable message handling across SDK versions — all while maintaining backward compatibility.  
Additionally, we've updated workers-ai-provider v2.0.0, the official provider for Cloudflare Workers AI models, to be compatible with AI SDK v5.  
#### useAgentChat(options)  
Creates a new chat interface with enhanced v5 capabilities.

**TypeScript**  
```ts  
// Basic chat setup  
const { messages, sendMessage, addToolResult } = useAgentChat({  
  agent,  
  experimental_automaticToolResolution: true,  
  tools,  
});  
// With custom tool confirmation  
const chat = useAgentChat({  
  agent,  
  experimental_automaticToolResolution: true,  
  toolsRequiringConfirmation: ["dangerousOperation"],  
});  
```  
#### Automatic Tool Resolution  
Tools are automatically categorized based on their configuration:

**TypeScript**  
```ts  
const tools = {  
  // Auto-executes (has execute function)  
  getLocalTime: {  
    description: "Get current local time",  
    inputSchema: z.object({}),  
    execute: async () => new Date().toLocaleString(),  
  },  
  // Requires confirmation (no execute function)  
  deleteFile: {  
    description: "Delete a file from the system",  
    inputSchema: z.object({  
      filename: z.string(),  
    }),  
  },  
  // Server-executed (no client confirmation)  
  analyzeData: {  
    description: "Analyze dataset on server",  
    inputSchema: z.object({ data: z.array(z.number()) }),  
    serverExecuted: true,  
  },  
} satisfies Record<string, AITool>;  
```  
#### Message Handling  
Send messages using the new v5 format with parts array:

**TypeScript**  
```ts  
// Text message  
sendMessage({  
  role: "user",  
  parts: [{ type: "text", text: "Hello, assistant!" }],  
});  
// Multi-part message with file  
sendMessage({  
  role: "user",  
  parts: [  
    { type: "text", text: "Analyze this image:" },  
    { type: "image", image: imageData },  
  ],  
});  
```  
#### Tool Confirmation Detection  
Simplified logic for detecting pending tool confirmations:

**TypeScript**  
```ts  
const pendingToolCallConfirmation = messages.some((m) =>  
  m.parts?.some(  
    (part) => isToolUIPart(part) && part.state === "input-available",  
  ),  
);  
// Handle tool confirmation  
if (pendingToolCallConfirmation) {  
  await addToolResult({  
    toolCallId: part.toolCallId,  
    tool: getToolName(part),  
    output: "User approved the action",  
  });  
}  
```  
#### Automatic Message Migration  
Seamlessly handle legacy message formats without code changes.

**TypeScript**  
```ts  
// All these formats are automatically converted:  
// Legacy v4 string content  
const legacyMessage = {  
  role: "user",  
  content: "Hello world",  
};  
// Legacy v4 with tool calls  
const legacyWithTools = {  
  role: "assistant",  
  content: "",  
  toolInvocations: [  
    {  
      toolCallId: "123",  
      toolName: "weather",  
      args: { city: "SF" },  
      state: "result",  
      result: "Sunny, 72°F",  
    },  
  ],  
};  
// Automatically becomes v5 format:  
// {  
//   role: "assistant",  
//   parts: [{  
//     type: "tool-call",  
//     toolCallId: "123",  
//     toolName: "weather",  
//     args: { city: "SF" },  
//     state: "result",  
//     result: "Sunny, 72°F"  
//   }]  
// }  
```  
#### Tool Definition Updates  
Migrate tool definitions to use the new `inputSchema` property.

**TypeScript**  
```ts  
// Before (AI SDK v4)  
const tools = {  
  weather: {  
    description: "Get weather information",  
    parameters: z.object({  
      city: z.string(),  
    }),  
    execute: async (args) => {  
      return await getWeather(args.city);  
    },  
  },  
};  
// After (AI SDK v5)  
const tools = {  
  weather: {  
    description: "Get weather information",  
    inputSchema: z.object({  
      city: z.string(),  
    }),  
    execute: async (args) => {  
      return await getWeather(args.city);  
    },  
  },  
};  
```  
#### Cloudflare Workers AI Integration  
Seamless integration with Cloudflare Workers AI models through the updated workers-ai-provider v2.0.0.  
#### Model Setup with Workers AI  
Use Cloudflare Workers AI models directly in your agent workflows:

**TypeScript**  
```ts  
import { createWorkersAI } from "workers-ai-provider";  
import { useAgentChat } from "agents/ai-react";  
// Create Workers AI model (v2.0.0 - same API, enhanced v5 internals)  
const model = createWorkersAI({  
  binding: env.AI,  
})("@cf/meta/llama-3.2-3b-instruct");  
```  
#### Enhanced File and Image Support  
Workers AI models now support v5 file handling with automatic conversion:

**TypeScript**  
```ts  
// Send images and files to Workers AI models  
sendMessage({  
  role: "user",  
  parts: [  
    { type: "text", text: "Analyze this image:" },  
    {  
      type: "file",  
      data: imageBuffer,  
      mediaType: "image/jpeg",  
    },  
  ],  
});  
// Workers AI provider automatically converts to proper format  
```  
#### Streaming with Workers AI  
Enhanced streaming support with automatic warning detection:

**TypeScript**  
```ts  
// Streaming with Workers AI models  
const result = await streamText({  
  model: createWorkersAI({ binding: env.AI })("@cf/meta/llama-3.2-3b-instruct"),  
  messages,  
  onChunk: (chunk) => {  
    // Enhanced streaming with warning handling  
    console.log(chunk);  
  },  
});  
```  
#### Import Updates  
Update your imports to use the new v5 types:

**TypeScript**  
```ts  
// Before (AI SDK v4)  
import type { Message } from "ai";  
import { useChat } from "ai/react";  
// After (AI SDK v5)  
import type { UIMessage } from "ai";  
// or alias for compatibility  
import type { UIMessage as Message } from "ai";  
import { useChat } from "@ai-sdk/react";  
```  
#### Resources

  * [Migration Guide ↗](https://github.com/cloudflare/agents/blob/main/docs/migration-to-ai-sdk-v5.md) \- Comprehensive migration documentation
  * [AI SDK v5 Documentation ↗](https://ai-sdk.dev/docs/migration-guides/migration-guide-5-0) \- Official AI SDK migration guide
  * [An Example PR showing the migration from AI SDK v4 to v5 ↗](https://github.com/cloudflare/agents-starter/pull/105)
  * [GitHub Issues ↗](https://github.com/cloudflare/agents/issues) \- Report bugs or request features  
#### Feedback Welcome  
We'd love your feedback! We're particularly interested in feedback on:

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

Sep 10, 2025
1. ### [Built with Cloudflare button](https://edgetunnel-b2h.pages.dev/changelog/post/2025-09-10-built-with-cloudflare-button/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
We've updated our "Built with Cloudflare" button to make it easier to share that you're building on Cloudflare with the world. Embed it in your project's README, blog post, or wherever you want to let people know.  
![Built with Cloudflare](https://workers.cloudflare.com/built-with-cloudflare.svg)  
Check out the [documentation](https://edgetunnel-b2h.pages.dev/workers/platform/built-with-cloudflare) for usage information.

```json
{"@context":"https://schema.org","@type":"BlogPosting","@id":"https://edgetunnel-b2h.pages.dev/changelog/product/workers/5/#page","headline":"Workers Changelog | Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/changelog/product/workers/5/","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/"}}
```