Changelog

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.

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.

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

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:

• cloudflare-typescript ↗︎ (4.4.1)
• cloudflare-python ↗︎ (4.3.1)

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

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:

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

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 ↗︎

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",
		}),
	},
});

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 ↗︎

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.

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

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.

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" }'

{
	"result": {
		"id": "bf153a27ba2b464bb9f04dcf75de1ef9",
		"pattern": "",
		"script": null,
		"request_limit_fail_open": false
	},
	"success": true,
	"errors": [],
	"messages": []
}

Now, it properly returns all values!

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

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:

• Secrets Store with the "Secrets Store Secret" binding on Workers and Workers for Platforms Script Upload
• "Secret Text" Binding on Workers Script Upload and Workers for Platforms Script Upload
• Workers (and WFP) Secrets API

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

• React Router v7 (Remix)
• Astro
• Hono
• Vue.js
• Nuxt
• Svelte (SvelteKit)
• And more.

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

• Next.js, supported through @opennextjs/cloudflare ↗︎ is now v1.0-beta.
• Angular
• SolidJS (SolidStart)

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

• You can “just use Vite" ↗︎ and React together, and build a back-end API in the same Worker. Follow our React SPA with an API tutorial to learn how.

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.