Skip to content

Changelog

New updates and improvements at Cloudflare.

Launching FLUX.2 [dev] on Workers AI

We've partnered with Black Forest Labs (BFL) to bring their latest FLUX.2 [dev] model to Workers AI! This model excels in generating high-fidelity images with physical world grounding, multi-language support, and digital asset creation. You can also create specific super images with granular controls like JSON prompting.

Read the BFL blog to learn more about the model itself. Read our Cloudflare blog to see the model in action, or try it out yourself on our multi modal playground.

Pricing documentation is available on the model page or pricing page. Note, we expect to drop pricing in the next few days after iterating on the model performance.

Workers AI Platform specifics

The model hosted on Workers AI is able to support up to 4 image inputs (512x512 per input image). Note, this image model is one of the most powerful in the catalog and is expected to be slower than the other image models we currently support. One catch to look out for is that this model takes multipart form data inputs, even if you just have a prompt.

With the REST API, the multipart form data input looks like this:

curl --request POST \
  --url 'https://api.cloudflare.com/client/v4/accounts/{ACCOUNT}/ai/run/@cf/black-forest-labs/flux-2-dev' \
  --header 'Authorization: Bearer {TOKEN}' \
  --header 'Content-Type: multipart/form-data' \
  --form 'prompt=a sunset at the alps' \
  --form steps=25
  --form width=1024
  --form height=1024

With the Workers AI binding, you can use it as such:


const form = new FormData();
form.append('prompt', 'a sunset with a dog');
form.append('width', '1024');
form.append('height', '1024');

//this dummy request is temporary hack
//we're pushing a change to address this soon
const formRequest = new Request('http://dummy', {
  method: 'POST',
  body: form
});
const formStream = formRequest.body;
const formContentType = formRequest.headers.get('content-type') || 'multipart/form-data';

const resp = await env.AI.run("@cf/black-forest-labs/flux-2-dev", {
  multipart: {
    body: formStream,
    contentType: formContentType
  }
});

The parameters you can send to the model are detailed here:

JSON Schema for Model Required Parameters

  • prompt (string) - Text description of the image to generate

Optional Parameters

  • input_image_0 (string) - Binary image
  • input_image_1 (string) - Binary image
  • input_image_2 (string) - Binary image
  • input_image_3 (string) - Binary image
  • steps (integer) - Number of inference steps. Higher values may improve quality but increase generation time
  • guidance (float) - Guidance scale for generation. Higher values follow the prompt more closely
  • width (integer) - Width of the image, default 1024 Range: 256-1920
  • height (integer) - Height of the image, default 768 Range: 256-1920
  • seed (integer) - Seed for reproducibility

## Multi-Reference Images

The FLUX.2 model is great at generating images based on reference images. You can use this feature to apply the style of one image to another, add a new character to an image, or iterate on past generate images. You would use it with the same multipart form data structure, with the input images in binary.

For the prompt, you can reference the images based on the index, like `take the subject of image 1 and style it like image 0` or even use natural language like `place the dog beside the woman`.

Note: you have to name the input parameter as `input_image_0`, `input_image_1`, `input_image_2` for it to work correctly. All input images must be smaller than 512x512.

```bash
curl --request POST \
  --url 'https://api.cloudflare.com/client/v4/accounts/{ACCOUNT}/ai/run/@cf/black-forest-labs/flux-2-dev' \
  --header 'Authorization: Bearer {TOKEN}' \
  --header 'Content-Type: multipart/form-data' \
  --form 'prompt=take the subject of image 1 and style it like image 0' \
  --form input_image_0=@/Users/johndoe/Desktop/icedoutkeanu.png \
  --form input_image_1=@/Users/johndoe/Desktop/me.png \
  --form steps=25
  --form width=1024
  --form height=1024

Through Workers AI Binding:


//helper function to convert ReadableStream to Blob
async function streamToBlob(stream: ReadableStream, contentType: string): Promise<Blob> {
  const reader = stream.getReader();
  const chunks = [];

  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    chunks.push(value);
  }

  return new Blob(chunks, { type: contentType });
}

const image0 = await fetch("http://image-url");
const image1 = await fetch("http://image-url");
const form = new FormData();

const image_blob0 = await streamToBlob(image0.body, "image/png");
const image_blob1 = await streamToBlob(image1.body, "image/png");
form.append('input_image_0', image_blob0)
form.append('input_image_1', image_blob1)
form.append('prompt', 'take the subject of image 1and style it like image 0')

//this dummy request is temporary hack
//we're pushing a change to address this soon
const formRequest = new Request('http://dummy', {
  method: 'POST',
  body: form
});
const formStream = formRequest.body;
const formContentType = formRequest.headers.get('content-type') || 'multipart/form-data';

const resp = await env.AI.run("@cf/black-forest-labs/flux-2-dev", {
    multipart: {
        body: form,
        contentType: "multipart/form-data"
    }
})

JSON Prompting

The model supports prompting in JSON to get more granular control over images. You would pass the JSON as the value of the 'prompt' field in the multipart form data. See the JSON schema below on the base parameters you can pass to the model.

JSON Prompting Schema
{
  "type": "object",
  "properties": {
    "scene": {
      "type": "string",
      "description": "Overall scene setting or location"
    },
    "subjects": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "type": { 
            "type": "string", 
            "description": "Type of subject (e.g., desert nomad, blacksmith, DJ, falcon)" 
          },
          "description": { 
            "type": "string", 
            "description": "Physical attributes, clothing, accessories" 
          },
          "pose": { 
            "type": "string", 
            "description": "Action or stance" 
          },
          "position": { 
            "type": "string",
            "enum": ["foreground", "midground", "background"],
            "description": "Depth placement in scene"
          }
        },
        "required": ["type", "description", "pose", "position"]
      }
    },
    "style": {
      "type": "string",
      "description": "Artistic rendering style (e.g., digital painting, photorealistic, pixel art, noir sci-fi, lifestyle photo, wabi-sabi photo)"
    },
    "color_palette": {
      "type": "array",
      "items": { "type": "string" },
      "minItems": 3,
      "maxItems": 3,
      "description": "Exactly 3 main colors for the scene (e.g., ['navy', 'neon yellow', 'magenta'])"
    },
    "lighting": {
      "type": "string",
      "description": "Lighting condition and direction (e.g., fog-filtered sun, moonlight with star glints, dappled sunlight)"
    },
    "mood": {
      "type": "string",
      "description": "Emotional atmosphere (e.g., harsh and determined, playful and modern, peaceful and dreamy)"
    },
    "background": {
      "type": "string",
      "description": "Background environment details"
    },
    "composition": {
      "type": "string",
      "enum": [
        "rule of thirds",
        "circular arrangement",
        "framed by foreground",
        "minimalist negative space",
        "S-curve",
        "vanishing point center",
        "dynamic off-center",
        "leading leads",
        "golden spiral",
        "diagonal energy",
        "strong verticals",
        "triangular arrangement"
      ],
      "description": "Compositional technique"
    },
    "camera": {
      "type": "object",
      "properties": {
        "angle": { 
          "type": "string",
          "enum": ["eye level", "low angle", "slightly low", "bird's-eye", "worm's-eye", "over-the-shoulder", "isometric"],
          "description": "Camera perspective"
        },
        "distance": { 
          "type": "string",
          "enum": ["close-up", "medium close-up", "medium shot", "medium wide", "wide shot", "extreme wide"],
          "description": "Framing distance"
        },
        "focus": { 
          "type": "string",
          "enum": ["deep focus", "macro focus", "selective focus", "sharp on subject", "soft background"],
          "description": "Focus type"
        },
        "lens": { 
          "type": "string",
          "enum": ["14mm", "24mm", "35mm", "50mm", "70mm", "85mm"],
          "description": "Focal length (wide to telephoto)"
        },
        "f-number": { 
          "type": "string", 
          "description": "Aperture (e.g., f/2.8, the smaller the number the more blurry the background)" 
        },
        "ISO": { 
          "type": "number", 
          "description": "Light sensitivity value (comfortable range between 100 & 6400, lower = less sensitivity)" 
        }
      }
    },
    "effects": {
      "type": "array",
      "items": { "type": "string" },
      "description": "Post-processing effects (e.g., 'lens flare small', 'subtle film grain', 'soft bloom', 'god rays', 'chromatic aberration mild')"
    }
  },
  "required": ["scene", "subjects"]
}

Other features to try

  • The model also supports the most common latin and non-latin character languages
  • You can prompt the model with specific hex codes like #2ECC71
  • Try creating digital assets like landing pages, comic strips, infographics too!

Mount R2 buckets in Containers

Containers now support mounting R2 buckets as FUSE (Filesystem in Userspace) volumes, allowing applications to interact with R2 using standard filesystem operations.

Common use cases include:

  • Bootstrapping containers with datasets, models, or dependencies for sandboxes and agent environments
  • Persisting user configuration or application state without managing downloads
  • Accessing large static files without bloating container images or downloading at startup

FUSE adapters like tigrisfs, s3fs, and gcsfuse can be installed in your container image and configured to mount buckets at startup.

FROM alpine:3.20

# Install FUSE and dependencies
RUN apk update && \
    apk add --no-cache ca-certificates fuse curl bash

# Install tigrisfs
RUN ARCH=$(uname -m) && \
    if [ "$ARCH" = "x86_64" ]; then ARCH="amd64"; fi && \
    if [ "$ARCH" = "aarch64" ]; then ARCH="arm64"; fi && \
    VERSION=$(curl -s https://api.github.com/repos/tigrisdata/tigrisfs/releases/latest | grep -o '"tag_name": "[^"]*' | cut -d'"' -f4) && \
    curl -L "https://github.com/tigrisdata/tigrisfs/releases/download/${VERSION}/tigrisfs_${VERSION#v}_linux_${ARCH}.tar.gz" -o /tmp/tigrisfs.tar.gz && \
    tar -xzf /tmp/tigrisfs.tar.gz -C /usr/local/bin/ && \
    rm /tmp/tigrisfs.tar.gz && \
    chmod +x /usr/local/bin/tigrisfs

# Create startup script that mounts bucket
RUN printf '#!/bin/sh\n\
    set -e\n\
    mkdir -p /mnt/r2\n\
    R2_ENDPOINT="https://${R2_ACCOUNT_ID}.r2.cloudflarestorage.com"\n\
    /usr/local/bin/tigrisfs --endpoint "${R2_ENDPOINT}" -f "${BUCKET_NAME}" /mnt/r2 &\n\
    sleep 3\n\
    ls -lah /mnt/r2\n\
    ' > /startup.sh && chmod +x /startup.sh

CMD ["/startup.sh"]

See the Mount R2 buckets with FUSE example for a complete guide on mounting R2 buckets and/or other S3-compatible storage buckets within your containers.

New CPU Pricing for Containers and Sandboxes

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.

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

Better local deployment flow for Cloudflare Workers

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

Also, if instead Wrangler detects that a deployment would override remote dashboard settings but in an additive way, without modifying or removing any of them, it will simply proceed with the deployment without requesting any user interaction.

Update to Wrangler v4.50.0 or greater to take advantage of this improved deploy flow.

Terraform v5.13.0 now available

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-3 week cadence to ensure its stability and reliability, including the v5.13 release. We have also pivoted from an issue-to-issue approach to a resource-per-resource approach - we will be focusing on specific resources to not only stabilize the resource but also ensure it is migration-friendly for those migrating from v4 to v5.

Thank you for continuing to raise issues. They make our provider stronger and help us build products that reflect your needs.

This release includes new features, new resources and data sources, bug fixes, updates to our Developer Documentation, and more.

Breaking Change

Please be aware that there are breaking changes for the cloudflare_api_token and cloudflare_account_token resources. These changes eliminate configuration drift caused by policy ordering differences in the Cloudflare API.

For more specific information about the changes or the actions required, please see the detailed Repository changelog.

Features

  • New resources and data sources added
    • cloudflare_connectivity_directory
    • cloudflare_sso_connector
    • cloudflare_universal_ssl_setting
  • api_token+account_tokens: state upgrader and schema bump (#6472)
  • docs: make docs explicit when a resource does not have import support
  • magic_transit_connector: support self-serve license key (#6398)
  • worker_version: add content_base64 support
  • worker_version: boolean support for run_worker_first (#6407)
  • workers_script_subdomains: add import support (#6375)
  • zero_trust_access_application: add proxy_endpoint for ZT Access Application (#6453)
  • zero_trust_dlp_predefined_profile: Switch DLP Predefined Profile endpoints, introduce enabled_entries attribute

Bug Fixes

  • account_token: token policy order and nested resources (#6440)
  • allow r2_bucket_event_notification to be applied twice without failing (#6419)
  • cloudflare_worker+cloudflare_worker_version: import for the resources (#6357)
  • dns_record: inconsistent apply error (#6452)
  • pages_domain: resource tests (#6338)
  • pages_project: unintended resource state drift (#6377)
  • queue_consumer: id population (#6181)
  • workers_kv: multipart request (#6367)
  • workers_kv: updating workers metadata attribute to be read from endpoint (#6386)
  • workers_script_subdomain: add note to cloudflare_workers_script_subdomain about redundancy with cloudflare_worker (#6383)
  • workers_script: allow config.run_worker_first to accept list input
  • zero_trust_device_custom_profile_local_domain_fallback: drift issues (#6365)
  • zero_trust_device_custom_profile: resolve drift issues (#6364)
  • zero_trust_dex_test: correct configurability for 'targeted' attribute to fix drift
  • zero_trust_tunnel_cloudflared_config: remove warp_routing from cloudflared_config (#6471)

Upgrading

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. We will be releasing a new migration tool in March 2026 to help support v4 to v5 transitions for our most popular resources.

For more info

AI Search support for crawling login protected website content

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
CF-Access-Client-Secret: your-token-secret

The crawler will automatically include these headers in all requests, allowing it to access protected pages that would otherwise be blocked.

Learn more about configuring custom headers for website crawling in AI Search.

More SQL aggregate, date and time functions available in Workers Analytics Engine

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?

Whether you're building usage-based billing systems, customer analytics dashboards, or other custom analytics, these functions let you get the most out of your data. Get started with Workers Analytics Engine and explore all available functions in our SQL reference documentation.

cloudflared proxy-dns command will be removed starting February 2, 2026

Starting February 2, 2026, the cloudflared proxy-dns command will be removed from all new cloudflared releases.

This change is being made to enhance security and address a potential vulnerability in an underlying DNS library. This vulnerability is specific to the proxy-dns command and does not affect any other cloudflared features, such as the core Cloudflare Tunnel service.

The proxy-dns command, which runs a client-side DNS-over-HTTPS (DoH) proxy, has been an officially undocumented feature for several years. This functionality is fully and securely supported by our actively developed products.

Versions of cloudflared released before this date will not be affected and will continue to operate. However, note that our official support policy for any cloudflared release is one year from its release date.

Migration paths

We strongly advise users of this undocumented feature to migrate to one of the following officially supported solutions before February 2, 2026, to continue benefiting from secure DNS-over-HTTPS.

End-user devices

The preferred method for enabling DNS-over-HTTPS on user devices is the Cloudflare WARP client. The WARP client automatically secures and proxies all DNS traffic from your device, integrating it with your organization's Zero Trust policies and posture checks.

Servers, routers, and IoT devices

For scenarios where installing a client on every device is not possible (such as servers, routers, or IoT devices), we recommend using the WARP Connector.

Instead of running cloudflared proxy-dns on a machine, you can install the WARP Connector on a single Linux host within your private network. This connector will act as a gateway, securely routing all DNS and network traffic from your entire subnet to Cloudflare for filtering and logging.

Select Wrangler environments using the CLOUDFLARE_ENV environment variable

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:

# Set the environment for both build and deploy
CLOUDFLARE_ENV=production npm run build & wrangler deploy

When using @cloudflare/vite-plugin, the build process generates a "redirected deploy config" that is flattened to only contain the active environment. Wrangler will validate that the environment specified matches the environment used during the build to prevent accidentally deploying a Worker built for one environment to a different environment.

Learn more

Workers automatic tracing, now in open beta

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:

To get started, set:

{
	"observability": {
		"traces": {
			"enabled": true,
		},
	},
}

Want to learn more?

D1 can restrict data localization with jurisdictions

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.

Announcing Workers VPC Services (Beta)

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.

Capture Wrangler command output in structured format

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.

Increased Workflows instance and concurrency 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.

Access Workers preview URLs from the Build details page

You can now access preview URLs directly from the build details page, making it easier to test your changes when reviewing builds in the dashboard.

preview button

What's new

  • A Preview button now appears in the top-right corner of the build details page for successful builds
  • Click it to instantly open the latest preview URL
  • Matches the same experience you're familiar with from Pages

Reranking and API-based system prompt configuration in AI Search

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({
		query: 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 resource provisioning for KV, R2, and D1

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.

Build TanStack Start apps with the Cloudflare Vite plugin

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:

npm 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
npm i -D @cloudflare/vite-plugin wrangler
  1. 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(),
	],
});
  1. Add your Worker config file
{
	"$schema": "./node_modules/wrangler/config-schema.json",
	"name": "my-tanstack-start-app",
	// Set this to today's date
	"compatibility_date": "2026-08-16",
	"compatibility_flags": [
		"nodejs_compat"
	],
	"main": "@tanstack/react-start/server-entry"
}
"$schema" = "./node_modules/wrangler/config-schema.json"
name = "my-tanstack-start-app"
# Set this to today's date
compatibility_date = "2026-08-16"
compatibility_flags = [ "nodejs_compat" ]
main = "@tanstack/react-start/server-entry"
  1. Modify the scripts in your package.json
package.jsonjson
{
	"scripts": {
		"dev": "vite dev",
		"build": "vite build && tsc --noEmit",
		"start": "node .output/server/index.mjs",
		"preview": "vite preview",
		"deploy": "npm run build && wrangler deploy",
		"cf-typegen": "wrangler types"
	}
}

See the TanStack Start framework guide for more info.

Workers AI Markdown Conversion: New endpoint to list supported formats

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.

Workers Preview URL default behavior now matches your workers.dev setting

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.

View and edit Durable Object data in UI with Data Studio (Beta)

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

Worker startup time limit increased to 1 second

You can now upload a Worker that takes up 1 second to parse and execute its global scope. Previously, startup time was limited to 400 ms.

This allows you to run Workers that import more complex packages and execute more code prior to requests being handled.

For more information, see the documentation on Workers startup limits.

You can now deploy full-stack apps on Workers using Terraform

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

With cloudflare_workers_script

Here's how you can use the existing cloudflare_workers_script resource to upload your Worker code and assets in one shot.

resource "cloudflare_workers_script" "my_app" {
  account_id  = var.account_id
  script_name = "my-app"

  content_file   = "./dist/worker/index.js"
  content_sha256 = filesha256("./dist/worker/index.js")
  main_module    = "index.js"

  # Just point to your assets directory - that's it!
  assets = {
    directory = "./dist/static"
  }
}

With cloudflare_worker, cloudflare_worker_version, and cloudflare_workers_deployment

And here's an example using the beta cloudflare_worker_version resource, alongside the cloudflare_worker and cloudflare_workers_deployment resources:


# This tracks the existence of your Worker, so that you
# can upload code and assets separately from tracking Worker state.

resource "cloudflare_worker" "my_app" {
  account_id = var.account_id
  name       = "my-app"
}

resource "cloudflare_worker_version" "my_app_version" {
  account_id = var.account_id
  worker_id  = cloudflare_worker.my_app.id

  # Just point to your assets directory - that's it!
  assets = {
    directory = "./dist/static"
  }

  modules = [{
    name         = "index.js"
    content_file = "./dist/worker/index.js"
    content_type = "application/javascript+module"
  }]
}

resource "cloudflare_workers_deployment" "my_app_deployment" {
  account_id  = var.account_id
  script_name = cloudflare_worker.my_app.name

  strategy = "percentage"
  versions = [{
    version_id = cloudflare_worker_version.my_app_version.id
    percentage = 100
  }]
}

What's changed

Under the hood, the Cloudflare Terraform provider now handles the same logic that Wrangler uses for static asset uploads. This includes scanning your assets directory, computing hashes for each file, generating a manifest with file metadata, and calling the Cloudflare API to upload any missing files in chunks. We support large directories with parallel uploads and chunking, and when the asset manifest hash changes, we detect what's changed and trigger an upload for only those changed files.

Try it out