Changelog

Three new properties are now available on request.cf in Workers that expose Layer 4 transport telemetry from the client connection. These properties let your Worker make decisions based on real-time connection quality signals — such as round-trip time and data delivery rate — without requiring any client-side changes.

Previously, this telemetry was only available via the Server-Timing: cfL4 response header. These new properties surface the same data directly in the Workers runtime, so you can use it for routing, logging, or response customization.

export default {
  async fetch(request) {
    const cf = request.cf;

    const rtt = cf.clientTcpRtt ?? cf.clientQuicRtt ?? 0;
    const deliveryRate = cf.edgeL4?.deliveryRate ?? 0;
    const transport = cf.clientTcpRtt ? "TCP" : "QUIC";

    console.log(`Transport: ${transport}, RTT: ${rtt}ms, Delivery rate: ${deliveryRate} B/s`);

    const headers = new Headers(request.headers);
    headers.set("X-Client-RTT", String(rtt));
    headers.set("X-Delivery-Rate", String(deliveryRate));

    return fetch(new Request(request, { headers }));
  },
};

For more information, refer to Workers Runtime APIs: Request.

Four new fields are now available on request.cf.tlsClientAuth in Workers for requests that include a mutual TLS (mTLS) client certificate. These fields encode the client certificate and its intermediate chain in RFC 9440 ↗︎ format — the same standard format used by the Client-Cert and Client-Cert-Chain HTTP headers — so your Worker can forward them directly to your origin without any custom parsing or encoding logic.

export default {
  async fetch(request) {
    const tls = request.cf.tlsClientAuth;

    // Only forward if cert was verified and chain is complete
    if (!tls || !tls.certVerified || tls.certRevoked || tls.certChainRFC9440TooLarge) {
      return new Response("Unauthorized", { status: 401 });
    }

    const headers = new Headers(request.headers);
    headers.set("Client-Cert", tls.certRFC9440);
    headers.set("Client-Cert-Chain", tls.certChainRFC9440);

    return fetch(new Request(request, { headers }));
  },
};

For more information, refer to Client certificate variables and Mutual TLS authentication.

The new secrets configuration property lets you declare the secret names your Worker requires in your Wrangler configuration file. Required secrets are validated during local development and deploy, and used as the source of truth for type generation.

{
	"secrets": {
		"required": ["API_KEY", "DB_PASSWORD"],
	},
}

[secrets]
required = [ "API_KEY", "DB_PASSWORD" ]

When secrets is defined, wrangler dev and vite dev load only the keys listed in secrets.required from .dev.vars or .env/process.env. Additional keys in those files are excluded. If any required secrets are missing, a warning is logged listing the missing names.

wrangler types generates typed bindings from secrets.required instead of inferring names from .dev.vars or .env. This lets you run type generation in CI or other environments where those files are not present. Per-environment secrets are supported — the aggregated Env type marks secrets that only appear in some environments as optional.

wrangler deploy and wrangler versions upload validate that all secrets in secrets.required are configured on the Worker before the operation succeeds. If any required secrets are missing, the command fails with an error listing which secrets need to be set.

For more information, refer to the secrets configuration property reference.

Dynamic Workers are now in open beta ↗︎ for all paid Workers users. You can now have a Worker spin up other Workers, called Dynamic Workers, at runtime to execute code on-demand in a secure, sandboxed environment. Dynamic Workers start in milliseconds, making them well suited for fast, secure code execution at scale.

• Code Mode: LLMs are trained to write code. Run tool-calling logic written in code instead of stepping through many tool calls, which can save up to 80% in inference tokens and cost.
• AI agents executing code: Run code for tasks like data analysis, file transformation, API calls, and chained actions.
• Running AI-generated code: Run generated code for prototypes, projects, and automations in a secure, isolated sandboxed environment.
• Fast development and previews: Load prototypes, previews, and playgrounds in milliseconds.
• Custom automations: Create custom tools on the fly that execute a task, call an integration, or automate a workflow.

Dynamic Workers support two loading modes:

• load(code) — for one-time code execution (equivalent to calling get() with a null ID).
• get(id, callback) — caches a Dynamic Worker by ID so it can stay warm across requests. Use this when the same code will receive subsequent requests.

export default {
	async fetch(request, env) {
		const worker = env.LOADER.load({
			compatibilityDate: "2026-01-01",
			mainModule: "src/index.js",
			modules: {
				"src/index.js": `
					export default {
						fetch() {
							return new Response("Hello from a dynamic Worker");
						},
					};
				`,
			},
			// Block all outbound network access from the Dynamic Worker.
			globalOutbound: null,
		});

		return worker.getEntrypoint().fetch(request);
	},
};

export default {
	async fetch(request: Request, env: Env): Promise<Response> {
		const worker = env.LOADER.load({
			compatibilityDate: "2026-01-01",
			mainModule: "src/index.js",
			modules: {
				"src/index.js": `
					export default {
						fetch() {
							return new Response("Hello from a dynamic Worker");
						},
					};
				`,
			},
			// Block all outbound network access from the Dynamic Worker.
			globalOutbound: null,
		});

		return worker.getEntrypoint().fetch(request);
	},
};

Here are 3 new libraries to help you build with Dynamic Workers:

• @cloudflare/codemode ↗︎: Replace individual tool calls with a single code() tool, so LLMs write and execute TypeScript that orchestrates multiple API calls in one pass.

• @cloudflare/worker-bundler ↗︎: Resolve npm dependencies and bundle source files into ready-to-load modules for Dynamic Workers, all at runtime.

• @cloudflare/shell ↗︎: Give your agent a virtual filesystem inside a Dynamic Worker with persistent storage backed by SQLite and R2.

Dynamic Workers Starter

Use this starter ↗︎ to deploy a Worker that can load and execute Dynamic Workers.

Dynamic Workers Playground

Deploy the Dynamic Workers Playground ↗︎ to write or import code, bundle it at runtime with @cloudflare/worker-bundler, execute it through a Dynamic Worker, and see real-time responses and execution logs.

For the full API reference and configuration options, refer to the Dynamic Workers documentation.

Dynamic Workers pricing is based on three dimensions: Dynamic Workers created daily, requests, and CPU time.

¹ Uses Workers Standard rates and will appear as part of your existing Workers bill, not as separate Dynamic Workers charges.

Note: Dynamic Workers requests and CPU time are already billed as part of your Workers plan and will count toward your Workers requests and CPU usage. The Dynamic Workers created daily charge is not yet active — you will not be billed for the number of Dynamic Workers created at this time. Pricing information is shared in advance so you can estimate future costs.

In the Cloudflare One dashboard, the overview page for a specific Cloudflare Tunnel now shows all replicas of that tunnel and supports streaming logs from multiple replicas at once.

Previously, you could only stream logs from one replica at a time. With this update:

• Replicas on the tunnel overview — All active replicas for the selected tunnel now appear on that tunnel's overview page under Connectors. Select any replica to stream its logs.
• Multi-connector log streaming — Stream logs from multiple replicas simultaneously, making it easier to correlate events across your infrastructure during debugging or incident response. To try it out, log in to Cloudflare One ↗︎ and go to Networks > Connectors > Cloudflare Tunnels. Select View logs next to the tunnel you want to monitor.

For more information, refer to Tunnel log streams and Deploy replicas.

You can now manage Cloudflare Tunnels directly from Wrangler, the CLI for the Cloudflare Developer Platform. The new wrangler tunnel commands let you create, run, and manage tunnels without leaving your terminal.

Available commands:

• wrangler tunnel create — Create a new remotely managed tunnel.
• wrangler tunnel list — List all tunnels in your account.
• wrangler tunnel info — Display details about a specific tunnel.
• wrangler tunnel delete — Delete a tunnel.
• wrangler tunnel run — Run a tunnel using the cloudflared daemon.
• wrangler tunnel quick-start — Start a free, temporary tunnel without an account using Quick Tunnels.

Wrangler handles downloading and managing the cloudflared binary automatically. On first use, you will be prompted to download cloudflared to a local cache directory.

These commands are currently experimental and may change without notice.

To get started, refer to the Wrangler tunnel commands documentation.

You can now use a Workers binding to transform videos with Media Transformations. This allows you to resize, crop, extract frames, and extract audio from videos stored anywhere, even in private locations like R2 buckets.

The Media Transformations binding is useful when you want to:

• Transform videos stored in private or protected sources
• Optimize videos and store the output directly back to R2 for re-use
• Extract still frames for classification or description with Workers AI
• Extract audio tracks for transcription using Workers AI

To get started, add the Media binding to your Wrangler configuration:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "media": {
    "binding": "MEDIA"
  }
}

[media]
binding = "MEDIA"

Then use the binding in your Worker to transform videos:

export default {
	async fetch(request, env) {
		const video = await env.R2_BUCKET.get("input.mp4");

		const result = env.MEDIA.input(video.body)
			.transform({ width: 480, height: 270 })
			.output({ mode: "video", duration: "5s" });

		return await result.response();
	},
};

export default {
	async fetch(request, env) {
		const video = await env.R2_BUCKET.get("input.mp4");

		const result = env.MEDIA.input(video.body)
			.transform({ width: 480, height: 270 })
			.output({ mode: "video", duration: "5s" });

		return await result.response();
	},
};

Output modes include video for optimized MP4 clips, frame for still images, spritesheet for multiple frames, and audio for M4A extraction.

For more information, refer to the Media Transformations binding documentation.

Pywrangler ↗︎, the CLI tool for managing Python Workers and packages, now supports Windows, allowing you to develop and deploy Python Workers from Windows environments. Previously, Pywrangler was only available on macOS and Linux.

You can install and use Pywrangler on Windows the same way you would on other platforms. Specify your Worker's Python dependencies in your pyproject.toml file, then use the following commands to develop and deploy:

uvx --from workers-py pywrangler dev
uvx --from workers-py pywrangler deploy

All existing Pywrangler functionality, including package management, local development, and deployment, works on Windows without any additional configuration.

This feature requires the following minimum versions:

• wrangler >= 4.64.0
• workers-py >= 1.72.0
• uv >= 0.9.28

To upgrade workers-py (which includes Pywrangler) in your project, run:

uv tool upgrade workers-py

To upgrade wrangler, run:

npm install -g wrangler@latest

To upgrade uv, run:

uv self update

To get started with Python Workers on Windows, refer to the Python packages documentation for full details on Pywrangler.

Workers Observability now includes a query language that lets you write structured queries directly in the search bar to filter your logs and traces. The search bar doubles as a free text search box — type any term to search across all metadata and attributes, or write field-level queries for precise filtering.

Queries written in the search bar sync with the Query Builder sidebar, so you can write a query by hand and then refine it visually, or build filters in the Query Builder and see the corresponding query syntax. The search bar provides autocomplete suggestions for metadata fields and operators as you type.

The query language supports:

• Free text search — search everywhere with a keyword like error, or match an exact phrase with "exact phrase"
• Field queries — filter by specific fields using comparison operators (for example, status = 500 or $workers.wallTimeMs > 100)
• Operators — =, !=, >, >=, <, <=, and : (contains)
• Functions — contains(field, value), startsWith(field, prefix), regex(field, pattern), and exists(field)
• Boolean logic — add conditions with AND, OR, and NOT

Select the help icon next to the search bar to view the full syntax reference, including all supported operators, functions, and keyboard shortcuts.

Go to the Workers Observability dashboard ↗︎ to try the query language.

You can now deploy any existing project to Cloudflare Workers — even without a Wrangler configuration file — and wrangler deploy will just work.

Starting with Wrangler 4.68.0, running wrangler deploy automatically configures your project by detecting your framework, installing required adapters, and deploying it to Cloudflare Workers.

npx wrangler deploy

When you run wrangler deploy in a project without a configuration file, Wrangler:

1. Detects your framework from package.json
2. Prompts you to confirm the detected settings
3. Installs any required adapters
4. Generates a wrangler.jsonc configuration file
5. Deploys your project to Cloudflare Workers

You can also use wrangler setup to configure without deploying, or pass --yes to skip prompts.

When you connect a repository through the Workers dashboard ↗︎, a pull request is generated for you with all necessary files, and a preview deployment to check before merging.

In December 2025, we introduced automatic configuration as an experimental feature. It is now generally available and the default behavior.

If you have questions or run into issues, join the GitHub discussion ↗︎.

You can now disable a live input to reject incoming RTMPS and SRT connections. When a live input is disabled, any broadcast attempts will fail to connect.

This gives you more control over your live inputs:

• Temporarily pause an input without deleting it
• Programmatically end creator broadcasts
• Prevent new broadcasts from starting on a specific input

To disable a live input via the API, set the enabled property to false:

curl --request PUT \
https://api.cloudflare.com/client/v4/accounts/{account_id}/stream/live_inputs/{input_id} \
--header "Authorization: Bearer <API_TOKEN>" \
--data '{"enabled": false}'

You can also disable or enable a live input from the Live inputs list page or the live input detail page in the Dashboard.

All existing live inputs remain enabled by default. For more information, refer to Start a live stream.

Cloudflare Tunnel is now available in the main Cloudflare Dashboard at Networking > Tunnels ↗︎, bringing first-class Tunnel management to developers using Tunnel for securing origin servers.

This new experience provides everything you need to manage Tunnels for public applications, including:

• Full Tunnel lifecycle management: Create, configure, delete, and monitor all your Tunnels in one place.
• Native integrations: View Tunnels by name when configuring DNS records and Workers VPC — no more copy-pasting UUIDs.
• Real-time visibility: Monitor replicas and Tunnel health status directly in the dashboard.
• Routing map: Manage all ingress routes for your Tunnel, including public applications, private hostnames, private CIDRs, and Workers VPC services, from a single interactive interface.

Core Dashboard: Navigate to Networking > Tunnels ↗︎ to manage Tunnels for:

• Securing origin servers and public applications with CDN, WAF, Load Balancing, and DDoS protection
• Connecting Workers to private services via Workers VPC

Cloudflare One Dashboard: Navigate to Zero Trust > Networks > Connectors ↗︎ to manage Tunnels for:

• Securing your public applications with Zero Trust access policies
• Connecting users to private applications
• Building a private mesh network

Both dashboards provide complete Tunnel management capabilities — choose based on your primary workflow.

New to Tunnel? Learn how to get started with Cloudflare Tunnel or explore advanced use cases like securing SSH servers or running Tunnels in Kubernetes.

Cloudflare has deprecated the Workers Quick Editor dev tools inspector and replaced it with a lightweight log viewer.

This aligns our logging with wrangler tail and gives us the opportunity to focus our efforts on bringing benefits from the work we have invested in observability, which would not be possible otherwise.

We have made improvements to this logging viewer based on your feedback such that you can log object and array types, and easily clear the list of logs. This does not include class instances. Limitations are documented in the Workers Playground docs.

If you do need to develop your Worker with a remote inspector, you can still do this using Wrangler locally. Cloning a project from your quick editor to your computer for local development can be done with the wrangler init --from-dash command. For more information, refer to Wrangler commands.

A new Workers Best Practices guide provides opinionated recommendations for building fast, reliable, observable, and secure Workers. The guide draws on production patterns, Cloudflare internal usage, and best practices observed from developers building on Workers.

Key guidance includes:

• Keep your compatibility date current and enable nodejs_compat — Ensure you have access to the latest runtime features and Node.js built-in modules.

{
	"name": "my-worker",
	"main": "src/index.ts",
	// Set this to today's date
	"compatibility_date": "2026-10-11",
	"compatibility_flags": ["nodejs_compat"],
}

name = "my-worker"
main = "src/index.ts"
# Set this to today's date
compatibility_date = "2026-10-11"
compatibility_flags = [ "nodejs_compat" ]

• Generate binding types with wrangler types — Never hand-write your Env interface. Let Wrangler generate it from your actual configuration to catch mismatches at compile time.
• Stream request and response bodies — Avoid buffering large payloads in memory. Use TransformStream and pipeTo to stay within the 128 MB memory limit and improve time-to-first-byte.
• Use bindings, not REST APIs — Bindings to KV, R2, D1, Queues, and other Cloudflare services are direct, in-process references with no network hop and no authentication overhead.
• Use Queues and Workflows for background work — Move long-running or retriable tasks out of the critical request path. Use Queues for simple fan-out and buffering, and Workflows for multi-step durable processes.
• Enable Workers Logs and Traces — Configure observability before deploying to production so you have data when you need to debug.
• Avoid global mutable state — Workers reuse isolates across requests. Storing request-scoped data in module-level variables causes cross-request data leaks.
• Always await or waitUntil your Promises — Floating promises cause silent bugs and dropped work.
• Use Web Crypto for secure token generation — Never use Math.random() for security-sensitive operations.

To learn more, refer to Workers Best Practices.

Workers no longer have a limit of 1000 subrequests per invocation, allowing you to make more fetch() calls or requests to Cloudflare services on every incoming request. This is especially important for long-running Workers requests, such as open websockets on Durable Objects or long-running Workflows, as these could often exceed this limit and error.

By default, Workers on paid plans are now limited to 10,000 subrequests per invocation, but this limit can be increased up to 10 million by setting the new subrequests limit in your Wrangler configuration file.

{
	"limits": {
		"subrequests": 50000,
	},
}

[limits]
subrequests = 50_000

Workers on the free plan remain limited to 50 external subrequests and 1000 subrequests to Cloudflare services per invocation.

To protect against runaway code or unexpected costs, you can also set a lower limit for both subrequests and CPU usage.

{
	"limits": {
		"subrequests": 10,
		"cpu_ms": 1000,
	},
}

[limits]
subrequests = 10
cpu_ms = 1_000

For more information, refer to the Wrangler configuration documentation for limits and subrequest limits.

The Cloudflare Vite plugin now integrates seamlessly @vitejs/plugin-rsc ↗︎, the official Vite plugin for React Server Components ↗︎.

A childEnvironments option has been added to the plugin config to enable using multiple environments within a single Worker. The parent environment can then import modules from a child environment in order to access a separate module graph. For a typical RSC use case, the plugin might be configured as in the following example:

export default defineConfig({
	plugins: [
		cloudflare({
			viteEnvironment: {
				name: "rsc",
				childEnvironments: ["ssr"],
			},
		}),
	],
});

@vitejs/plugin-rsc provides the lower level functionality that frameworks, such as React Router ↗︎, build upon. The GitHub repository includes a basic Cloudflare example ↗︎.

The Workers Observability dashboard ↗︎ has some major updates to make it easier to debug your application's issues and share findings with your team.

You can now:

• Create visualizations — Build charts from your Worker data directly in a Worker's Observability tab
• Export data as JSON or CSV — Download logs and traces for offline analysis or to share with teammates
• Share events and traces — Generate direct URLs to specific events, invocations, and traces that open standalone pages with full context
• Customize table columns — Improved field picker to add, remove, and reorder columns in the events table
• Expandable event details — Expand events inline to view full details without leaving the table
• Keyboard shortcuts — Navigate the dashboard with hotkey support

These updates are now live in the Cloudflare dashboard, both in a Worker's Observability tab and in the account-level Observability dashboard for a unified experience. To get started, go to Workers & Pages > select your Worker > Observability.

You can now configure Workers to run close to infrastructure in legacy cloud regions to minimize latency to existing services and databases. This is most useful when your Worker makes multiple round trips.

To set a placement hint, set the placement.region property in your Wrangler configuration file:

{
	"placement": {
		"region": "aws:us-east-1",
	},
}

[placement]
region = "aws:us-east-1"

Placement hints support Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure region identifiers. Workers run in the Cloudflare data center ↗︎ with the lowest latency to the specified cloud region.

If your existing infrastructure is not in these cloud providers, expose it to placement probes with placement.host for layer 4 checks or placement.hostname for layer 7 checks. These probes are designed to locate single-homed infrastructure and are not suitable for anycasted or multicasted resources.

{
	"placement": {
		"host": "my_database_host.com:5432",
	},
}

[placement]
host = "my_database_host.com:5432"

{
	"placement": {
		"hostname": "my_api_server.com",
	},
}

[placement]
hostname = "my_api_server.com"

This is an extension of Smart Placement, which automatically places your Workers closer to back-end APIs based on measured latency. When you do not know the location of your back-end APIs or have multiple back-end APIs, set mode: "smart":

{
	"placement": {
		"mode": "smart",
	},
}

[placement]
mode = "smart"

Auxiliary Workers are now fully supported when using full-stack frameworks, such as React Router and TanStack Start, that integrate with the Cloudflare Vite plugin. They are included alongside the framework's build output in the build output directory. Note that this feature requires Vite 7 or above.

Auxiliary Workers are additional Workers that can be called via service bindings from your main (entry) Worker. They are defined in the plugin config, as in the example below:

import { defineConfig } from "vite";
import { tanstackStart } from "@tanstack/react-start/plugin/vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
	plugins: [
		tanstackStart(),
		cloudflare({
			viteEnvironment: { name: "ssr" },
			auxiliaryWorkers: [{ configPath: "./wrangler.aux.jsonc" }],
		}),
	],
});

See the Vite plugin API docs for more info.

The .sql file extension is now automatically configured to be importable in your Worker code when using Wrangler or the Cloudflare Vite plugin. This is particular useful for importing migrations in Durable Objects and means you no longer need to configure custom rules when using Drizzle ↗︎.

SQL files are imported as JavaScript strings:

// `example` will be a JavaScript string
import example from "./example.sql";

We have made it easier to validate connectivity when deploying WARP Connector as part of your software-defined private network.

You can now ping the WARP Connector host directly on its LAN IP address immediately after installation. This provides a fast, familiar way to confirm that the Connector is online and reachable within your network before testing access to downstream services.

Starting with version 2025.10.186.0, WARP Connector responds to traffic addressed to its own LAN IP, giving you immediate visibility into Connector reachability.

Learn more about deploying WARP Connector and building private network connectivity with Cloudflare One.

The wrangler types command now generates TypeScript types for bindings from all environments defined in your Wrangler configuration file by default.

Previously, wrangler types only generated types for bindings in the top-level configuration (or a single environment when using the --env flag). This meant that if you had environment-specific bindings — for example, a KV namespace only in production or an R2 bucket only in staging — those bindings would be missing from your generated types, causing TypeScript errors when accessing them.

Now, running wrangler types collects bindings from all environments and includes them in the generated Env type. This ensures your types are complete regardless of which environment you deploy to.

If you want the previous behavior of generating types for only a specific environment, you can use the --env flag:

wrangler types --env production

Learn more about generating types for your Worker in the Wrangler documentation.

Wrangler now supports a --check flag for the wrangler types command. This flag validates that your generated types are up to date without writing any changes to disk.

This is useful in CI/CD pipelines where you want to ensure that developers have regenerated their types after making changes to their Wrangler configuration. If the types are out of date, the command will exit with a non-zero status code.

npx wrangler types --check

If your types are up to date, the command will succeed silently. If they are out of date, you'll see an error message indicating which files need to be regenerated.

For more information, see the Wrangler types documentation.

You can now receive notifications when your Workers' builds start, succeed, fail, or get cancelled using Event Subscriptions.

Workers Builds publishes events to a Queue that your Worker can read messages from, and then send notifications wherever you need — Slack, Discord, email, or any webhook endpoint.

You can deploy this Worker ↗︎ to your own Cloudflare account to send build notifications to Slack:

The template includes:

• Build status with Preview/Live URLs for successful deployments
• Inline error messages for failed builds
• Branch, commit hash, and author name

For setup instructions, refer to the template README ↗︎ or the Event Subscriptions documentation.

Wrangler now includes built-in shell tab completion support, making it faster and easier to navigate commands without memorizing every option. Press Tab as you type to autocomplete commands, subcommands, flags, and even option values like log levels.

Tab completions are supported for Bash, Zsh, Fish, and PowerShell.

Generate the completion script for your shell and add it to your configuration file:

# Bash
wrangler complete bash >> ~/.bashrc

# Zsh
wrangler complete zsh >> ~/.zshrc

# Fish
wrangler complete fish >> ~/.config/fish/config.fish

# PowerShell
wrangler complete powershell >> $PROFILE

After adding the script, restart your terminal or source your configuration file for the changes to take effect. Then you can simply press Tab to see available completions:

wrangler d<TAB>          # completes to 'deploy', 'dev', 'd1', etc.
wrangler kv <TAB>        # shows subcommands: namespace, key, bulk

Tab completions are dynamically generated from Wrangler's command registry, so they stay up-to-date as new commands and options are added. This feature is powered by @bomb.sh/tab ↗︎.

See the wrangler complete documentation for more details.