Blog

A new Beta release for the macOS WARP client is now available on the beta releases downloads page.

This release contains minor fixes and improvements.

Changes and improvements

• The Local Domain Fallback feature has been fixed for devices running WARP client version 2025.4.929.0 and newer. Previously, these devices could experience failures with Local Domain Fallback unless a fallback server was explicitly configured. This configuration is no longer a requirement for the feature to function correctly.
• Proxy mode now supports transparent HTTP proxying in addition to CONNECT-based proxying.

The Cloudflare Vite plugin now supports programmatic configuration of Workers without a Wrangler configuration file. You can use the config option to define Worker settings directly in your Vite configuration, or to modify existing configuration loaded from a Wrangler config file. This is particularly useful when integrating with other build tools or frameworks, as it allows them to control Worker configuration without needing users to manage a separate config file.

The config option

The Vite plugin’s new config option accepts either a partial configuration object or a function that receives the current configuration and returns overrides. This option is applied after any config file is loaded, allowing the plugin to override specific values or define Worker configuration entirely in code.

Example usage

Setting config to an object to provide configuration values that merge with defaults and config file settings:

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
  plugins: [
    cloudflare({
      config: {
        name: "my-worker",
        compatibility_flags: ["nodejs_compat"],
        send_email: [
          {
            name: "EMAIL",
          },
        ],
      },
    }),
  ],
});

Use a function to modify the existing configuration:

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";
export default defineConfig({
  plugins: [
    cloudflare({
      config: (userConfig) => {
        delete userConfig.compatibility_flags;
      },
    }),
  ],
});

Return an object with values to merge:

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
  plugins: [
    cloudflare({
      config: (userConfig) => {
        if (!userConfig.compatibility_flags.includes("no_nodejs_compat")) {
          return { compatibility_flags: ["nodejs_compat"] };
        }
      },
    }),
  ],
});

Auxiliary Workers

Auxiliary Workers also support the config option, enabling multi-Worker architectures without config files.

Define auxiliary Workers without config files using config inside the auxiliaryWorkers array:

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
  plugins: [
    cloudflare({
      config: {
        name: "entry-worker",
        main: "./src/entry.ts",
        services: [{ binding: "API", service: "api-worker" }],
      },
      auxiliaryWorkers: [
        {
          config: {
            name: "api-worker",
            main: "./src/api.ts",
          },
        },
      ],
    }),
  ],
});

For more details and examples, see Programmatic configuration.

When using the Cloudflare Vite plugin to build and deploy Workers, a Wrangler configuration file is now optional for assets-only (static) sites. If no wrangler.toml, wrangler.json, or wrangler.jsonc file is found, the plugin generates sensible defaults for an assets-only site. The name is based on the package.json or the project directory name, and the compatibility_date uses the latest date supported by your installed Miniflare version.

This allows easier setup for static sites using Vite. Note that SPAs will still need to set assets.not_found_handling to single-page-application in order to function correctly.

Python Workers now feature improved cold start performance, reducing initialization time for new Worker instances.
This improvement is particularly noticeable for Workers with larger dependency sets or complex initialization logic.

Every time you deploy a Python Worker, a memory snapshot is captured after the top level of the Worker is executed.
This snapshot captures all imports, including package imports that are often costly to load. The memory snapshot is loaded
when the Worker is first started, avoiding the need to reload the Python runtime and all dependencies on each cold start.

We set up a benchmark that imports common packages (httpx,
fastapi and pydantic)
to see how Python Workers stack up against other platforms:

These benchmarks run continuously. You can view the results and the methodology on our benchmark page.

In additional testing, we have found that without any memory snapshot, the cold start for this benchmark takes around 10 seconds, so this change improves cold start performance by roughly a factor of 10.

To get started with Python Workers, check out our Python Workers overview.

We are introducing a brand new tool called Pywrangler, which simplifies package management in Python Workers by
automatically installing Workers-compatible Python packages into your project.

With Pywrangler, you specify your Worker’s Python dependencies in your pyproject.toml file:

[project]
name = "python-beautifulsoup-worker"
version = "0.1.0"
description = "A simple Worker using beautifulsoup4"
requires-python = ">=3.12"
dependencies = [
    "beautifulsoup4"
]

[dependency-groups]
dev = [
  "workers-py",
  "workers-runtime-sdk"
]

You can then develop and deploy your Worker using the following commands:

uv run pywrangler dev
uv run pywrangler deploy

Pywrangler automatically downloads and vendors the necessary packages for your Worker, and these packages are bundled with the Worker when you deploy.

Consult the Python packages documentation for full details on Pywrangler and Python package management in Workers.

We are reinstating the maximum request-payload size the Cloudflare WAF inspects to the following values:

Key Findings

On December 5, 2025, we initially attempted to increase the maximum WAF payload limit to 1 MB across all plans. However, an automatic rollout for all customers proved impractical because the increase led to a surge in false positives. This issue was particularly notable within the Cloudflare Managed Ruleset and the Cloudflare OWASP Core Ruleset, impacting customer traffic.

Consequently, we have decided to revert this change. Our Free plans will maintain the 1 MB limit as they are not experiencing an increase in false positives.

Impact

Customers on paid plans can increase the limit to 1 MB for any of their zones by contacting Cloudflare Support. Free zones are already protected up to 1 MB and do not require any action.

The initial increase in the size of the body inspected by the WAF may result in a higher rate of false positives being triggered in both the Cloudflare Managed Ruleset and the Cloudflare OWASP Core Ruleset. This higher rate should revert back to a normal value once the new limits are in place.

We are increasing the maximum request-payload size the WAF inspects to 1 MB across all plans. This enhancement strengthens our detection capabilities for React RCE (CVE-2025-55182) by ensuring the WAF can fully analyse React payloads up to their standard maximum size. Long term limits might change based on plans in the future.

Key Findings

React payloads commonly have a default maximum size of 1 MB. Cloudflare WAF previously inspected up to 128 KB on Enterprise plans, with even lower limits on other plans.

Impact

All WAF rules now evaluate up to 1 MB of request payload data, improving coverage and detection accuracy.

Workers applications now use reusable Cloudflare Access policies to reduce duplication and simplify access management across multiple Workers.

Previously, enabling Cloudflare Access on a Worker created per-application policies, unique to each application. Now, we create reusable policies that can be shared across applications:

• Preview URLs: All Workers preview URLs share a single “Cloudflare Workers Preview URLs” policy across your account. This policy is automatically created the first time you enable Access on any preview URL. By sharing a single policy across all preview URLs, you can configure access rules once and have them apply company-wide to all Workers which protect preview URLs. This makes it much easier to manage who can access preview environments without having to update individual policies for each Worker.

• Production workers.dev URLs: When enabled, each Worker gets its own reusable policy (named <worker-name> - Production) by default. We recognize production services often have different access requirements and having individual policies here makes it easier to configure service-to-service authentication or protect internal dashboards or applications with specific user groups. Keeping these policies separate gives you the flexibility to configure exactly the right access rules for each production service. When you disable Access on a production Worker, the associated policy is automatically cleaned up if it’s not being used by other applications.

This change reduces policy duplication, simplifies cross-company access management for preview environments, and provides the flexibility needed for production services. You can still customize access rules by editing the reusable policies in the Zero Trust dashboard.

To enable Cloudflare Access on your Worker:

1. In the Cloudflare dashboard, go to Workers & Pages.
2. Select your Worker.
3. Go to Settings > Domains & Routes.
4. For workers.dev or Preview URLs, click Enable Cloudflare Access.
5. Optionally, click Manage Cloudflare Access to customize the policy.

For more information on configuring Cloudflare Access for Workers, refer to the Workers Access documentation.

You can now connect directly to remote databases and databases requiring TLS with wrangler dev.
This lets you run your Worker code locally while connecting to remote databases, without needing to use wrangler dev --remote.

The localConnectionString field and CLOUDFLARE_HYPERDRIVE_LOCAL_CONNECTION_STRING_<BINDING_NAME> environment variable can be used to configure the connection string used by wrangler dev.

{
  "hyperdrive": [
    {
      "binding": "HYPERDRIVE",
      "id": "your-hyperdrive-id",
      "localConnectionString": "postgres://user:[email protected]:5432/database?sslmode=require"
    }
  ]
}

Learn more about local development with Hyperdrive.

The WAF rule deployed yesterday to block unsafe deserialization-based RCE has been updated. The rule description now reads “React – RCE – CVE-2025-55182”, explicitly mapping to the recently disclosed React Server Components vulnerability. Detection logic remains unchanged.

Key Findings

Rule description updated to reference React – RCE – CVE-2025-55182 while retaining existing unsafe-deserialization detection.

Impact

Improved classification and traceability with no change to coverage against remote code execution attempts.