Developer Platform Release Notes

What's new

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.

• 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

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.

Cloudflare Workflows account-level limits increased

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

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({
    query,
    system_prompt: systemPrompt
  });
  return response;
}

// Example usage
const query = "What is Cloudflare?";
const tone = "friendly";
const answer = await getAnswer(query, tone);
console.log(answer);

Learn more about Reranking and System Prompt in AI Search.

Automatic provisioning for attached resources (beta)

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 [email protected] 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"
  }]
}

Usage

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

Notes

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

Existing projects

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

• 1. Install @cloudflare/vite-plugin and wrangler
• 1. Add the Cloudflare plugin to your Vite config
• 1. Add your Worker config file
• 1. Modify the scripts in your package.json

See the TanStack Start framework guide for more info.

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

You can override the default setting by explicitly enabling or disabling the preview URL in your Worker's configuration through the API, Dashboard, or Wrangler.

Wrangler Version Behavior

The default behavior depends on the version of Wrangler you are using. This new logic applies to the latest version. Here is a summary of the behavior across different versions:

• Before v4.34.0: Preview URLs defaulted to enabled, regardless of the workers.dev setting.
• v4.34.0 up to (but not including) v4.44.0: Preview URLs defaulted to disabled, regardless of the workers.dev setting.
• v4.44.0 or later: Preview URLs now default to matching your workers.dev setting.

Why we’re making this change

In July, we introduced preview URLs to Workers, which let you preview code changes before deploying to production. This made disabling your Worker’s workers.dev URL an ambiguous action — the preview URL, served as a subdomain of workers.dev (ex: preview-id-worker-name.account-name.workers.dev) would still be live even if you had disabled your Worker’s workers.dev route. If you misinterpreted what it meant to disable your workers.dev route, you might unintentionally leave preview URLs enabled when you didn’t mean to, and expose them to the public Internet.

To address this, we made a one-time update to disable preview URLs on existing Workers that had their workers.dev route disabled and changed the default behavior to be disabled for all new deployments where a preview URL setting was not explicitly configured. While this change helped secure many customers, it was disruptive for customers who keep their workers.dev route enabled and actively use the preview functionality, as it now required them to explicitly enable preview URLs on every redeployment. This new, more intuitive behavior ensures that your preview URL settings align with your workers.dev configuration by default, providing a more secure and predictable experience.

Securing access to workers.dev and preview URL endpoints

To further secure your workers.dev subdomain and preview URL, you can enable Cloudflare Access with a single click in your Worker's settings to limit access to specific users or groups.