Storage Updates & Release Notes

KV

Jurisdictions for Workers KV namespaces are now generally available. When you create a namespace, you can set a jurisdiction to make sure the namespace's data is only durably stored within that region. Jurisdictions can help you comply with data localization regulations such as GDPR or FedRAMP. Supported jurisdictions are eu, us, and fedramp.

A jurisdiction can only be set when a namespace is created, using the Cloudflare dashboard, Wrangler, the cf CLI, or the REST API, and cannot be added or changed afterwards.

npx wrangler@latest kv namespace create <NAMESPACE_NAME> --jurisdiction=eu

cf kv namespaces create --title <NAMESPACE_NAME> --jurisdiction eu

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/storage/kv/namespaces" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "title": "<NAMESPACE_NAME>",
    "jurisdiction": "eu"
  }'

Workers can still access a namespace restricted to a jurisdiction from anywhere in the world, and KV data can be cached outside the jurisdiction on Cloudflare's network. The jurisdiction only controls where the namespace's data is durably stored.

To learn more, refer to Data location.

Basin Pipelines Basin

Each Basin Pipelines stream can now ingest up to 1 GB/s, increased from 5 MB/s.

The higher per-stream limit gives high-volume application events, telemetry, and logs more room to grow without splitting ingestion across streams solely to stay within the previous limit.

For the full list of stream, sink, and pipeline limits, refer to Basin Pipelines limits.

Basin Basin Pipelines Basin Catalog Basin SQL

Basin, formerly the Cloudflare Data Platform, is now generally available. Basin brings an end-to-end analytics platform to the Developer Platform, enabling you to collect data from a variety of sources, such as apps, infrastructure, devices, and other Cloudflare services, then query it to answer analytical questions.

Basin Pipelines

Basin Pipelines, formerly Cloudflare Pipelines, ingests events from Workers, HTTP endpoints, and Cloudflare Logpush. It transforms events with SQL and ingests them into Iceberg tables or files on R2. With Basin Pipelines you can:

• Ingest application and device events through HTTP endpoints or Workers bindings.
• Filter and reshape Cloudflare logs before storing them as Iceberg tables, Parquet, or JSON.
• Catch schema mismatches with typed bindings and investigate dropped events in the dashboard.

Basin Catalog …

Pending service binding requests now keep Durable Objects running while they wait for a response. Pending calls to another Durable Object through remote procedure call (RPC) or fetch(), as well as this.ctx.container.monitor(), now also keep the Durable Object running.

Promises passed to this.ctx.waitUntil() and pending setTimeout() and setInterval() timers also receive this protection.

Previously, Cloudflare could shut down an idle Durable Object while one of these operations remained pending without a connected client. This could stop unfinished work.

This change helps you run long-running tasks such as agents. An agent can call tools through service bindings, coordinate with other Durable Objects, or wait for a container process without relying on the original client to remain connected.

Outbound fetch() requests to external services, TCP sockets, and outbound WebSockets already keep Durable Objects running.

Each pending operation prevents idle shutdown for up to 15 minutes. Starting another one later can extend the Durable Object's time in memory. The limit applies to each operation, not to the total time in memory.

Timeline of a service binding fetch, an RPC call, and monitor() each preventing eviction for up to 15 minutes …

Pending service binding requests now keep Durable Objects running while they wait for a response. Pending calls to another Durable Object through remote procedure call (RPC) or fetch(), as well as this.ctx.container.monitor(), now also keep the Durable Object running.

Promises passed to this.ctx.waitUntil() and pending setTimeout() and setInterval() timers also receive this protection.

Previously, Cloudflare could shut down an idle Durable Object while one of these operations remained pending without a connected client. This could stop unfinished work.

This change helps you run long-running tasks such as agents. An agent can call tools through service bindings, coordinate with other Durable Objects, or wait for a container process without relying on the original client to remain connected.

Outbound fetch() requests to external services, TCP sockets, and outbound WebSockets already keep Durable Objects running.

Each pending operation prevents idle shutdown for up to 15 minutes. Starting another one later can extend the Durable Object's time in memory. The limit applies to each operation, not to the total time in memory.

Timeline of a service binding fetch, an RPC call, and monitor() each preventing eviction for up to 15 minutes …

Browser Run Queues

Browser Run crawl jobs can publish lifecycle events to Cloudflare Queues. Subscribe to started, updated, and finished events to track progress or trigger downstream processing without polling.

To create an account-level subscription, run the following command:

npmyarnpnpm

npx wrangler queues subscription create <QUEUE_NAME> --source browserRun --events crawl.started,crawl.updated,crawl.finished

yarn wrangler queues subscription create <QUEUE_NAME> --source browserRun --events crawl.started,crawl.updated,crawl.finished

pnpm wrangler queues subscription create <QUEUE_NAME> --source browserRun --events crawl.started,crawl.updated,crawl.finished

For payload examples, refer to the Browser Run event schemas.

R2

New R2 product-level Metrics page in the Cloudflare dashboard shows bandwidth usage. You can view usage across all buckets or per bucket.

Go to R2 Metrics ↗ R2 upload and download throughput across all buckets over 24 hours

Bandwidth throughput is split by object upload and download. The GraphQL Analytics API exposes the same bandwidth usage metrics that power the dashboard for your queries and analytics.

For more information, refer to R2 metrics and analytics.

Durable Objects

Durable Object name searches in the Cloudflare dashboard now accept up to 128 characters, up from 20.

Search results and recent invocation lists show up to 128 characters before being truncated with an ellipsis. This limit applies to the object filter on the Metrics tab and object search in Data Studio.

For more information, refer to Metrics and analytics and Data Studio.

Workers Durable Objects

Workers traces can now follow JavaScript RPC calls across Worker boundaries and into Durable Objects. Previously, a trace stopped at the caller's RPC boundary. The dashboard now shows the caller-side session and method calls alongside the callee invocation, nested calls, and callbacks into another Worker.

A session span covers the lifetime of a caller-side session and groups calls that reuse it. Individual call spans show each method invocation. Execution colors distinguish the Workers or Durable Object entrypoints involved, while arrows mark outgoing and incoming calls. Together, these details show where time was spent, which calls reused a session, and how returned stubs and callbacks fit into the request.

A Workers trace of a Worker-to-Worker RPC session, showing the session span, the caller's getCounter and increment call spans, and the callee's invocation and matching call spans

Enable tracing with one setting in your Wrangler configuration file:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "observability": {
    "traces": {
      "enabled": true
    }
  }
}

[observability.traces] …

Basin Catalog Basin R2

R2 Data Catalog now provides table-level maintenance visibility and manual compaction queueing in the Cloudflare dashboard. These updates make it easier to understand when maintenance is eligible to run, inspect completed operations, and request maintenance without leaving the table view.

To view table maintenance details:

1. In the Cloudflare dashboard, go to R2 Data Catalog.
2. Select a catalog, then select the Explorer tab. The Explorer tab opens by default.
3. Select a table.
4. Select the Maintenance tab.

Maintenance tab for an R2 Data Catalog table showing schedules and recent runs

The updated dashboard includes:

• Maintenance tab — View compaction and snapshot expiration settings, schedules, and next eligibility alongside the table's Schema and Metadata tabs.
• Recent runs — Review a paginated audit log with job status, duration, and expandable details for manifest rewrites, compaction, and snapshot expiration. Expanded rows include operation metrics for each maintenance operation. …

R2

R2 Data Access Logs are now generally available. Turn on logging for a bucket to record object read, write, list, multipart upload, and delete operations with response status codes below 400.

Data Access Logs cover requests made through the S3-compatible API, Cloudflare API and dashboard, Workers bindings, and public buckets through r2.dev or custom domains. Events are available in Workers Observability, where you can filter by bucket, operation, interface, actor, and other request fields.

Log delivery is asynchronous and best effort. Events may be delayed or omitted, so do not rely on Data Access Logs as a complete record of bucket activity.

Data Access Logs are available for non-jurisdictional buckets. For setup instructions, supported operations, and the event field reference, refer to R2 Data Access Logs.

You will receive email alerts when the daily limit is reached. The following errors indicate that a limit has been exceeded:

Error	Description
Your account has exceeded D1's free tier daily row read limit. Upgrade to a paid plan or wait until tomorrow (midnight UTC) to continue.	The account has reached its daily row read limit.
Your account has exceeded D1's free tier daily row write limit. Upgrade to a paid plan or wait until tomorrow (midnight UTC) to continue.	The account has reached its daily row write limit.

Inspect database query activity before the enforcement date to identify queries that may exceed these limits. To reduce row reads, add indexes to tables and review queries that perform full table scans. If usage requires higher limits after optimization, upgrade to a Workers Paid plan.

For more information on D1 errors and how to handle them, refer to the D1 error list.

You will receive email alerts when the daily limit is reached. The following errors indicate that a limit has been exceeded:

Error	Description
Your account has exceeded D1's free tier daily row read limit. Upgrade to a paid plan or wait until tomorrow (midnight UTC) to continue.	The account has reached its daily row read limit.
Your account has exceeded D1's free tier daily row write limit. Upgrade to a paid plan or wait until tomorrow (midnight UTC) to continue.	The account has reached its daily row write limit.

Inspect database query activity before the enforcement date to identify queries that may exceed these limits. To reduce row reads, add indexes to tables and review queries that perform full table scans. If usage requires higher limits after optimization, upgrade to a Workers Paid plan.

For more information on D1 errors and how to handle them, refer to the D1 error list.

Workers Durable Objects

Durable Objects can have up to ten distinct Dynamic Workers with in-flight requests, increased from four. This limit applies across all concurrent requests to the same Durable Object because they share an input/output (I/O) context. Other Workers can have up to four distinct Dynamic Workers with in-flight requests per request.

Multiple in-flight requests to the same Dynamic Worker count as one toward this limit.

For more information, refer to Dynamic Workers limits.

Durable Objects

By default, an alarm interrupted by ctx.abort() retries after the Durable Object resets. Pass { retryAlarm: false } when the alarm should stop instead:

src/index.jsjs

import { DurableObject } from "cloudflare:workers";

export class CleanupTask extends DurableObject {
	async alarm() {
		await this.ctx.storage.deleteAll();

		this.ctx.abort("Cleanup complete", { retryAlarm: false });
	}
}

src/index.tsts

import { DurableObject } from "cloudflare:workers";

export class CleanupTask extends DurableObject {
	async alarm(): Promise<void> {
		await this.ctx.storage.deleteAll();

		this.ctx.abort("Cleanup complete", { retryAlarm: false });
	}
}

For example, an alarm that deletes its storage can use this option to avoid repeating the cleanup or re-running the Durable Object constructor.

Alarms can run concurrently with other requests to the same Durable Object. If another request calls ctx.abort() while an alarm is running, the retryAlarm option on that call also controls whether the alarm retries.

The default retry prevents an unrelated request from permanently canceling the alarm. Set retryAlarm: false on every abort path that should stop an in-progress alarm, not only on calls from the alarm handler. Existing calls to ctx.abort() keep retrying alarms.