Cloud intelligence

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.

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.

You can now monitor how much memory your Workers and Durable Objects consume across invocations with the new Memory Usage chart in the Workers Metrics tab, broken down by P50, P90, P99, and P999 percentiles. Memory usage measures the V8 isolate memory at the time of each invocation, subject to the 128 MB per-isolate limit — a single isolate can handle many concurrent requests and shares memory across them. Use the Memory Usage chart to: Track memory trends — Spot gradual increases that may indicate a memory leak before they cause Exceeded Memory errors. Correlate with deployments — Deployment markers on the chart help you identify whether a new version introduced a memory regression. Right-size your Worker — Understand your baseline memory footprint and how much headroom you have before hitting the 128 MB limit.

Workers fetch() requests now support the cf.vary request option. Use cf.vary to control how Cloudflare caches origin responses with a Vary header for a single subrequest. src/index.jsjsexport default { async fetch(request) { return fetch(request, { cf: { vary: { default: { action: "bypass" }, headers: { accept: { action: "normalize", media_types: ["text/html", "application/json"], }, "accept-language": { action: "normalize", languages: ["en", "fr", "de"], }, }, }, }, }); }, }; src/index.tstsexport default { async fetch(request): Promise<Response> { return fetch(request, { cf: { vary: { default: { action: "bypass" }, headers: { accept: { action: "normalize", media_types: ["text/html", "application/json"], }, "accept-language": { action: "normalize", languages: ["en", "fr", "de"], }, }, }, }, }); }, } satisfies ExportedHandler; For more information, refer to cf.vary.

Durable Objects now supports a us jurisdiction, letting you create Durable Objects that only run and store data within the United States. Use the us jurisdiction when you need to keep a Durable Object's compute and storage inside the United States to meet data residency requirements. Create a namespace restricted to the us jurisdiction the same way as any other jurisdiction: // Worker export default { async fetch(request, env) { const usSubnamespace = env.MY_DURABLE_OBJECT.jurisdiction("us"); const stub = usSubnamespace.getByName("general"); return stub.fetch(request); }, }; Workers may still access Durable Objects constrained to the us jurisdiction from anywhere in the world. The jurisdiction constraint only controls where the Durable Object itself runs and persists data. For the full list of supported jurisdictions, refer to Data location — Restrict Durable Objects to a jurisdiction.

The @cloudflare/vitest-pool-workers package now includes evictDurableObject and evictAllDurableObjects test helpers, exported from cloudflare:test. These helpers let you test how a Durable Object behaves across evictions, simulating the production lifecycle where an idle Durable Object can be evicted from memory. For more context, refer to Lifecycle of a Durable Object.

Durable Objects now supports two new location hints for Asia-Pacific: apac-ne (Northeast Asia-Pacific) and apac-se (Southeast Asia-Pacific). Use apac-ne or apac-se when you want finer-grained placement within Asia-Pacific rather than the broader apac hint. Use the new hints the same way as any other locationHint: // Northeast Asia-Pacific (Japan, Korea, etc.) const stubNE = env.MY_DURABLE_OBJECT.get(id, { locationHint: "apac-ne" }); // Southeast Asia-Pacific (Singapore, Indonesia, etc.) const stubSE = env.MY_DURABLE_OBJECT.get(id, { locationHint: "apac-se" }); If your users are spread across all of Asia-Pacific, the existing apac hint remains the right choice. Only reach for apac-ne or apac-se when your traffic is clearly concentrated in one sub-region and you want to minimize round-trip time to that audience.

You can create PlanetScale Postgres and MySQL databases from Cloudflare and bill PlanetScale database usage through your Cloudflare account as a pay-as-you-go customer. Cloudflare contract customers will be able to add PlanetScale usage to their contract in July so reach out to your Cloudflare account team if interested. Create a PlanetScale database from the Cloudflare dashboard to check out globally distributed Workers optimized for regional data access. Go to Create a PlanetScale database ↗ PlanetScale databases created from Cloudflare work with Workers through Hyperdrive. Hyperdrive manages database connection pools and query caching, so you can use PlanetScale as a centralized relational database for Workers applications without changing your database drivers, object-relational mapping (ORM) libraries, or SQL tooling.

You can now create custom trace spans in your Workers code using tracing.enterSpan(). Custom spans appear alongside the automatic platform instrumentation (fetch calls, KV reads, D1 queries, and other platform operations) in your traces and OpenTelemetry exports, with correct parent-child nesting. The API is available via import { tracing } from "cloudflare:workers" or through the handler context as ctx.tracing: import { tracing } from "cloudflare:workers"; export default { async fetch(request, env, ctx) { return tracing.enterSpan("handleRequest", async (span) => { span.setAttribute("url.path", new URL(request.url).pathname); const data = await env.MY_KV.get("key"); return new Response(data); }); }, }; Spans nest automatically based on the JavaScript async context, and are auto-ended when the callback returns or its returned promise settles.

You can now filter the Metrics tab for a Durable Objects namespace by an individual Durable Object's ID or name in the Cloudflare dashboard. Previously, metrics charts only showed aggregate, namespace-level data, making it difficult to isolate the behavior of a specific object. Go to Durable Objects ↗ Start typing an ID or name into the filter and select a match from the autocomplete dropdown. The autocomplete only shows objects with invocations during the selected time range, so an object that does not appear has not been invoked in that window. This does not necessarily mean the object has been deleted. Every chart on the page updates to reflect only the selected object. This makes it easier to identify and investigate a single Durable Object when debugging a high-traffic object, an error spike, or unexpected storage usage. Clear the filter to return to namespace-level metrics.

Customers can now view the number of Dynamic Workers invoked during their billing period from the Workers overview page in the Cloudflare dashboard. This count reflects the number of Dynamic Workers that Cloudflare would bill for during the selected billing period. Dynamic Workers usage data only goes back to June 1, 2026. You can also query this count through the GraphQL Analytics API by using workersInvocationsByOwnerAndScriptGroups and selecting distinctDynamicWorkerCount: query getDynamicWorkersCount( $accountTag: string!