Developer Platform Updates & Release Notes

Containers and Sandboxes pricing for CPU time is now based on active usage only, instead of provisioned resources.

This means that you now pay less for Containers and Sandboxes.

An Example Before and After

Imagine running the standard-2 instance type for one hour, which can use up to 1 vCPU, but on average you use only 20% of your CPU capacity.

CPU-time is priced at $0.00002 per vCPU-second.

Previously, you would be charged for the CPU allocated to the instance multiplied by the time it was active, in this case 1 hour.

CPU cost would have been: $0.072 — 1 vCPU * 3600 seconds * $0.00002

Now, since you are only using 20% of your CPU capacity, your CPU cost is cut to 20% of the previous amount.

CPU cost is now: $0.0144 — 1 vCPU * 3600 seconds * $0.00002 * 20% utilization

This can significantly reduce costs for Containers and Sandboxes.

Note

Memory cost and disk pricing remain unchanged, and is still calculated based on provisioned resources.

See the documentation to learn more about Containers, Sandboxes, and associated pricing.

Until now, if a Worker had been previously deployed via the Cloudflare Dashboard ↗︎, a subsequent deployment done via the Cloudflare Workers CLI, Wrangler (through the deploy command), would allow the user to override the Worker's dashboard settings without providing details on what dashboard settings would be lost.

Now instead, wrangler deploy presents a helpful representation of the differences between the local configuration and the remote dashboard settings, and offers to update your local configuration file for you.

See example below showing a before and after for wrangler deploy when a local configuration is expected to override a Worker's dashboard settings:

Before

wrangler deploy run before the improved workflow

After

wrangler deploy run after the improved workflow …

AI Search now supports custom HTTP headers for website crawling, solving a common problem where valuable content behind authentication or access controls could not be indexed.

Previously, AI Search could only crawl publicly accessible pages, leaving knowledge bases, documentation, and other protected content out of your search results. With custom headers support, you can now include authentication credentials that allow the crawler to access this protected content.

This is particularly useful for indexing content like:

• Internal documentation behind corporate login systems
• Premium content that requires users to provide access to unlock
• Sites protected by Cloudflare Access using service tokens

To add custom headers when creating an AI Search instance, select Parse options. In the Extra headers section, you can add up to five custom headers per Website data source.

Custom headers configuration in AI Search

For example, to crawl a site protected by Cloudflare Access, you can add service token credentials as custom headers:

CF-Access-Client-Id: your-token-id.access …

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: ↗︎

• countIf() - count the number of rows which satisfy a provided condition
• sumIf() - calculate a sum from rows which satisfy a provided condition
• avgIf() - calculate an average from rows which satisfy a provided condition

New date and time functions: ↗︎

• toYear()
• toMonth()
• toDayOfMonth()
• toDayOfWeek()
• toHour()
• toMinute()
• toSecond()
• toStartOfYear()
• toStartOfMonth()
• toStartOfWeek()
• toStartOfDay()
• toStartOfHour()
• toStartOfFifteenMinutes()
• toStartOfTenMinutes()
• toStartOfFiveMinutes()
• toStartOfMinute()
• today()
• toYYYYMM()

Ready to get started?

…

Wrangler now supports using the CLOUDFLARE_ENV environment variable to select the active environment for your Worker commands. This provides a more flexible way to manage environments, especially when working with build tools and CI/CD pipelines.

What's new

Environment selection via environment variable:

• Set CLOUDFLARE_ENV to specify which environment to use for Wrangler commands
• Works with all Wrangler commands that support the --env flag
• The --env command line argument takes precedence over the CLOUDFLARE_ENV environment variable

Example usage

# Deploy to the production environment using CLOUDFLARE_ENV
CLOUDFLARE_ENV=production wrangler deploy

# Upload a version to the staging environment
CLOUDFLARE_ENV=staging wrangler versions upload

# The --env flag takes precedence over CLOUDFLARE_ENV
CLOUDFLARE_ENV=dev wrangler deploy --env production
# This will deploy to production, not dev

Use with build tools

The CLOUDFLARE_ENV environment variable is particularly useful when working with build tools like Vite. You can set the environment once during the build process, and it will be used for both building and deploying your Worker:

Enable automatic tracing on your Workers, giving you detailed metadata and timing information for every operation your Worker performs.

Tracing example

Tracing helps you identify performance bottlenecks, resolve errors, and understand how your Worker interacts with other services on the Workers platform. You can now answer questions like:

• Which calls are slowing down my application?
• Which queries to my database take the longest?
• What happened within a request that resulted in an error?

You can now:

• View traces alongside your logs in the Workers Observability dashboard
• Export traces (and correlated logs) to any OTLP-compatible destination ↗︎, such as Honeycomb, Sentry, or Grafana, by configuring a tracing destination in the Cloudflare dashboard ↗︎
• Analyze and query across span attributes (operation type, status, duration, errors)

To get started, set:

{
	"observability": {
		"traces": { …

You can now set a jurisdiction when creating a D1 database to guarantee where your database runs and stores data. Jurisdictions can help you comply with data localization regulations such as GDPR. Supported jurisdictions include eu and fedramp.

A jurisdiction can only be set at database creation time via wrangler, REST API or the UI and cannot be added/updated after the database already exists.

npx wrangler@latest d1 create db-with-jurisdiction --jurisdiction eu

curl -X POST "https://api.cloudflare.com/client/v4/accounts/<account_id>/d1/database" \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     --data '{"name": "db-with-jurisdiction", "jurisdiction": "eu" }'

To learn more, visit D1's data location documentation.

Workers VPC Services is now available, enabling your Workers to securely access resources in your private networks, without having to expose them on the public Internet.

What's new

• VPC Services: Create secure connections to internal APIs, databases, and services using familiar Worker binding syntax
• Multi-cloud Support: Connect to resources in private networks in any external cloud (AWS, Azure, GCP, etc.) or on-premise using Cloudflare Tunnels

export default {
	async fetch(request, env, ctx) {
		// Perform application logic in Workers here

		// Sample call to an internal API running on ECS in AWS using the binding
		const response = await env.AWS_VPC_ECS_API.fetch("https://internal-host.example.com");

		// Additional application logic in Workers
		return new Response();
	},
};

Getting started

Set up a Cloudflare Tunnel, create a VPC Service, add service bindings to your Worker, and access private resources securely. Refer to the documentation to get started.

You can now capture Wrangler command output in a structured ND-JSON ↗︎ format by setting the WRANGLER_OUTPUT_FILE_PATH or WRANGLER_OUTPUT_FILE_DIRECTORY environment variables. This feature is particularly useful for CI/CD pipelines and automation tools that need programmatic access to deployment information such as worker names, version IDs, deployment URLs, and error details. Commands that support this feature include wrangler deploy, wrangler versions upload, wrangler versions deploy, and wrangler pages deploy.

Workers, including those using Durable Objects and Browser Rendering, may now process WebSocket messages up to 32 MiB in size. Previously, this limit was 1 MiB.

This change allows Workers to handle use cases requiring large message sizes, such as processing Chrome Devtools Protocol messages.

For more information, please see the Durable Objects startup limits.

We've raised the Cloudflare Workflows account-level limits for all accounts on the Workers paid plan:

• Instance creation rate increased from 100 workflow instances per 10 seconds to 100 instances per second
• Concurrency limit increased from 4,500 to 10,000 workflow instances per account

These increases mean you can create new instances up to 10x faster, and have more workflow instances concurrently executing. To learn more and get started with Workflows, refer to the getting started guide.

If your application requires a higher limit, fill out the Limit Increase Request Form or contact your account team. Please refer to Workflows pricing for more information.

AI Search now supports reranking for improved retrieval quality and allows you to set the system prompt directly in your API requests.

Rerank for more relevant results

You can now enable reranking to reorder retrieved documents based on their semantic relevance to the user’s query. Reranking helps improve accuracy, especially for large or noisy datasets where vector similarity alone may not produce the optimal ordering.

You can enable and configure reranking in the dashboard or directly in your API requests:

const answer = await env.AI.autorag("my-autorag").aiSearch({
	query: "How do I train a llama to deliver coffee?",
	model: "@cf/meta/llama-3.3-70b-instruct-fp8-fast",
	reranking: {
		enabled: true,
		model: "@cf/baai/bge-reranker-base",
	},
});

Set system prompts in API

Previously, system prompts could only be configured in the dashboard. You can now define them directly in your API requests, giving you per-query control over behavior. For example:

// Dynamically set query and system prompt in AI Search
async function getAnswer(query, tone) {
	const systemPrompt = `You are a ${tone} assistant.`;

	const response = await env.AI.autorag("my-autorag").aiSearch({ …

Previously, if you wanted to develop or deploy a worker with attached resources, you'd have to first manually create the desired resources. Now, if your Wrangler configuration file includes a KV namespace, D1 database, or R2 bucket that does not yet exist on your account, you can develop locally and deploy your application seamlessly, without having to run additional commands.

Automatic provisioning is launching as an open beta, and we'd love to hear your feedback to help us make improvements! It currently works for KV, R2, and D1 bindings. You can disable the feature using the --no-x-provision flag.

To use this feature, update to wrangler@4.45.0 and add bindings to your config file without resource IDs e.g.:

{
	"kv_namespaces": [{ "binding": "MY_KV" }],
	"d1_databases": [{ "binding": "MY_DB" }],
	"r2_buckets": [{ "binding": "MY_R2" }],
}

wrangler dev will then automatically create these resources for you locally, and on your next run of wrangler deploy, Wrangler will call the Cloudflare API to create the requested resources and link them to your Worker.

Though resource IDs will be automatically written back to your Wrangler config file after resource creation, resources will stay linked across future deploys even without adding the resource IDs to the config file. This is especially useful for shared templates, which now no longer need to include account-specific resource IDs when adding a binding.

The Cloudflare Vite plugin now supports TanStack Start ↗︎ apps. Get started with new or existing projects.

New projects

Create a new TanStack Start project that uses the Cloudflare Vite plugin via the create-cloudflare CLI:

npmyarnpnpm

npm create cloudflare@latest -- my-tanstack-start-app --framework=tanstack-start

yarn create cloudflare my-tanstack-start-app --framework=tanstack-start

pnpm create cloudflare@latest my-tanstack-start-app --framework=tanstack-start

Existing projects

Migrate an existing TanStack Start project to use the Cloudflare Vite plugin:

1. Install @cloudflare/vite-plugin and wrangler

npmyarnpnpmbun

npm i -D @cloudflare/vite-plugin wrangler

yarn add -D @cloudflare/vite-plugin wrangler

pnpm add -D @cloudflare/vite-plugin wrangler

bun add -d @cloudflare/vite-plugin wrangler

2. Add the Cloudflare plugin to your Vite config

vite.config.tsts

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

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

3. Add your Worker config file

{ …

Developers can now programmatically retrieve a list of all file formats supported by the Markdown Conversion utility in Workers AI.

You can use the env.AI binding:

await env.AI.toMarkdown().supported()

Or call the REST API:

curl https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/tomarkdown/supported \
  -H 'Authorization: Bearer {API_TOKEN}'

Both return a list of file formats that users can convert into Markdown:

[
	{
		"extension": ".pdf",
		"mimeType": "application/pdf",
	},
	{
		"extension": ".jpeg",
		"mimeType": "image/jpeg",
	},
	...
]

Learn more about our Markdown Conversion utility.

We have updated the default behavior for Cloudflare Workers Preview URLs. Going forward, if a preview URL setting is not explicitly configured during deployment, its default behavior will automatically match the setting of your workers.dev subdomain.

This change is intended to provide a more intuitive and secure experience by aligning your preview URL's default state with your workers.dev configuration to prevent cases where a preview URL might remain public even after you disabled your workers.dev route.

What this means for you:

• If neither setting is configured: both the workers.dev route and the preview URL will default to enabled
• If your workers.dev route is enabled and you do not explicitly set Preview URLs to enabled or disabled: Preview URLs will default to enabled
• If your workers.dev route is disabled and you do not explicitly set Preview URLs to enabled or disabled: Preview URLs will default to disabled …

Screenshot of Durable Objects Data Studio

You can now view and write to each Durable Object's storage using a UI editor on the Cloudflare dashboard. Only Durable Objects using SQLite storage can use Data Studio.

Go to Durable Objects ↗

Data Studio unlocks easier data access with Durable Objects for prototyping application data models to debugging production storage usage. Before, querying your Durable Objects data required deploying a Worker.

To access a Durable Object, you can provide an object's unique name or ID generated by Cloudflare. Data Studio requires you to have at least the Workers Platform Admin role, and all queries are captured with audit logging for your security and compliance needs. Queries executed by Data Studio send requests to your remote, deployed objects and incur normal usage billing.

To learn more, visit the Data Studio documentation. If you have feedback or suggestions for the new Data Studio, please share your experience on Discord ↗︎