Skip to content
Cloudflare Docs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS
View all RSS feeds

hero image

  1. Playwright for Browser Rendering now available

    Browser Rendering

    We're excited to share that you can now use Playwright's browser automation capabilities ↗ from Cloudflare Workers.

    Playwright ↗ is an open-source package developed by Microsoft that can do browser automation tasks; it's commonly used to write software tests, debug applications, create screenshots, and crawl pages. Like Puppeteer, we forked ↗ Playwright and modified it to be compatible with Cloudflare Workers and Browser Rendering ↗.

    Below is an example of how to use Playwright with Browser Rendering to test a TODO application using assertions:

    Assertion example
    import type { Fetcher } from '@cloudflare/workers-types';
    import { launch } from '@cloudflare/playwright';
    import { expect } from '@cloudflare/playwright/test';
    

    interface Env {
      MYBROWSER: Fetcher;
    }
    

    export default {
      async fetch(request: Request, env: Env) {
    

        const browser = await launch(env.MYBROWSER);
        const page = await browser.newPage();
    

        await page.goto('https://demo.playwright.dev/todomvc');
    

        const TODO_ITEMS = todos.length > 0 ? todos : [
            'buy some cheese',
            'feed the cat',
            'book a doctors appointment'
        ];
    

        const newTodo = page.getByPlaceholder('What needs to be done?');
        for (const item of TODO_ITEMS) {
            await newTodo.fill(item);
            await newTodo.press('Enter');
        }
    

        await expect(page.getByTestId('todo-title')).toHaveCount(TODO_ITEMS.length);
    

        await Promise.all(TODO_ITEMS.map(
            (value, index) => expect(page.getByTestId('todo-title').nth(index)).toHaveText(value)
        ));
      },
    };

    Playwright is available as an npm package at @cloudflare/playwright ↗ and the code is at GitHub ↗.

    Learn more in our documentation.

  1. All cache purge methods now available for all plans

    Cache / CDN

    You can now access all Cloudflare cache purge methods — no matter which plan you’re on. Whether you need to update a single asset or instantly invalidate large portions of your site’s content, you now have the same powerful tools previously reserved for Enterprise customers.

    Anyone on Cloudflare can now:

    1. Purge Everything: Clears all cached content associated with a website.
    2. Purge by Prefix: Targets URLs sharing a common prefix.
    3. Purge by Hostname: Invalidates content by specific hostnames.
    4. Purge by URL (single-file purge): Precisely targets individual URLs.
    5. Purge by Tag: Uses Cache-Tag response headers to invalidate grouped assets, offering flexibility for complex cache management scenarios.

    Want to learn how each purge method works, when to use them, or what limits apply to your plan? Dive into our purge cache documentation and API reference ↗ for all the details.

  1. New Pause & Purge APIs for Queues

    Queues

    Queues now supports the ability to pause message delivery and/or purge (delete) messages on a queue. These operations can be useful when:

    • Your consumer has a bug or downtime, and you want to temporarily stop messages from being processed while you fix the bug
    • You have pushed invalid messages to a queue due to a code change during development, and you want to clean up the backlog
    • Your queue has a backlog that is stale and you want to clean it up to allow new messages to be consumed

    To pause a queue using Wrangler, run the pause-delivery command. Paused queues continue to receive messages. And you can easily unpause a queue using the resume-delivery command.

    Pause and resume a queue
    $ wrangler queues pause-delivery my-queue
    Pausing message delivery for queue my-queue.
    Paused message delivery for queue my-queue.
    

    $ wrangler queues resume-delivery my-queue
    Resuming message delivery for queue my-queue.
    Resumed message delivery for queue my-queue.

    Purging a queue permanently deletes all messages in the queue. Unlike pausing, purging is an irreversible operation:

    Purge a queue
    $ wrangler queues purge my-queue
    ✔ This operation will permanently delete all the messages in queue my-queue. Type my-queue to proceed. … my-queue
    Purged queue 'my-queue'

    You can also do these operations using the Queues REST API, or the dashboard page for a queue.

    Pause and purge using the dashboard

    This feature is available on all new and existing queues. Head over to the pause and purge documentation to learn more. And if you haven't used Cloudflare Queues before, get started with the Cloudflare Queues guide.

  1. Audit logs (version 2) - Beta Release

    Audit Logs

    The latest version of audit logs streamlines audit logging by automatically capturing all user and system actions performed through the Cloudflare Dashboard or public APIs. This update leverages Cloudflare’s existing API Gateway to generate audit logs based on OpenAPI schemas, ensuring a more consistent and automated logging process.

    Availability: Audit logs (version 2) is now in Beta, with support limited to API access.

    Use the following API endpoint to retrieve audit logs:

    GET https://api.cloudflare.com/client/v4/accounts/<account_id>/logs/audit?since=<date>&before=<date>

    You can access detailed documentation for audit logs (version 2) Beta API release here ↗.

    Key Improvements in the Beta Release:

    • Automated & standardized logging: Logs are now generated automatically using a standardized system, replacing manual, team-dependent logging. This ensures consistency across all Cloudflare services.

    • Expanded product coverage: Increased audit log coverage from 75% to 95%. Key API endpoints such as /accounts, /zones, and /organizations are now included.

    • Granular filtering: Logs now follow a uniform format, enabling precise filtering by actions, users, methods, and resources—allowing for faster and more efficient investigations.

    • Enhanced context and traceability: Each log entry now includes detailed context, such as the authentication method used, the interface (API or Dashboard) through which the action was performed, and mappings to Cloudflare Ray IDs for better traceability.

    • Comprehensive activity capture: Expanded logging to include GET requests and failed attempts, ensuring that all critical activities are recorded.

    Known Limitations in Beta

    • Error handling for the API is not implemented.
    • There may be gaps or missing entries in the available audit logs.
    • UI is unavailable in this Beta release.
    • System-level logs and User-Activity logs are not included.

    Support for these features is coming as part of the GA release later this year. For more details, including a sample audit log, check out our blog post: Introducing Automatic Audit Logs ↗

  1. Register and renew .ai and .shop domains at cost

    Registrar

    Example search for .ai domains

    Cloudflare Registrar now supports .ai and .shop domains. These are two of our most highly-requested top-level domains (TLDs) and are great additions to the 300+ other TLDs we support ↗.

    Starting today, customers can:

    • Register and renew these domains at cost without any markups or add-on fees
    • Enjoy best-in-class security and performance with native integrations with Cloudflare DNS, CDN, and SSL services like one-click DNSSEC
    • Combat domain hijacking with Custom Domain Protection ↗ (available on enterprise plans)

    We can't wait to see what AI and e-commerce projects you deploy on Cloudflare. To get started, transfer your domains to Cloudflare or search for new ones to register ↗.

  1. Run Workers for up to 5 minutes of CPU-time

    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...
    }

    For more information on the updates limits, see the documentation on Wrangler configuration for cpu_ms and on Workers CPU time limits.

    For building long-running tasks on Cloudflare, we also recommend checking out Workflows and Queues.

  1. Updates to Account Home - Quick actions, traffic insights, Workers projects, and more

    Cloudflare Fundamentals

    Updated Account Home

    Recently, Account Home has been updated to streamline your workflows:

    • Recent Workers projects: You'll now find your projects readily accessible from a new Developer Platform tab on Account Home. See recently-modified projects and explore what you can work our developer-focused products.

    • Traffic and security insights: Get a snapshot of domain performance at a glance with key metrics and trends.

    • Quick actions: You can now perform common actions for your account, domains, and even Workers in just 1-2 clicks from the 3-dot menu.

    • Keep starred domains front and center: Now, when you filter for starred domains on Account Home, we'll save your preference so you'll continue to only see starred domains by default.

    We can't wait for you to take the new Account Home for a spin.

    For more info:

  1. Source Maps are Generally Available

    Workers

    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.

    Stack Trace without Source Map remapping

    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.

    Stack Trace with Source Map remapping

    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:

    {
      "upload_source_maps": true
    }

  1. New Managed WAF rule for Next.js CVE-2025-29927.

    Workers Pages WAF Rules

    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.

    This rule is opt-in only for sites on the Pro plan or above in the WAF managed ruleset.

    To enable the rule:

    1. Head to Security > WAF > Managed rules in the Cloudflare dashboard for the zone (website) you want to protect.
    2. Click the three dots next to Cloudflare Managed Ruleset and choose Edit
    3. Scroll down and choose Browse Rules
    4. Search for CVE-2025-29927 (ruleId: 34583778093748cc83ff7b38f472013e)
    5. 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.
    6. Click Next
    7. Scroll down and choose Save
    Enable the CVE-2025-29927 rule

    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:

    1. Head to Security > WAF > Custom rules in the Cloudflare dashboard for the zone (website) you want to protect.
    2. Give the rule a name - e.g. next-js-CVE-2025-29927
    3. Set the matching parameters for the rule match any request where the x-middleware-subrequest header exists per the rule expression below.
    Terminal window
    (len(http.request.headers["x-middleware-subrequest"]) > 0)
    1. 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).
    2. Deploy the rule.
    Next.js CVE-2025-29927 WAF 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.

  1. Secure DNS Locations Management User Role

    Gateway

    We’re excited to introduce the Cloudflare Zero Trust Secure DNS Locations Write role, designed to provide DNS filtering customers with granular control over third-party access when configuring their Protective DNS (PDNS) solutions.​

    Many DNS filtering customers rely on external service partners to manage their DNS location endpoints. This role allows you to grant access to external parties to administer DNS locations without overprovisioning their permissions.​

    Secure DNS Location Requirements:

    • Mandate usage of Bring your own DNS resolver IP addresses ↗ if available on the account.​

    • Require source network filtering for IPv4/IPv6/DoT endpoints; token authentication or source network filtering for the DoH endpoint.​

    You can assign the new role via Cloudflare Dashboard (Manage Accounts > Members) or via API. For more information, refer to the Secure DNS Locations documentation ↗.