Changelog

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

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

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

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

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

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

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

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

To enable Cloudflare Access:

1. In the Cloudflare dashboard, go to the Workers & Pages page.

   Go to Workers & 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 to learn about configuring alternate rules.

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

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

import { jwtVerify, createRemoteJWKSet } from "jose";

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

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

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

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

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

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

Add these environment variables to your Worker:

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

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

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

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

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

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

New aggregate functions: ↗︎

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

New bit functions: ↗︎

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

New mathematical functions: ↗︎

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

New string functions: ↗︎

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

New encoding functions: ↗︎

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

New type conversion functions: ↗︎

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

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

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

Example:

import { WorkerEntrypoint } from "cloudflare:workers";

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

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

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

See the API reference for more information.

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

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

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

Now, the following works as expected:

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

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

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

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

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

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

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

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

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

For more details, refer to Workers Rate Limiting documentation.

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

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

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

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

We now attach a default panic handler in Rust:

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

Which is registered by default in the JS initialization:

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

How to Re-enable Your Preview URL

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

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

{
  "preview_urls": true
}

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.

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

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

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

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

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

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

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

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

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

• Wrangler v4.37.0
• The Cloudflare Vite Plugin
• The Cloudflare Vitest Plugin

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

This allows you to:

• Promote any of the 100 most recent versions to be the active deployment.

• Split traffic using gradual deployments between your latest code and any of the 100 most recent versions.

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

Learn more about versioned deployments and rollbacks.

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

Check out the documentation for usage information.

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

Before: Required remembering multiple flags and parameters

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

After: Simple directory deployment with guided setup

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

Interactive prompts for missing configuration:

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

Automatic configuration generation:

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

# Deploy your built static site
wrangler deploy dist

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• A Worker couldn't exist without code: To create a Worker, you had to upload its code in the same API request. This meant platform teams couldn't provision Workers with the proper settings, and then hand them off to development teams to deploy the actual code.

• Several endpoints implicitly created deployments: Simple updates like adding a secret or changing a script's content would implicitly create a new version and immediately deploy it.

• Updating a setting was confusing: Configuration was scattered across eight endpoints with overlapping responsibilities. This ambiguity made it difficult for human developers (and even more so for AI agents) to reliably update a Worker via API.

• Scripts used names as primary identifiers: This meant simple renames could turn into a risky migration, requiring you to create a brand new Worker and update every reference. If you were using Terraform, this could inadvertently destroy your Worker altogether.

The new API introduces cleaner resource management with three core resources: Worker, Versions, and Deployment.

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

• Worker: The parent resource representing your application. It has a stable UUID and holds persistent settings like name, tags, and logpush. You can now create a Worker to establish its identity and settings before any code is uploaded.

• Version: An immutable snapshot of your code and its specific configuration, like bindings and compatibility_date. Creating a new version is a safe action that doesn't affect live traffic.

• Deployment: An explicit action that directs traffic to a specific version.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This dual approach means:

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

• Infrastructure as Code (IaC) guide
• API documentation
• Versions and Deployments overview

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

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

This change improves:

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

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

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

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

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

Before	After (Light)	After (Dark)

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

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

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

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

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

import fs from "node:fs";

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

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

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

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

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

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

const root = navigator.storage.getDirectory();

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

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

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

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

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

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

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

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

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

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

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

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

from workers import Response, WorkerEntrypoint

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

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

{
	"compatibility_flags": [
		"disable_python_no_global_handlers"
	]
}

compatibility_flags = [ "disable_python_no_global_handlers" ]

Consult the Python Workers documentation for more details.

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

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

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

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

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

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

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

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

Available in Cloudflare Terraform Provider 5.8.0.

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

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

Available in Cloudflare Terraform Provider 5.8.0.

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

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

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

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

Previously when creating a KV value like this:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

API_TOKEN="staging-token"

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

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

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

• Environment variables and secrets
• Wrangler Documentation ↗︎
• Cloudflare Vite Plugin Documentation ↗︎

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

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

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

import { waitUntil } from "cloudflare:workers";

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

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

This is particularly useful when you want to:

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

import { waitUntil } from "cloudflare:workers";

export default {
	async fetch(request, env, ctx) {
		// Background task that should complete even after response is sent
		cleanupTempData(env.KV_NAMESPACE);
		return new Response("Hello, World!");
	}
};

function cleanupTempData(kvNamespace) {
	// This function can now use waitUntil without needing ctx
	const deletePromise = kvNamespace.delete("temp-key");
	waitUntil(deletePromise);
}

For more information, see the waitUntil documentation.