Changelog

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.

By setting the value of the cache property to no-cache, you can force Cloudflare's cache to revalidate its contents with the origin when making subrequests from Cloudflare Workers.

export default {
	async fetch(req, env, ctx) {
		const request = new Request("https://cloudflare.com", {
			cache: "no-cache",
		});
		const response = await fetch(request);
		return response;
	},
};

export default {
  async fetch(req, env, ctx): Promise<Response> {
		const request = new Request("https://cloudflare.com", { cache: 'no-cache'});
		const response = await fetch(request);
    return response;
  }
} satisfies ExportedHandler<Environment>

When no-cache is set, the Worker request will first look for a match in Cloudflare's cache, then:

• If there is a match, a conditional request is sent to the origin, regardless of whether or not the match is fresh or stale. If the resource has not changed, the cached version is returned. If the resource has changed, it will be downloaded from the origin, updated in the cache, and returned.
• If there is no match, Workers will make a standard request to the origin and cache the response.

This increases compatibility with NPM packages and JavaScript frameworks that rely on setting the cache property, which is a cross-platform standard part of the Request interface. Previously, if you set the cache property on Request to 'no-cache', the Workers runtime threw an exception.

• Learn how the Cache works with Cloudflare Workers
• Enable Node.js compatibility for your Cloudflare Worker
• Explore Runtime APIs and Bindings available in Cloudflare Workers

The latest releases of @cloudflare/agents ↗ brings major improvements to MCP transport protocols support and agents connectivity. Key updates include:

MCP servers can now request user input during tool execution, enabling interactive workflows like confirmations, forms, and multi-step processes. This feature uses durable storage to preserve elicitation state even during agent hibernation, ensuring seamless user interactions across agent lifecycle events.

// Request user confirmation via elicitation
const confirmation = await this.elicitInput({
	message: `Are you sure you want to increment the counter by ${amount}?`,
	requestedSchema: {
		type: "object",
		properties: {
			confirmed: {
				type: "boolean",
				title: "Confirm increment",
				description: "Check to confirm the increment",
			},
		},
		required: ["confirmed"],
	},
});

Check out our demo ↗ to see elicitation in action.

MCP now supports HTTP streamable transport which is recommended over SSE. This transport type offers:

• Better performance: More efficient data streaming and reduced overhead
• Improved reliability: Enhanced connection stability and error recover- Automatic fallback: If streamable transport is not available, it gracefully falls back to SSE

export default MyMCP.serve("/mcp", {
	binding: "MyMCP",
});

The SDK automatically selects the best available transport method, gracefully falling back from streamable-http to SSE when needed.

Significant improvements to MCP server connections and transport reliability:

• Auto transport selection: Automatically determines the best transport method, falling back from streamable-http to SSE as needed
• Improved error handling: Better connection state management and error reporting for MCP servers
• Reliable prop updates: Centralized agent property updates ensure consistency across different contexts

You can use .queue() to enqueue background work — ideal for tasks like processing user messages, sending notifications etc.

class MyAgent extends Agent {
	doSomethingExpensive(payload) {
		// a long running process that you want to run in the background
	}

	queueSomething() {
		await this.queue("doSomethingExpensive", somePayload); // this will NOT block further execution, and runs in the background
		await this.queue("doSomethingExpensive", someOtherPayload); // the callback will NOT run until the previous callback is complete
		// ... call as many times as you want
	}
}

Want to try it yourself? Just define a method like processMessage in your agent, and you’re ready to scale.

Want to build an AI agent that can receive and respond to emails automatically? With the new email adapter and onEmail lifecycle method, now you can.

export class EmailAgent extends Agent {
	async onEmail(email: AgentEmail) {
		const raw = await email.getRaw();
		const parsed = await PostalMime.parse(raw);

		// create a response based on the email contents
		// and then send a reply

		await this.replyToEmail(email, {
			fromName: "Email Agent",
			body: `Thanks for your email! You've sent us "${parsed.subject}". We'll process it shortly.`,
		});
	}
}

You route incoming mail like this:

export default {
	async email(email, env) {
		await routeAgentEmail(email, env, {
			resolver: createAddressBasedEmailResolver("EmailAgent"),
		});
	},
};

You can find a full example here ↗.

Custom methods are now automatically wrapped with the agent's context, so calling getCurrentAgent() should work regardless of where in an agent's lifecycle it's called. Previously this would not work on RPC calls, but now just works out of the box.

export class MyAgent extends Agent {
	async suggestReply(message) {
		// getCurrentAgent() now correctly works, even when called inside an RPC method
		const { agent } = getCurrentAgent()!;
		return generateText({
			prompt: `Suggest a reply to: "${message}" from "${agent.name}"`,
			tools: [replyWithEmoji],
		});
	}
}

Try it out and tell us what you build!

We’ve shipped a major release for the @cloudflare/sandbox ↗ SDK, turning it into a full-featured, container-based execution platform that runs securely on Cloudflare Workers.

This update adds live streaming of output, persistent Python and JavaScript code interpreters with rich output support (charts, tables, HTML, JSON), file system access, Git operations, full background process control, and the ability to expose running services via public URLs.

This makes it ideal for building AI agents, CI runners, cloud REPLs, data analysis pipelines, or full developer tools — all without managing infrastructure.

Create persistent code contexts with support for rich visual + structured outputs.

Creates a new code execution context with persistent state.

// Create a Python context
const pythonCtx = await sandbox.createCodeContext({ language: "python" });

// Create a JavaScript context
const jsCtx = await sandbox.createCodeContext({ language: "javascript" });

Options:

• language: Programming language ('python' | 'javascript' | 'typescript')
• cwd: Working directory (default: /workspace)
• envVars: Environment variables for the context

Executes code with optional streaming callbacks.

// Simple execution
const execution = await sandbox.runCode('print("Hello World")', {
	context: pythonCtx,
});

// With streaming callbacks
await sandbox.runCode(
	`
for i in range(5):
    print(f"Step {i}")
    time.sleep(1)
`,
	{
		context: pythonCtx,
		onStdout: (output) => console.log("Real-time:", output.text),
		onResult: (result) => console.log("Result:", result),
	},
);

Options:

• language: Programming language ('python' | 'javascript' | 'typescript')
• cwd: Working directory (default: /workspace)
• envVars: Environment variables for the context

Returns a streaming response for real-time processing.

const stream = await sandbox.runCodeStream(
	"import time; [print(i) for i in range(10)]",
);
// Process the stream as needed

Interpreter outputs are auto-formatted and returned in multiple formats:

• text
• html (e.g., Pandas tables)
• png, svg (e.g., Matplotlib charts)
• json (structured data)
• chart (parsed visualizations)

const result = await sandbox.runCode(
	`
import seaborn as sns
import matplotlib.pyplot as plt

data = sns.load_dataset("flights")
pivot = data.pivot("month", "year", "passengers")
sns.heatmap(pivot, annot=True, fmt="d")
plt.title("Flight Passengers")
plt.show()

pivot.to_dict()
`,
	{ context: pythonCtx },
);

if (result.png) {
	console.log("Chart output:", result.png);
}

Start background processes and expose them with live URLs.

await sandbox.startProcess("python -m http.server 8000");
const preview = await sandbox.exposePort(8000);

console.log("Live preview at:", preview.url);

Start, inspect, and terminate long-running background processes.

const process = await sandbox.startProcess("node server.js");
console.log(`Started process ${process.id} with PID ${process.pid}`);

// Monitor the process
const logStream = await sandbox.streamProcessLogs(process.id);
for await (const log of parseSSEStream<LogEvent>(logStream)) {
	console.log(`Server: ${log.data}`);
}

• listProcesses() - List all running processes
• getProcess(id) - Get detailed process status
• killProcess(id, signal) - Terminate specific processes
• killAllProcesses() - Kill all processes
• streamProcessLogs(id, options) - Stream logs from running processes
• getProcessLogs(id) - Get accumulated process output

Clone Git repositories directly into the sandbox.

await sandbox.gitCheckout("https://github.com/user/repo", {
	branch: "main",
	targetDir: "my-project",
});

Sandboxes are still experimental. We're using them to explore how isolated, container-like workloads might scale on Cloudflare — and to help define the developer experience around them.

We're thrilled to be a Day 0 partner with OpenAI ↗ to bring their latest open models ↗ to Workers AI, including support for Responses API, Code Interpreter, and Web Search (coming soon).

Get started with the new models at @cf/openai/gpt-oss-120b and @cf/openai/gpt-oss-20b. Check out the blog ↗ for more details about the new models, and the gpt-oss-120b and gpt-oss-20b model pages for more information about pricing and context windows.

If you call the model through:

• Workers Binding, it will accept/return Responses API – env.AI.run(“@cf/openai/gpt-oss-120b”)
• REST API on /run endpoint, it will accept/return Responses API – https://api.cloudflare.com/client/v4/accounts/<account_id>/ai/run/@cf/openai/gpt-oss-120b
• REST API on new /responses endpoint, it will accept/return Responses API – https://api.cloudflare.com/client/v4/accounts/<account_id>/ai/v1/responses
• REST API for OpenAI Compatible endpoint, it will return Chat Completions (coming soon) – https://api.cloudflare.com/client/v4/accounts/<account_id>/ai/v1/chat/completions

curl https://api.cloudflare.com/client/v4/accounts/<account_id>/ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $CLOUDFLARE_API_KEY" \
  -d '{
    "model": "@cf/openai/gpt-oss-120b",
    "reasoning": {"effort": "medium"},
    "input": [
      {
        "role": "user",
        "content": "What are the benefits of open-source models?"
      }
    ]
  }'

The model is natively trained to support stateful code execution, and we've implemented support for this feature using our Sandbox SDK ↗ and Containers ↗. Cloudflare's Developer Platform is uniquely positioned to support this feature, so we're very excited to bring our products together to support this new use case.

We are working to implement Web Search for the model, where users can bring their own Exa API Key so the model can browse the Internet.

As part of the ongoing open beta for Workers Builds, we’ve increased the available disk space for builds from 8 GB to 20 GB for both Free and Paid plans.

This provides more space for larger projects, dependencies, and build artifacts while improving overall build reliability.

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

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 cadeance to ensure it's stability and reliability. 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.

• Resources stabilized:
  • cloudflare_custom_pages
  • cloudflare_page_rule
  • cloudflare_dns_record
  • cloudflare_argo_tiered_caching
• Addressed chronic drift issues in cloudflare_logpush_job, cloudflare_zero_trust_dns_location, cloudflare_ruleset & cloudflare_api_token
• cloudflare_zone_subscription returns expected values rate_plan.id from former versions
• cloudflare_workers_script can now successfully be destroyed with bindings & migration for Durable Objects now recorded in tfstate
• Ability to configure add_headers under cloudflare_zero_trust_gateway_policy
• Other bug fixes

For a more detailed look at all of the changes, see the changelog ↗ in GitHub.

• #5666: cloudflare_ruleset example lists id which is a read-only field ↗
• #5578: cloudflare_logpush_job plan always suggests changes ↗
• #5552: 5.4.0: Since provider update, existing cloudflare_list_item would be recreated "created" state ↗
• #5670: cloudflare_zone_subscription: uses wrong ID field in Read/Update ↗
• #5548: cloudflare_api_token resource always shows changes (drift) ↗
• #5634: cloudflare_workers_script with bindings fails to be destroyed ↗
• #5616: cloudflare_workers_script Unable to deploy worker assets ↗
• #5331: cloudflare_workers_script 500 internal server error when uploading python ↗
• #5701: cloudflare_workers_script migrations for Durable Objects not recorded in tfstate; cannot be upgraded between versions ↗
• #5704: cloudflare_workers_script randomly fails to deploy when changing compatibility_date ↗
• #5439: cloudflare_workers_script (v5.2.0) ignoring content and bindings properties ↗
• #5522: cloudflare_workers_script always detects changes after apply ↗
• #5693: cloudflare_zero_trust_access_identity_provider gives recurring change on OTP pin login ↗
• #5567: cloudflare_r2_custom_domain doesn't roundtrip jurisdiction properly ↗
• #5179: Bad request with when creating cloudflare_api_shield_schema resource ↗

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 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, although 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 ↗.

• Terraform provider ↗
• Documentation on using Terraform with Cloudflare

You can now configure and run Containers alongside your Worker during local development when using the Cloudflare Vite plugin. Previously, you could only develop locally when using Wrangler as your local development server.

You can simply configure your Worker and your Container(s) in your Wrangler configuration file:

{
  "name": "container-starter",
  "main": "src/index.js",
  "containers": [
    {
      "class_name": "MyContainer",
      "image": "./Dockerfile",
      "instances": 5
    }
  ],
  "durable_objects": {
    "bindings": [
      {
        "class_name": "MyContainer",
        "name": "MY_CONTAINER"
      }
    ]
  },
  "migrations": [
    {
      "new_sqlite_classes": [
        "MyContainer"
      ],
      "tag": "v1"
    }
  ],
}

name = "container-starter"
main = "src/index.js"

[[containers]]
class_name = "MyContainer"
image = "./Dockerfile"
instances = 5

[[durable_objects.bindings]]
class_name = "MyContainer"
name = "MY_CONTAINER"

[[migrations]]
new_sqlite_classes = [ "MyContainer" ]
tag = "v1"

Once your Worker and Containers are configured, you can access the Container instances from your Worker code:

import { Container, getContainer } from "@cloudflare/containers";

export class MyContainer extends Container {
  defaultPort = 4000; // Port the container is listening on
  sleepAfter = "10m"; // Stop the instance if requests not sent for 10 minutes
}

async fetch(request, env) {
  const { "session-id": sessionId } = await request.json();
  // Get the container instance for the given session ID
  const containerInstance = getContainer(env.MY_CONTAINER, sessionId)
  // Pass the request to the container instance on its default port
  return containerInstance.fetch(request);
}

To develop your Worker locally, start a local dev server by running

vite dev

in your terminal.

Learn more about Cloudflare Containers ↗ or the Cloudflare Vite plugin ↗ in our developer docs.

Any template which uses Worker environment variables, secrets, or Secrets Store secrets can now be deployed using a Deploy to Cloudflare button.

Define environment variables and secrets store bindings in your Wrangler configuration file as normal:

{
  "name": "my-worker",
  "main": "./src/index.ts",
	// Set this to today's date
	"compatibility_date": "2026-08-16",
  "vars": {
    "API_HOST": "https://example.com",
  },
	"secrets_store_secrets": [
		{
			"binding": "API_KEY",
			"store_id": "demo",
			"secret_name": "api-key"
		}
	]
}

name = "my-worker"
main = "./src/index.ts"
# Set this to today's date
compatibility_date = "2026-08-16"

[vars]
API_HOST = "https://example.com"

[[secrets_store_secrets]]
binding = "API_KEY"
store_id = "demo"
secret_name = "api-key"

Add secrets to a .dev.vars.example or .env.example file:

COOKIE_SIGNING_KEY=my-secret # comment

And optionally, you can add a description for these bindings in your template's package.json to help users understand how to configure each value:

{
	"name": "my-worker",
	"private": true,
	"cloudflare": {
		"bindings": {
			"API_KEY": {
				"description": "Select your company's API key for connecting to the example service."
			},
			"COOKIE_SIGNING_KEY": {
				"description": "Generate a random string using `openssl rand -hex 32`."
			}
		}
	}
}

These secrets and environment variables will be presented to users in the dashboard as they deploy this template, allowing them to configure each value. Additional information about creating templates and Deploy to Cloudflare buttons can be found in our documentation.

We’ve launched pricing for Browser Rendering, including a free tier and a pay-as-you-go model that scales with your needs. Starting August 20, 2025, Cloudflare will begin billing for Browser Rendering.

There are two ways to use Browser Rendering. Depending on the method you use, here’s how billing will work:

• REST API: Charged for Duration only ($/browser hour)
• Browser Sessions: Charged for both Duration and Concurrency ($/browser hour and # of concurrent browsers)

Included usage and pricing by plan

What you need to know:

• Workers Free Plan: 10 minutes of browser usage per day with 3 concurrent browsers at no charge.
• Workers Paid Plan: 10 hours of browser usage per month with 10 concurrent browsers (averaged monthly) at no charge. Additional usage is charged as shown above.

You can monitor usage via the Cloudflare dashboard ↗. Go to Compute > Browser Run.

If you've been using Browser Rendering and do not wish to incur charges, ensure your usage stays within your plan's included usage. To estimate costs, take a look at these example pricing scenarios.

You can now run your Browser Rendering locally using npx wrangler dev, which spins up a browser directly on your machine before deploying to Cloudflare's global network. By running tests locally, you can quickly develop, debug, and test changes without needing to deploy or worry about usage costs.

Get started with this example guide that shows how to use Cloudflare's fork of Puppeteer (you can also use Playwright) to take screenshots of webpages and store the results in Workers KV.

Now, when you connect your Cloudflare Worker to a git repository on GitHub or GitLab, each branch of your repository has its own stable preview URL, that you can use to preview code changes before merging the pull request and deploying to production.

This works the same way that Cloudflare Pages does — every time you create a pull request, you'll automatically get a shareable preview link where you can see your changes running, without affecting production. The link stays the same, even as you add commits to the same branch. These preview URLs are named after your branch and are posted as a comment to each pull request. The URL stays the same with every commit and always points to the latest version of that branch.

Each comment includes two preview URLs as shown above:

• Commit Preview URL: Unique to the specific version/commit (e.g., <version-prefix>-<worker-name>.<subdomain>.workers.dev)
• Branch Preview URL: A stable alias based on the branch name (e.g., <branch-name>-<worker-name>.<subdomain>.workers.dev)

When you create a pull request:

• A preview alias is automatically created based on the Git branch name (e.g., <branch-name> becomes <branch-name>-<worker-name>.<subdomain>.workers.dev)
• No configuration is needed, the alias is generated for you
• The link stays the same even as you add commits to the same branch
• Preview URLs are posted directly to your pull request as comments (just like they are in Cloudflare Pages)

You can also assign a custom preview alias using the Wrangler CLI, by passing the --preview-alias flag when uploading a version of your Worker:

wrangler versions upload --preview-alias staging

• Only available on the workers.dev subdomain (custom domains not yet supported)
• Requires Wrangler v4.21.0+
• Preview URLs are not generated for Workers that use Durable Objects
• Not yet supported for Workers for Platforms

We now support audio mode! Use this feature to extract audio from a source video, outputting an M4A file to use in downstream workflows like AI inference, content moderation, or transcription.

For example,

https://example.com/cdn-cgi/media/<OPTIONS>/<SOURCE-VIDEO>
https://example.com/cdn-cgi/media/mode=audio,time=3s,duration=60s/<input video with diction>

For more information, learn about Transforming Videos.

Subaddressing, as defined in RFC 5233 ↗, also known as plus addressing, is now supported in Email Routing. This enables using the "+" separator to augment your custom addresses with arbitrary detail information.

Now you can send an email to user+detail@example.com and it will be captured by the user@example.com custom address. The +detail part is ignored by Email Routing, but it can be captured next in the processing chain in the logs, an Email Worker or an Agent application ↗.

Customers can use this feature to dynamically add context to their emails, such as tracking the source of an email or categorizing emails without needing to create multiple custom addresses.

Check our Developer Docs to learn how to enable subaddressing in Email Routing.

Vite 7 ↗ is now supported in the Cloudflare Vite plugin. See the Vite changelog ↗ for a list of changes.

Note that the minimum Node.js versions supported by Vite 7 are 20.19 and 22.12. We continue to support Vite 6 so you do not need to immediately upgrade.

Your real-time applications running over Cloudflare Tunnel are now faster and more reliable. We've completely re-architected the way cloudflared proxies UDP traffic in order to isolate it from other traffic, ensuring latency-sensitive applications like private DNS are no longer slowed down by heavy TCP traffic (like file transfers) on the same Tunnel.

This is a foundational improvement to Cloudflare Tunnel, delivered automatically to all customers. There are no settings to configure — your UDP traffic is already flowing faster and more reliably.

What’s new:

• Faster UDP performance: We've significantly reduced the latency for establishing new UDP sessions, making applications like private DNS much more responsive.
• Greater reliability for mixed traffic: UDP packets are no longer affected by heavy TCP traffic, preventing timeouts and connection drops for your real-time services.

Learn more about running TCP or UDP applications and private networks through Cloudflare Tunnel.

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, with 13.5% of resources impacted. We have committed to releasing improvements on a 2 week cadeance to ensure it's stability and relability, including the v5.7 release.

Thank you for continuing to raise issues and please keep an eye on this changelog for more information about upcoming releases.

• Addressed permanent diff bug on Cloudflare Tunnel config
• State is now saved correctly for Zero Trust Access applications
• Exact match is now working as expected within data.cloudflare_zero_trust_access_applications
• cloudflare_zero_trust_access_policy now supports OIDC claims & diff issues resolved
• Self hosted applications with private IPs no longer require a public domain for cloudflare_zero_trust_access_application.
• New resource:
  • cloudflare_zero_trust_tunnel_warp_connector
• Other bug fixes

For a more detailed look at all of the changes, see the changelog ↗ in GitHub.

• #5563: cloudflare_logpull_retention is missing import ↗
• #5608: cloudflare_zero_trust_access_policy in 5.5.0 provider gives error upon apply unexpected new value: .app_count: was cty.NumberIntVal(0), but now cty.NumberIntVal(1) ↗
• #5612: data.cloudflare_zero_trust_access_applications does not exact match ↗
• #5532: cloudflare_zero_trust_access_identity_provider detects changes on every plan ↗
• #5662: cloudflare_zero_trust_access_policy does not support OIDC claims ↗
• #5565: Running Terraform with the cloudflare_zero_trust_access_policy resource results in updates on every apply, even when no changes are made - breaks idempotency ↗
• #5529: cloudflare_zero_trust_access_application: self hosted applications with private ips require public domain ↗

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 on migration to v5 while we work on stabilization of the v5 provider. This will ensure Cloudflare can work ahead and avoid any blocking issues.

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, although 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 ↗.

• Terraform provider ↗
• Documentation on using Terraform with Cloudflare

You can now expect 3-5× faster indexing in AutoRAG, and with it, a brand new Jobs view to help you monitor indexing progress.

With each AutoRAG, indexing jobs are automatically triggered to sync your data source (i.e. R2 bucket) with your Vectorize index, ensuring new or updated files are reflected in your query results. You can also trigger jobs manually via the Sync API or by clicking “Sync index” in the dashboard.

With the new jobs observability, you can now:

• View the status, job ID, source, start time, duration and last sync time for each indexing job
• Inspect real-time logs of job events (e.g. Starting indexing data source...)
• See a history of past indexing jobs under the Jobs tab of your AutoRAG

This makes it easier to understand what’s happening behind the scenes.

Coming soon: We’re adding APIs to programmatically check indexing status, making it even easier to integrate AutoRAG into your workflows.

Try it out today on the Cloudflare dashboard ↗.

You can use Images to ingest HEIC images and serve them in supported output formats like AVIF, WebP, JPEG, and PNG.

When inputting a HEIC image, dimension and sizing limits may still apply. Refer to our documentation to see limits for uploading to Images or transforming a remote image.

Workers now support breakpoint debugging using VSCode's built-in JavaScript Debug Terminals ↗. All you have to do is open a JS debug terminal (Cmd + Shift + P and then type javascript debug) and run wrangler dev (or vite dev) from within the debug terminal. VSCode will automatically connect to your running Worker (even if you're running multiple Workers at once!) and start a debugging session.

In 2023 we announced breakpoint debugging support ↗ for Workers, which meant that you could easily debug your Worker code in Wrangler's built-in devtools (accessible via the [d] hotkey) as well as multiple other devtools clients, including VSCode ↗. For most developers, breakpoint debugging via VSCode is the most natural flow, but until now it's required manually configuring a launch.json file ↗, running wrangler dev, and connecting via VSCode's built-in debugger. Now it's much more seamless!

You can now specify the number of connections your Hyperdrive configuration uses to connect to your origin database.

All configurations have a minimum of 5 connections. The maximum connection count for a Hyperdrive configuration depends on the Hyperdrive limits of your Workers plan.

This feature allows you to right-size your connection pool based on your database capacity and application requirements. You can configure connection counts through the Cloudflare dashboard or API.

Refer to the Hyperdrive configuration documentation for more information.

You can now use any of Vite's static asset handling ↗ features in your Worker as well as in your frontend. These include importing assets as URLs, importing as strings and importing from the public directory as well as inlining assets.

Additionally, assets imported as URLs in your Worker are now automatically moved to the client build output.

Here is an example that fetches an imported asset using the assets binding and modifies the response.

// Import the asset URL
// This returns the resolved path in development and production
import myImage from "./my-image.png";

export default {
	async fetch(request, env) {
		// Fetch the asset using the binding
		const response = await env.ASSETS.fetch(new URL(myImage, request.url));
		// Create a new `Response` object that can be modified
		const modifiedResponse = new Response(response.body, response);
		// Add an additional header
		modifiedResponse.headers.append("my-header", "imported-asset");

		// Return the modified response
		return modifiedResponse;
	},
};

Refer to Static Assets in the Cloudflare Vite plugin docs for more info.

The Email Routing platform supports SPF ↗ records and DKIM (DomainKeys Identified Mail) ↗ signatures and honors these protocols when the sending domain has them configured. However, if the sending domain doesn't implement them, we still forward the emails to upstream mailbox providers.

Starting on July 3, 2025, we will require all emails to be authenticated using at least one of the protocols, SPF or DKIM, to forward them. We also strongly recommend that all senders implement the DMARC protocol.

If you are using a Worker with an Email trigger to receive email messages and forward them upstream, you will need to handle the case where the forward action may fail due to missing authentication on the incoming email.

SPAM has been a long-standing issue with email. By enforcing mail authentication, we will increase the efficiency of identifying abusive senders and blocking bad emails. If you're an email server delivering emails to large mailbox providers, it's likely you already use these protocols; otherwise, please ensure you have them properly configured.

We recently announced ↗ our public beta for remote bindings, which allow you to connect to deployed resources running on your Cloudflare account (like R2 buckets or D1 databases) while running a local development session.

Now, you can use remote bindings with your Next.js applications through the @opennextjs/cloudflare adaptor ↗ by enabling the experimental feature in your next.config.ts:

- initOpenNextCloudflareForDev();
+ initOpenNextCloudflareForDev({
+  experimental: { remoteBindings: true }
+ });

Then, all you have to do is specify which bindings you want connected to the deployed resource on your Cloudflare account via the experimental_remote flag in your binding definition:

{
	"r2_buckets": [
		{
			"bucket_name": "testing-bucket",
			"binding": "MY_BUCKET",
			"experimental_remote": true,
		},
	],
}

[[r2_buckets]]
bucket_name = "testing-bucket"
binding = "MY_BUCKET"
experimental_remote = true

You can then run next dev to start a local development session (or start a preview with opennextjs-cloudflare preview), and all requests to env.MY_BUCKET will be proxied to the remote testing-bucket — rather than the default local binding simulations.

Remote bindings are also used during the build process, which comes with significant benefits for pages using Incremental Static Regeneration (ISR) ↗. During the build step for an ISR page, your server executes the page's code just as it would for normal user requests. If a page needs data to display (like fetching user info from KV), those requests are actually made. The server then uses this fetched data to render the final HTML.

Data fetching is a critical part of this process, as the finished HTML is only as good as the data it was built with. If the build process can't fetch real data, you end up with a pre-rendered page that's empty or incomplete.

With remote bindings support in OpenNext, your pre-rendered pages are built with real data from the start. The build process uses any configured remote bindings, and any data fetching occurs against the deployed resources on your Cloudflare account.

Want to learn more? Get started with remote bindings and OpenNext ↗.

Have feedback? Join the discussion in our beta announcement ↗ to share feedback or report any issues.

Workers can now talk to each other across separate dev commands using service bindings and tail consumers, whether started with vite dev or wrangler dev.

Simply start each Worker in its own terminal:

# Terminal 1
vite dev

# Terminal 2
wrangler dev

This is useful when different teams maintain different Workers, or when each Worker has its own build setup or tooling.

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