Cloudflare Release Notes

Workflows pricing now includes per-step billing. Requests and CPU time billing have been enabled since the initial public beta and is not changing.

Workflows adds step billing

A step is each unit of work executed by a Workflow, including step operations such as sleeping or waiting for events.

You can query Workflows analytics, including stepCount for a Workflow instance, with the GraphQL Analytics API.

Steps and storage billing to take effect August 10th, 2026

Starting no earlier than August 10th, 2026, Cloudflare will begin billing for step and storage usage on Workers Paid plans.

Storage pricing has been published since Workflows became generally available and is not changing. Storage is measured as persisted Workflow state in GB-months.

Dimension

Workers Free

Workers Paid

Steps

3,000 included per day

500,000 included per month, then $0.80 per additional 100,000 steps

Storage

1 GB-month included

1 GB-month included, then $0.20 per additional GB-month …

R2 Data Catalog is a managed Apache Iceberg ↗︎ catalog built directly into your R2 bucket. Iceberg tracks your data through a tree of metadata files, so every insert, update, and delete must go through a catalog transaction. Manually adding, modifying, or deleting objects outside the catalog can leave pointers referencing files that no longer exist, corrupting the table into an inconsistent state that is difficult to recover from.

To help prevent this, the R2 dashboard and Wrangler now warn you when you attempt a manual delete operation on a Data Catalog-enabled bucket.

Dashboard

When you try to delete objects from a bucket that has R2 Data Catalog enabled, the dashboard displays a warning explaining that the operation could leave the catalog in an invalid state, with a link to the documentation for deleting data correctly. You can cancel the operation or choose to proceed anyway.

R2 dashboard warning shown before deleting objects from a Data Catalog-enabled bucket

Wrangler

Wrangler now checks whether a bucket is Data Catalog-enabled before running a delete and warns you before continuing:

Data Catalog is enabled for this bucket. …

Browser Run now supports a standalone /accessibilityTree endpoint, giving agent and automation workflows direct access to the browser's accessibility tree for a rendered webpage.

An accessibility tree is the browser's structured view of a rendered page: roles, names, states, values, and hierarchy. It is useful for accessibility tooling, but also for AI agents and automation workflows that need page structure without the noise of raw HTML or the cost of screenshots.

For AI agents, this means less inference from pixels and less parsing HTML. You can provide the page structure directly, helping agents identify available elements and determine which actions they can take.

With the new /accessibilityTree endpoint, you can request the accessibility tree directly when you only need the semantic structure of a page. If you need multiple page formats in a single API call, you can use the /snapshot endpoint, which also returns Markdown, HTML, and screenshots.

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-run/accessibilityTree' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com/"
}'

{
	"success": true,
	"result": {
		"accessibilityTree": {
			"role": "RootWebArea",
			"name": "Example Domain",
			"children": [
				{ …

Logs

Enterprise customers can now push per-connection WebSocket analytics to any Logpush destination using the new websocket_analytics dataset. Each log record is emitted when a WebSocket connection closes and includes fields that were previously only available to Cloudflare engineers via internal tooling.

Key fields include:

• ConnectionCloseReason — why the connection ended: peerReset, peerNoError, timedOut, upstreamReset, protocolViolation, unspecifiedError, or none.
• ConnectionCloseSource — which side initiated the close: upstream, downstream, me, or both.
• ConnectionTransportCloseCode — the TLS alert code or TCP-level close code for additional precision.
• RayID — correlate WebSocket connection events with your existing HTTP Request logs.

The dataset also includes directional byte counts (BytesSentClient, BytesReceivedClient, BytesSentOrigin, BytesReceivedOrigin), connection timestamps, client IP, colo code, and request metadata from the original WebSocket upgrade.

This data lets you build alerts on connection close patterns — for example, detecting spikes in TCP resets (ConnectionCloseReason == "peerReset") grouped by host and data center — directly in your existing log analysis tools. …

Enterprise customers can now push per-connection WebSocket analytics to any Logpush destination using the new websocket_analytics dataset. Each log record is emitted when a WebSocket connection closes and includes fields that were previously only available to Cloudflare engineers via internal tooling.

Key fields include:

• ConnectionCloseReason — why the connection ended: peerReset, peerNoError, timedOut, upstreamReset, protocolViolation, unspecifiedError, or none.
• ConnectionCloseSource — which side initiated the close: upstream, downstream, me, or both.
• ConnectionTransportCloseCode — the TLS alert code or TCP-level close code for additional precision.
• RayID — correlate WebSocket connection events with your existing HTTP Request logs.

The dataset also includes directional byte counts (BytesSentClient, BytesReceivedClient, BytesSentOrigin, BytesReceivedOrigin), connection timestamps, client IP, colo code, and request metadata from the original WebSocket upgrade.

This data lets you build alerts on connection close patterns — for example, detecting spikes in TCP resets (ConnectionCloseReason == "peerReset") grouped by host and data center — directly in your existing log analysis tools. …

You can now register a Cloudflare One Virtual Appliance and generate its license key directly from the dashboard, without contacting your account team.

Registering a Cloudflare One Virtual Appliance and generating its authentication key from the Connectors page

• On the Connectors page, select Add an appliance and choose Virtual appliance to register a virtual appliance and generate its authentication key.
• Use Regenerate authentication key from a virtual appliance connector's menu to rotate its key. The previous key is immediately and irrevocably revoked.
• The authentication key is shown only once — copy and store it securely.

This complements the existing API and Terraform self-serve workflow for provisioning virtual appliances. Hardware appliances continue to use the existing account-team fulfillment workflow.

For details, refer to Configure a Cloudflare One Virtual Appliance.

A new declarative exports field in your Wrangler configuration file replaces the imperative migrations array for managing Durable Object class lifecycle. Instead of writing an ordered list of migration steps with unique tags, you declare each Durable Object class your Worker exports and Cloudflare compares that against what's already deployed to determine what Durable Object state needs to be created, renamed, or deleted.

With legacy migrations, renaming ChatRoom to Room requires retaining both tagged steps:

Before — legacy migrationsjsonc

{
	"migrations": [
		{ "tag": "v1", "new_sqlite_classes": ["ChatRoom"] },
		{
			"tag": "v2",
			"renamed_classes": [{ "from": "ChatRoom", "to": "Room" }],
		},
	],
}

With exports, you instead declare Room as the current class and mark ChatRoom as renamed:

After — declarative exportsjsonc

{
	"exports": {
		"ChatRoom": {
			"type": "durable-object",
			"state": "renamed",
			"renamed_to": "Room",
		},
		"Room": { "type": "durable-object", "storage": "sqlite" },
	},
}

Each entry is keyed by class name. The state field carries the lifecycle (created by default — a live class — plus tombstone states deleted, renamed, and transferred, and the expecting-transfer receiving state for cross-Worker transfers). …

A new declarative exports field in your Wrangler configuration file replaces the imperative migrations array for managing Durable Object class lifecycle. Instead of writing an ordered list of migration steps with unique tags, you declare each Durable Object class your Worker exports and Cloudflare compares that against what's already deployed to determine what Durable Object state needs to be created, renamed, or deleted.

With legacy migrations, renaming ChatRoom to Room requires retaining both tagged steps:

Before — legacy migrationsjsonc

{
	"migrations": [
		{ "tag": "v1", "new_sqlite_classes": ["ChatRoom"] },
		{
			"tag": "v2",
			"renamed_classes": [{ "from": "ChatRoom", "to": "Room" }],
		},
	],
}

With exports, you instead declare Room as the current class and mark ChatRoom as renamed:

After — declarative exportsjsonc

{
	"exports": {
		"ChatRoom": {
			"type": "durable-object",
			"state": "renamed",
			"renamed_to": "Room",
		},
		"Room": { "type": "durable-object", "storage": "sqlite" },
	},
}

Each entry is keyed by class name. The state field carries the lifecycle (created by default — a live class — plus tombstone states deleted, renamed, and transferred, and the expecting-transfer receiving state for cross-Worker transfers). …

We have released version 5 of @cloudflare/workers-types ↗︎. This release simplifies the package to expose only the latest runtime types.

We still recommend that you generate types for your Worker using wrangler types, but if you want to use the package directly, you can install it with your package manager of choice:

npmyarnpnpmbun

npm i -D @cloudflare/workers-types@latest

yarn add -D @cloudflare/workers-types@latest

pnpm add -D @cloudflare/workers-types@latest

bun add -d @cloudflare/workers-types@latest

The package now exposes two entrypoints:

• @cloudflare/workers-types reflects the latest compatibility date, using the latest stable compatibility flags.
• @cloudflare/workers-types/experimental reflects APIs behind experimental compatibility flags.

The dated entrypoints, such as @cloudflare/workers-types/2022-11-30 and @cloudflare/workers-types/2023-03-01, are removed. With runtime type generation in Wrangler v4, you can generate these with the wrangler types command to create types locked to your Worker's compatibility date.

For more information, refer to TypeScript language support.

You can now add hostname routes to a Cloudflare Mesh node, in addition to CIDR routes.

1. Client device

   Requests wiki.internal.local

2. DNS query↓

3. Cloudflare Gateway

   Returns a token IP, then rewrites the destination to the real private IP.

   172.64.128.0/20

4. Hostname route↓

5. Mesh node

   Forwards traffic to the host on the local network

6. ↓

7. Private host

   wiki.internal.local · 10.0.0.50

Instead of managing IP ranges, you can attract traffic for a hostname to a Mesh node:

• Private hostname (for example, wiki.internal.local) — reach an internal application by name, which is useful when it has an unknown or ephemeral IP. On Mesh you do not need to run a DNS server; a local hosts-file entry on the node is enough, or you can use a Gateway resolver policy for split DNS.
• Public hostname (for example, www.example.com) — route that hostname's traffic through the node and egress via the node's public IP.

Go to Mesh ↗ …

When you connect a data source to your AI Search instance, AI Search runs sync jobs to keep your index up to date with your content. You can now manage those jobs directly from Wrangler.

For example, you can trigger a sync job from your CI/CD or automated pipelines with the jobs create command so your index refreshes when you push a change:

wrangler ai-search jobs create my-instance

This creates an asynchronous sync job that checks for changes in your data source, and sends new, modified, or deleted files to be indexed. The following commands are available:

Command

Description

wrangler ai-search jobs create

Trigger a new sync job

wrangler ai-search jobs list

List sync jobs for an instance

wrangler ai-search jobs get

Get details for a job

wrangler ai-search jobs cancel

Cancel a running job

wrangler ai-search jobs logs

View log entries for a job

All commands accept --namespace/-n (defaults to default) and --json for structured output that automation and AI agents can parse directly. The list and logs commands also support --page and --per-page for pagination, and cancel prompts for confirmation unless you pass -y/--force. …

Wrangler CLI now supports auth profiles: named logins that you scope to specific Cloudflare accounts and switch between automatically, based on the directory you are working in.

A profile is a named OAuth login bound to a directory. Commands run in that directory, and its subdirectories, use the matching account — so you can move between accounts without re-running wrangler login.

Use profiles to keep a separate login for each client when working at an agency, or to separate staging and production into different accounts. Pair a profile with an account_id in your Wrangler configuration file so a command cannot reach the wrong account.

# Create a profile for each account, choosing which accounts it can reach
wrangler auth create client-a
wrangler auth activate client-a ~/clients/client-a

wrangler auth create client-b
wrangler auth activate client-b ~/clients/client-b

Use the --profile flag to run a single command with a specific profile:

wrangler deploy --profile personal

In CI and other automated environments, CLOUDFLARE_API_TOKEN still takes precedence over all profiles.

For setup, the resolution order, and the full command reference, refer to Authentication profiles.

Your origin can serve different responses for the same URL — different languages based on Accept-Language, or different formats based on Accept — by returning a Vary ↗︎ response header. Cloudflare's cache now honors that header directly in Cache Rules, so the same URL can hold multiple cached versions and each request is matched to the right one. Content that previously had to bypass cache to stay correct can now be cached, following standard HTTP caching behavior ↗︎.

What changed

Your origin now decides which request headers matter by listing them in its Vary response, and you control how Cloudflare treats each one. When you have enabled Vary using a cache rule and a response includes a Vary header, the request headers listed become part of the cache key.

For each header your origin varies on, choose one of three actions:

Action

Behavior

Best for

normalize

Converts equivalent header values to the same cache key value before matching, collapsing redundant versions.

Most Accept, Accept-Language, and Accept-Encoding use cases.

passthrough

Uses the raw header value to select the cached version and forwards it to the origin unchanged.

When byte-for-byte differences in the header value should create versions.

bypass …

Logs

Cloudflare has updated Logpush datasets:

Updated fields in existing datasets

• Gateway DNS (added): AppliedMaxTTL and UpstreamRecordTTLs.
• Gateway HTTP (added): Warnings.
• HTTP requests (added): CacheLockWaitedMs.

For the complete field definitions for each dataset, refer to Logpush datasets.

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

This package is the same release as 2026.6.822.0, with a fix for our RPM package. Previously the repository served a single build to every OS version, so an install could pull a dependency that isn't available on that release. The repository now serves the correct build for each operating system version, so installs automatically pull the dependencies that version requires. Debian and Ubuntu were not affected.

If you installed version 2026.6.822.0 on an RPM-based distribution, we recommend refreshing your repository configuration:

sudo curl -fsSL https://pkg.cloudflareclient.com/cloudflare-warp-ascii.repo | sudo tee /etc/yum.repos.d/cloudflare-warp.repo
sudo dnf clean all
sudo dnf install cloudflare-warp

Access now correctly preserves URL fragment characters (/, ?, =, &, ;) when redirecting users back to an application after login. Previously, these characters were encoded with encodeURIComponent, which mangled fragment-based routes used by single-page applications (SPAs).

For example, an SPA URL like https://app.example.com/#/dashboard?tab=settings&view=advanced would previously redirect to a broken URL after login. This is now handled correctly.

If your SPA users were experiencing broken navigation after authenticating through Access, this fix resolves the issue without any configuration changes.

Access for Infrastructure now supports independent multi-factor authentication (MFA) for SSH connections using YubiKey PIV keys. This adds a hardware-backed second factor to SSH access, ensuring that a compromised device session alone is not sufficient to reach your servers.

With per-application and per-policy configuration, you can enforce PIV key authentication for sensitive usernames (for example, root) while applying different requirements for other usernames. You can also set an MFA session duration to control how often users must re-authenticate.

Enrollment

Users enroll their YubiKey PIV key through the App Launcher. For enrollment instructions and SSH client setup, refer to Enroll a PIV key for infrastructure apps.

Configuration

For setup instructions, refer to Enforce MFA for infrastructure applications.

Containers now support Google Artifact Registry ↗︎ images. After you configure credentials, you can use a fully qualified Google Artifact Registry image reference in your Wrangler configuration instead of first pushing the image to Cloudflare Registry.

Provide the service account email with --gar-email and pipe the service account JSON key through stdin:

cat <PATH_TO_KEY> | npx wrangler containers registries configure <REGION>-docker.pkg.dev --gar-email=<SERVICE_ACCOUNT_EMAIL> --secret-name=<SECRET_NAME>

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "containers": [
    {
      "image": "<REGION>-docker.pkg.dev/<PROJECT_ID>/<REPOSITORY>/<IMAGE>:<TAG>"
    }
  ]
}

# Example: us-central1-docker.pkg.dev/my-project/my-repo/my-image:latest
[[containers]]
image = "<REGION>-docker.pkg.dev/<PROJECT_ID>/<REPOSITORY>/<IMAGE>:<TAG>"

Only *-docker.pkg.dev hosts are supported. To configure credentials, refer to Use private Google Artifact Registry images.

For more information, refer to Image management.

The Images binding is now billed per unique transformation, matching the model already used for URL-based transformations. Repeat requests for the same combination of source image and parameters within the same calendar month are counted only once.

Previously, every call to the binding counted as a separate transformation regardless of whether the image or parameters were unique. With this change, you can call the binding on hot paths without paying for each individual request.

Calls to .info() are no longer billed.

For more information, refer to Images pricing and the Images binding documentation.