Skip to content
Cloudflare Docs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS
View all RSS feeds

Select...
hero image

  1. Browser Isolation Overview page for Zero Trust

    Browser Isolation

    A new Browser Isolation Overview page is now available in the Cloudflare Zero Trust dashboard. This centralized view simplifies the management of Remote Browser Isolation (RBI) deployments, providing:

    This update consolidates previously disparate settings, accelerating deployment, improving visibility into isolation activity, and making it easier to ensure your protections are working effectively.

    Browser Isolation Overview

    To access the new overview, log in to your Cloudflare Zero Trust dashboard ↗ and find Browser Isolation in the side navigation bar.

  1. Dark Mode for Zero Trust Dashboard

    Cloudflare Zero Trust

    The Cloudflare Zero Trust dashboard ↗ now supports Cloudflare's native dark mode for all accounts and plan types.

    Zero Trust Dashboard will automatically accept your user-level preferences for system settings, so if your Dashboard appearance is set to 'system' or 'dark', the Zero Trust dashboard will enter dark mode whenever the rest of your Cloudflare account does.

    Zero Trust dashboard supports dark mode

    To update your view preference in the Zero Trust dashboard:

    1. Log into the Zero Trust dashboard ↗.
    2. Select your user icon.
    3. Select Dark Mode.

  1. FQDN Filtering For Gateway Egress Policies

    Gateway

    Cloudflare One administrators can now control which egress IP is used based on a destination's fully qualified domain name (FDQN) within Gateway Egress policies.

    • Host, Domain, Content Categories, and Application selectors are now available in the Gateway Egress policy builder in beta.
    • During the beta period, you can use these selectors with traffic on-ramped to Gateway with the WARP client, proxy endpoints (commonly deployed with PAC files), or Cloudflare Browser Isolation.

    This will help apply egress IPs to your users' traffic when an upstream application or network requires it, while the rest of their traffic can take the most performant egress path.

  1. Custom Errors are now Generally Available

    Rules

    Custom Errors are now generally available for all paid plans — bringing a unified and powerful experience for customizing error responses at both the zone and account levels.

    You can now manage Custom Error Rules, Custom Error Assets, and redesigned Error Pages directly from the Cloudflare dashboard. These features let you deliver tailored messaging when errors occur, helping you maintain brand consistency and improve user experience — whether it’s a 404 from your origin or a security challenge from Cloudflare.

    What's new:

    • Custom Errors are now GA – Available on all paid plans and ready for production traffic.
    • UI for Custom Error Rules and Assets – Manage your zone-level rules from the Rules > Overview and your zone-level assets from the Rules > Settings tabs.
    • Define inline content or upload assets – Create custom responses directly in the rule builder, upload new or reuse previously stored assets.
    • Refreshed UI and new name for Error Pages – Formerly known as “Custom Pages,” Error Pages now offer a cleaner, more intuitive experience for both zone and account-level configurations.
    • Powered by Ruleset Engine – Custom Error Rules support conditional logic and override Error Pages for 500 and 1000 class errors, as well as errors originating from your origin or other Cloudflare products. You can also configure Response Header Transform Rules to add, change, or remove HTTP headers from responses returned by Custom Error Rules.
    Custom Errors GA

    Learn more in the Custom Errors documentation.

  1. Cron triggers are now supported in Python Workers

    Workers

    You can now create Python Workers which are executed via a cron trigger.

    This is similar to how it's done in JavaScript Workers, simply define a scheduled event listener in your Worker:

    from workers import handler
    

    @handler
    async def on_scheduled(event, env, ctx):
      print("cron processed")

    Define a cron trigger configuration in your Wrangler configuration file:

    {
      "triggers": {
        "crons": [
          "*/3 * * * *",
          "0 15 1 * *",
          "59 23 LW * *"
        ]
      }
    }

    Then test your new handler by using Wrangler with the --test-scheduled flag and making a request to /cdn-cgi/handler/scheduled?cron=*+*+*+*+*:

    Terminal window
    npx wrangler dev --test-scheduled
    

    curl "http://localhost:8787/cdn-cgi/handler/scheduled?cron=*+*+*+*+*"

    Consult the Workers Cron Triggers page for full details on cron triggers in Workers.

  1. Metadata filtering and multitenancy support in AutoRAG

    AutoRAG

    You can now filter AutoRAG search results by folder and timestamp using metadata filtering to narrow down the scope of your query.

    This makes it easy to build multitenant experiences where each user can only access their own data. By organizing your content into per-tenant folders and applying a folder filter at query time, you ensure that each tenant retrieves only their own documents.

    Example folder structure:

    Terminal window
    customer-a/logs/
    customer-a/contracts/
    customer-b/contracts/

    Example query:

    const response = await env.AI.autorag("my-autorag").search({
      query: "When did I sign my agreement contract?",
      filters: {
        type: "eq",
        key: "folder",
        value: "customer-a/contracts/",
      },
    });

    You can use metadata filtering by creating a new AutoRAG or reindexing existing data. To reindex all content in an existing AutoRAG, update any chunking setting and select Sync index. Metadata filtering is available for all data indexed on or after April 21, 2025.

    If you are new to AutoRAG, get started with the Get started AutoRAG guide.

  1. Access bulk policy tester

    Access

    The Access bulk policy tester is now available in the Cloudflare Zero Trust dashboard. The bulk policy tester allows you to simulate Access policies against your entire user base before and after deploying any changes. The policy tester will simulate the configured policy against each user's last seen identity and device posture (if applicable).

    Example policy tester

  1. Custom fields raw and transformed values support

    Logs

    Custom Fields now support logging both raw and transformed values for request and response headers in the HTTP requests dataset.

    These fields are configured per zone and apply to all Logpush jobs in that zone that include request headers, response headers. Each header can be logged in only one format—either raw or transformed—not both.

    By default:

    • Request headers are logged as raw values
    • Response headers are logged as transformed values

    These defaults can be overidden to suit your logging needs.

    For more information refer to Custom fields documentation

  1. Read multiple keys from Workers KV with bulk reads

    KV

    You can now retrieve up to 100 keys in a single bulk read request made to Workers KV using the binding.

    This makes it easier to request multiple KV pairs within a single Worker invocation. Retrieving many key-value pairs using the bulk read operation is more performant than making individual requests since bulk read operations are not affected by Workers simultaneous connection limits.

    // Read single key
    const key = "key-a";
    const value = await env.NAMESPACE.get(key);
    

    // Read multiple keys
    const keys = ["key-a", "key-b", "key-c", ...] // up to 100 keys
    const values : Map<string, string?> = await env.NAMESPACE.get(keys);
    

    // Print the value of "key-a" to the console.
    console.log(`The first key is ${values.get("key-a")}.`)

    Consult the Workers KV Read key-value pairs API for full details on Workers KV's new bulk reads support.

  1. Increased limits for Queues pull consumers

    Queues

    Queues pull consumers can now pull and acknowledge up to 5,000 messages / second per queue. Previously, pull consumers were rate limited to 1,200 requests / 5 minutes, aggregated across all queues.

    Pull consumers allow you to consume messages over HTTP from any environment—including outside of Cloudflare Workers. They’re also useful when you need fine-grained control over how quickly messages are consumed.

    To setup a new queue with a pull based consumer using Wrangler, run:

    Create a queue with a pull based consumer
    npx wrangler queues create my-queue
    npx wrangler queues consumer http add my-queue

    You can also configure a pull consumer using the REST API or the Queues dashboard.

    Once configured, you can pull messages from the queue using any HTTP client. You'll need a Cloudflare API Token with queues_read and queues_write permissions. For example:

    Pull messages from a queue
    curl "https://api.cloudflare.com/client/v4/accounts/${CF_ACCOUNT_ID}/queues/${QUEUE_ID}/messages/pull" \
    --header "Authorization: Bearer ${API_TOKEN}" \
    --header "Content-Type: application/json" \
    --data '{ "visibility_timeout": 10000, "batch_size": 2 }'

    To learn more about how to acknowledge messages, pull batches at once, and setup multiple consumers, refer to the pull consumer documentation.

    As always, Queues doesn't charge for data egress. Pull operations continue to be billed at the existing rate, of $0.40 / million operations. The increased limits are available now, on all new and existing queues. If you're new to Queues, get started with the Cloudflare Queues guide.