Developer Platform Updates & Release Notes

You can now upload Workers with static assets (like HTML, CSS, JavaScript, images) with the Cloudflare Terraform provider v5.11.0 ↗︎, making it even easier to deploy and manage full-stack apps with IaC.

Previously, you couldn't use Terraform to upload static assets without writing custom scripts to handle generating an asset manifest, calling the Cloudflare API to upload assets in chunks, and handling change detection.

Now, you simply define the directory where your assets are built, and we handle the rest. Check out the examples for what this looks like in Terraform configuration.

You can get started today with the Cloudflare Terraform provider (v5.11.0) ↗︎, using either the existing cloudflare_workers_script resource ↗︎, or the beta cloudflare_worker_version resource ↗︎.

Examples

…

You can now create and manage Workflows using Terraform, now supported in the Cloudflare Terraform provider v5.11.0 ↗︎. Workflows allow you to build durable, multi-step applications -- without needing to worry about retrying failed tasks or managing infrastructure.

Now, you can deploy and manage Workflows through Terraform using the new cloudflare_workflow resource ↗︎:

resource "cloudflare_workflow" "my_workflow" {
  account_id    = var.account_id
  workflow_name = "my-workflow"
  class_name    = "MyWorkflow"
  script_name   = "my-worker"
}

Examples

Here are full examples of how to configure cloudflare_workflow in Terraform, using the existing cloudflare_workers_script resource ↗︎, and the beta cloudflare_worker_version resource ↗︎.

With cloudflare_workflow and cloudflare_workers_script

resource "cloudflare_workers_script" "workflow_worker" {
  account_id  = var.cloudflare_account_id
  script_name = "my-workflow-worker" …

Screenshot of the Workers overview page in the Cloudflare dashboard

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 compaction for individual Apache Iceberg ↗︎ tables in R2 Data Catalog, giving you fine-grained control over different workloads.

# Enable compaction for a specific table (no token required)
npx wrangler r2 bucket catalog compaction enable <BUCKET> <NAMESPACE> <TABLE> --target-size 256

This allows you to:

• Apply different target file sizes per table
• Disable compaction for specific tables
• Optimize based on table-specific access patterns

Learn more at Manage catalogs.

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

Screenshot of the Enable/Disable Cloudflare Access button on the workers.dev route settings page

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. …

Deepgram's newest Flux model @cf/deepgram/flux is now available on Workers AI, hosted directly on Cloudflare's infrastructure. We're excited to be a launch partner with Deepgram and offer their new Speech Recognition model built specifically for enabling voice agents. Check out Deepgram's blog ↗︎ for more details on the release.

The Flux model can be used in conjunction with Deepgram's speech-to-text model @cf/deepgram/nova-3 and text-to-speech model @cf/deepgram/aura-1 to build end-to-end voice agents. Having Deepgram on Workers AI takes advantage of our edge GPU infrastructure, for ultra low latency voice AI applications.

Promotional Pricing

For the month of October 2025, Deepgram's Flux model will be free to use on Workers AI. Official pricing will be announced soon and charged after the promotional pricing period ends on October 31, 2025. Check out the model page for pricing details in the future.

Example Usage

The new Flux model is WebSocket only as it requires live bi-directional streaming in order to recognize speech activity.

1. Create a worker that establishes a websocket connection with @cf/deepgram/flux

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 …

New instance types provide up to 4 vCPU, 12 GiB of memory, and 20 GB of disk per container instance.

Instance Type

vCPU

Memory

Disk

lite

1/16

256 MiB

2 GB

basic

1/4

1 GiB

4 GB

standard-1

1/2

4 GiB

8 GB

standard-2

1

6 GiB

12 GB

standard-3

2

8 GiB

16 GB

standard-4

4

12 GiB

20 GB

The dev and standard instance types are preserved for backward compatibility and are aliases for lite and standard-1, respectively. The standard-1 instance type now provides up to 8 GB of disk instead of only 4 GB.

See the getting started guide to deploy your first Container, and the limits documentation for more details on the available instance types and limits.

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. …

Today, we are launching the new Cloudflare Pipelines: a streaming data platform that ingests events, transforms them with SQL, and writes to R2 as Apache Iceberg ↗︎ tables or Parquet files.

Pipelines can receive events via HTTP endpoints or Worker bindings, transform them with SQL, and deliver to R2 with exactly-once guarantees. This makes it easy to build analytics-ready warehouses for server logs, mobile application events, IoT telemetry, or clickstream data without managing streaming infrastructure.

For example, here is a pipeline that ingests clickstream events and filters out bot traffic while extracting domain information:

INSERT into events_table
SELECT
  user_id,
  lower(event) AS event_type,
  to_timestamp_micros(ts_us) AS event_time,
  regexp_match(url, '^https?://([^/]+)')[1]  AS domain,
  url,
  referrer,
  user_agent
FROM events_json
WHERE event = 'page_view'
  AND NOT regexp_like(user_agent, '(?i)bot|spider');
``` …

Today, we are launching the open beta for R2 SQL: A serverless, distributed query engine that can efficiently analyze petabytes of data in Apache Iceberg ↗︎ tables managed by R2 Data Catalog.

R2 SQL is ideal for exploring analytical and time-series data stored in R2, such as logs, events from Pipelines, or clickstream and user behavior data.

If you already have a table in R2 Data Catalog, running queries is as simple as:

npx wrangler r2 sql query YOUR_WAREHOUSE "
SELECT
    user_id,
    event_type,
    value
FROM events.user_events
WHERE event_type = 'CHANGELOG' or event_type = 'BLOG'
  AND __ingest_ts > '2025-09-24T00:00:00Z'
ORDER BY __ingest_ts DESC
LIMIT 100"

To get started with R2 SQL, check out our getting started guide or learn more about supported features in the SQL reference. For a technical deep dive into how we built R2 SQL, read our blog post ↗︎.

We’re shipping three updates to Browser Rendering:

• Playwright support is now Generally Available and synced with Playwright v1.55 ↗︎, giving you a stable foundation for critical automation and AI-agent workflows.
• We’re also adding Stagehand support (Beta) so you can combine code with natural language instructions to build more resilient automations.
• Finally, we’ve tripled limits for paid plans across both the REST API and Browser Sessions to help you scale.

To get started with Stagehand, refer to the Stagehand example that uses Stagehand and Workers AI to search for a movie on this example movie directory ↗︎, extract its details using natural language (title, year, rating, duration, and genre), and return the information along with a screenshot of the webpage.

Stagehand examplets

const stagehand = new Stagehand({
	env: "LOCAL",
	localBrowserLaunchOptions: { cdpUrl: endpointURLString(env.BROWSER) },
	llmClient: new WorkersAIClient(env.AI),
	verbose: 1,
});

await stagehand.init(); …

AutoRAG is now AI Search! The new name marks a new and bigger mission: to make world-class search infrastructure available to every developer and business.

With AI Search you can now use models from different providers like OpenAI and Anthropic. By attaching your provider keys to the AI Gateway linked to your AI Search instance, you can use many more models for both embedding and inference.

To use AI Search with other model providers:

1. Add provider keys to AI Gateway
   1. Go to AI > AI Gateway in the dashboard.
   2. Select or create an AI gateway.
   3. In Provider Keys, choose your provider, click Add, and enter the key.
2. Connect a gateway to AI Search: When creating a new AI Search, select the AI Gateway with your provider keys. For an existing AI Search, go to Settings and switch to a gateway that has your keys under Resources.
3. Select models: Embedding models are only available to be changed when creating a new AI Search. Generation model can be selected when creating a new AI Search and can be changed at any time in Settings.

Once configured, your AI Search instance will be able to reference models available through your AI Gateway when making a /ai-search request:

export default {
  async fetch(request, env) {
    
    // Query your AI Search instance with a natural language question to an OpenAI model …

You can now enable automatic compaction for Apache Iceberg ↗︎ tables in R2 Data Catalog to improve query performance.

Compaction is the process of taking a group of small files and combining them into fewer larger files. This is an important maintenance operation as it helps ensure that query performance remains consistent by reducing the number of files that needs to be scanned.

To enable automatic compaction in R2 Data Catalog, find it under R2 Data Catalog in your R2 bucket settings in the dashboard.

compaction-dash

Or with Wrangler, run:

npx wrangler r2 bucket catalog compaction enable <BUCKET_NAME>  --target-size 128 --token <API_TOKEN>

To get started with compaction, check out manage catalogs. For best practices and limitations, refer to about compaction.

You can now run more Containers concurrently with higher limits on CPU, memory, and disk.

Limit

New Limit

Previous Limit

Memory for concurrent live Container instances

400GiB

40GiB

vCPU for concurrent live Container instances

100

20

Disk for concurrent live Container instances

2TB

100GB

You can now run 1000 instances of the dev instance type, 400 instances of basic, or 100 instances of standard concurrently.

This opens up new possibilities for running larger-scale workloads on Containers.

See the getting started guide to deploy your first Container, and the limits documentation for more details on the available instance types and limits.

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.

./api/src/index.tsjs

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 });
	},
};
``` …

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.

./api/src/index.tsjs

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 });
	},
};
``` …

AutoRAG now includes a Metrics tab that shows how your data is indexed and searched. Get a clear view of the health of your indexing pipeline, compare usage between ai-search and search, and see which files are retrieved most often.

Metrics

You can find these metrics within each AutoRAG instance:

• Indexing: Track how files are ingested and see status changes over time.
• Search breakdown: Compare usage between ai-search and search endpoints.
• Top file retrievals: Identify which files are most frequently retrieved in a given period.

Try it today in AutoRAG.

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.

Fixing Rust Panics with Wasm Bindgen

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

We now attach a default panic handler in Rust:

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.

Resetting VM State in Wasm Bindgen

…