Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
Workers for Platforms
hero image

  1. Workers for Platforms - Dashboard Improvements

    Workers for Platforms

    Workers for Platforms lets you build multi-tenant platforms on Cloudflare Workers, allowing your end users to deploy and run their own code on your platform. It's designed for anyone building an AI vibe coding platform, e-commerce platform, website builder, or any product that needs to securely execute user-generated code at scale.

    Previously, setting up Workers for Platforms required using the API. Now, the Workers for Platforms UI supports namespace creation, dispatch worker templates, and tag management, making it easier for Workers for Platforms customers to build and manage multi-tenant platforms directly from the Cloudflare dashboard.

    Workers for Platforms Dashboard Improvements

    Key improvements

    • Namespace Management: You can now create and configure dispatch namespaces directly within the dashboard to start a new platform setup.
    • Dispatch Worker Templates: New Dispatch Worker templates allow you to quickly define how traffic is routed to individual Workers within your namespace. Refer to the Dynamic Dispatch documentation for more examples.
    • Tag Management: You can now set and update tags on User Workers, making it easier to group and manage your Workers.
    • Binding Visibility: Bindings attached to User Workers are now visible directly within the User Worker view.
    • Deploy Vibe Coding Platform in one-click: Deploy a reference implementation of an AI vibe coding platform directly from the dashboard. Powered by the Cloudflare's VibeSDK ↗, this starter kit integrates with Workers for Platforms to handle the deployment of AI-generated projects at scale.

    To get started, go to Workers for Platforms under Compute & AI in the Cloudflare dashboard ↗.

  1. Increased static asset limits for Workers

    Workers Workers for Platforms

    You can now upload up to 100,000 static assets per Worker version

    • Paid and Workers for Platforms users can now upload up to 100,000 static assets per Worker version, a 5x increase from the previous limit of 20,000.
    • Customers on the free plan still have the same limit as before — 20,000 static assets per version of your Worker
    • The individual file size limit of 25 MiB remains unchanged for all customers.

    This increase allows you to build larger applications with more static assets without hitting limits.

    Wrangler

    To take advantage of the increased limits, you must use Wrangler version 4.34.0 or higher. Earlier versions of Wrangler will continue to enforce the previous 20,000 file limit.

    Learn more

    For more information about Workers static assets, see the Static Assets documentation and Platform Limits.

  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. Fixed and documented Workers Routes and Secrets API

    Workers Workers for Platforms

    Workers Routes API

    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.

    Example request
    curl https://api.cloudflare.com/client/v4/zones/$CF_ACCOUNT_ID/workers/routes \
    -X PUT \
    -H "Authorization: Bearer $CF_API_TOKEN" \
    -H 'Content-Type: application/json' \
    --data '{ "pattern": "example.com/*", "script": "hello-world-script" }'
    Example bad response
    {
      "result": {
        "id": "bf153a27ba2b464bb9f04dcf75de1ef9",
        "pattern": "",
        "script": null,
        "request_limit_fail_open": false
      },
      "success": true,
      "errors": [],
      "messages": []
    }

    Now, it properly returns all values!

    Example good response
    {
      "result": {
        "id": "bf153a27ba2b464bb9f04dcf75de1ef9",
        "pattern": "example.com/*",
        "script": "hello-world-script",
        "request_limit_fail_open": false
      },
      "success": true,
      "errors": [],
      "messages": []
    }

    Workers Secrets API

    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_secret Terraform resources ↗ are being removed in a future release. This resource is not recommended for managing secrets. Users should instead use the:

  1. Full-stack frameworks are now Generally Available on Cloudflare Workers

    Workers Workers for Platforms
    Full-stack on Cloudflare Workers

    The following full-stack frameworks now have Generally Available ("GA") adapters for Cloudflare Workers, and are ready for you to use in production:

    The following frameworks are now in beta, with GA support coming very soon:

    You can also build complete full-stack apps on Workers without a framework:

    Get started building today with our framework guides, or read our Developer Week 2025 blog post ↗ about all the updates to building full-stack applications on Workers.

  1. Workers for Platforms - Instant dispatch for newly created User Workers

    Workers for Platforms

    Workers for Platforms ↗ is an architecture wherein a centralized dispatch Worker processes incoming requests and routes them to isolated sub-Workers, called User Workers.

    Workers for Platforms Requests

    Previously, when a new User Worker was uploaded, there was a short delay before it became available for dispatch. This meant that even though an API request could return a 200 OK response, the script might not yet be ready to handle requests, causing unexpected failures for platforms that immediately dispatch to new Workers.

    With this update, first-time uploads of User Workers are now deployed synchronously. A 200 OK response guarantees the script is fully provisioned and ready to handle traffic immediately, ensuring more predictable deployments and reducing errors.

  1. Workers for Platforms now supports Static Assets

    Workers for Platforms

    Workers for Platforms customers can now attach static assets (HTML, CSS, JavaScript, images) directly to User Workers, removing the need to host separate infrastructure to serve the assets.

    This allows your platform to serve entire front-end applications from Cloudflare's global edge, utilizing caching for fast load times, while supporting dynamic logic within the same Worker. Cloudflare automatically scales its infrastructure to handle high traffic volumes, enabling you to focus on building features without managing servers.

    What you can build

    Static Sites: Host and serve HTML, CSS, JavaScript, and media files directly from Cloudflare's network, ensuring fast loading times worldwide. This is ideal for blogs, landing pages, and documentation sites because static assets can be efficiently cached and delivered closer to the user, reducing latency and enhancing the overall user experience.

    Full-Stack Applications: Combine asset hosting with Cloudflare Workers to power dynamic, interactive applications. If you're an e-commerce platform, you can serve your customers' product pages and run inventory checks from within the same Worker.

    index.js
    export default {
      async fetch(request, env) {
        const url = new URL(request.url);
    

        // Check real-time inventory
        if (url.pathname === "/api/inventory/check") {
          const product = url.searchParams.get("product");
          const inventory = await env.INVENTORY_KV.get(product);
          return new Response(inventory);
        }
    

        // Serve static assets (HTML, CSS, images)
        return env.ASSETS.fetch(request);
      },
    };

    Get Started: Upload static assets using the Workers for Platforms API or Wrangler. For more information, visit our Workers for Platforms documentation. ↗

Search all changelog entries