--- title: Workers Changelog image: https://developers.cloudflare.com/cf-twitter-card.png --- [Skip to content](#%5Ftop) # Changelog New updates and improvements at Cloudflare. [ Subscribe to RSS ](https://developers.cloudflare.com/changelog/rss/index.xml) [ View RSS feeds ](https://developers.cloudflare.com/fundamentals/new-features/available-rss-feeds/) Workers ![hero image](https://developers.cloudflare.com/_astro/hero.CVYJHPAd_26AMqX.svg) Aug 05, 2025 1. ### [Cloudflare Sandbox SDK adds streaming, code interpreter, Git support, process control and more](https://developers.cloudflare.com/changelog/post/2025-08-05-sandbox-sdk-major-update/) [ Agents ](https://developers.cloudflare.com/agents/)[ Workers ](https://developers.cloudflare.com/workers/) We’ve shipped a major release for the [@cloudflare/sandbox ↗](https://github.com/cloudflare/sandbox-sdk) SDK, turning it into a full-featured, container-based execution platform that runs securely on Cloudflare Workers. This update adds live streaming of output, persistent Python and JavaScript code interpreters with rich output support (charts, tables, HTML, JSON), file system access, Git operations, full background process control, and the ability to expose running services via public URLs. This makes it ideal for building AI agents, CI runners, cloud REPLs, data analysis pipelines, or full developer tools — all without managing infrastructure. #### Code interpreter (Python, JS, TS) Create persistent code contexts with support for rich visual + structured outputs. #### createCodeContext(options) Creates a new code execution context with persistent state. TypeScript ``` // Create a Python context const pythonCtx = await sandbox.createCodeContext({ language: "python" }); // Create a JavaScript context const jsCtx = await sandbox.createCodeContext({ language: "javascript" }); ``` Options: * language: Programming language ('python' | 'javascript' | 'typescript') * cwd: Working directory (default: /workspace) * envVars: Environment variables for the context #### runCode(code, options) Executes code with optional streaming callbacks. TypeScript ``` // Simple execution const execution = await sandbox.runCode('print("Hello World")', { context: pythonCtx, }); // With streaming callbacks await sandbox.runCode( ` for i in range(5): print(f"Step {i}") time.sleep(1) `, { context: pythonCtx, onStdout: (output) => console.log("Real-time:", output.text), onResult: (result) => console.log("Result:", result), }, ); ``` Options: * language: Programming language ('python' | 'javascript' | 'typescript') * cwd: Working directory (default: /workspace) * envVars: Environment variables for the context #### Real-time streaming output Returns a streaming response for real-time processing. TypeScript ``` const stream = await sandbox.runCodeStream( "import time; [print(i) for i in range(10)]", ); // Process the stream as needed ``` #### Rich output handling Interpreter outputs are auto-formatted and returned in multiple formats: * text * html (e.g., Pandas tables) * png, svg (e.g., Matplotlib charts) * json (structured data) * chart (parsed visualizations) TypeScript ``` const result = await sandbox.runCode( ` import seaborn as sns import matplotlib.pyplot as plt data = sns.load_dataset("flights") pivot = data.pivot("month", "year", "passengers") sns.heatmap(pivot, annot=True, fmt="d") plt.title("Flight Passengers") plt.show() pivot.to_dict() `, { context: pythonCtx }, ); if (result.png) { console.log("Chart output:", result.png); } ``` #### Preview URLs from Exposed Ports Start background processes and expose them with live URLs. TypeScript ``` await sandbox.startProcess("python -m http.server 8000"); const preview = await sandbox.exposePort(8000); console.log("Live preview at:", preview.url); ``` #### Full process lifecycle control Start, inspect, and terminate long-running background processes. TypeScript ``` const process = await sandbox.startProcess("node server.js"); console.log(`Started process ${process.id} with PID ${process.pid}`); // Monitor the process const logStream = await sandbox.streamProcessLogs(process.id); for await (const log of parseSSEStream(logStream)) { console.log(`Server: ${log.data}`); } ``` * listProcesses() - List all running processes * getProcess(id) - Get detailed process status * killProcess(id, signal) - Terminate specific processes * killAllProcesses() - Kill all processes * streamProcessLogs(id, options) - Stream logs from running processes * getProcessLogs(id) - Get accumulated process output #### Git integration Clone Git repositories directly into the sandbox. TypeScript ``` await sandbox.gitCheckout("https://github.com/user/repo", { branch: "main", targetDir: "my-project", }); ``` Sandboxes are still experimental. We're using them to explore how isolated, container-like workloads might scale on Cloudflare — and to help define the developer experience around them. Aug 04, 2025 1. ### [Increased disk space for Workers Builds](https://developers.cloudflare.com/changelog/post/2025-08-04-builds-increased-disk-size/) [ Workers ](https://developers.cloudflare.com/workers/) As part of the ongoing open beta for [Workers Builds](https://developers.cloudflare.com/workers/ci-cd/builds/), we’ve increased the available disk space for builds from **8 GB** to **20 GB** for both Free and Paid plans. This provides more space for larger projects, dependencies, and build artifacts while improving overall build reliability. | Metric | Free Plan | Paid Plans | | ---------- | --------- | ---------- | | Disk Space | 20 GB | 20 GB | All other [build limits](https://developers.cloudflare.com/workers/ci-cd/builds/limits-and-pricing/) — including CPU, memory, build minutes, and timeout remain unchanged. Aug 01, 2025 1. ### [Develop locally with Containers and the Cloudflare Vite plugin](https://developers.cloudflare.com/changelog/post/2025-08-01-containers-in-vite-dev/) [ Workers ](https://developers.cloudflare.com/workers/) You can now configure and run [Containers](https://developers.cloudflare.com/containers) alongside your [Worker](https://developers.cloudflare.com/workers) during local development when using the [Cloudflare Vite plugin](https://developers.cloudflare.com/workers/vite-plugin/). Previously, you could only develop locally when using [Wrangler](https://developers.cloudflare.com/workers/wrangler/) as your local development server. #### Configuration You can simply configure your Worker and your Container(s) in your Wrangler configuration file: * [ wrangler.jsonc ](#tab-panel-276) * [ wrangler.toml ](#tab-panel-277) JSONC ``` { "name": "container-starter", "main": "src/index.js", "containers": [ { "class_name": "MyContainer", "image": "./Dockerfile", "instances": 5 } ], "durable_objects": { "bindings": [ { "class_name": "MyContainer", "name": "MY_CONTAINER" } ] }, "migrations": [ { "new_sqlite_classes": [ "MyContainer" ], "tag": "v1" } ], } ``` TOML ``` name = "container-starter" main = "src/index.js" [[containers]] class_name = "MyContainer" image = "./Dockerfile" instances = 5 [[durable_objects.bindings]] class_name = "MyContainer" name = "MY_CONTAINER" [[migrations]] new_sqlite_classes = [ "MyContainer" ] tag = "v1" ``` #### Worker Code Once your Worker and Containers are configured, you can access the Container instances from your Worker code: TypeScript ``` import { Container, getContainer } from "@cloudflare/containers"; export class MyContainer extends Container { defaultPort = 4000; // Port the container is listening on sleepAfter = "10m"; // Stop the instance if requests not sent for 10 minutes } async fetch(request, env) { const { "session-id": sessionId } = await request.json(); // Get the container instance for the given session ID const containerInstance = getContainer(env.MY_CONTAINER, sessionId) // Pass the request to the container instance on its default port return containerInstance.fetch(request); } ``` #### Local development To develop your Worker locally, start a local dev server by running Terminal window ``` vite dev ``` in your terminal. #### Resources Learn more about [Cloudflare Containers ↗](https://developers.cloudflare.com/containers/) or the [Cloudflare Vite plugin ↗](https://developers.cloudflare.com/workers/vite-plugin/) in our developer docs. Jul 29, 2025 1. ### [Deploy to Cloudflare buttons now support Worker environment variables, secrets, and Secrets Store secrets](https://developers.cloudflare.com/changelog/post/2025-07-01-workers-deploy-button-supports-environment-variables-and-secrets/) [ Workers ](https://developers.cloudflare.com/workers/)[ Secrets Store ](https://developers.cloudflare.com/secrets-store/) Any template which uses [Worker environment variables](https://developers.cloudflare.com/workers/configuration/environment-variables/), [secrets](https://developers.cloudflare.com/workers/configuration/secrets/), or [Secrets Store secrets](https://developers.cloudflare.com/secrets-store/) can now be deployed using a [Deploy to Cloudflare button](https://developers.cloudflare.com/workers/platform/deploy-buttons/). Define environment variables and secrets store bindings in your Wrangler configuration file as normal: * [ wrangler.jsonc ](#tab-panel-270) * [ wrangler.toml ](#tab-panel-271) JSONC ``` { "name": "my-worker", "main": "./src/index.ts", // Set this to today's date "compatibility_date": "2026-04-04", "vars": { "API_HOST": "https://example.com", }, "secrets_store_secrets": [ { "binding": "API_KEY", "store_id": "demo", "secret_name": "api-key" } ] } ``` TOML ``` name = "my-worker" main = "./src/index.ts" # Set this to today's date compatibility_date = "2026-04-04" [vars] API_HOST = "https://example.com" [[secrets_store_secrets]] binding = "API_KEY" store_id = "demo" secret_name = "api-key" ``` Add secrets to a `.dev.vars.example` or `.env.example` file: .dev.vars.example ``` COOKIE_SIGNING_KEY=my-secret # comment ``` And optionally, you can add a description for these bindings in your template's `package.json` to help users understand how to configure each value: package.json ``` { "name": "my-worker", "private": true, "cloudflare": { "bindings": { "API_KEY": { "description": "Select your company's API key for connecting to the example service." }, "COOKIE_SIGNING_KEY": { "description": "Generate a random string using `openssl rand -hex 32`." } } } } ``` These secrets and environment variables will be presented to users in the dashboard as they deploy this template, allowing them to configure each value. Additional information about creating templates and Deploy to Cloudflare buttons can be found in [our documentation](https://developers.cloudflare.com/workers/platform/deploy-buttons/). Jul 22, 2025 1. ### [Test out code changes before shipping with per-branch preview deployments for Cloudflare Workers](https://developers.cloudflare.com/changelog/post/2025-07-23-workers-preview-urls/) [ Workers ](https://developers.cloudflare.com/workers/) Now, when you connect your Cloudflare Worker to a git repository on GitHub or GitLab, each branch of your repository has its own stable preview URL, that you can use to preview code changes before merging the pull request and deploying to production. This works the same way that Cloudflare Pages does — every time you create a pull request, you'll automatically get a shareable preview link where you can see your changes running, without affecting production. The link stays the same, even as you add commits to the same branch. These preview URLs are named after your branch and are posted as a comment to each pull request. The URL stays the same with every commit and always points to the latest version of that branch. ![PR comment preview](https://developers.cloudflare.com/_astro/preview-urls-comment.0wQffFIq_2uQPCz.webp) #### Preview URL types Each comment includes **two preview URLs** as shown above: * **Commit Preview URL**: Unique to the specific version/commit (e.g., `-..workers.dev`) * **Branch Preview URL**: A stable alias based on the branch name (e.g., `-..workers.dev`) #### How it works When you create a pull request: * **A preview alias is automatically created** based on the Git branch name (e.g., `` becomes `-..workers.dev`) * **No configuration is needed**, the alias is generated for you * **The link stays the same** even as you add commits to the same branch * **Preview URLs are posted directly to your pull request as comments** (just like they are in Cloudflare Pages) #### Custom alias name You can also assign a custom preview alias using the [Wrangler CLI](https://developers.cloudflare.com/workers/wrangler/), by passing the `--preview-alias` flag when [uploading a version](https://developers.cloudflare.com/workers/wrangler/commands/general/#versions-upload) of your Worker: Terminal window ``` wrangler versions upload --preview-alias staging ``` #### Limitations while in beta * Only available on the **workers.dev** subdomain (custom domains not yet supported) * Requires **Wrangler v4.21.0+** * Preview URLs are not generated for Workers that use [Durable Objects](https://developers.cloudflare.com/durable-objects/) * Not yet supported for [Workers for Platforms](https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/) Jul 17, 2025 1. ### [The Cloudflare Vite plugin now supports Vite 7](https://developers.cloudflare.com/changelog/post/2025-07-17-vite-plugin-vite-7-support/) [ Workers ](https://developers.cloudflare.com/workers/) [Vite 7 ↗](https://vite.dev/blog/announcing-vite7) is now supported in the Cloudflare Vite plugin. See the [Vite changelog ↗](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md#700-2025-06-24) for a list of changes. Note that the minimum Node.js versions supported by Vite 7 are 20.19 and 22.12\. We continue to support Vite 6 so you do not need to immediately upgrade. Jul 04, 2025 1. ### [Workers now supports JavaScript debug terminals in VSCode, Cursor and Windsurf IDEs](https://developers.cloudflare.com/changelog/post/2025-07-04-javascript-debug-terminals/) [ Workers ](https://developers.cloudflare.com/workers/) Workers now support breakpoint debugging using VSCode's built-in [JavaScript Debug Terminals ↗](https://code.visualstudio.com/docs/nodejs/nodejs-debugging#%5Fjavascript-debug-terminal). All you have to do is open a JS debug terminal (`Cmd + Shift + P` and then type `javascript debug`) and run `wrangler dev` (or `vite dev`) from within the debug terminal. VSCode will automatically connect to your running Worker (even if you're running multiple Workers at once!) and start a debugging session. In 2023 we announced [breakpoint debugging support ↗](https://blog.cloudflare.com/debugging-cloudflare-workers/) for Workers, which meant that you could easily debug your Worker code in Wrangler's built-in devtools (accessible via the `[d]` hotkey) as well as multiple other devtools clients, [including VSCode ↗](https://developers.cloudflare.com/workers/observability/dev-tools/breakpoints/). For most developers, breakpoint debugging via VSCode is the most natural flow, but until now it's required [manually configuring a launch.json file ↗](https://developers.cloudflare.com/workers/observability/dev-tools/breakpoints/#setup-vs-code-to-use-breakpoints), running `wrangler dev`, and connecting via VSCode's built-in debugger. Now it's much more seamless! Jul 01, 2025 1. ### [Enhanced support for static assets with the Cloudflare Vite plugin](https://developers.cloudflare.com/changelog/post/2025-07-01-vite-plugin-enhanced-assets-support/) [ Workers ](https://developers.cloudflare.com/workers/) You can now use any of Vite's [static asset handling ↗](https://vite.dev/guide/assets) features in your Worker as well as in your frontend. These include importing assets as URLs, importing as strings and importing from the `public` directory as well as inlining assets. Additionally, assets imported as URLs in your Worker are now automatically moved to the client build output. Here is an example that fetches an imported asset using the [assets binding](https://developers.cloudflare.com/workers/static-assets/binding/#binding) and modifies the response. TypeScript ``` // Import the asset URL // This returns the resolved path in development and production import myImage from "./my-image.png"; export default { async fetch(request, env) { // Fetch the asset using the binding const response = await env.ASSETS.fetch(new URL(myImage, request.url)); // Create a new `Response` object that can be modified const modifiedResponse = new Response(response.body, response); // Add an additional header modifiedResponse.headers.append("my-header", "imported-asset"); // Return the modfied response return modifiedResponse; }, }; ``` Refer to [Static Assets](https://developers.cloudflare.com/workers/vite-plugin/reference/static-assets/) in the Cloudflare Vite plugin docs for more info. Jun 30, 2025 1. ### [Remote bindings (beta) now works with Next.js — connect to remote resources (D1, KV, R2, etc.) during local development](https://developers.cloudflare.com/changelog/post/2025-06-25-getplatformproxy-support-remote-bindings/) [ Workers ](https://developers.cloudflare.com/workers/) We [recently announced ↗](https://github.com/cloudflare/workers-sdk/discussions/9660) our public beta for [remote bindings](https://developers.cloudflare.com/workers/development-testing/#remote-bindings), which allow you to connect to deployed resources running on your Cloudflare account (like [R2 buckets](https://developers.cloudflare.com/r2) or [D1 databases](https://developers.cloudflare.com/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`: ``` 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-268) * [ wrangler.toml ](#tab-panel-269) JSONC ``` { "r2_buckets": [ { "bucket_name": "testing-bucket", "binding": "MY_BUCKET", "experimental_remote": true, }, ], } ``` 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://developers.cloudflare.com/workers/development-testing/#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://developers.cloudflare.com/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://developers.cloudflare.com/changelog/post/2025-06-26-vite-plugin-cross-commands-binding/) [ Workers ](https://developers.cloudflare.com/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: Terminal window ``` # 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://developers.cloudflare.com/workers/development-testing/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://developers.cloudflare.com/changelog/post/2025-06-24-announcing-sandboxes/) [ Agents ](https://developers.cloudflare.com/agents/)[ Workers ](https://developers.cloudflare.com/workers/)[ Workflows ](https://developers.cloudflare.com/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 ``` 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://developers.cloudflare.com/changelog/post/2025-06-25-actors-package-alpha/) [ Durable Objects ](https://developers.cloudflare.com/durable-objects/)[ Workers ](https://developers.cloudflare.com/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://developers.cloudflare.com/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://developers.cloudflare.com/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 ``` import { Storage } from "@cloudflare/actors/storage"; export class ChatRoom extends DurableObject { 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 { // 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 ``` export class MyActor extends Actor { async fetch(request: Request): Promise { return new Response('Hello, World!') } } export default handler(MyActor); ``` You can [route](https://developers.cloudflare.com/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 ``` export class MyActor extends Actor { static nameFromRequest(request: Request): string { let url = new URL(request.url); return url.searchParams.get("userId") ?? "foo"; } async fetch(request: Request): Promise { 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://developers.cloudflare.com/changelog/post/2025-06-20-increased-blob-size-limits-in-workers-analytics/) [ Workers ](https://developers.cloudflare.com/workers/) We’ve increased the total allowed size of [blob](https://developers.cloudflare.com/analytics/analytics-engine/get-started/#2-write-data-points-from-your-worker) fields on data points written to [Workers Analytics Engine](https://developers.cloudflare.com/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://developers.cloudflare.com/analytics/analytics-engine/limits/). * [ JavaScript ](#tab-panel-278) * [ TypeScript ](#tab-panel-279) JavaScript ``` export default { async fetch(request, env) { env.analyticsDataset.writeDataPoint({ // The sum of all of the blob's sizes can now be 16 KB blobs: [ // The URL of the request to the Worker request.url, // Some metadata about your application you'd like to store JSON.stringify(metadata), // The version of your Worker this datapoint was collected from env.versionMetadata.tag, ], indexes: ["sample-index"], }); }, }; ``` TypeScript ``` export default { async fetch(request, env) { env.analyticsDataset.writeDataPoint({ // The sum of all of the blob's sizes can now be 16 KB blobs: [ // The URL of the request to the Worker request.url, // Some metadata about your application you'd like to store JSON.stringify(metadata), // The version of your Worker this datapoint was collected from env.versionMetadata.tag, ], indexes: ["sample-index"], }); } }; ``` Jun 19, 2025 1. ### [Automate Worker deployments with a simplified SDK and more reliable Terraform provider](https://developers.cloudflare.com/changelog/post/2025-06-17-workers-terraform-sdk-api-fixes/) [ D1 ](https://developers.cloudflare.com/d1/)[ Workers ](https://developers.cloudflare.com/workers/)[ Workers for Platforms ](https://developers.cloudflare.com/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://developers.cloudflare.com/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://developers.cloudflare.com/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: Terminal window ``` curl https://api.cloudflare.com/client/v4/accounts//workers/scripts/my-hello-world-script \ -X PUT \ -H 'Authorization: Bearer ' \ -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' < | Passing the Build UUID along to custom workflows | | WORKERS\_CI\_COMMIT\_SHA | | Passing current commit ID to error reporting, for example, Sentry | | WORKERS\_CI\_BRANCH | **Settings** \> **Environment variables**. Learn more in the [Build configuration documentation](https://developers.cloudflare.com/workers/ci-cd/builds/configuration/#environment-variables). Jun 09, 2025 1. ### [Workers native integrations were removed from the Cloudflare dashboard](https://developers.cloudflare.com/changelog/post/2025-06-09-workers-integrations-changes/) [ Workers ](https://developers.cloudflare.com/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://developers.cloudflare.com/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://developers.cloudflare.com/workers/observability/logs/tail-workers/) that were created from the original integration setup. * **Update secrets**: Use `npx wrangler secret put ` 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://developers.cloudflare.com/workers/observability/third-party-integrations/sentry), [Turso](https://developers.cloudflare.com/workers/databases/third-party-integrations/turso/), [Neon](https://developers.cloudflare.com/workers/databases/third-party-integrations/neon/), [Supabase](https://developers.cloudflare.com/workers/databases/third-party-integrations/supabase/), [PlanetScale](https://developers.cloudflare.com/workers/databases/third-party-integrations/planetscale/), [Upstash](https://developers.cloudflare.com/workers/databases/third-party-integrations/upstash/), [Xata](https://developers.cloudflare.com/workers/databases/third-party-integrations/xata/). Jun 05, 2025 1. ### [Performance and size optimization for the Cloudflare adapter for Open Next](https://developers.cloudflare.com/changelog/post/2025-06-05-open-next-size/) [ Workers ](https://developers.cloudflare.com/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://developers.cloudflare.com/changelog/post/2025-06-03-visualize-your-worker-architecture/) [ Workers ](https://developers.cloudflare.com/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://developers.cloudflare.com/d1), [Durable Objects](https://developers.cloudflare.com/durable-objects), [KV namespaces](https://developers.cloudflare.com/kv), and [more](https://developers.cloudflare.com/workers/runtime-apis/bindings/). ![Bindings canvas](https://developers.cloudflare.com/_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://developers.cloudflare.com/changelog/post/2025-05-21-vite-plugin-chrome-devtools/) [ Workers ](https://developers.cloudflare.com/workers/) You can now [debug, profile, view logs, and analyze memory usage for your Worker ↗](https://developers.cloudflare.com/workers/observability/dev-tools/) using [Chrome Devtools ↗](https://developer.chrome.com/docs/devtools) when your Worker runs locally using the [Cloudflare Vite plugin ↗](https://developers.cloudflare.com/workers/vite-plugin/). Previously, this was only possible if your Worker ran locally using the [Wrangler CLI ↗](https://developers.cloudflare.com/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: ``` 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://developers.cloudflare.com/_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://developers.cloudflare.com/workers/observability/dev-tools/breakpoints/) * [Profile CPU usage](https://developers.cloudflare.com/workers/observability/dev-tools/cpu-usage/) * [Observe memory usage and debug memory leaks](https://developers.cloudflare.com/workers/observability/dev-tools/memory-usage/) May 29, 2025 1. ### [50-500ms Faster D1 REST API Requests](https://developers.cloudflare.com/changelog/post/2025-05-30-d1-rest-api-latency/) [ D1 ](https://developers.cloudflare.com/d1/)[ Workers ](https://developers.cloudflare.com/workers/) Users using Cloudflare's [REST API](https://developers.cloudflare.com/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://developers.cloudflare.com/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://developers.cloudflare.com/changelog/post/2025-05-22-handle-request-cancellation/) [ Workers ](https://developers.cloudflare.com/workers/) In Cloudflare Workers, you can now attach an event listener to [Request](https://developers.cloudflare.com/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://developers.cloudflare.com/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-282) * [ TypeScript ](#tab-panel-283) index.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 ``` export default { async fetch(request, env, ctx): Promise { // 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; async function sendPing(writable: WritableStream): Promise { 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://developers.cloudflare.com/workers/runtime-apis/request). [Search all changelog entries](https://developers.cloudflare.com/search/?contentType=Changelog+entry)