Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
Developer platform
hero image

  1. Introducing pricing for the Browser Rendering API — $0.09 per browser hour

    Browser Run

    We’ve launched pricing for Browser Rendering, including a free tier and a pay-as-you-go model that scales with your needs. Starting August 20, 2025, Cloudflare will begin billing for Browser Rendering.

    There are two ways to use Browser Rendering. Depending on the method you use, here’s how billing will work:

    • REST API: Charged for Duration only ($/browser hour)
    • Browser Sessions: Charged for both Duration and Concurrency ($/browser hour and # of concurrent browsers)

    Included usage and pricing by plan

    PlanIncluded durationIncluded concurrencyPrice (beyond included)
    Workers Free10 minutes per day3 concurrent browsersN/A
    Workers Paid10 hours per month10 concurrent browsers (averaged monthly)1. REST API: $0.09 per additional browser hour
    2. Workers Bindings: $0.09 per additional browser hour
    $2.00 per additional concurrent browser

    What you need to know:

    • Workers Free Plan: 10 minutes of browser usage per day with 3 concurrent browsers at no charge.
    • Workers Paid Plan: 10 hours of browser usage per month with 10 concurrent browsers (averaged monthly) at no charge. Additional usage is charged as shown above.

    You can monitor usage via the Cloudflare dashboard ↗. Go to Compute > Browser Run.

    Browser Rendering dashboard

    If you've been using Browser Rendering and do not wish to incur charges, ensure your usage stays within your plan's included usage. To estimate costs, take a look at these example pricing scenarios.

  1. Browser Rendering now supports local development

    Browser Run

    You can now run your Browser Rendering locally using npx wrangler dev, which spins up a browser directly on your machine before deploying to Cloudflare's global network. By running tests locally, you can quickly develop, debug, and test changes without needing to deploy or worry about usage costs.

    Get started with this example guide that shows how to use Cloudflare's fork of Puppeteer (you can also use Playwright) to take screenshots of webpages and store the results in Workers KV.

  1. Test out code changes before shipping with per-branch preview deployments for Cloudflare Workers

    Workers

    Now, when you connect your Cloudflare Worker to a git repository on GitHub or GitLab, each branch of your repository has its own stable preview URL, that you can use to preview code changes before merging the pull request and deploying to production.

    This works the same way that Cloudflare Pages does — every time you create a pull request, you'll automatically get a shareable preview link where you can see your changes running, without affecting production. The link stays the same, even as you add commits to the same branch. These preview URLs are named after your branch and are posted as a comment to each pull request. The URL stays the same with every commit and always points to the latest version of that branch.

    PR comment preview

    Preview URL types

    Each comment includes two preview URLs as shown above:

    • Commit Preview URL: Unique to the specific version/commit (e.g., <version-prefix>-<worker-name>.<subdomain>.workers.dev)
    • Branch Preview URL: A stable alias based on the branch name (e.g., <branch-name>-<worker-name>.<subdomain>.workers.dev)

    How it works

    When you create a pull request:

    • A preview alias is automatically created based on the Git branch name (e.g., <branch-name> becomes <branch-name>-<worker-name>.<subdomain>.workers.dev)
    • No configuration is needed, the alias is generated for you
    • The link stays the same even as you add commits to the same branch
    • Preview URLs are posted directly to your pull request as comments (just like they are in Cloudflare Pages)

    Custom alias name

    You can also assign a custom preview alias using the Wrangler CLI, by passing the --preview-alias flag when uploading a version of your Worker:

    Terminal window
    wrangler versions upload --preview-alias staging

    Limitations while in beta

    • Only available on the workers.dev subdomain (custom domains not yet supported)
    • Requires Wrangler v4.21.0+
    • Preview URLs are not generated for Workers that use Durable Objects
    • Not yet supported for Workers for Platforms

  1. Audio mode for Media Transformations

    Stream

    We now support audio mode! Use this feature to extract audio from a source video, outputting an M4A file to use in downstream workflows like AI inference, content moderation, or transcription.

    For example,

    Example URL
    https://example.com/cdn-cgi/media/<OPTIONS>/<SOURCE-VIDEO>
    https://example.com/cdn-cgi/media/mode=audio,time=3s,duration=60s/<input video with diction>

    For more information, learn about Transforming Videos.

  1. Subaddressing support in Email Routing

    Email Routing

    Subaddressing, as defined in RFC 5233 ↗, also known as plus addressing, is now supported in Email Routing. This enables using the "+" separator to augment your custom addresses with arbitrary detail information.

    Now you can send an email to user+detail@example.com and it will be captured by the user@example.com custom address. The +detail part is ignored by Email Routing, but it can be captured next in the processing chain in the logs, an Email Worker or an Agent application ↗.

    Customers can use this feature to dynamically add context to their emails, such as tracking the source of an email or categorizing emails without needing to create multiple custom addresses.

    Subaddressing

    Check our Developer Docs to learn on to enable subaddressing in Email Routing.

  1. The Cloudflare Vite plugin now supports Vite 7

    Workers

    Vite 7 ↗ is now supported in the Cloudflare Vite plugin. See the Vite changelog ↗ for a list of changes.

    Note that the minimum Node.js versions supported by Vite 7 are 20.19 and 22.12. We continue to support Vite 6 so you do not need to immediately upgrade.

  1. Faster, more reliable UDP traffic for Cloudflare Tunnel

    Cloudflare Tunnel Cloudflare Tunnel for SASE

    Your real-time applications running over Cloudflare Tunnel are now faster and more reliable. We've completely re-architected the way cloudflared proxies UDP traffic in order to isolate it from other traffic, ensuring latency-sensitive applications like private DNS are no longer slowed down by heavy TCP traffic (like file transfers) on the same Tunnel.

    This is a foundational improvement to Cloudflare Tunnel, delivered automatically to all customers. There are no settings to configure — your UDP traffic is already flowing faster and more reliably.

    What’s new:

    • Faster UDP performance: We've significantly reduced the latency for establishing new UDP sessions, making applications like private DNS much more responsive.
    • Greater reliability for mixed traffic: UDP packets are no longer affected by heavy TCP traffic, preventing timeouts and connection drops for your real-time services.

    Learn more about running TCP or UDP applications and private networks through Cloudflare Tunnel.

  1. Terraform v5.7.0 now available

    Cloudflare Fundamentals Terraform

    Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues ↗ reported by the Cloudflare community related to the v5 release, with 13.5% of resources impacted. We have committed to releasing improvements on a 2 week cadeance to ensure it's stability and relability, including the v5.7 release.

    Thank you for continuing to raise issues and please keep an eye on this changelog for more information about upcoming releases.

    Changes

    • Addressed permanent diff bug on Cloudflare Tunnel config
    • State is now saved correctly for Zero Trust Access applications
    • Exact match is now working as expected within data.cloudflare_zero_trust_access_applications
    • cloudflare_zero_trust_access_policy now supports OIDC claims & diff issues resolved
    • Self hosted applications with private IPs no longer require a public domain for cloudflare_zero_trust_access_application.
    • New resource:
      • cloudflare_zero_trust_tunnel_warp_connector
    • Other bug fixes

    For a more detailed look at all of the changes, see the changelog ↗ in GitHub.

    Issues Closed

    If you have an unaddressed issue with the provider, we encourage you to check the open issues ↗ and open a new one if one does not already exist for what you are experiencing.

    Upgrading

    We suggest holding on migration to v5 while we work on stabilization of the v5 provider. This will ensure Cloudflare can work ahead and avoid any blocking issues.

    If you'd like more information on migrating from v4 to v5, please make use of the migration guide ↗. We have provided automated migration scripts using Grit which simplify the transition, although these do not support implementations which use Terraform modules, so customers making use of modules need to migrate manually. Please make use of terraform plan to test your changes before applying, and let us know if you encounter any additional issues by reporting to our GitHub repository ↗.

    For more info

  1. Faster indexing and new Jobs view in AutoRAG

    AI Search

    You can now expect 3-5× faster indexing in AutoRAG, and with it, a brand new Jobs view to help you monitor indexing progress.

    With each AutoRAG, indexing jobs are automatically triggered to sync your data source (i.e. R2 bucket) with your Vectorize index, ensuring new or updated files are reflected in your query results. You can also trigger jobs manually via the Sync API or by clicking “Sync index” in the dashboard.

    With the new jobs observability, you can now:

    • View the status, job ID, source, start time, duration and last sync time for each indexing job
    • Inspect real-time logs of job events (e.g. Starting indexing data source...)
    • See a history of past indexing jobs under the Jobs tab of your AutoRAG

    This makes it easier to understand what’s happening behind the scenes.

    Coming soon: We’re adding APIs to programmatically check indexing status, making it even easier to integrate AutoRAG into your workflows.

    Try it out today on the Cloudflare dashboard ↗.

  1. HEIC support in Cloudflare Images

    Cloudflare Images

    You can use Images to ingest HEIC images and serve them in supported output formats like AVIF, WebP, JPEG, and PNG.

    When inputting a HEIC image, dimension and sizing limits may still apply. Refer to our documentation to see limits for uploading to Images or transforming a remote image.

  1. Workers now supports JavaScript debug terminals in VSCode, Cursor and Windsurf IDEs

    Workers

    Workers now support breakpoint debugging using VSCode's built-in JavaScript Debug Terminals ↗. All you have to do is open a JS debug terminal (Cmd + Shift + P and then type javascript debug) and run wrangler dev (or vite dev) from within the debug terminal. VSCode will automatically connect to your running Worker (even if you're running multiple Workers at once!) and start a debugging session.

    In 2023 we announced breakpoint debugging support ↗ for Workers, which meant that you could easily debug your Worker code in Wrangler's built-in devtools (accessible via the [d] hotkey) as well as multiple other devtools clients, including VSCode ↗. For most developers, breakpoint debugging via VSCode is the most natural flow, but until now it's required manually configuring a launch.json file ↗, running wrangler dev, and connecting via VSCode's built-in debugger. Now it's much more seamless!

  1. Hyperdrive now supports configuring the amount of database connections

    Hyperdrive

    You can now specify the number of connections your Hyperdrive configuration uses to connect to your origin database.

    All configurations have a minimum of 5 connections. The maximum connection count for a Hyperdrive configuration depends on the Hyperdrive limits of your Workers plan.

    This feature allows you to right-size your connection pool based on your database capacity and application requirements. You can configure connection counts through the Cloudflare dashboard or API.

    Refer to the Hyperdrive configuration documentation for more information.

  1. Enhanced support for static assets with the Cloudflare Vite plugin

    Workers

    You can now use any of Vite's static asset handling ↗ features in your Worker as well as in your frontend. These include importing assets as URLs, importing as strings and importing from the public directory as well as inlining assets.

    Additionally, assets imported as URLs in your Worker are now automatically moved to the client build output.

    Here is an example that fetches an imported asset using the assets binding and modifies the response.

    TypeScript
    // Import the asset URL
    // This returns the resolved path in development and production
    import myImage from "./my-image.png";
    

    export default {
      async fetch(request, env) {
        // Fetch the asset using the binding
        const response = await env.ASSETS.fetch(new URL(myImage, request.url));
        // Create a new `Response` object that can be modified
        const modifiedResponse = new Response(response.body, response);
        // Add an additional header
        modifiedResponse.headers.append("my-header", "imported-asset");
    

        // Return the modified response
        return modifiedResponse;
      },
    };

    Refer to Static Assets in the Cloudflare Vite plugin docs for more info.

  1. Mail authentication requirements for Email Routing

    Email Routing

    The Email Routing platform supports SPF ↗ records and DKIM (DomainKeys Identified Mail) ↗ signatures and honors these protocols when the sending domain has them configured. However, if the sending domain doesn't implement them, we still forward the emails to upstream mailbox providers.

    Starting on July 3, 2025, we will require all emails to be authenticated using at least one of the protocols, SPF or DKIM, to forward them. We also strongly recommend that all senders implement the DMARC protocol.

    If you are using a Worker with an Email trigger to receive email messages and forward them upstream, you will need to handle the case where the forward action may fail due to missing authentication on the incoming email.

    SPAM has been a long-standing issue with email. By enforcing mail authentication, we will increase the efficiency of identifying abusive senders and blocking bad emails. If you're an email server delivering emails to large mailbox providers, it's likely you already use these protocols; otherwise, please ensure you have them properly configured.

  1. Remote bindings (beta) now works with Next.js — connect to remote resources (D1, KV, R2, etc.) during local development

    Workers

    We recently announced ↗ our public beta for remote bindings, which allow you to connect to deployed resources running on your Cloudflare account (like R2 buckets or D1 databases) while running a local development session.

    Now, you can use remote bindings with your Next.js applications through the @opennextjs/cloudflare adaptor ↗ by enabling the experimental feature in your next.config.ts:

    initOpenNextCloudflareForDev();
    initOpenNextCloudflareForDev({
     experimental: { remoteBindings: true }
    });

    Then, all you have to do is specify which bindings you want connected to the deployed resource on your Cloudflare account via the experimental_remote flag in your binding definition:

    JSONC
    {
      "r2_buckets": [
        {
          "bucket_name": "testing-bucket",
          "binding": "MY_BUCKET",
          "experimental_remote": true,
        },
      ],
    }

    You can then run next dev to start a local development session (or start a preview with opennextjs-cloudflare preview), and all requests to env.MY_BUCKET will be proxied to the remote testing-bucket — rather than the default local binding simulations.

    Remote bindings & ISR

    Remote bindings are also used during the build process, which comes with significant benefits for pages using Incremental Static Regeneration (ISR) ↗. During the build step for an ISR page, your server executes the page's code just as it would for normal user requests. If a page needs data to display (like fetching user info from KV), those requests are actually made. The server then uses this fetched data to render the final HTML.

    Data fetching is a critical part of this process, as the finished HTML is only as good as the data it was built with. If the build process can't fetch real data, you end up with a pre-rendered page that's empty or incomplete.

    With remote bindings support in OpenNext, your pre-rendered pages are built with real data from the start. The build process uses any configured remote bindings, and any data fetching occurs against the deployed resources on your Cloudflare account.

    Want to learn more? Get started with remote bindings and OpenNext ↗.

    Have feedback? Join the discussion in our beta announcement ↗ to share feedback or report any issues.

  1. Run and connect Workers in separate dev commands with the Cloudflare Vite plugin

    Workers

    Workers can now talk to each other across separate dev commands using service bindings and tail consumers, whether started with vite dev or wrangler dev.

    Simply start each Worker in its own terminal:

    Terminal window
    # Terminal 1
    vite dev
    

    # Terminal 2
    wrangler dev

    This is useful when different teams maintain different Workers, or when each Worker has its own build setup or tooling.

    Check out the Developing with multiple Workers guide to learn more about the different approaches and when to use each one.

  1. Run AI-generated code on-demand with Code Sandboxes (new)

    Agents Workers Workflows

    AI is supercharging app development for everyone, but we need a safe way to run untrusted, LLM-written code. We’re introducing Sandboxes ↗, which let your Worker run actual processes in a secure, container-based environment.

    TypeScript
    import { getSandbox } from "@cloudflare/sandbox";
    export { Sandbox } from "@cloudflare/sandbox";
    

    export default {
      async fetch(request: Request, env: Env) {
        const sandbox = getSandbox(env.Sandbox, "my-sandbox");
        return sandbox.exec("ls", ["-la"]);
      },
    };

    Methods

    • exec(command: string, args: string[], options?: { stream?: boolean }):Execute a command in the sandbox.
    • gitCheckout(repoUrl: string, options: { branch?: string; targetDir?: string; stream?: boolean }): Checkout a git repository in the sandbox.
    • mkdir(path: string, options: { recursive?: boolean; stream?: boolean }): Create a directory in the sandbox.
    • writeFile(path: string, content: string, options: { encoding?: string; stream?: boolean }): Write content to a file in the sandbox.
    • readFile(path: string, options: { encoding?: string; stream?: boolean }): Read content from a file in the sandbox.
    • deleteFile(path: string, options?: { stream?: boolean }): Delete a file from the sandbox.
    • renameFile(oldPath: string, newPath: string, options?: { stream?: boolean }): Rename a file in the sandbox.
    • moveFile(sourcePath: string, destinationPath: string, options?: { stream?: boolean }): Move a file from one location to another in the sandbox.
    • ping(): Ping the sandbox.

    Sandboxes are still experimental. We're using them to explore how isolated, container-like workloads might scale on Cloudflare — and to help define the developer experience around them.

    You can try it today from your Worker, with just a few lines of code. Let us know what you build.

  1. @cloudflare/actors library - SDK for Durable Objects in beta

    Durable Objects Workers

    The new @cloudflare/actors ↗ library is now in beta!

    The @cloudflare/actors library is a new SDK for Durable Objects and provides a powerful set of abstractions for building real-time, interactive, and multiplayer applications on top of Durable Objects. With beta usage and feedback, @cloudflare/actors will become the recommended way to build on Durable Objects and draws upon Cloudflare's experience building products/features on Durable Objects.

    The name "actors" originates from the actor programming model, which closely ties to how Durable Objects are modelled.

    The @cloudflare/actors library includes:

    • Storage helpers for querying embeddeded, per-object SQLite storage
    • Storage helpers for managing SQL schema migrations
    • Alarm helpers for scheduling multiple alarms provided a date, delay in seconds, or cron expression
    • Actor class for using Durable Objects with a defined pattern
    • Durable Objects Workers API ↗ is always available for your application as needed

    Storage and alarm helper methods can be combined with any Javascript class ↗ that defines your Durable Object, i.e, ones that extend DurableObject including the Actor class.

    JavaScript
    import { Storage } from "@cloudflare/actors/storage";
    

    export class ChatRoom extends DurableObject<Env> {
        storage: Storage;
    

        constructor(ctx: DurableObjectState, env: Env) {
            super(ctx, env)
            this.storage = new Storage(ctx.storage);
            this.storage.migrations = [{
                idMonotonicInc: 1,
                description: "Create users table",
                sql: "CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY)"
            }]
        }
        async fetch(request: Request): Promise<Response> {
            // Run migrations before executing SQL query
            await this.storage.runMigrations();
    

            // Query with SQL template
            let userId = new URL(request.url).searchParams.get("userId");
            const query = this.storage.sql`SELECT * FROM users WHERE id = ${userId};`
            return new Response(`${JSON.stringify(query)}`);
        }
    }

    @cloudflare/actors library introduces the Actor class pattern. Actor lets you access Durable Objects without writing the Worker that communicates with your Durable Object (the Worker is created for you). By default, requests are routed to a Durable Object named "default".

    JavaScript
    export class MyActor extends Actor<Env> {
        async fetch(request: Request): Promise<Response> {
            return new Response('Hello, World!')
        }
    }
    

    export default handler(MyActor);

    You can route to different Durable Objects by name within your Actor class using nameFromRequest ↗.

    JavaScript
    export class MyActor extends Actor<Env> {
        static nameFromRequest(request: Request): string {
            let url = new URL(request.url);
            return url.searchParams.get("userId") ?? "foo";
        }
    

        async fetch(request: Request): Promise<Response> {
            return new Response(`Actor identifier (Durable Object name): ${this.identifier}`);
        }
    }
    

    export default handler(MyActor);

    For more examples, check out the library README ↗. @cloudflare/actors library is a place for more helpers and built-in patterns, like retry handling and Websocket-based applications, to reduce development overhead for common Durable Objects functionality. Please share feedback and what more you would like to see on our Discord channel ↗.

  1. Increased blob size limits in Workers Analytics Engine

    Workers

    We’ve increased the total allowed size of blob fields on data points written to Workers Analytics Engine from 5 KB to 16 KB.

    This change gives you more flexibility when logging rich observability data — such as base64-encoded payloads, AI inference traces, or custom metadata — without hitting request size limits.

    You can find full details on limits for queries, filters, payloads, and more here in the Workers Analytics Engine limits documentation.

    JavaScript
    export default {
      async fetch(request, env) {
        env.analyticsDataset.writeDataPoint({
          // The sum of all of the blob's sizes can now be 16 KB
          blobs: [
            // The URL of the request to the Worker
            request.url,
            // Some metadata about your application you'd like to store
            JSON.stringify(metadata),
            // The version of your Worker this datapoint was collected from
            env.versionMetadata.tag,
          ],
          indexes: ["sample-index"],
        });
      },
    };

  1. View custom metadata in responses and guide AI-search with context in AutoRAG

    AI Search

    In AutoRAG, you can now view your object's custom metadata in the response from /search and /ai-search, and optionally add a context field in the custom metadata of an object to provide additional guidance for AI-generated answers.

    You can add custom metadata to an object when uploading it to your R2 bucket.

    Object's custom metadata in search responses

    When you run a search, AutoRAG now returns any custom metadata associated with the object. This metadata appears in the response inside attributes then file , and can be used for downstream processing.

    For example, the attributes section of your search response may look like:

    {
      "attributes": {
        "timestamp": 1750001460000,
        "folder": "docs/",
        "filename": "launch-checklist.md",
        "file": {
          "url": "https://wiki.company.com/docs/launch-checklist",
          "context": "A checklist for internal launch readiness, including legal, engineering, and marketing steps."
        }
      }
    }

    Add a context field to guide LLM answers

    When you include a custom metadata field named context, AutoRAG attaches that value to each chunk of the file. When you run an /ai-search query, this context is passed to the LLM and can be used as additional input when generating an answer.

    We recommend using the context field to describe supplemental information you want the LLM to consider, such as a summary of the document or a source URL. If you have several different metadata attributes, you can join them together however you choose within the context string.

    For example:

    {
      "context": "summary: 'Checklist for internal product launch readiness, including legal, engineering, and marketing steps.'; url: 'https://wiki.company.com/docs/launch-checklist'"
    }

    This gives you more control over how your content is interpreted, without requiring you to modify the original contents of the file.

    Learn more in AutoRAG's metadata filtering documentation.

  1. Filter your AutoRAG search by file name

    AI Search

    In AutoRAG, you can now filter by an object's file name using the filename attribute, giving you more control over which files are searched for a given query.

    This is useful when your application has already determined which files should be searched. For example, you might query a PostgreSQL database to get a list of files a user has access to based on their permissions, and then use that list to limit what AutoRAG retrieves.

    For example, your search query may look like:

    JavaScript
    const response = await env.AI.autorag("my-autorag").search({
      query: "what is the project deadline?",
      filters: {
        type: "eq",
        key: "filename",
        value: "project-alpha-roadmap.md",
      },
    });

    This allows you to connect your application logic with AutoRAG's retrieval process, making it easy to control what gets searched without needing to reindex or modify your data.

    Learn more in AutoRAG's metadata filtering documentation.

  1. Automate Worker deployments with a simplified SDK and more reliable Terraform provider

    D1 Workers Workers for Platforms

    Simplified Worker Deployments with our SDKs

    We've simplified the programmatic deployment of Workers via our Cloudflare SDKs. This update abstracts away the low-level complexities of the multipart/form-data upload process, allowing you to focus on your code while we handle the deployment mechanics.

    This new interface is available in:

    For complete examples, see our guide on programmatic Worker deployments.

    The Old way: Manual API calls

    Previously, deploying a Worker programmatically required manually constructing a multipart/form-data HTTP request, packaging your code and a separate metadata.json file. This was more complicated and verbose, and prone to formatting errors.

    For example, here's how you would upload a Worker script previously with cURL:

    Terminal window
    curl https://api.cloudflare.com/client/v4/accounts/<account_id>/workers/scripts/my-hello-world-script \
      -X PUT \
      -H 'Authorization: Bearer <api_token>' \
      -F 'metadata={
            "main_module": "my-hello-world-script.mjs",
            "bindings": [
              {
                "type": "plain_text",
                "name": "MESSAGE",
                "text": "Hello World!"
              }
            ],
            "compatibility_date": "$today"
          };type=application/json' \
      -F 'my-hello-world-script.mjs=@-;filename=my-hello-world-script.mjs;type=application/javascript+module' <<EOF
    export default {
      async fetch(request, env, ctx) {
        return new Response(env.MESSAGE, { status: 200 });
      }
    };
    EOF

    After: SDK interface

    With the new SDK interface, you can now define your entire Worker configuration using a single, structured object.

    This approach allows you to specify metadata like main_module, bindings, and compatibility_date as clearer properties directly alongside your script content. Our SDK takes this logical object and automatically constructs the complex multipart/form-data API request behind the scenes.

    Here's how you can now programmatically deploy a Worker via the cloudflare-typescript SDK ↗

    JavaScript
    import Cloudflare from "cloudflare";
    import { toFile } from "cloudflare/index";
    

    // ... client setup, script content, etc.
    

    const script = await client.workers.scripts.update(scriptName, {
      account_id: accountID,
      metadata: {
        main_module: scriptFileName,
        bindings: [],
      },
      files: {
        [scriptFileName]: await toFile(Buffer.from(scriptContent), scriptFileName, {
          type: "application/javascript+module",
        }),
      },
    });

    View the complete example here: https://github.com/cloudflare/cloudflare-typescript/blob/main/examples/workers/script-upload.ts ↗

    Terraform provider improvements

    We've also made several fixes and enhancements to the Cloudflare Terraform provider ↗:

    • Fixed the cloudflare_workers_script ↗ resource in Terraform, which previously was producing a diff even when there were no changes. Now, your terraform plan outputs will be cleaner and more reliable.
    • Fixed the cloudflare_workers_for_platforms_dispatch_namespace ↗, where the provider would attempt to recreate the namespace on a terraform apply. The resource now correctly reads its remote state, ensuring stability for production environments and CI/CD workflows.
    • The cloudflare_workers_route ↗ resource now allows for the script property to be empty, null, or omitted to indicate that pattern should be negated for all scripts (see routes docs). You can now reserve a pattern or temporarily disable a Worker on a route without deleting the route definition itself.
    • Using primary_location_hint in the cloudflare_d1_database ↗ resource will no longer always try to recreate. You can now safely change the location hint for a D1 database without causing a destructive operation.

    API improvements

    We've also properly documented the Workers Script And Version Settings in our public OpenAPI spec and SDKs.

  1. Remote bindings public beta - Connect to remote resources (D1, KV, R2, etc.) during local development

    Workers

    Today we announced the public beta ↗ of remote bindings for local development. With remote bindings, you can now connect to deployed resources like R2 buckets and D1 databases while running Worker code on your local machine. This means you can test your local code changes against real data and services, without the overhead of deploying for each iteration.

    Example configuration

    To enable remote mode, add "experimental_remote" : true to each binding that you want to rely on a remote resource running on Cloudflare:

    JSONC
    {
      "name": "my-worker",
      // Set this to today's date
      "compatibility_date": "2026-04-29",
    

      "r2_buckets": [
        {
          "bucket_name": "screenshots-bucket",
          "binding": "screenshots_bucket",
          "experimental_remote": true,
        },
      ],
    }

    When remote bindings are configured, your Worker still executes locally, but all binding calls are proxied to the deployed resource that runs on Cloudflare's network.

    You can try out remote bindings for local development today with:

    Have feedback? Join the discussion in our beta announcement ↗ to share feedback or report any issues.

  1. Terraform v5.6.0 now available

    Cloudflare Fundamentals Terraform

    Earlier this year, we announced the launch of the new Terraform v5 Provider. Unlike the earlier Terraform providers, v5 is automatically generated based on the OpenAPI Schemas for our REST APIs. Since launch, we have seen an unexpectedly high number of issues ↗ reported by customers. These issues currently impact about 15% of resources. We have been working diligently to address these issues across the company, and have released the v5.6.0 release which includes a number of bug fixes. Please keep an eye on this changelog for more information about upcoming releases.

    Changes

    • Broad fixes across resources with recurring diffs, including, but not limited to:
      • cloudflare_zero_trust_access_identity_provider
        • cloudflare_zone
    • cloudflare_page_rules runtime panic when setting cache_level to cache_ttl_by_status
    • Failure to serialize requests in cloudflare_zero_trust_tunnel_cloudflared_config
    • Undocumented field 'priority' on zone_lockdown resource
    • Missing importability for cloudflare_zero_trust_device_default_profile_local_domain_fallback and cloudflare_account_subscription
    • New resources:
      • cloudflare_schema_validation_operation_settings
      • cloudflare_schema_validation_schemas
      • cloudflare_schema_validation_settings
      • cloudflare_zero_trust_device_settings
    • Other bug fixes

    For a more detailed look at all of the changes, see the changelog ↗ in GitHub.

    Issues Closed

    If you have an unaddressed issue with the provider, we encourage you to check the open issues ↗ and open a new one if one does not already exist for what you are experiencing.

    Upgrading

    If you are evaluating a move from v4 to v5, please make use of the migration guide ↗. We have provided automated migration scripts using Grit which simplify the transition, although these do not support implementations which use Terraform modules, so customers making use of modules need to migrate manually. Please make use of terraform plan to test your changes before applying, and let us know if you encounter any additional issues by reporting to our GitHub repository ↗.

    For more info

  1. Control which routes invoke your Worker script for Single Page Applications

    Workers

    For those building Single Page Applications (SPAs) on Workers, you can now explicitly define which routes invoke your Worker script in Wrangler configuration. The run_worker_first config option has now been expanded to accept an array of route patterns, allowing you to more granularly specify when your Worker script runs.

    Configuration example:

    JSONC
    {
      "name": "my-spa-worker",
      // Set this to today's date
      "compatibility_date": "2026-04-29",
      "main": "./src/index.ts",
      "assets": {
        "directory": "./dist/",
        "not_found_handling": "single-page-application",
        "binding": "ASSETS",
        "run_worker_first": ["/api/*", "!/api/docs/*"]
      }
    }

    This new routing control was done in partnership with our community and customers who provided great feedback on our public proposal ↗. Thank you to everyone who brought forward use-cases and feedback on the design!

    Prerequisites

    To use advanced routing control with run_worker_first, you'll need:

Search all changelog entries