Previously, a request to the Workers Create Route API always returned null for "script" and an empty string for "pattern" even if the request was successful.
The Workers and Workers for Platforms secrets APIs are now properly documented in the Cloudflare OpenAPI docs. Previously, these endpoints were not publicly documented, leaving users confused on how to directly manage their secrets via the API. Now, you can find the proper endpoints in our public documentation, as well as in our API Library SDKs such as cloudflare-typescript ↗︎ (>4.2.0) and cloudflare-python ↗︎ (>4.1.0).
Note the cloudflare_workers_secret and cloudflare_workers_for_platforms_script_secretTerraform resources ↗︎ are being removed in a future release. This resource is not recommended for managing secrets. Users should instead use the:
Secrets Store with the "Secrets Store Secret" binding on Workers and Workers for Platforms Script Upload
The Overview tab shows logs from all your Workers in one place. The Invocations view groups logs together by invocation, which refers to the specific trigger that started the execution of the Worker (i.e. fetch). The Events view shows logs in the order they were produced, based on timestamp. Previously, you could only view logs for a single Worker.
The Investigate tab presents a Query Builder, which helps you write structured queries to investigate and visualize your logs. The Query Builder can help answer questions such as:
Which paths are experiencing the most 5XX errors?
What is the wall time distribution by status code for my Worker?
What are the slowest requests, and where are they coming from?
Who are my top N users?
The Query Builder can use any field that you store in your logs as a key to visualize, filter, and group by. Use the Query Builder to quickly access your data, build visualizations, save queries, and share them with your team.
Workers Logs is now Generally Available
Workers Logs is now Generally Available. With a small change to your Wrangler configuration, Workers Logs ingests, indexes, and stores all logs emitted from your Workers for up to 7 days.
We've introduced a number of changes during our beta period, including:
Dashboard enhancements with customizable fields as columns in the Logs view and support for invocation-based grouping
Performance improvements to ensure no adverse impact
The API documents three endpoints: list the keys in the telemetry dataset, run a query, and list the unique values for a key. For more, visit our REST API documentation ↗︎.
Visit the docs to learn more about the capabilities and methods exposed by the Query Builder. Start using Workers Logs and the Query Builder today by enabling observability for your Workers:
For Workers Logpush, CPU and Wall time are surfaced at the top level of the Workers Trace Events object. All new jobs will have these new fields included by default. Existing jobs need to be updated to include CPU time and Wall time.
You can use a Workers Logs filter to search for logs where Wall time exceeds 100ms.
You can also use the Workers Observability Query Builder ↗︎ to find the median CPU time and median Wall time for all of your Workers.
You can now add a Deploy to Cloudflare button to the README of your Git repository containing a Workers application — making it simple for other developers to quickly set up and deploy your project!
The Deploy to Cloudflare button:
Creates a new Git repository on your GitHub/ GitLab account: Cloudflare will automatically clone and create a new repository on your account, so you can continue developing.
Automatically provisions resources the app needs: If your repository requires Cloudflare primitives like a Workers KV namespace, a D1 database, or an R2 bucket, Cloudflare will automatically provision them on your account and bind them to your Worker upon deployment.
Configures Workers Builds (CI/CD): Every new push to your production branch on your newly created repository will automatically build and deploy courtesy of Workers Builds.
To create a Deploy to Cloudflare button in your README, you can add the following snippet, including your Git repository URL:
[](https://deploy.workers.cloudflare.com/?url=<YOUR_GIT_REPO_URL>)
Check out our documentation for more information on how to set up a deploy button for your application and best practices to ensure a successful deployment for other developers.
When you use @cloudflare/vite-plugin, you can use Vite's local development server and build tooling, while ensuring that while developing, your code runs in workerd ↗︎, the open-source Workers runtime.
This lets you get the best of both worlds for a full-stack app — you can use Hot Module Replacement ↗︎ from Vite right alongside Durable Objects and other runtime APIs and bindings that are unique to Cloudflare Workers.
You can build any type of application with @cloudflare/vite-plugin, using any rendering mode, from single page applications (SPA) and static sites to server-side rendered (SSR) pages and API routes.
React Router v7 (Remix) is the first full-stack framework to provide full support for Cloudflare Vite plugin, allowing you to use all parts of Cloudflare's developer platform, without additional build steps.
You can also build complete full-stack apps on Workers without a framework — "just use Vite" ↗︎ and React together, and build a back-end API in the same Worker. Follow our React SPA with an API tutorial to learn how.
Configuration
If you're already using Vite ↗︎ in your build and development toolchain, you can start using our plugin with minimal changes to your vite.config.ts:
vite.config.tsts
import { defineConfig } from "vite";import { cloudflare } from "@cloudflare/vite-plugin";export default defineConfig({ plugins: [cloudflare()],});
You can now capture a maximum of 256 KB of log events per Workers invocation, helping you gain better visibility into application behavior.
All console.log() statements, exceptions, request metadata, and headers are automatically captured during the Worker invocation and emitted
as JSON object. Workers Logs deserializes
this object before indexing the fields and storing them. You can also capture, transform, and export the JSON object in a
Tail Worker.
256 KB is a 2x increase from the previous 128 KB limit. After you exceed this limit, further context associated with the request will not be
recorded in your logs.
This limit is automatically applied to all Workers.
You can now run a Worker for up to 5 minutes of CPU time for each request.
Previously, each Workers request ran for a maximum of 30 seconds of CPU time — that is the time that a Worker is actually performing a task (we still allowed unlimited wall-clock time, in case you were waiting on slow resources). This
meant that some compute-intensive tasks were impossible to do with a Worker. For instance,
you might want to take the cryptographic hash of a large file from R2. If
this computation ran for over 30 seconds, the Worker request would have timed out.
By default, Workers are still limited to 30 seconds of CPU time. This protects developers
from incurring accidental cost due to buggy code.
By changing the cpu_ms value in your Wrangler configuration, you can opt in to
any value up to 300,000 (5 minutes).
{ // ...rest of your configuration... "limits": { "cpu_ms": 300000, }, // ...rest of your configuration...}
Source maps are now Generally Available (GA). You can now be uploaded with a maximum gzipped size of 15 MB.
Previously, the maximum size limit was 15 MB uncompressed.
Source maps help map between the original source code and the transformed/minified code that gets deployed
to production. By uploading your source map, you allow Cloudflare to map the stack trace from exceptions
onto the original source code making it easier to debug.
With no source maps uploaded: notice how all the Javascript has been minified to one file, so the stack trace is missing information on file name, shows incorrect line numbers, and incorrectly references js instead of ts.
With source maps uploaded: all methods reference the correct files and line numbers.
Uploading source maps and stack trace remapping happens out of band from the Worker execution,
so source maps do not affect upload speed, bundle size, or cold starts. The remapped stack
traces are accessible through Tail Workers, Workers Logs, and Workers Logpush.
To enable source maps, add the following to your
Pages Function's or Worker's wrangler configuration:
Update: Mon Mar 24th, 11PM UTC: Next.js has made further changes to address a smaller vulnerability introduced in the patches made to its middleware handling. Users should upgrade to Next.js versions 15.2.4, 14.2.26, 13.5.10 or 12.3.6. If you are unable to immediately upgrade or are running an older version of Next.js, you can enable the WAF rule described in this changelog as a mitigation.
Update: Mon Mar 24th, 8PM UTC: Next.js has now backported the patch for this vulnerability ↗︎ to cover Next.js v12 and v13. Users on those versions will need to patch to 13.5.9 and 12.3.5 (respectively) to mitigate the vulnerability.
Update: Sat Mar 22nd, 4PM UTC: We have changed this WAF rule to opt-in only, as sites that use auth middleware with third-party auth vendors were observing failing requests.
We strongly recommend updating your version of Next.js (if eligible) to the patched versions, as your app will otherwise be vulnerable to an authentication bypass attack regardless of auth provider.
Enable the Managed Rule (strongly recommended)
This rule is opt-in only for sites on the Pro plan or above in the WAF managed ruleset.
To enable the rule:
Head to Security > WAF > Managed rules in the Cloudflare dashboard for the zone (website) you want to protect.
Click the three dots next to Cloudflare Managed Ruleset and choose Edit
Scroll down and choose Browse Rules
Search for CVE-2025-29927 (ruleId: 34583778093748cc83ff7b38f472013e)
Change the Status to Enabled and the Action to Block. You can optionally set the rule to Log, to validate potential impact before enabling it. Log will not block requests.
Click Next
Scroll down and choose Save
This will enable the WAF rule and block requests with the x-middleware-subrequest header regardless of Next.js version.
Create a WAF rule (manual)
For users on the Free plan, or who want to define a more specific rule, you can create a Custom WAF rule to block requests with the x-middleware-subrequest header regardless of Next.js version.
To create a custom rule:
Head to Security > WAF > Custom rules in the Cloudflare dashboard for the zone (website) you want to protect.
Give the rule a name - e.g. next-js-CVE-2025-29927
Set the matching parameters for the rule match any request where the x-middleware-subrequest header exists per the rule expression below.
Set the action to 'block'. If you want to observe the impact before blocking requests, set the action to 'log' (and edit the rule later).
Deploy the rule.
Next.js CVE-2025-29927
We've made a WAF (Web Application Firewall) rule available to all sites on Cloudflare to protect against the Next.js authentication bypass vulnerability ↗︎ (CVE-2025-29927) published on March 21st, 2025.
Note: This rule is not enabled by default as it blocked requests across sites for specific authentication middleware.
This managed rule protects sites using Next.js on Workers and Pages, as well as sites using Cloudflare to protect Next.js applications hosted elsewhere.
This rule has been made available (but not enabled by default) to all sites as part of our WAF Managed Ruleset and blocks requests that attempt to bypass authentication in Next.js applications.
The vulnerability affects almost all Next.js versions, and has been fully patched in Next.js 14.2.26 and 15.2.4. Earlier, interim releases did not fully patch this vulnerability.
Users on older versions of Next.js (11.1.4 to 13.5.6) did not originally have a patch available, but this the patch for this vulnerability and a subsequent additional patch have been backported to Next.js versions 12.3.6 and 13.5.10 as of Monday, March 24th. Users on Next.js v11 will need to deploy the stated workaround or enable the WAF rule.
The managed WAF rule mitigates this by blocking external user requests with the x-middleware-subrequest header regardless of Next.js version, but we recommend users using Next.js 14 and 15 upgrade to the patched versions of Next.js as an additional mitigation.
Smart Placement is a unique Cloudflare feature that can make decisions to move your Worker to run in a more optimal location (such as closer to a database). Instead of always running in the default location (the one closest to where the request is received), Smart Placement uses certain “heuristics” (rules and thresholds) to decide if a different location might be faster or more efficient.
Previously, if these heuristics weren't consistently met, your Worker would revert to running in the default location—even after it had been optimally placed. This meant that if your Worker received minimal traffic for a period of time, the system would reset to the default location, rather than remaining in the optimal one.
Now, once Smart Placement has identified and assigned an optimal location, temporarily dropping below the heuristic thresholds will not force a return to default locations. For example in the previous algorithm, a drop in requests for a few days might return to default locations and heuristics would have to be met again. This was problematic for workloads that made requests to a geographically located resource every few days or longer. In this scenario, your Worker would never get placed optimally. This is no longer the case.
You can now access bindings
from anywhere in your Worker by importing the env object from cloudflare:workers.
Previously, env could only be accessed during a request. This meant that
bindings could not be used in the top-level context of a Worker.
Now, you can import env and access bindings such as secrets
or environment variables in the
initial setup for your Worker:
import { env } from "cloudflare:workers";import ApiClient from "example-api-client";// API_KEY and LOG_LEVEL now usable in top-level scopeconst apiClient = ApiClient.new({ apiKey: env.API_KEY });const LOG_LEVEL = env.LOG_LEVEL || "info";export default { fetch(req) { // you can use apiClient or LOG_LEVEL, configured before any request is handled },};
Additionally, env was normally accessed as a argument to a Worker's entrypoint handler,
such as fetch.
This meant that if you needed to access a binding from a deeply nested function,
you had to pass env as an argument through many functions to get it to the
right spot. This could be cumbersome in complex codebases.
Now, you can access the bindings from anywhere in your codebase
without passing env as an argument:
// helpers.jsimport { env } from "cloudflare:workers";// env is *not* an argument to this functionexport async function getValue(key) { let prefix = env.KV_PREFIX; return await env.KV.get(`${prefix}-${key}`);}
You can now retry your Cloudflare Pages and Workers builds directly from GitHub. No need to switch to the Cloudflare Dashboard for a simple retry!
Let\u2019s say you push a commit, but your build fails due to a spurious error like a network timeout. Instead of going to the Cloudflare Dashboard to manually retry, you can now rerun the build with just a few clicks inside GitHub, keeping you inside your workflow.
For Pages and Workers projects connected to a GitHub repository:
When a build fails, go to your GitHub repository or pull request
Select the failed Check Run for the build
Select "Details" on the Check Run
Select "Rerun" to trigger a retry build for that commit
We've released the next major version of Wrangler, the CLI for Cloudflare Workers — wrangler@4.0.0. Wrangler v4 is a major release focused on updates to underlying systems and dependencies, along with improvements to keep Wrangler commands consistent and clear.
You can run the following command to install it in your projects:
npm i wrangler@latest
yarn add wrangler@latest
pnpm add wrangler@latest
bun add wrangler@latest
Unlike previous major versions of Wrangler, which were foundational rewrites ↗︎ and rearchitectures ↗︎ — Version 4 of Wrangler includes a much smaller set of changes. If you use Wrangler today, your workflow is very unlikely to change.
Going forward, we'll continue supporting Wrangler v3 with bug fixes and security updates until Q1 2026, and with critical security updates until Q1 2027, at which point it will be out of support.
You can now debug your Workers tests with our Vitest integration by running the following command:
vitest --inspect --no-file-parallelism
Attach a debugger to the port 9229 and you can start stepping through your Workers tests. This is available with @cloudflare/vitest-pool-workers v0.7.5 or later.
In Node.js, environment variables are exposed via the global process.env object. Some libraries
assume that this object will be populated, and many developers may be used to accessing variables
in this way.
Previously, the process.env object was always empty unless written to in Worker code. This could
cause unexpected errors or friction when developing Workers using code previously written for Node.js.
To opt-in to the new process.env behaviour now, add the nodejs_compat_populate_process_env compatibility flag to your
wrangler.json configuration:
{ // Rest of your configuration // Add "nodejs_compat_populate_process_env" to your compatibility_flags array "compatibility_flags": ["nodejs_compat", "nodejs_compat_populate_process_env"], // Rest of your configuration
After April 1, 2025, populating process.env will become the default behavior when both nodejs_compat is enabled and
your Worker's compatibility_date is after "2025-04-01".
We've released a release candidate of the next major version of Wrangler, the CLI for Cloudflare Workers — wrangler@4.0.0-rc.0.
You can run the following command to install it and be one of the first to try it out:
npm i wrangler@v4-rc
yarn add wrangler@v4-rc
pnpm add wrangler@v4-rc
bun add wrangler@v4-rc
Unlike previous major versions of Wrangler, which were foundational rewrites ↗︎ and rearchitectures ↗︎ — Version 4 of Wrangler includes a much smaller set of changes. If you use Wrangler today, your workflow is very unlikely to change. Before we release Wrangler v4 and advance past the release candidate stage, we'll share a detailed migration guide in the Workers developer docs. But for the vast majority of cases, you won't need to do anything to migrate — things will just work as they do today. We are sharing this release candidate in advance of the official release of v4, so that you can try it out early and share feedback.
New JavaScript language features that you can now use with Wrangler v4
Version 4 of Wrangler updates the version of esbuild ↗︎ that Wrangler uses internally, allowing you to use modern JavaScript language features, including:
The using keyword from Explicit Resource Management
function sendEmail(id, message) { using user = await env.USER_SERVICE.findUser(id); await user.sendEmail(message); // user[Symbol.dispose]() is implicitly called at the end of the scope.}
Import attributes
Import attributes ↗︎ allow you to denote the type or other attributes of the module that your code imports. For example, you can import a JSON module, using the following syntax:
import data from "./data.json" with { type: "json" };
Other changes
--local is now the default for all CLI commands
All commands that access resources (for example, wrangler kv, wrangler r2, wrangler d1) now access local datastores by default, ensuring consistent behavior.
Clearer policy for the minimum required version of Node.js required to run Wrangler
Moving forward, the active, maintenance, and current versions of Node.js ↗︎ will be officially supported by Wrangler. This means the minimum officially supported version of Node.js you must have installed for Wrangler v4 will be Node.js v18 or later. This policy mirrors how many other packages and CLIs support older versions of Node.js, and ensures that as long as you are using a version of Node.js that the Node.js project itself supports, this will be supported by Wrangler as well.
Features previously deprecated in Wrangler v3 are now removed in Wrangler v4
All previously deprecated features in Wrangler v2 ↗︎ and in Wrangler v3 ↗︎ have now been removed. Additionally, the following features that were deprecated during the Wrangler v3 release have been removed:
Legacy Assets (using wrangler dev/deploy --legacy-assets or the legacy_assets config file property). Instead, we recommend you migrate to Workers assets ↗︎.
Legacy Node.js compatibility (using wrangler dev/deploy --node-compat or the node_compat config file property). Instead, use the nodejs_compat compatibility flag ↗︎. This includes the functionality from legacy node_compat polyfills and natively implemented Node.js APIs.
wrangler version. Instead, use wrangler --version to check the current version of Wrangler.
getBindingsProxy() (via import { getBindingsProxy } from "wrangler"). Instead, use the getPlatformProxy() API ↗︎, which takes exactly the same arguments.
Small misconfigurations shouldn’t break your deployments. Cloudflare is introducing automatic error detection and fixes in Workers Builds, identifying common issues in your wrangler.toml or wrangler.jsonc and proactively offering fixes, so you spend less time debugging and more time shipping.
Here's how it works:
Before running your build, Cloudflare checks your Worker's Wrangler configuration file (wrangler.toml or wrangler.jsonc) for common errors.
Once you submit a build, if Cloudflare finds an error it can fix, it will submit a pull request to your repository that fixes it.
Once you merge this pull request, Cloudflare will run another build.
We're starting with fixing name mismatches between your Wrangler file and the Cloudflare dashboard, a top cause of build failures.
This is just the beginning, we want your feedback on what other errors we should catch and fix next. Let us know in the Cloudflare Developers Discord, #workers-and-pages-feature-suggestions ↗︎.
Importing a Git repository: Choose an existing Git repo on your GitHub/GitLab account and set up Workers Builds to deploy your Worker.
Deploying a template with Git: Choose from a brand new selection of production ready examples ↗︎ to help you get started with popular frameworks like Astro ↗︎, Remix ↗︎ and Next ↗︎ or build stateful applications with Cloudflare resources like D1 databases, Workers AI or Durable Objects! When you're ready to deploy, Cloudflare will set up your project by cloning the template to your GitHub/GitLab account, provisioning any required resources and deploying your Worker.
With every push to your chosen branch, Cloudflare will automatically build and deploy your Worker.
These new features are available today in the Cloudflare dashboard to a subset of Cloudflare customers, and will be coming to all customers in the next few weeks. Don't see it in your dashboard, but want early access? Add your Cloudflare Account ID to this form ↗︎.
Now you can easily compare metrics across Worker versions, understand the current state of a gradual deployment, and review key Workers metrics in a single view. This new interface enables you to:
Drag-and-select using a graphical timepicker for precise metric selection.
Use histograms to visualize cumulative metrics, allowing you to bucket and compare rates over time.
Focus on Worker versions by directly interacting with the version numbers in the legend.
Monitor and compare active gradual deployments.
Track error rates across versions with grouping both by version and by invocation status.
This can be helpful in a variety of situations. For instance, you may have a Worker in front of an origin,
and want to replace an element with content from a different source. Prior to this change, you would have to load
all of the content from the upstream URL and convert it into a string before replacing the element. This slowed
down overall response times.
Now, you can pass the Response object directly into the replace method, and HTMLRewriter will immediately
start replacing the content as it is streamed in. This makes responses faster.
index.jsjs
class ElementRewriter { async element(element) { // able to replace elements while streaming content // the fetched body is not buffered into memory as part // of the replace let res = await fetch("https://upstream-content-provider.example"); element.replace(res); }}export default { async fetch(request, env, ctx) { let response = await fetch("https://site-to-replace.com"); return new HTMLRewriter() .on("[data-to-replace]", new ElementRewriter()) .transform(response); },};
index.tsts
class ElementRewriter { async element(element: any) { // able to replace elements while streaming content // the fetched body is not buffered into memory as part // of the replace let res = await fetch('https://upstream-content-provider.example'); element.replace(res); }}export default { async fetch(request, env, ctx): Promise<Response> { let response = await fetch('https://site-to-replace.com'); return new HTMLRewriter().on('[data-to-replace]', new ElementRewriter()).transform(response); },} satisfies ExportedHandler<Env>;
import dns from "node:dns";let response = await dns.promises.resolve4("cloudflare.com", "NS");
index.tsts
import dns from 'node:dns';let response = await dns.promises.resolve4('cloudflare.com', 'NS');
All node:dns functions are available, except lookup, lookupService, and resolve which throw "Not implemented" errors when called.
node:timers
You can use node:timers ↗︎ to schedule functions to be called at some future period of time.
This includes setTimeout ↗︎ for calling a function after a delay,
setInterval ↗︎ for calling a function repeatedly,
and setImmediate ↗︎ for calling a function in the next iteration of the event loop.
Workers Builds, the integrated CI/CD system for Workers (currently in beta), now lets you cache artifacts across builds, speeding up build jobs by eliminating repeated work, such as downloading dependencies at the start of each build.
Build Caching: Cache dependencies and build outputs between builds with a shared project-wide cache, ensuring faster builds for the entire team.
Build Watch Paths: Define paths to include or exclude from the build process, ideal for monorepos to target only the files that need to be rebuilt per Workers project.
To get started, select your Worker on the Cloudflare dashboard ↗︎ then go to Settings > Builds, and connect a GitHub or GitLab repository. Once connected, you'll see options to configure Build Caching and Build Watch Paths.
When you set the value to no-store on a subrequest made from a Worker, the Cloudflare Workers runtime will not check whether a match exists in the cache, and not add the response to the cache, even if the response includes directives in the Cache-Control HTTP header that otherwise indicate that the response is cacheable.
This increases compatibility with NPM packages and JavaScript frameworks that rely on setting the cache property, which is a cross-platform standard part of the Request interface. Previously, if you set the cache property on Request, the Workers runtime threw an exception.
If you've tried to use @planetscale/database, redis-js, stytch-node, supabase, axiom-js or have seen the error message The cache field on RequestInitializerDict is not implemented in fetch — you should try again, making sure that the Compatibility Date of your Worker is set to on or after 2024-11-11, or the cache_option_enabled compatibility flag is enabled for your Worker.
