Cloud intelligence

Enterprise customers can now configure a zone's CDN Maximum Upload Size up to 5 GB directly from the Network page in the Cloudflare dashboard. This removes the need to contact your account team or Cloudflare Support when applications need to accept request bodies larger than 500 MB and no greater than 5 GB. The default maximum upload size remains 500 MB. Upload limits above 5 GB still require additional configuration through your account team or Cloudflare Support. Very large uploads may reach connection or read timeouts before reaching the configured size limit. Make sure clients and origins allow enough time to complete the transfer when increasing this setting. Refer to Cache upload limits and Workers request body size limits for details.

Vercel opened Basic build machines to Pro and Enterprise teams on September 3. Each provides two virtual CPUs and 8 GB of memory, aimed at smaller applications or agents with lighter build requirements. Vercel lists a price of $0.007 per build minute. New paid projects still default to Elastic machines; Basic can be selected in settings or with CLI 59.6.0 and later.

Vercel added .app and .dev to its Pro domain promotion on September 2. The offer covers one eligible, non-premium domain per team for the first year, alongside six previously supported extensions. The benefit ends after that year: Vercel says the domain renews automatically at the regular price displayed when it is claimed, so the offer does not remove future renewal costs.

Python web frameworks following the Web Server Gateway Interface (WSGI) ↗︎ or Asynchronous Server Gateway Interface (ASGI) ↗︎ specification can now be used in Python Workers. Using web frameworks with Python Workers Based on the web framework you are using, you can use either wsgi or asgi from the workers module. WSGI frameworks For WSGI frameworks like Django or Flask: from workers import wsgi from django.core.wsgi import get_wsgi_application app = get_wsgi_application() Default = wsgi.entrypoint(app) The wsgi.entrypoint is equivalent to creating a WorkerEntrypoint class and using the wsgi.fetch method.

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.

Console methods now preserve exception details in your Worker's logs. When your Worker logs an exception, the corresponding log entry includes the exception name, message, and stack. For example, your Worker can catch and log an exception: try { throw new Error("Deliberately created exception"); } catch (error) { console.error("caught exception:", error); } try { throw new Error("Deliberately created exception"); } catch (error) { console.error("caught exception:", error); } If you use Workers Observability, your log is automatically enriched with structured error information. The following example shows how the enriched log appears in the Cloudflare dashboard: The exception's stack trace appears directly in the log message.

Durable Object namespaces now have a Deployments tab in the Cloudflare dashboard, showing the versions of the backing Worker that are currently live and the traffic split between them. Go to Durable Objects ↗ A Durable Object namespace is backed by a Worker script, so its deployments are the same as that Worker's deployments. Previously, checking on a gradual deployment in progress for a Durable Object meant navigating to the backing Worker. The new tab surfaces that information directly on the namespace, alongside the metrics that matter for it: requests, error rate, and wall time per version. The tab is read-only — promoting, rolling back, or splitting traffic on a deployment is still managed from the backing Worker's Deployments tab.

Version 1 of the Workers Vitest integration is published as @cloudflare/vitest-plugin ↗︎. The package was formerly named @cloudflare/vitest-pool-workers. The Vitest configuration API is unchanged. Existing projects must update the dependency name, package imports, and TypeScript types entries. To migrate automatically, run: npmyarnpnpm npx @cloudflare/codemods vitest:pool-workers-to-vitest-plugin yarn @cloudflare/codemods vitest:pool-workers-to-vitest-plugin pnpm @cloudflare/codemods vitest:pool-workers-to-vitest-plugin The codemod updates your dependency, imports, and test TypeScript configuration. For manual migration steps, refer to Migrate to Vitest plugin. For outbound request mocks in Workers tests, use the @msw/cloudflare ↗︎ integration. Refer to Mock outbound requests.

You now have two new ways to protect your Workers with Cloudflare Access. Protect an application across all its domains at once Until now, if a Worker was reachable on a route, a Custom Domain, and a workers.dev URL, you had to manually add each one to an Access application and keep the list in sync whenever routes or domains changed. Now, Access attaches the policy to the Worker itself, so every associated domain and preview URL stays protected even when its routes or domains change. Protect all new and existing Workers by default Make all Workers private by default, so every existing and newly created Worker requires sign-in before anyone can reach it. If a specific Worker should remain publicly accessible, add a Worker-level bypass to exempt it.

wrangler login now supports the OAuth 2.0 Device Authorization Grant ↗︎. Pass --device to authenticate without starting a temporary callback server on localhost:8976: npx wrangler login --device Wrangler prints a verification URL and a short user code, opens the URL in your default browser with the code already filled in, and polls Cloudflare for an access token while you approve the request: ⛅️ wrangler 4.119.0 ──────────────────── Attempting to login via OAuth Device Authorization Grant... To authorize Wrangler, please visit: https://dash.cloudflare.com/oauth2/device and enter the code: jPqK6Qvs You have 5 minutes to approve this request. Opening a link in your default browser: https://dash.cloudflare.com/oauth2/device?user_code=jPqK6Qvs Successfully logged in.

Workers now enable the nodejs_compat and nodejs_compat_v2 compatibility flags by default for compatibility dates of 2026-08-04 or later. These flags are not used for these compatibility dates because the compatibility date enables the same behavior. This means all Node.js built-in APIs supported by the Workers runtime are available by default, including node:crypto, node:buffer, node:stream, node:net, node:dns, node:fs, node:http, and more. npm packages that depend on these APIs will work without additional configuration. Workers using an earlier compatibility date are not affected. They can still opt in by adding nodejs_compat to compatibility_flags. New projects do not need to add either flag. Existing projects can update their compatibility date without removing them.

You can now call methods between Python and JavaScript Workers using Workers RPC. This works through Service bindings without extra dependencies, schema definitions, or serialization code. Cross-language RPC calls behave like ordinary function calls. Exceptions propagate to the call site. You can pass structured cloneable types ↗︎ as parameters or return values, and Pyodide Foreign Function Interface (FFI) automatically converts types between languages.

wrangler check startup now reports your Worker's raw and compressed bundle sizes. It also summarizes local CPU activity during startup directly in your terminal. Large bundles and costly startup work can introduce cold-start latency, so use this command to find code and large dependencies that slow your Worker before it handles requests. The summary includes sampled, active, garbage collection, and idle time. Wrangler continues to save a .cpuprofile file for detailed flamegraph analysis in Chrome DevTools or VS Code. ⛅️ wrangler 4.116.0 ─────────────────────────────────────────────── ├ Building your Worker │ Worker Built!

Workers Builds now uses Node.js 24.18.0 by default. The build image preinstalls Node.js 22.23.2 and 24.18.0. You can continue to override the default with the NODE_VERSION environment variable, an .nvmrc file, or a .node-version file. For more information, refer to Override default versions.

The Workers runtime now provides built-in tracing.startActiveSpan() and span.end() APIs, allowing you to write custom spans for operations that last beyond a single callback — for example, instrumenting a stream pipeline where the span should stay open until the stream is fully consumed. This augments the existing API for writing custom spans, tracing.enterSpan(), which automatically ends a span when its callback is returned.

Wrangler now provides createTestHarness(), an API for running integration tests against Workers built with Wrangler or the Cloudflare Vite plugin from any Node.js test runner. The test harness starts a local Worker server with helpers for dispatching requests, resetting storage, and inspecting runtime logs.

Workers Logs and OpenTelemetry spans for Durable Object requests include the Durable Object instance ID. Use $workers.durableObjectId to filter logs for a specific instance. Root and child spans include the same ID in cloudflare.durable_object.id. Use these fields to isolate a specific instance and correlate its logs and traces. For more information, refer to Durable Objects metrics and analytics and Workers tracing spans and attributes.

We are turning on budget alerts by default for eligible Pay-as-you-go accounts. If your account does not already have a budget alert, Cloudflare will create one for you with a $10 account-level threshold. Your default alert will enable at the turn of your next billing cycle, so it will not fire based on usage you have already incurred. We are rolling this out in cohorts over the coming weeks, so eligible accounts may see their default alert appear at different times. The default alert behaves exactly like an alert you would create yourself. When your cumulative usage-based spend this cycle reaches the threshold, you receive an email notification. The alert is informational only. It does not cap your usage or impact your account in any way. Usage is processed once per day for the prior day's activity, so budget alerts fire the day after the threshold is reached rather than in real time.

You can now monitor the total SQLite storage used by a Durable Object namespace over time in the Cloudflare dashboard. The new Total storage chart shows the maximum storage reported during each hour. This helps you identify storage growth, validate data cleanup, and investigate unexpected usage. Go to Durable Objects ↗ The chart appears only for SQLite-backed Durable Object namespaces. It does not appear for namespaces that use the legacy key-value storage backend. Viewing storage for individual Durable Objects by ID or name is not supported. For more information, refer to Metrics and analytics.

Platforms can now create temporary preview accounts through the Cloudflare REST API. This lets your platform deploy a live Worker before the user signs in to Cloudflare. With the Temporary Accounts API, coding agents, AI app builders, and other platforms can build a similar flow for generated Workers and supported resources. Your platform can keep users in its onboarding flow while they generate, deploy, and test an application. Users do not need an existing Cloudflare account, and your platform does not need write access to one. The API returns a claim URL that lets the user make the temporary account and its resources permanent. Cloudflare Drop ↗︎ demonstrates this preview-and-claim pattern for static sites. Someone can upload a site, test and share it for one hour, then sign in or create an account only when they want to keep it.

If your account does not already have a key-value (KV) backed Durable Object namespace, you can no longer create new ones. New Durable Object namespaces must use the SQLite storage backend, which has been recommended for all new Durable Objects since it became generally available ↗︎ in 2024. Create a new class with a new_sqlite_classes migration: { "$schema": "./node_modules/wrangler/config-schema.json", "migrations": [ { "tag": "v1", "new_sqlite_classes": [ "MyDurableObject" ] } ] } [[migrations]] tag = "v1" new_sqlite_classes = ["MyDurableObject"] SQLite-backed Durable Objects have feature parity with the key-value backend — including the key-value storage API — and additionally support relational SQL queries and point-in-time recovery to restore an object's storage to any point in the past 30 days.

Wrangler now collects npm package dependency information from your project's package.json during wrangler deploy and wrangler versions upload, and includes it in the upload metadata sent to the Cloudflare API. This data, each dependency's name, declared version range, and exact installed version, enables dependency analytics and future supply chain security features such as vulnerability alerting. To opt out, set dependencies_instrumentation.enabled to false in your Wrangler configuration file: { "dependencies_instrumentation": { "enabled": false } } [dependencies_instrumentation] enabled = false For more details, refer to Wrangler configuration.

Cloudflare Drop ↗︎ lets you deploy a static site to Cloudflare without requiring a Cloudflare account to get started. Upload a folder or zip file of static assets (static HTML, CSS, JavaScript, images, and fonts) and get a temporary live preview that stays live for 1 hour. During that window, you can test the site, share the preview URL, or claim the deployment to keep it. When you are ready to make the deployment permanent, click Claim to sign in or create a Cloudflare account. You can claim the site into an existing Cloudflare account or create a new account for the deployment. Note If you are creating a new account, you will need to verify your email address before continuing. After claiming the site, you can: Add a domain: Connect an existing domain or purchase a new one for your site. Enable observability: Monitor your site's performance and usage.

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.