Merge branch 'production' of https://github.com/Marcinthecloud/cloudflare-docs into production

Author: Marcinthecloud

src/assets/images/workers/platform/api-after.png

@@ -0,0 +1,25 @@
+---
+title: Increased static asset limits for Workers
+description: Paid and Workers for Platforms users can now upload up to 100,000 static assets per Worker version, up from the previous limit of 20,000.
+products:
+  - workers
+  - workers-for-platforms
+date: 2025-09-04
+---
+
+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](/workers/static-assets/) and [Platform Limits](/workers/platform/limits/#static-assets).

src/assets/images/workers/platform/api-before.png

@@ -0,0 +1,198 @@
+---
+title: A new, simpler REST API for Cloudflare Workers (Beta)
+description: Simpler Workers API, SDK methods, and Terraform resources for directly managing Workers, Versions, and Deployments
+date: 2025-09-04
+---
+You can now manage [**Workers**](/api/resources/workers/subresources/beta/subresources/workers/methods/create/), [**Versions**](/api/resources/workers/subresources/beta/subresources/workers/models/worker/#(schema)), and [**Deployments**](/api/resources/workers/subresources/scripts/subresources/content/methods/update/) as separate resources with a new, resource-oriented API (Beta).
+
+This new API is supported in the [Cloudflare Terraform provider](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs) and the [Cloudflare Typescript SDK](https://github.com/cloudflare/cloudflare-typescript), allowing platform teams to manage a Worker's infrastructure in Terraform, while development teams handle code deployments from a separate repository or workflow. We also designed this API with AI agents in mind, as a clear, predictable structure is essential for them to reliably build, test, and deploy applications.
+
+### Try it out
+- [**New beta API endpoints**](/api/resources/workers/subresources/beta/)
+- [**Cloudflare TypeScript SDK v5.0.0**](https://github.com/cloudflare/cloudflare-typescript)
+- [**Cloudflare Go SDK v6.0.0**](https://github.com/cloudflare/cloudflare-go)
+- [**Terraform provider v5.9.0**](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs): [`cloudflare_worker`](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/worker) , [`cloudflare_worker_version`](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/worker_version), and [`cloudflare_workers_deployments`](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/workers_deployment) resources.
+- See full examples in our [Infrastructure as Code (IaC) guide](/workers/platform/infrastructure-as-code)
+
+
+## Before: Eight+ endpoints with mixed responsibilities
+![**Before**](~/assets/images/workers/platform/api-before.png)
+
+
+The existing API was originally designed for simple, one-shot script uploads:
+
+```sh
+curl -X PUT "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/scripts/$SCRIPT_NAME" \
+    -H "X-Auth-Email: $CLOUDFLARE_EMAIL" \
+    -H "X-Auth-Key: $CLOUDFLARE_API_KEY" \
+    -H "Content-Type: multipart/form-data" \
+    -F 'metadata={
+      "main_module": "worker.js",
+      "compatibility_date": "$today$"
+    }' \
+    -F "[email protected];type=application/javascript+module"
+
+```
+
+This API worked for creating a basic Worker, uploading all of its code, and deploying it immediately — but came with challenges:
+
+- **A Worker couldn't exist without code**: To create a Worker, you had to upload its code in the same API request. This meant platform teams couldn't provision Workers with the proper settings, and then hand them off to development teams to deploy the actual code.
+
+- **Several endpoints implicitly created deployments**: Simple updates like adding a secret or changing a script's content would implicitly create a new version and immediately deploy it.
+
+- **Updating a setting was confusing**: Configuration was scattered across eight endpoints with overlapping responsibilities.  This ambiguity made it difficult for human developers (and even more so for AI agents) to reliably update a Worker via API.
+
+- **Scripts used names as primary identifiers**: This meant simple renames could turn into a risky migration, requiring you to create a brand new Worker and update every reference. If you were using Terraform, this could inadvertently destroy your Worker altogether.
+
+## After: Three resources with clear boundaries
+![**After**](~/assets/images/workers/platform/api-after.png)
+The new API introduces cleaner resource management with three core resources: [**Worker**](/api/resources/workers/subresources/beta/subresources/workers/methods/create/), [**Versions**](/api/resources/workers/subresources/beta/subresources/workers/models/worker/#(schema)), and [**Deployment**](/api/resources/workers/subresources/scripts/subresources/content/methods/update/).
+
+All endpoints now use simple JSON payloads, with script content embedded as `base64`-encoded strings -- a more consistent and reliable approach than the previous `multipart/form-data` format.
+- **Worker**: The parent resource representing your application. It has a stable UUID and holds persistent settings like `name`, `tags`, and `logpush`. You can now create a Worker to establish its identity and settings **before** any code is uploaded.
+
+- **Version**: An immutable snapshot of your code and its specific configuration, like bindings and `compatibility_date`. Creating a new version is a safe action that doesn't affect live traffic.
+
+- **Deployment**: An explicit action that directs traffic to a specific version.
+
+:::note
+[Workers](/api/resources/workers/subresources/beta/subresources/workers/) and [Versions](/api/resources/workers/subresources/beta/subresources/workers/subresources/versions/) use the new `/workers/` beta endpoints, while [Deployments](/api/resources/workers/subresources/scripts/subresources/deployments/) remain on the existing `/scripts/` endpoint. Pair the new endpoints with the existing Deployment API for a complete workflow.
+:::
+
+## Why this matters
+
+### You can now create Workers before uploading code
+
+Workers are now standalone resources that can be created and configured without any code. Platform teams can provision Workers with the right settings, then hand them off to development teams for implementation.
+
+#### Example: Typescript SDK
+```ts
+// Step 1: Platform team creates the Worker resource (no code needed)
+const worker = await client.workers.beta.workers.create({
+  name: "payment-service",
+  account_id: "...",
+  observability: {
+    enabled: true,
+  },
+});
+
+// Step 2: Development team adds code and creates a version later
+const version = await client.workers.beta.workers.versions.create(worker.id, {
+  account_id: "...",
+  main_module: "worker.js",
+  compatibility_date: "$today",
+  bindings: [ /*...*/ ],
+  modules: [
+    {
+      name: "worker.js",
+      content_type: "application/javascript+module",
+      content_base64: Buffer.from(scriptContent).toString("base64"),
+    },
+  ],
+});
+
+// Step 3: Deploy explicitly when ready
+const deployment = await client.workers.scripts.deployments.create(worker.name, {
+  account_id: "...",
+  strategy: "percentage",
+  versions: [
+    {
+      percentage: 100,
+      version_id: version.id,
+    },
+  ],
+});
+````
+#### Example: Terraform
+If you use Terraform, you can now declare the Worker in your Terraform configuration and manage configuration outside of Terraform in your Worker's [`wrangler.jsonc` file](/workers/wrangler/configuration/) and deploy code changes using [Wrangler](/workers/wrangler/).
+
+```tf
+resource "cloudflare_worker" "my_worker" {
+  account_id = "..."
+  name = "my-important-service"
+}
+# Manage Versions and Deployments here or outside of Terraform
+# resource "cloudflare_worker_version" "my_worker_version" {}
+# resource "cloudflare_workers_deployment" "my_worker_deployment" {}
+```
+
+### Deployments are always explicit, never implicit
+
+Creating a version and deploying it are now always explicit, separate actions - never implicit side effects. To update version-specific settings (like bindings), you create a new version with those changes. The existing deployed version remains unchanged until you explicitly deploy the new one.
+
+```sh
+# Step 1: Create a new version with updated settings (doesn't affect live traffic)
+POST /workers/workers/{id}/versions
+{
+  "compatibility_date": "$today",
+  "bindings": [
+    {
+      "name": "MY_NEW_ENV_VAR",
+      "text": "new_value",
+      "type": "plain_text"
+    }
+  ],
+  "modules": [...]
+}
+
+# Step 2: Explicitly deploy when ready (now affects live traffic)
+POST /workers/scripts/{script_name}/deployments
+{
+  "strategy": "percentage",
+  "versions": [
+    {
+      "percentage": 100,
+      "version_id": "new_version_id"
+    }
+  ]
+}
+```
+
+### Settings are clearly organized by scope
+Configuration is now logically divided: [**Worker settings**](/api/resources/workers/subresources/beta/subresources/workers/) (like `name` and `tags`) persist across all versions, while [**Version settings**](/api/resources/workers/subresources/beta/subresources/workers/subresources/versions/) (like `bindings` and `compatibility_date`) are specific to each code snapshot.
+
+```sh
+# Worker settings (the parent resource)
+PUT /workers/workers/{id}
+{
+  "name": "payment-service",
+  "tags": ["production"],
+  "logpush": true,
+}
+```
+
+```sh
+# Version settings (the "code")
+POST /workers/workers/{id}/versions
+{
+  "compatibility_date": "$today",
+  "bindings": [...],
+  "modules": [...]
+}
+```
+
+### `/workers` API endpoints now support UUIDs (in addition to names)
+
+The `/workers/workers/` path now supports addressing a Worker by both its immutable UUID and its mutable name.
+
+```sh
+# Both work for the same Worker
+GET /workers/workers/29494978e03748669e8effb243cf2515  # UUID (stable for automation)
+GET /workers/workers/payment-service                  # Name (convenient for humans)
+```
+This dual approach means:
+  - Developers can use readable names for debugging.
+  - Automation can rely on stable UUIDs to prevent errors when Workers are renamed.
+  - Terraform can rename Workers without destroying and recreating them.
+
+
+## Learn more
+- [Infrastructure as Code (IaC) guide](/workers/platform/infrastructure-as-code)
+- [API documentation](/api/resources/workers/subresources/beta/)
+- [Versions and Deployments overview](/workers/configuration/versions-and-deployments/)
+
+## Technical notes
+
+- The pre-existing Workers REST API remains fully supported. Once the new API exits beta, we'll provide a migration timeline with ample notice and comprehensive migration guides.
+- Existing Terraform resources and SDK methods will continue to be fully supported through the current major version.
+- While the Deployments API currently remains on the `/scripts/` endpoint, we plan to introduce a new Deployments endpoint under `/workers/` to match the new API structure.

src/content/changelog/workers/2025-09-02-increased-static-asset-limits.mdx

@@ -12,23 +12,53 @@ import { GlossaryTooltip } from "~/components";
 
 Below you will find answers to our most commonly asked questions. If you cannot find the answer you are looking for, refer to the [Discord](https://discord.cloudflare.com) to explore additional resources.
 
-### I see `Cannot read properties of undefined (reading 'fetch')` when using Browser Rendering. How do I fix this?
+---
 
-This error occurs because your Puppeteer launch is not receiving the Browser binding or you are not on a Workers Paid plan.
+## Getting started & Development
+
+### Does local development support all Browser Rendering features?
+
+Not yet. Local development currently has the following limitation(s):
+- Requests larger than 1 MB are not supported.
 
-To resolve: Pass your Browser binding into `puppeteer.launch`.
+For full feature access, use `npx wrangler dev --remote`.
 
 ### Will Browser Rendering bypass Cloudflare's Bot Protection?
 
 No, Browser Rendering requests are always identified as bots by Cloudflare and do not bypass Bot Protection.
 
 If you are attempting to scan your **own zone** and need Browser Rendering to access areas protected by Cloudflare’s Bot Protection, you can create a [WAF skip rule](/waf/custom-rules/skip/) to bypass the bot protection using a header or a custom user agent.
 
+### Does Browser Rendering rotate IP addresses for outbound requests?
+
+No. Browser Rendering requests originate from Cloudflare's global network and you cannot configure per-request IP rotation. All rendering traffic comes from Cloudflare IP ranges and requests include [automatic headers](/browser-rendering/reference/automatic-request-headers/), such as `cf-biso-request-id` and `cf-biso-devtools` so origin servers can identify them.
+
+### Is there a limit to how many requests a single browser session can handle?
+
+There is no fixed limit on the number of requests per browser session. A single browser can handle multiple requests as long as it stays within available compute and memory limits.
+
+### How can I manage concurrency and session isolation with Browser Rendering?
+
+If you are hitting concurrency [limits](/browser-rendering/platform/limits/#workers-paid), or want to optimize concurrent browser usage with the [Workers Binding method](/browser-rendering/workers-bindings/), here are a few tips:
+
+- Optimize with tabs or shared browsers: Instead of launching a new browser for each task, consider opening multiple tabs or running multiple actions within the same browser instance. 
+- [Reuse sessions](/browser-rendering/workers-bindings/reuse-sessions/): You can optimize your setup and decrease startup time by reusing sessions instead of launching a new browser every time. If you are concerned about maintaining test isolation (for example, for tests that depend on a clean environment), we recommend using [incognito browser contexts](https://pptr.dev/api/puppeteer.browser.createbrowsercontext), which isolate cookies and cache with other sessions. 
+
+If you are still running into concurrency limits you can [request a higher limit](https://forms.gle/CdueDKvb26mTaepa9). 
+
+---
+
+## Errors & Troubleshooting
+
+### I see `Cannot read properties of undefined (reading 'fetch')` when using Browser Rendering. How do I fix this?
+
+This error typically occurs because your Puppeteer launch is not receiving the Browser binding. To resolve: Pass your Browser binding into `puppeteer.launch`.
+
 ### Why can't I use an XPath selector when using Browser Rendering with Puppeteer?
 
 Currently it is not possible to use Xpath to select elements since this poses a security risk to Workers.
 
-As an alternative try to use a css selector or `page.evaluate` for example:
+As an alternative, try to use a css selector or `page.evaluate`. For example:
 
 ```ts
 const innerHtml = await page.evaluate(() => {
@@ -45,55 +75,16 @@ const innerHtml = await page.evaluate(() => {
 
 :::note
 
-Keep in mind that `page.evaluate` can only return primitive types like strings, numbers, etc.
-
-Returning an `HTMLElement` will not work.
+Keep in mind that `page.evaluate` can only return primitive types like strings, numbers, etc. Returning an `HTMLElement` will not work.
 
 :::
 
-### What are the usage limits for Browser Rendering and how do I estimate my costs?
-
-You can view the complete breakdown of concurrency caps, request rates, timeouts, and REST API quotas on the [limits page](/browser-rendering/platform/limits/).
-
-You can monitor your Browser Rendering usage in the [Cloudflare dashboard](https://dash.cloudflare.com). Go to **Compute (Workers)** > **Browser Rendering**. Then, you can use [the pricing page](/browser-rendering/platform/pricing/) to estimate your costs.
-
-### Does Browser Rendering rotate IP addresses for outbound requests?
+### Why is my screenshot blurry?
 
-No. Browser Rendering requests originate from Cloudflares global network, but you cannot configure per-request IP rotation. All rendering traffic comes from Cloudflare IP ranges and requests include special headers [(`cf-biso-request-id`, `cf-biso-devtools`)](/browser-rendering/reference/automatic-request-headers/) so origin servers can identify them.
+It may be because you increased the height and width of the viewport. To fix this, increase the value of the `deviceScaleFactor` (default is 1).
 
 ### I see `Error processing the request: Unable to create new browser: code: 429: message: Browser time limit exceeded for today`. How do I fix it?
 
 This error indicates you have hit the daily browser-instance limit on the Workers Free plan. [Free-plan accounts are capped at free plan limit is 10 minutes of browser use a day](/browser-rendering/platform/limits/#workers-free) once you exceed those, further creation attempts return a 429 until the next UTC day.
 
 To resolve: [Upgrade to a Workers Paid plan](/workers/platform/pricing/) which allows for more than 10 minutes of usage a day and has higher [limits](/browser-rendering/platform/limits/#workers-paid). If you recently upgraded but still see this error, try redeploying your Worker to ensure your usage is correctly associated with your new plan. 
-
-### Does local development support all Browser Rendering features?
-
-Not yet. Local development currently has the following limitation(s):
-- Requests larger than 1 MB are not supported.
-
-For full feature access, use `npx wrangler dev --remote`.
-
-### I upgraded from the Workers Free plan, but I'm still hitting the 10-minute per day limit. What should I do?
-
-If you recently upgraded to the Workers Paid plan to increase your Browser Rendering usage limits, but you're still encountering the 10-minute per day cap, try redeploying your Worker. This ensures your usage is correctly associated with your new plan.
-
-### Why is my screenshot blurry?
-
-If your screenshot is blurry, it may be because you increased the height and width of the viewport. To fix this, increase the value of the `deviceScaleFactor` (default is 1).
-
-### How can I manage concurrency and session isolation with Browser Rendering?
-
-If you are hitting concurrency limits, or would like to better manage concurrent browser usage with the [Workers Binding method](/browser-rendering/workers-bindings/), here are a few tips:
-
-- Optimize with tabs or shared browsers: Instead of launching a new browser for each task, consider opening multiple tabs or running multiple actions within the same browser instance. 
-- [Reuse sessions](/browser-rendering/workers-bindings/reuse-sessions/): You can optimize your setup and decrease startup time by reusing sessions instead of launching a new browser every time. If you are concerned about maintaining test isolation, for example for tests that depend on a clean environment, we recommend using [incognito browser contexts](https://pptr.dev/api/puppeteer.browser.createbrowsercontext), which isolate cookies and cache with other sessions. 
-
-If you are still running into concurrency limits you can [request a higher limit](https://forms.gle/CdueDKvb26mTaepa9). 
-
-### Is there a limit to how many requests a single browser session can handle?
-
-No, there is not a fixed limit on the number of requests per browser session. A single browser can handle multiple requests as long as it stays within the available compute and memory limits.
-
-###  Do failed API calls, such as those that time out, add to billable browser hours?
-No. If a request to the Browser Rendering REST API fails with a `waitForTimeout` error, the browser session is not charged.