Cloudflare Release Notes

Workers AI is excited to add 4 new models to the catalog, including 2 brand new classes of models with a text-to-speech and reranker model. Introducing:

• @cf/baai/bge-m3 - a multi-lingual embeddings model that supports over 100 languages. It can also simultaneously perform dense retrieval, multi-vector retrieval, and sparse retrieval, with the ability to process inputs of different granularities.
• @cf/baai/bge-reranker-base - our first reranker model! Rerankers are a type of text classification model that takes a query and context, and outputs a similarity score between the two. When used in RAG systems, you can use a reranker after the initial vector search to find the most relevant documents to return to a user by reranking the outputs.
• @cf/openai/whisper-large-v3-turbo - a faster, more accurate speech-to-text model. This model was added earlier but is graduating out of beta with pricing included today.
• @cf/myshell-ai/melotts - our first text-to-speech model that allows users to generate an MP3 with voice audio from inputted text.

Pricing is available for each of these models on the Workers AI pricing page. …

You can now access bindings from anywhere in your Worker by importing the env object from cloudflare:workers.

Previously, env could only be accessed during a request. This meant that bindings could not be used in the top-level context of a Worker.

Now, you can import env and access bindings such as secrets or environment variables in the initial setup for your Worker:

import { env } from "cloudflare:workers";
import ApiClient from "example-api-client";

// API_KEY and LOG_LEVEL now usable in top-level scope
const apiClient = ApiClient.new({ apiKey: env.API_KEY });
const LOG_LEVEL = env.LOG_LEVEL || "info";

export default {
	fetch(req) {
		// you can use apiClient or LOG_LEVEL, configured before any request is handled
	},
};

Note

Workers do not allow I/O from outside a request context. This means that even though env is accessible from the top-level scope, you will not be able to access every binding's methods. …

You can now retry your Cloudflare Pages and Workers builds directly from GitHub. No need to switch to the Cloudflare Dashboard for a simple retry!

Let\u2019s say you push a commit, but your build fails due to a spurious error like a network timeout. Instead of going to the Cloudflare Dashboard to manually retry, you can now rerun the build with just a few clicks inside GitHub, keeping you inside your workflow.

For Pages and Workers projects connected to a GitHub repository:

1. When a build fails, go to your GitHub repository or pull request
2. Select the failed Check Run for the build
3. Select "Details" on the Check Run
4. Select "Rerun" to trigger a retry build for that commit

Learn more about Pages Builds and Workers Builds.

You can now access bindings from anywhere in your Worker by importing the env object from cloudflare:workers.

Previously, env could only be accessed during a request. This meant that bindings could not be used in the top-level context of a Worker.

Now, you can import env and access bindings such as secrets or environment variables in the initial setup for your Worker:

import { env } from "cloudflare:workers";
import ApiClient from "example-api-client";

// API_KEY and LOG_LEVEL now usable in top-level scope
const apiClient = ApiClient.new({ apiKey: env.API_KEY });
const LOG_LEVEL = env.LOG_LEVEL || "info";

export default {
	fetch(req) {
		// you can use apiClient or LOG_LEVEL, configured before any request is handled
	},
};

Note

Workers do not allow I/O from outside a request context. This means that even though env is accessible from the top-level scope, you will not be able to access every binding's methods. …

Ruleset

Rule ID

Legacy Rule ID

Description

Previous Action

New Action

Comments

Cloudflare Managed Ruleset

...e59ec18a

100725

Fortinet FortiManager - Remote Code Execution - CVE:CVE-2023-42791, CVE:CVE-2024-23666

Log

Block

Cloudflare Managed Ruleset

...1dbf58df

100726

Ivanti - Remote Code Execution - CVE:CVE-2024-8190

Log

Block

Cloudflare Managed Ruleset

...0ad61fa7

100727

Cisco IOS XE - Remote Code Execution - CVE:CVE-2023-20198

Log

Disabled

Fixed action value in changelog; no rule changes.

Cloudflare Managed Ruleset

...7ee56b66

100728

Sitecore - Remote Code Execution - CVE:CVE-2024-46938

Log

Block

Cloudflare Managed Ruleset

...a6752a38

100729

Microsoft SharePoint - Remote Code Execution - CVE:CVE-2023-33160

Log

Block

Cloudflare Managed Ruleset

...98d47b69

100730

Pentaho - Template Injection - CVE:CVE-2022-43769, CVE:CVE-2022-43939

Log

Block

Cloudflare Managed Ruleset

...69fe1e0d

100700

Apache SSRF vulnerability CVE-2021-40438

N/A

Block

Magic Firewall now supports a new managed list of Cloudflare IP ranges. This list is available as an option when creating a Magic Firewall policy based on IP source/destination addresses. When selecting "is in list" or "is not in list", the option "Cloudflare IP Ranges" will appear in the dropdown menu.

This list is based on the IPs listed in the Cloudflare IP ranges ↗︎. Updates to this managed list are applied automatically.

Cloudflare IPs Managed List

Note: IP Lists require a Cloudflare Advanced Network Firewall subscription. For more details about Cloudflare Network Firewall plans, refer to Plans.

We've released the next major version of Wrangler, the CLI for Cloudflare Workers — wrangler@4.0.0. Wrangler v4 is a major release focused on updates to underlying systems and dependencies, along with improvements to keep Wrangler commands consistent and clear.

You can run the following command to install it in your projects:

npmyarnpnpmbun

npm i wrangler@latest

yarn add wrangler@latest

pnpm add wrangler@latest

bun add wrangler@latest

Unlike previous major versions of Wrangler, which were foundational rewrites ↗︎ and rearchitectures ↗︎ — Version 4 of Wrangler includes a much smaller set of changes. If you use Wrangler today, your workflow is very unlikely to change.

A detailed migration guide is available and if you find a bug or hit a roadblock when upgrading to Wrangler v4, open an issue on the cloudflare/workers-sdk repository on GitHub ↗︎.

Going forward, we'll continue supporting Wrangler v3 with bug fixes and security updates until Q1 2026, and with critical security updates until Q1 2027, at which point it will be out of support.

We’re removing some of the restrictions in Email Routing so that AI Agents and task automation can better handle email workflows, including how Workers can reply to incoming emails.

It's now possible to keep a threaded email conversation with an Email Worker script as long as:

• The incoming email has to have valid DMARC ↗︎.
• The email can only be replied to once in the same EmailMessage event.
• The recipient in the reply must match the incoming sender.
• The outgoing sender domain must match the same domain that received the email.
• Every time an email passes through Email Routing or another MTA, an entry is added to the References list. We stop accepting replies to emails with more than 100 References entries to prevent abuse or accidental loops.

Here's an example of a Worker responding to Emails using a Workers AI model:

AI model responding to emailsts

import PostalMime from "postal-mime";
import { createMimeMessage } from "mimetext";
import { EmailMessage } from "cloudflare:email";

export default {
	async email(message, env, ctx) {
		const email = await PostalMime.parse(message.raw);
		const res = await env.AI.run("@cf/meta/llama-2-7b-chat-fp16", {
			messages: [
				{
					role: "user", …

You can now access environment variables and secrets on process.env when using the nodejs_compat compatibility flag.

const apiClient = ApiClient.new({ apiKey: process.env.API_KEY });
const LOG_LEVEL = process.env.LOG_LEVEL || "info";

In Node.js, environment variables are exposed via the global process.env object. Some libraries assume that this object will be populated, and many developers may be used to accessing variables in this way.

Previously, the process.env object was always empty unless written to in Worker code. This could cause unexpected errors or friction when developing Workers using code previously written for Node.js.

Now, environment variables, secrets, and version metadata can all be accessed on process.env. …

Digital Experience Monitoring (DEX) provides visibility into device, network, and application performance across your Cloudflare SASE deployment. The latest release of the Cloudflare One agent (v2025.1.861) now includes device endpoint monitoring capabilities to provide deeper visibility into end-user device performance which can be analyzed directly from the dashboard.

Device health metrics are now automatically collected, allowing administrators to:

• View the last network a user was connected to
• Monitor CPU and RAM utilization on devices
• Identify resource-intensive processes running on endpoints

Device endpoint monitoring dashboard

This feature complements existing DEX features like synthetic application monitoring and network path visualization, creating a comprehensive troubleshooting workflow that connects application performance with device state.

For more details refer to our DEX documentation.

Hyperdrive now pools database connections in one or more regions close to your database. This means that your uncached queries and new database connections have up to 90% less latency as measured from connection pools.

Hyperdrive query latency decreases by 90% during Hyperdrive's gradual rollout of regional pooling.

By improving placement of Hyperdrive database connection pools, Workers' Smart Placement is now more effective when used with Hyperdrive, ensuring that your Worker can be placed as close to your database as possible.

With this update, Hyperdrive also uses Cloudflare's standard IP address ranges ↗︎ to connect to your database. This enables you to configure the firewall policies (IP access control lists) of your database to only allow access from Cloudflare and Hyperdrive.

Refer to documentation on how Hyperdrive makes connecting to regional databases from Cloudflare Workers fast.

This improvement is enabled on all Hyperdrive configurations.

You can now use bucket locks to set retention policies on your R2 buckets (or specific prefixes within your buckets) for a specified period — or indefinitely. This can help ensure compliance by protecting important data from accidental or malicious deletion.

Locks give you a few ways to ensure your objects are retained (not deleted or overwritten). You can:

• Lock objects for a specific duration, for example 90 days.
• Lock objects until a certain date, for example January 1, 2030.
• Lock objects indefinitely, until the lock is explicitly removed.

Buckets can have up to 1,000 bucket lock rules. Each rule specifies which objects it covers (via prefix) and how long those objects must remain retained.

Here are a couple of examples showing how you can configure bucket lock rules using Wrangler:

Ensure all objects in a bucket are retained for at least 180 days

npx wrangler r2 bucket lock add <bucket> --name 180-days-all --retention-days 180

Prevent deletion or overwriting of all logs indefinitely (via prefix)

Today, we are thrilled to announce Media Transformations, a new service that brings the magic of Image Transformations to short-form video files, wherever they are stored!

For customers with a huge volume of short video — generative AI output, e-commerce product videos, social media clips, or short marketing content — uploading those assets to Stream is not always practical. Sometimes, the greatest friction to getting started was the thought of all that migrating. Customers want a simpler solution that retains their current storage strategy to deliver small, optimized MP4 files. Now you can do that with Media Transformations.

To transform a video or image, enable transformations for your zone, then make a simple request with a specially formatted URL. The result is an MP4 that can be used in an HTML video element without a player library. If your zone already has Image Transformations enabled, then it is ready to optimize videos with Media Transformations, too.

URL formattext

https://example.com/cdn-cgi/media/<OPTIONS>/<SOURCE-VIDEO>

For example, we have a short video of the mobile in Austin's office. The original is nearly 30 megabytes and wider than necessary for this layout. Consider a simple width adjustment:

Example URLtext

https://example.com/cdn-cgi/media/width=640/<SOURCE-VIDEO> …

Stream

Today, we are thrilled to announce Media Transformations, a new service that brings the magic of Image Transformations to short-form video files, wherever they are stored!

For customers with a huge volume of short video — generative AI output, e-commerce product videos, social media clips, or short marketing content — uploading those assets to Stream is not always practical. Sometimes, the greatest friction to getting started was the thought of all that migrating. Customers want a simpler solution that retains their current storage strategy to deliver small, optimized MP4 files. Now you can do that with Media Transformations.

To transform a video or image, enable transformations for your zone, then make a simple request with a specially formatted URL. The result is an MP4 that can be used in an HTML video element without a player library. If your zone already has Image Transformations enabled, then it is ready to optimize videos with Media Transformations, too.

URL formattext

https://example.com/cdn-cgi/media/<OPTIONS>/<SOURCE-VIDEO>

For example, we have a short video of the mobile in Austin's office. The original is nearly 30 megabytes and wider than necessary for this layout. Consider a simple width adjustment:

Example URLtext

We’ve streamlined the Logpush setup process by integrating R2 bucket creation directly into the Logpush workflow!

Now, you no longer need to navigate multiple pages to manually create an R2 bucket or copy credentials. With this update, you can seamlessly configure a Logpush job to R2 in just one click, reducing friction and making setup faster and easier.

This enhancement makes it easier for customers to adopt Logpush and R2.

For more details refer to our Logs documentation.

We're excited to announce that new logging capabilities for Remote Browser Isolation (RBI) through Logpush are available in Beta starting today!

With these enhanced logs, administrators can gain visibility into end user behavior in the remote browser and track blocked data extraction attempts, along with the websites that triggered them, in an isolated session.

{
	"AccountID": "$ACCOUNT_ID",
	"Decision": "block",
	"DomainName": "www.example.com",
	"Timestamp": "2025-02-27T23:15:06Z",
	"Type": "copy",
	"UserID": "$USER_ID"
}

User Actions available:

• Copy & Paste
• Downloads & Uploads
• Printing

Learn more about how to get started with Logpush in our documentation.