Developer Platform Updates & Release Notes

Chat recovery improvements

@cloudflare/ai-chat now keeps server turns running when a browser or client stream is interrupted. This is useful for long-running AI responses where users refresh the page, close a tab, or temporarily lose connection. Calling stop() still cancels the server turn.

Set cancelOnClientAbort: true if browser or client aborts should also cancel the server turn:

JavaScript

const chat = useAgentChat({
  agent: "assistant",
  name: "user-123",
  cancelOnClientAbort: true,
});

TypeScript

const chat = useAgentChat({
  agent: "assistant",
  name: "user-123",
  cancelOnClientAbort: true,
});

Notable bug fixes:

Chat stream resume negotiation no longer throws when replay races with a closed WebSocket connection.

Recovered chat continuations no longer leave useAgentChat stuck in a streaming state when the original socket disconnects before a terminal response.

Approval auto-continuation preserves reasoning parts and persists continuation reasoning in the final message.

isServerStreaming now resets correctly when a resumed stream moves from the fallback observer path to a transport-owned stream.

Agent state and routing fixes

[email protected] prevents duplicate initial state frames during WebSocket connection setup. This avoids stale initial state messages overwriting state updates already sent by the client.

Agent recovery is also more reliable when tool calls span a Durable Object restart. Recovery now defers user finish hooks until after agent startup and isolates hook failures, so one failed hook does not block other recovered runs from finalizing.

getAgentByName() now supports routingRetry for transient Durable Object routing failures:

JavaScript

import { getAgentByName } from "agents";

const agent = await getAgentByName(env.AssistantAgent, "user-123", {
  routingRetry: {
    maxAttempts: 3,
  },
});

TypeScript

import { getAgentByName } from "agents";

const agent = await getAgentByName(env.AssistantAgent, "user-123", {
  routingRetry: {
    maxAttempts: 3,
  },
});

Durable Think submissions

@cloudflare/think now supports durable programmatic submissions. submitMessages() provides durable acceptance, idempotent retries, status inspection, cancellation, and cleanup for server-driven turns that should continue after the caller returns.

Think.chat() RPC turns now run inside chat recovery fibers and persist their stream chunks. Interrupted sub-agent turns can recover partial output instead of starting over.

ChatOptions.tools has been removed from the TypeScript API. Define durable tools on the child agent or use agent tools for orchestration. Runtime options.tools values passed by legacy callers are ignored with a warning.

Think message pruning behavior change

@cloudflare/think no longer applies pruneMessages({ toolCalls: "before-last-2-messages" }) to model context by default. The previous default could strip client-side tool results from longer multi-turn flows.

truncateOlderMessages still runs as before, so context cost remains bounded. Subclasses that relied on the old aggressive pruning can opt back in from beforeTurn:

JavaScript

import { Think } from "@cloudflare/think";
import { pruneMessages } from "ai";

export class MyAgent extends Think {
  beforeTurn(ctx) {
    return {
      messages: pruneMessages({
        messages: ctx.messages,
        toolCalls: "before-last-2-messages",
      }),
    };
  }
}

TypeScript

import { Think } from "@cloudflare/think";
import { pruneMessages } from "ai";

export class MyAgent extends Think<Env> {
  beforeTurn(ctx) {
    return {
      messages: pruneMessages({
        messages: ctx.messages,
        toolCalls: "before-last-2-messages",
      }),
    };
  }
}

Voice agent connection control

@cloudflare/voice adds an enabled option to useVoiceAgent. React apps can now delay creating and connecting a VoiceClient until prerequisites such as capability tokens are ready.

JavaScript

const voice = useVoiceAgent({
  agent: "MyVoiceAgent",
  enabled: Boolean(token),
});

TypeScript

const voice = useVoiceAgent({
  agent: "MyVoiceAgent",
  enabled: Boolean(token),
});

This release also fixes Workers AI speech-to-text session edge cases and withVoice text streaming from AI SDK textStream responses.

Other improvements

• Streamable HTTP routing — Server-to-client requests now route through the originating POST stream when no standalone SSE stream is available.
• Structured tool output — Tool output shapes are preserved when truncating older messages or oversized persisted rows.
• Non-chat Think tool steps — Think agent-tool children can complete without emitting assistant text and can return structured output through getAgentToolOutput.
• Sub-agent schedules — Stale sub-agent schedule rows are pruned when their owning facet registry entry no longer exists.
• @cloudflare/codemode — Adds a browser-safe export with an iframe sandbox executor and resolves OpenAPI specs inside the sandbox to avoid Worker Loader RPC size limits.

Upgrade

To update to the latest version:

npm i agents@latest @cloudflare/ai-chat@latest @cloudflare/think@latest @cloudflare/voice@latest

Refer to the Agents API reference and Chat agents documentation for more information.

Original source

SSH through Wrangler is now enabled by default for Containers. Previously, you had to set ssh.enabled to true in your Container configuration before you could connect.

This change does not expose any publicly accessible ports on your Container. The SSH service is reachable only through wrangler containers ssh, which authenticates against your Cloudflare account. You also need to add an ssh-ed25519 public key to authorized_keys before anyone can connect, so enabling SSH alone does not grant access.

To connect, add a public key to your Container configuration and run wrangler containers ssh <INSTANCE_ID>:

{
"containers": [
{
"authorized_keys": [
{
"name": "<NAME>",
"public_key": "<YOUR_PUBLIC_KEY_HERE>",
},
],
},
],
}

[[containers]]
[[containers.authorized_keys]]
name = "<NAME>"
public_key = "<YOUR_PUBLIC_KEY_HERE>"

To disable SSH, set ssh.enabled to false in your Container configuration:

{
"containers": [
{
"ssh": {
"enabled": false,
},
},
],
}

[[containers]]
[containers.ssh]
enabled = false

For more information, refer to the SSH documentation.

Original source

R2 Data Catalog is a managed Apache Iceberg data catalog built directly into your R2 bucket that allows you to connect query engines like R2 SQL, Spark, Snowflake, and DuckDB to your data in R2.

You can now query analytics for your R2 Data Catalog warehouses via Cloudflare's GraphQL Analytics API. Two new datasets are available:

• r2CatalogDataOperationsAdaptiveGroups tracks Iceberg REST API requests made to your catalog, including operation type, request duration, HTTP status, and request body bytes. Use this to monitor request volume and latency across warehouses, namespaces, and tables.

• r2CatalogTableMaintenanceAdaptiveGroups tracks table maintenance jobs such as compaction and snapshot expiration. Use this to monitor job success rates, files processed, bytes read and written, and job duration.

Both datasets support filtering by warehouse name, namespace, table name, and time range. They also include percentile aggregations for duration metrics.

For detailed schema information and example queries, refer to the R2 Data Catalog metrics and analytics documentation.

Original source

We are refreshing the Workers AI model catalog to make room for newer releases. Please update your apps to remove references to the models listed below before the deprecation date.

Recommended replacements

• @cf/zai-org/glm-4.7-flash — fast multilingual model with multi-turn tool calling and coding capabilities.
• @cf/google/gemma-4-26b-a4b-it — efficient open model with vision and tool calling.
• @cf/moonshotai/kimi-k2.6 — capable tool-calling and vision model for agentic workloads and coding.

For pricing, refer to the Workers AI pricing page.

Kimi K2.5

We originally stated Kimi K2.5 would be deprecated on May 10, 2026, however we have extended the deprecation date to May 30, 2026. Requests will be automatically aliased to Kimi K2.6 on May 30, 2026, which has a higher price. Please review the @cf/moonshotai/kimi-k2.6 pricing and model capabilities prior to May 30, 2026 to ensure that the model suits your needs.

Models deprecated on May 30, 2026

• @cf/moonshotai/kimi-k2.5 --> @cf/moonshotai/kimi-k2.6
• @hf/meta-llama/meta-llama-3-8b-instruct
• @cf/meta/llama-3-8b-instruct
• @cf/meta/llama-3-8b-instruct-awq
• @cf/meta/llama-3.1-8b-instruct
• @cf/meta/llama-3.1-8b-instruct-awq
• @cf/meta/llama-3.1-70b-instruct
• @cf/meta/llama-2-7b-chat-int8
• @cf/meta/llama-2-7b-chat-fp16
• @cf/mistral/mistral-7b-instruct-v0.1
• @hf/mistral/mistral-7b-instruct-v0.2
• @hf/google/gemma-7b-it
• @cf/google/gemma-3-12b-it
• @hf/nousresearch/hermes-2-pro-mistral-7b
• @cf/microsoft/phi-2
• @cf/defog/sqlcoder-7b-2
• @cf/unum/uform-gen2-qwen-500m
• @cf/facebook/bart-large-cnn

Variants that remain active

The -fast and -lora variants of models will remain active, including:

• @cf/meta/llama-3.3-70b-instruct-fp8-fast
• @cf/meta/llama-3.1-8b-instruct-fast
• @cf/google/gemma-7b-it-lora
• @cf/google/gemma-2b-it-lora
• @cf/mistral/mistral-7b-instruct-v0.2-lora
• @cf/meta-llama/llama-2-7b-chat-hf-lora

LoRA models may be deprecated in the future. We will be adding more LoRA capabilities to the catalog, and will communicate when new LoRA models come online to give users time to train new LoRAs before we deprecate old ones.

For the full list of available models, refer to the Workers AI model catalog.

Original source

WAF protections

Multiple security vulnerabilities were disclosed by the React team and Vercel affecting React Server Components and Next.js. These include denial of service, middleware and proxy bypass, server-side request forgery, cross-site scripting, and cache poisoning issues across a range of severity levels.

We strongly recommend updating your application and its dependencies immediately. Patched versions are available for React (react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack 19.0.6, 19.1.7, and 19.2.6) and Next.js (15.5.16 and 16.2.5).

Cloudflare WAF rules deployed in response to prior React Server Component CVEs (CVE-2025-55184 and CVE-2026-23864) already provide coverage for the newly disclosed denial-of-service vulnerabilities. These rules are enabled by default with a Block action for all customers using the Cloudflare Managed Ruleset, including Free plan customers using the Free Managed Ruleset.

Ruleset

• Rule description
• Rule ID
• Default action
• Cloudflare Managed Ruleset
• React - DoS - CVE-2025-55184
• 2694f1610c0b471393b21aef102ec699
• Block
• Cloudflare Managed Ruleset
• React - DoS - CVE-2026-23864
• aaede80b4d414dc89c443cea61680354
• Block

The existing rules detect the underlying attack patterns generically. As a result, they apply to the new CVE-2026-23870 denial-of-service vulnerability in Server Components and the corresponding Next.js advisory GHSA-8h8q-6873-q5fj.

Cloudflare is investigating whether WAF rules can be safely and effectively deployed for three of the high-severity advisories: CVE-2026-23870 / GHSA-8h8q-6873-q5fj, GHSA-267c-6grr-h53f, and GHSA-mg66-mrh9-m8jx. If it is possible to create a managed WAF rule that mitigates these CVEs and does not potentially break application behavior, Cloudflare will add additional managed WAF rules. These rules will be announced through the WAF changelog. Because these vulnerabilities were shared with Cloudflare with minimal advance notice, we are still investigating what WAF mitigations are possible.

Several of the disclosed vulnerabilities are not possible to block in WAF. We strongly recommend updating your applications so they are not purely reliant on WAF mitigations.

Customers on Pro, Business, or Enterprise plans should ensure that Managed Rules are enabled.

Next.js adapters

Vinext: Vinext is a Vite plugin that reimplements the Next.js API surface. Vinext's latest release is not vulnerable to any of the disclosed CVEs. Vinext's architecture differs from stock Next.js in ways that sidestep the affected code paths. For example, it does not implement the PPR resume protocol, does not expose Pages Router data-route endpoints, and strips internal headers such as x-nextjs-data at request boundaries. As an extra layer of defense, we added a React 19.2.6 or later requirement when running vinext init (PR #1118, PR #1112) to prevent accidentally running a vulnerable version of React with Vinext.

OpenNext on Cloudflare: OpenNext is an adapter that lets you deploy Next.js apps to the Cloudflare Workers platform. OpenNext itself is not directly vulnerable to the React denial-of-service CVE, but users must update the Next.js version in their application. The OpenNext team has updated the adapter to further harden against these vectors and released a new version of the Cloudflare adapter. Test fixtures and examples have been updated to use patched versions (PR #1255).

Summary of disclosed vulnerabilities

Advisory

• Severity
• Issue
• WAF status
• CVE-2026-23870 / GHSA-8h8q-6873-q5fj
• High
• Denial of service in Server Components
• WAF rules in place: 2694f1610c0b471393b21aef102ec699, aaede80b4d414dc89c443cea61680354
• Cloudflare is investigating additional managed WAF coverage
• GHSA-267c-6grr-h53f
• High
• Middleware bypass via segment-prefetch routes
• Cloudflare is investigating if this can be safely and effectively mitigated by a managed WAF rule
• GHSA-mg66-mrh9-m8jx
• High
• Denial of service via connection exhaustion in Cache Components
• Cloudflare is investigating if this can be safely and effectively mitigated by a managed WAF rule
• GHSA-492v-c6pp-mqqv
• High
• Middleware bypass via dynamic route parameter injection
• Not possible to safely enable a managed WAF rule without potentially breaking application behavior
• GHSA-c4j6-fc7j-m34r
• High
• SSRF via WebSocket upgrades
• Not possible to safely enable a managed WAF rule without potentially breaking application behavior
• GHSA-36qx-fr4f-26g5
• High
• Middleware bypass in Pages Router i18n
• Custom WAF rule possible; global managed rule could potentially break application behavior
• GHSA-ffhc-5mcf-pf4q
• Moderate
• XSS via CSP nonces
• Custom WAF rule possible; global managed rule could potentially break application behavior
• GHSA-gx5p-jg67-6x7h
• Moderate
• XSS in beforeInteractive scripts
• Not possible to safely enable a managed WAF rule without potentially breaking application behavior
• GHSA-h64f-5h5j-jqjh
• Moderate
• Denial of service in Image Optimization API
• Custom WAF rule possible; global managed rule could potentially break application behavior
• GHSA-wfc6-r584-vfw7
• Moderate
• Cache poisoning in RSC responses
• Custom WAF rule possible; global managed rule could potentially break application behavior
• GHSA-vfv6-92ff-j949
• Low
• Cache poisoning via RSC cache-busting collisions
• Not possible to safely enable a managed WAF rule without potentially breaking application behavior
• GHSA-3g8h-86w9-wvmq
• Low
• Middleware redirect cache poisoning
• Custom WAF rule possible; global managed rule could potentially break application behavior

Original source

You can now interact with your Stream video library using new bindings for Workers! This allows customers to upload content to Stream, provision direct uploads, manage videos, and generate signed URLs from a Worker without making authenticated API calls. We're excited to bring Stream and Workers closer together to empower more programmatic pipelines, tighter integrations, and support generative AI and inference workloads.

Use the Stream binding when you want to:

• Upload videos from URLs or create basic direct upload links for end users
• Generate signed playback tokens without managing signing keys
• Manage video metadata, captions, downloads, and watermarks
• Build video pipelines entirely within Workers

To get started, add the Stream binding to your Wrangler configuration:

wrangler.jsonc

{
"$schema": "./node_modules/wrangler/config-schema.json",
"stream": {
"binding": "STREAM"
}
}

wrangler.toml

[stream]
binding = "STREAM"

Generate a video with AI and upload directly to Stream or send a URL of a file you already have:

JavaScript

const aiResponse = await env.AI.run(
"google/veo-3.1",
{
prompt: "A dog walking next to a river",
duration: "10s",
aspect_ratio: "16:9",
resolution: "1080p",
generate_audio: true,
},
{
gateway: { id: "experiments" },
},
);
// Veo will return a URL of the generated asset.
const videoUrl = aiResponse.result.video;
// Alternative option: a video of the Austin Office mobile
// const videoUrl = 'https://pub-d9fcbc1abcd244c1821f38b99017347f.r2.dev/aus-mobile.mp4';
// Upload to Stream by providing a URL
const streamVideo = await env.STREAM.upload(videoUrl);
// The streamVideo response will include the video ID, playback and manifest
// URLs, and other information, just like the REST API.

TypeScript

const aiResponse = await env.AI.run(
'google/veo-3.1',
{
prompt: 'A dog walking next to a river',
duration: '10s',
aspect_ratio: '16:9',
resolution: '1080p',
generate_audio: true,
},
{
gateway: { id: 'experiments' },
},
);
// Veo will return a URL of the generated asset.
const videoUrl = aiResponse.result.video;
// Alternative option: a video of the Austin Office mobile
// const videoUrl = 'https://pub-d9fcbc1abcd244c1821f38b99017347f.r2.dev/aus-mobile.mp4';
// Upload to Stream by providing a URL
const streamVideo = await env.STREAM.upload(videoUrl);
// The streamVideo response will include the video ID, playback and manifest
// URLs, and other information, just like the REST API.

Generate a signed URL without using a signing key or an API call:

JavaScript

const video_id = "ce800be43a9772f4bb02f35b860fb516";
const token = await env.STREAM.video(video_id).generateToken();
// Use the "token" in an iframe embed code, manifest URL, or thumbnail:
const embedUrl = `https://customer-igynxd2rwhmuoxw8.cloudflarestream.com/${token}/iframe`;

TypeScript

const video_id = 'ce800be43a9772f4bb02f35b860fb516';
const token = await env.STREAM.video(video_id).generateToken();
// Use the "token" in an iframe embed code, manifest URL, or thumbnail:
const embedUrl = `https://customer-igynxd2rwhmuoxw8.cloudflarestream.com/${token}/iframe`;

Get and set video properties easily:

JavaScript

const video_id = "46c8b7f480d410840758c1cb14a72e47";
const result = await env.STREAM.video(video_id).details();
await env.STREAM.video(video_id).update({
meta: { name: "sample video" },
});

TypeScript

const video_id = '46c8b7f480d410840758c1cb14a72e47';
const result = await env.STREAM.video(video_id).details();
await env.STREAM.video(video_id).update({
meta: { name: 'sample video' }
});

For setup instructions and the full API reference, refer to Bind to Workers API.

Get started with your Agent

Add a binding for Cloudflare Stream (env.STREAM). On the watch page, use the Stream binding to get info based on the ID, and leverage video.meta.name as the page title.

Original source

You can now get a single unified trace across Worker-to-Worker subrequests, with trace context propagating automatically. Previously, automatic tracing produced disconnected traces when a Worker called another Worker through a service binding or Durable Object.

This means you can:

• Follow a request through your entire Worker architecture in one trace view
• See service binding and Durable Object calls as nested child spans instead of separate traces
• Debug cross-Worker request flows in the Cloudflare dashboard or in an external observability platform via OpenTelemetry

Tracing must be enabled in your Wrangler configuration for traces to be recorded. Checkout Workers tracing to get started.

Up next, we are working on external trace context propagation using W3C Trace Context standards, which will allow traces from your Workers to link with traces from services outside of Cloudflare.

Original source

Cloudflare Pipelines ingests streaming data via Workers or HTTP endpoints, transforms it with SQL, and writes it to R2 as Apache Iceberg tables. R2 Data Catalog manages those Iceberg tables, compaction, and compatibility with query engines like R2 SQL, Spark, and DuckDB.

You can now create and manage both products using Terraform, supported in the Cloudflare Terraform provider v5.19.0.

This adds four new resources that let you define your entire data pipeline as infrastructure-as-code: a data catalog, a stream for ingestion, a sink that writes to R2 Data Catalog or R2, and a pipeline that connects them with SQL.

The new Terraform resources are:

• cloudflare_r2_data_catalog — enable the data catalog on an R2 bucket
• cloudflare_pipeline_stream — create a stream that receives events via HTTP or Worker bindings
• cloudflare_pipeline_sink — create a sink that writes to R2 Data Catalog or R2
• cloudflare_pipeline — create a pipeline with SQL connecting a stream to a sink

Here is a minimal example that creates a stream, an R2 Data Catalog sink, and a pipeline:

resource "cloudflare_pipeline_stream" "my_stream" {
account_id = var.cloudflare_account_id
name = "my_stream"
format = { type = "json" }
schema = {
fields = [{
name = "value"
type = "json"
required = true
}]
}
http = { enabled = true, authentication = false, cors = {} }
worker_binding = { enabled = false }
}
resource "cloudflare_pipeline_sink" "my_sink" {
account_id = var.cloudflare_account_id
name = "my_sink"
type = "r2_data_catalog"
format = { type = "parquet" }
schema = { fields = [] }
config = {
account_id = var.cloudflare_account_id
bucket = "my-pipeline-bucket"
table_name = "my_table"
token = var.catalog_token
}
}
resource "cloudflare_pipeline" "my_pipeline" {
account_id = var.cloudflare_account_id
name = "my_pipeline"
sql = "INSERT INTO ${cloudflare_pipeline_sink.my_sink.name} SELECT * FROM ${cloudflare_pipeline_stream.my_stream.name}"
}

For a full end-to-end example that includes R2 bucket creation, data catalog setup, and scoped API token provisioning, refer to the Pipelines Terraform documentation.

Original source

You can now use @cloudflare/dynamic-workflows to run a Workflow inside a Dynamic Worker, ensuring durable execution for code that is loaded at runtime.

The Worker Loader loads Dynamic Workers on demand, which previously made durability challenging. Even within a Dynamic Worker, a Workflow might sleep for hours or days between steps, and by the time it resumes, the original Dynamic Worker code would no longer be in memory.

The library solves this by tagging each Workflow instance with metadata that identifies which Dynamic Worker to load — for example, a tenant ID — then reloading the matching Dynamic Worker through the Worker Loader whenever a Workflow awakens.

Because Dynamic Workers are created on-demand, you do not have to register each Workflow up front or manage them individually. Load the Workflow code in the Dynamic Worker when it is needed, and the Workflows engine handles persistence and retries behind the scenes. Your Workflow code itself is unaffected by the routing and behaves as normal.

This unlocks patterns where the Workflow code itself is dynamic. For example, this is useful with:

• SaaS platforms where each tenant defines their own automation, such as onboarding sequences, approval chains, or billing retry logic.
• AI agent frameworks where agents generate and execute multi-step plans at runtime, surviving restarts and waiting for human approval between tool calls.
• Multi-tenant job systems where each customer submits their own processing logic and every step persists progress and retries on failure.

import {
createDynamicWorkflowEntrypoint,
DynamicWorkflowBinding,
wrapWorkflowBinding,
type WorkflowRunner,
} from "@cloudflare/dynamic-workflows";

export { DynamicWorkflowBinding };

interface Env {
WORKFLOWS: Workflow;
LOADER: WorkerLoader;
}

function loadTenant(env: Env, tenantId: string) {
return env.LOADER.get(tenantId, async () => ({
compatibilityDate: "2026-01-01",
mainModule: "index.js",
modules: { "index.js": await fetchTenantCode(tenantId) },
// The Dynamic Worker uses this exactly like a real Workflow binding;
// every create() is tagged with { tenantId } automatically.
env: { WORKFLOWS: wrapWorkflowBinding({ tenantId }) },
}));
}

// The entrypoint name must match `class_name` in the workflows binding of your Wrangler config file.
export const DynamicWorkflow = createDynamicWorkflowEntrypoint<Env>(
async ({ env, metadata }) => {
const stub = loadTenant(env, metadata.tenantId as string);
return stub.getEntrypoint("TenantWorkflow") as unknown as WorkflowRunner;
},
);

export default {
fetch(request: Request, env: Env) {
const tenantId = request.headers.get("x-tenant-id")!;
return loadTenant(env, tenantId).getEntrypoint().fetch(request);
},
};

For a full walkthrough, refer to the Dynamic Workflows guide.

Original source

You can now empty an entire R2 bucket or delete folders directly from the dashboard. Emptying a bucket is required before you can delete it. Previously, this required scripting or configuring lifecycle rules. Now, the dashboard can handle it in a single action.

Empty a bucket

Go to your bucket's Settings tab and select Empty under the Empty Bucket section. This deletes all objects in the bucket while preserving the bucket and its configuration. For large buckets, the operation runs in the background and the dashboard displays progress.

Emptying a bucket is also a prerequisite for deleting it. The dashboard now guides you through both steps in one place.

Delete folders

R2 uses a flat object structure. The dashboard groups objects that share a common prefix into folders when the View prefixes as directories checkbox is selected. Deleting a folder removes every object under that prefix.

From the Objects tab, you can select one or more folders and delete them alongside individual objects.

For step-by-step instructions, refer to Delete buckets and Delete objects.

Original source

You can now connect Hyperdrive to a private database through a Workers VPC service. This is the recommended way to connect Hyperdrive to a private database that is not exposed to the public Internet.

When creating a Hyperdrive configuration in the Cloudflare dashboard, choose Connect to private database and then Workers VPC. From there, you can select an existing VPC service or create a new one inline by picking a Cloudflare Tunnel and entering your origin host and TCP port.

You can also create a Hyperdrive configuration backed by a Workers VPC service from the command line:

npx wrangler hyperdrive create my-vpc-database \
--service-id <YOUR_VPC_SERVICE_ID> \
--database <DATABASE_NAME> \
--user <DATABASE_USER> \
--password <DATABASE_PASSWORD> \
--scheme postgresql

Workers VPC services are reusable across Hyperdrive configurations and can also be bound directly to Workers, so you can share the same private connection across multiple products.

To get started, refer to Connect Hyperdrive to a private database using Workers VPC.

Original source

Queues, Cloudflare's managed message queue, now exposes realtime backlog metrics via the dashboard, REST API, and JavaScript API. Three new fields are available:

• backlog_count — the number of unacknowledged messages in the queue
• backlog_bytes — the total size of those messages in bytes
• oldest_message_timestamp_ms — the timestamp of the oldest unacknowledged message

The following endpoints also now include a metadata.metrics object on the result field after successful message consumption:

• /accounts/{account_id}/queues/{queue_id}/messages/pull
• /accounts/{account_id}/queues/{queue_id}/messages
• /accounts/{account_id}/queues/{queue_id}/messages/batch

Javascript APIs

Call env.QUEUE.metrics() to get realtime backlog metrics:

const {
backlogCount, // number
backlogBytes, // number
oldestMessageTimestamp, // Date | undefined
} = await env.QUEUE.metrics();

env.QUEUE.send() and env.QUEUE.sendBatch() also now return a metrics object on the response.

You can also query these fields via the GraphQL Analytics API or view realtime backlog on the dashboard.

For more information, refer to Queues metrics.

Original source

R2 Data Catalog, a managed Apache Iceberg catalog built into R2, now removes unreferenced data files during automatic snapshot expiration. This improvement reduces storage costs and eliminates the need to run manual maintenance jobs to reclaim space from deleted data.

Previously, snapshot expiration only cleaned up Iceberg metadata files such as manifests and manifest lists. Data files that were no longer referenced by active snapshots remained in R2 storage until you manually ran remove_orphan_files or expire_snapshots through an engine like Spark. This required extra operational overhead and left stale data files consuming storage.

Snapshot expiration now handles both metadata and data file cleanup automatically. When a snapshot is expired, any data files that are no longer referenced by retained snapshots are removed from R2 storage.

Enable catalog-level snapshot expiration

npx wrangler r2 bucket catalog snapshot-expiration enable my-bucket \
--older-than-days 7 \
--retain-last 10

To learn more about snapshot expiration and other automatic maintenance operations, refer to the table maintenance documentation.

Original source

Pay-as-you-go customers can now monitor usage-based costs and configure spend alerts through two new features: the Billable Usage dashboard and Budget alerts.

Billable Usage dashboard

The Billable Usage dashboard provides daily visibility into usage-based costs across your Cloudflare account. The data comes from the same system that generates your monthly invoice, so the figures match your bill.

The dashboard displays:

• A bar chart showing daily usage charges for your billing period
• A sortable table breaking down usage by product, including total usage, billable usage, and cumulative costs
• Ability to view previous billing periods

Usage data aligns to your billing cycle, not the calendar month. The total usage cost shown at the end of a completed billing period matches the usage overage charges on your corresponding invoice.

To access the dashboard, go to Manage Account > Billing > Billable Usage.

Budget alerts

Budget alerts allow you to set dollar-based thresholds for your account-level usage spend. You receive an email notification when your projected monthly spend reaches your configured threshold, giving you proactive visibility into your bill before month-end.

To configure a budget alert:

• Go to Manage Account > Billing > Billable Usage.
• Select Set Budget Alert.
• Enter a budget threshold amount greater than $0.
• Select Create.

Alternatively, configure alerts via Notifications > Add > Budget Alert.

You can create multiple budget alerts at different dollar amounts. The notifications system automatically deduplicates alerts if multiple thresholds trigger at the same time. Budget alerts are calculated daily based on your usage trends and fire once per billing cycle when your projected spend first crosses your threshold.

Both features are available to Pay-as-you-go accounts with usage-based products (Workers, R2, Images, etc.). Enterprise contract accounts are not supported.

For more information, refer to the Usage based billing documentation.

Original source

Workflows now provides additional context inside step.do() callbacks and supports returning ReadableStream to handle larger step outputs.

Step context properties

The step.do() callback receives a context object with new properties alongside attempt:

• step.name — The name passed to step.do()
• step.count — How many times a step with that name has been invoked in this instance (1-indexed)

Useful when running the same step in a loop.

config — The resolved step configuration, including timeout and retries with defaults applied

type ResolvedStepConfig = {
  retries: {
    limit: number;
    delay: WorkflowDelayDuration | number;
    backoff?: "constant" | "linear" | "exponential";
  };
  timeout: WorkflowTimeoutDuration | number;
};

type WorkflowStepContext = {
  step: {
    name: string;
    count: number;
  };
  attempt: number;
  config: ResolvedStepConfig;
};

ReadableStream support in step.do()

Steps can now return a ReadableStream directly. Although non-stream step outputs are limited to 1 MiB, streamed outputs support much larger payloads.

const largePayload = await step.do("fetch-large-file", async () => {
  const object = await env.MY_BUCKET.get("large-file.bin");
  return object.body;
});

Note that streamed outputs are still considered part of the Workflow instance storage limit.

Original source