New updates and improvements at Cloudflare.
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-projectAfter: Simple directory deployment with guided setup
wrangler deploy dist
# Interactive prompts handle the rest as shown in the example flow belowInteractive prompts for missing configuration:
Automatic configuration generation:
wrangler.jsonc file with your deployment settings# 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 deployWe're excited to be a launch partner alongside Google ↗ to bring their newest embedding model, EmbeddingGemma, to Workers AI that delivers best-in-class performance for its size, enabling RAG and semantic search use cases.
@cf/google/embeddinggemma-300m is a 300M parameter embedding model from Google, built from Gemma 3 and the same research used to create Gemini models. This multilingual model supports 100+ languages, making it ideal for RAG systems, semantic search, content classification, and clustering tasks.
Using EmbeddingGemma in AI Search: Now you can leverage EmbeddingGemma directly through AI Search for your RAG pipelines. EmbeddingGemma's multilingual capabilities make it perfect for global applications that need to understand and retrieve content across different languages with exceptional accuracy.
To use EmbeddingGemma for your AI Search projects:
@cf/google/embeddinggemma-300m as your embedding modelTry it out and let us know what you think!
You can now upload up to 100,000 static assets per Worker version
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.
cloudflare_worker ↗ , cloudflare_worker_version ↗, and cloudflare_workers_deployments ↗ resources.
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:
/scripts/ endpoint, we plan to introduce a new Deployments endpoint under /workers/ to match the new API structure.Starting December 1, 2025, list endpoints for the Cloudflare Tunnel API and Zero Trust Networks API will no longer return deleted tunnels, routes, subnets and virtual networks by default. This change makes the API behavior more intuitive by only returning active resources unless otherwise specified.
No action is required if you already explicitly set is_deleted=false or if you only need to list active resources.
This change affects the following API endpoints:
GET /accounts/{account_id}/tunnelsGET /accounts/{account_id}/cfd_tunnelGET /accounts/{account_id}/warp_connectorGET /accounts/{account_id}/teamnet/routesGET /accounts/{account_id}/zerotrust/subnetsGET /accounts/{account_id}/teamnet/virtual_networksThe default behavior of the is_deleted query parameter will be updated.
| Scenario | Previous behavior (before December 1, 2025) | New behavior (from December 1, 2025) |
|---|---|---|
is_deleted parameter is omitted |
Returns active & deleted tunnels, routes, subnets and virtual networks | Returns only active tunnels, routes, subnets and virtual networks |
If you need to retrieve deleted (or all) resources, please update your API calls to explicitly include the is_deleted parameter before December 1, 2025.
To get a list of only deleted resources, you must now explicitly add the is_deleted=true query parameter to your request:
# Example: Get ONLY deleted Tunnels
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/tunnels?is_deleted=true" \
-H "Authorization: Bearer $API_TOKEN"
# Example: Get ONLY deleted Virtual Networks
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/virtual_networks?is_deleted=true" \
-H "Authorization: Bearer $API_TOKEN"Following this change, retrieving a complete list of both active and deleted resources will require two separate API calls: one to get active items (by omitting the parameter or using is_deleted=false) and one to get deleted items (is_deleted=true).
This update is based on user feedback and aims to:
To learn more, please visit the Cloudflare Tunnel API and Zero Trust Networks API documentation.
Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues ↗ reported by the Cloudflare community related to the v5 release. We have committed to releasing improvements on a 2 week cadence to ensure its stability and reliability, including the v5.9 release. We have also pivoted from an issue-to-issue approach to a resource-per-resource approach - we will be focusing on specific resources for every release, stabilizing the release, and closing all associated bugs with that resource before moving onto resolving migration issues.
Thank you for continuing to raise issues. We triage them weekly and they help make our products stronger.
This release includes a new resource, cloudflare_snippet, which replaces cloudflare_snippets. cloudflare_snippet is now considered deprecated but can still be used. Please utilize cloudflare_snippet as soon as possible.
cloudflare_zone_settingcloudflare_worker_scriptcloudflare_worker_routetiered_cachecloudflare_snippet which should be used in place of cloudflare_snippets. cloudflare_snippets is now deprecated. This enables the management of Cloudflare's snippet functionality through Terraform.created_on field inconsistencies and improved pool configuration handlingFor a more detailed look at all of the changes, refer to the changelog ↗ in GitHub.
If you have an unaddressed issue with the provider, we encourage you to check the open issues ↗ and open a new issue if one does not already exist for what you are experiencing.
We suggest holding off on migration to v5 while we work on stabilization. This help will you avoid any blocking issues while the Terraform resources are actively being stabilized.
If you'd like more information on migrating from v4 to v5, please make use of the migration guide ↗. We have provided automated migration scripts using Grit which simplify the transition. These do not support implementations which use Terraform modules, so customers making use of modules need to migrate manually. Please make use of terraform plan to test
your changes before applying, and let us know if you encounter any additional issues by reporting to our GitHub repository ↗.
New state-of-the-art models have landed on Workers AI! This time, we're introducing new partner models trained by our friends at Deepgram ↗ and Leonardo ↗, hosted on Workers AI infrastructure.
As well, we're introuding a new turn detection model that enables you to detect when someone is done speaking — useful for building voice agents!
Read the blog ↗ for more details and check out some of the new models on our platform:
@cf/deepgram/aura-1 is a text-to-speech model that allows you to input text and have it come to life in a customizable voice@cf/deepgram/nova-3 is speech-to-text model that transcribes multilingual audio at a blazingly fast speed@cf/pipecat-ai/smart-turn-v2 helps you detect when someone is done speaking@cf/leonardo/lucid-origin is a text-to-image model that generates images with sharp graphic design, stunning full-HD renders, or highly specific creative direction@cf/leonardo/phoenix-1.0 is a text-to-image model with exceptional prompt adherence and coherent textYou can filter out new partner models with the Partner capability on our Models page.
As well, we're introducing WebSocket support for some of our audio models, which you can filter though the Realtime capability on our Models page. WebSockets allows you to create a bi-directional connection to our inference server with low latency — perfect for those that are building voice agents.
An example python snippet on how to use WebSockets with our new Aura model:
import json
import os
import asyncio
import websockets
uri = f"wss://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/run/@cf/deepgram/aura-1"
input = [
"Line one, out of three lines that will be provided to the aura model.",
"Line two, out of three lines that will be provided to the aura model.",
"Line three, out of three lines that will be provided to the aura model. This is a last line.",
]
async def text_to_speech():
async with websockets.connect(uri, additional_headers={"Authorization": os.getenv("CF_TOKEN")}) as websocket:
print("connection established")
for line in input:
print(f"sending `{line}`")
await websocket.send(json.dumps({"type": "Speak", "text": line}))
print("line was sent, flushing")
await websocket.send(json.dumps({"type": "Flush"}))
print("flushed, recving")
resp = await websocket.recv()
print(f"response received {resp}")
if __name__ == "__main__":
asyncio.run(text_to_speech())You can now list all vector identifiers in a Vectorize index using the new list-vectors operation. This enables bulk operations, auditing, and data migration workflows through paginated requests that maintain snapshot consistency.
The operation is available via Wrangler CLI and REST API. Refer to the list-vectors best practices guide for detailed usage guidance.
Cloudflare Secrets Store is now integrated with AI Gateway, allowing you to store, manage, and deploy your AI provider keys in a secure and seamless configuration through Bring Your Own Key ↗. Instead of passing your AI provider keys directly in every request header, you can centrally manage each key with Secrets Store and deploy in your gateway configuration using only a reference, rather than passing the value in plain text.
You can now create a secret directly from your AI Gateway in the dashboard ↗ by navigating into your gateway -> Provider Keys -> Add.
You can also create your secret with the newly available ai_gateway scope via wrangler ↗, the Secrets Store dashboard ↗, or the API ↗.
Then, pass the key in the request header using its Secrets Store reference:
curl -X POST https://gateway.ai.cloudflare.com/v1/<ACCOUNT_ID>/my-gateway/anthropic/v1/messages \
--header 'cf-aig-authorization: ANTHROPIC_KEY_1 \
--header 'anthropic-version: 2023-06-01' \
--header 'Content-Type: application/json' \
--data '{"model": "claude-3-opus-20240229", "messages": [{"role": "user", "content": "What is Cloudflare?"}]}'Or, using Javascript:
import Anthropic from '@anthropic-ai/sdk';
const anthropic = new Anthropic({
apiKey: "ANTHROPIC_KEY_1",
baseURL: "https://gateway.ai.cloudflare.com/v1/<ACCOUNT_ID>/my-gateway/anthropic",
});
const message = await anthropic.messages.create({
model: 'claude-3-opus-20240229',
messages: [{role: "user", content: "What is Cloudflare?"}],
max_tokens: 1024
});For more information, check out the blog ↗!
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:
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.
Workers KV has completed rolling out performance improvements across all KV namespaces, providing a significant latency reduction on read operations for all KV users. This is due to architectural changes to KV's underlying storage infrastructure, which introduces a new metadata later and substantially improves redundancy.
The new hybrid architecture delivers substantial latency reductions throughout Europe, Asia, Middle East, Africa regions. Over the past 2 weeks, we have observed the following:
You can now build Workflows using Python. With Python Workflows, you get automatic retries, state persistence, and the ability to run multi-step operations that can span minutes, hours, or weeks using Python’s familiar syntax and the Python Workers runtime.
Python Workflows use the same step-based execution model as JavaScript Workflows, but with Python syntax and access to Python’s ecosystem. Python Workflows also enable DAG (Directed Acyclic Graph) workflows, where you can define complex dependencies between steps using the depends parameter.
Here’s a simple example:
from workers import Response, WorkflowEntrypoint
class PythonWorkflowStarter(WorkflowEntrypoint):
async def run(self, event, step):
@step.do("my first step")
async def my_first_step():
# do some work
return "Hello Python!"
await my_first_step()
await step.sleep("my-sleep-step", "10 seconds")
@step.do("my second step")
async def my_second_step():
# do some more work
return "Hello again!"
await my_second_step()
class Default(WorkerEntrypoint):
async def fetch(self, request):
await self.env.MY_WORKFLOW.create()
return Response("Hello Workflow creation!")Python Workflows support the same core capabilities as JavaScript Workflows, including sleep scheduling, event-driven workflows, and built-in error handling with configurable retry policies.
To learn more and get started, refer to Python Workflows documentation.
You can now create a client (a Durable Object stub) to a Durable Object with the new getByName method, removing the need to convert Durable Object names to IDs and then create a stub.
// Before: (1) translate name to ID then (2) get a client
const objectId = env.MY_DURABLE_OBJECT.idFromName("foo"); // or .newUniqueId()
const stub = env.MY_DURABLE_OBJECT.get(objectId);
// Now: retrieve client to Durable Object directly via its name
const stub = env.MY_DURABLE_OBJECT.getByName("foo");
// Use client to send request to the remote Durable Object
const rpcResponse = await stub.sayHello();Each Durable Object has a globally-unique name, which allows you to send requests to a specific object from anywhere in the world. Thus, a Durable Object can be used to coordinate between multiple clients who need to work together. You can have billions of Durable Objects, providing isolation between application tenants.
To learn more, visit the Durable Objects API Documentation or the getting started guide.
You can now subscribe to events from other Cloudflare services (for example, Workers KV, Workers AI, Workers) and consume those events via Queues, allowing you to build custom workflows, integrations, and logic in response to account activity.
Event subscriptions allow you to receive messages when events occur across your Cloudflare account. Cloudflare products can publish structured events to a queue, which you can then consume with Workers or pull via HTTP from anywhere.
To create a subscription, use the dashboard or Wrangler:
npx wrangler queues subscription create my-queue --source r2 --events bucket.createdAn event is a structured record of something happening in your Cloudflare account – like a Workers AI batch request being queued, a Worker build completing, or an R2 bucket being created. Events follow a consistent structure:
{
"type": "cf.r2.bucket.created",
"source": {
"type": "r2"
},
"payload": {
"name": "my-bucket",
"location": "WNAM"
},
"metadata": {
"accountId": "f9f79265f388666de8122cfb508d7776",
"eventTimestamp": "2025-07-28T10:30:00Z"
}
}Current event sources include R2, Workers KV, Workers AI, Workers Builds, Vectorize, Super Slurper, and Workflows. More sources and events are on the way.
For more information on event subscriptions, available events, and how to get started, refer to our documentation.
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.
Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues ↗ reported by the Cloudflare Community related to the v5 release. We have committed to releasing improvements on a two week cadence to ensure stability and reliability.
One key change we adopted in recent weeks is a pivot to more comprehensive, test-driven development. We are still evaluating individual issues, but are also investing in much deeper testing to drive our stabilization efforts. We will subsequently be investing in comprehensive migration scripts. As a result, you will see several of the highest traffic APIs have been stabilized in the most recent release, and are supported by comprehensive acceptance tests.
Thank you for continuing to raise issues. We triage them weekly and they help make our products stronger.
cloudflare_argo_smart_routingcloudflare_bot_managementcloudflare_listcloudflare_list_itemcloudflare_load_balancercloudflare_load_balancer_monitorcloudflare_load_balancer_poolcloudflare_spectrum_applicationcloudflare_managed_transformscloudflare_url_normalization_settingscloudflare_snippetcloudflare_snippet_rulescloudflare_zero_trust_access_applicationcloudflare_zero_trust_access_groupcloudflare_zero_trust_access_identity_providercloudflare_zero_trust_access_mtls_certificatecloudflare_zero_trust_access_mtls_hostname_settingscloudflare_zero_trust_access_policycloudflare_zonecloudflare_snippetcloudflare_bot_management diff issues resolves when running terraform plan and terraform applyFor a more detailed look at all of the changes, refer to the changelog ↗ in GitHub.
If you have an unaddressed issue with the provider, we encourage you to check the open issues ↗ and open a new one if one does not already exist for what you are experiencing.
We suggest holding off on migration to v5 while we work on stabilization. This will help you avoid any blocking issues while the Terraform resources are actively being stabilized.
If you'd like more information on migrating to v5, please make use of the migration guide ↗. We have provided automated migration scripts using Grit which simplify the transition. These migration scripts do not support implementations which use Terraform modules, so customers making use of modules need to migrate manually. Please make use of terraform plan to test your changes before applying, and let us know if you encounter any additional issues by reporting to our GitHub repository ↗.
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:
fs.globSync(...)) are not implemented.fs.watch(...)) are not implemented.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.
<branch-name>-<worker-name> → Uses actual branch name as is<truncated-branch-name>--<hash>-<worker-name> → Uses truncated name with 4-character hashWe 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:
secret_textA 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:
ArrayBuffer or MessagePort between ports.MessagePort is not yet serializable. This means that you cannot send a MessagePort object
through the postMessage method or via JSRPC calls.'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.'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:
New information about broadcast metrics and events is now available in Cloudflare Stream in the Live Input details of the Dashboard.
You can now easily understand broadcast-side health and performance with new observability, which can help when troubleshooting common issues, particularly for new customers who are just getting started, and platform customers who may have limited visibility into how their end-users configure their encoders.
To get started, start a live stream (just getting started?), then visit the Live Input details page in Dash.
See our new live Troubleshooting guide to learn what these metrics mean and how to use them to address common broadcast issues.