From b55f146548466a3b92a08ab701d9c34741a563d3 Mon Sep 17 00:00:00 2001 From: Mike Nomitch Date: Tue, 7 Apr 2026 10:22:36 -0700 Subject: [PATCH] Containers and Sandboxes beta removal --- public/__redirects | 4 +- .../2026-04-13-containers-sandbox-ga.mdx | 29 +++++++ src/content/docs/containers/beta-info.mdx | 75 ------------------- .../containers/examples/container-backend.mdx | 5 +- .../docs/containers/examples/stateless.mdx | 5 +- src/content/docs/containers/faq.mdx | 71 ++++++------------ src/content/docs/containers/get-started.mdx | 17 ++--- src/content/docs/containers/index.mdx | 22 +----- .../platform-details/architecture.mdx | 26 ++++--- .../containers/platform-details/limits.mdx | 5 +- .../containers/platform-details/rollouts.mdx | 30 ++++---- .../platform-details/scaling-and-routing.mdx | 18 ++--- .../diagrams/ai/ai-vibe-coding-platform.mdx | 29 ++++--- src/content/docs/sandbox/index.mdx | 12 +-- .../docs/sandbox/platform/beta-info.mdx | 38 ---------- src/content/docs/sandbox/platform/index.mdx | 3 +- src/content/docs/sandbox/platform/limits.mdx | 5 ++ .../docs/workers/wrangler/configuration.mdx | 2 +- 18 files changed, 135 insertions(+), 261 deletions(-) create mode 100644 src/content/changelog/containers/2026-04-13-containers-sandbox-ga.mdx delete mode 100644 src/content/docs/containers/beta-info.mdx delete mode 100644 src/content/docs/sandbox/platform/beta-info.mdx diff --git a/public/__redirects b/public/__redirects index 6af57372fd55c5f..ab9030b60421d87 100644 --- a/public/__redirects +++ b/public/__redirects @@ -425,12 +425,15 @@ # Constellation /constellation/ /workers-ai/ 301 # Containers +/containers/beta-info/ /containers/faq/ 301 /containers/image-management/ /containers/platform-details/image-management/ 301 /containers/scaling-and-routing/ /containers/platform-details/scaling-and-routing/ 301 /containers/architecture/ /containers/platform-details/architecture/ 301 /containers/durable-object-methods/ /containers/platform-details/durable-object-methods/ 301 /containers/container-package/ /containers/container-class/ 301 /containers/platform-details/ /containers/platform-details/architecture/ 301 +# Sandbox +/sandbox/platform/beta-info/ /sandbox/platform/ 301 # D1 /d1/client-api/ /d1/worker-api/ 301 /d1/build-with-d1/d1-client-api/ /d1/worker-api/ 301 @@ -2675,4 +2678,3 @@ /changelog/2024-* /changelog/post/2024-:splat 301 /changelog/2025-* /changelog/post/2025-:splat 301 /changelog/2026-* /changelog/post/2026-:splat 301 - diff --git a/src/content/changelog/containers/2026-04-13-containers-sandbox-ga.mdx b/src/content/changelog/containers/2026-04-13-containers-sandbox-ga.mdx new file mode 100644 index 000000000000000..b17a4f7a8052a6c --- /dev/null +++ b/src/content/changelog/containers/2026-04-13-containers-sandbox-ga.mdx @@ -0,0 +1,29 @@ +--- +title: Containers and Sandboxes are now generally available +description: Containers and Sandbox SDK are now generally available on the Workers Paid plan. +products: + - containers +date: 2026-04-13 +--- + +Cloudflare [Containers](/containers/) and [Sandboxes](/sandbox/) are now generally available. + +Containers let you run more workloads on the Workers platform, including resource-intensive applications, different languages, and CLI tools that need full Linux environments. + +Since the initial launch of Containers, there have been significant improvements to Containers' performance, stability, and feature set. Some highlights include: + +- [Higher limits](/changelog/post/2026-02-25-higher-container-resource-limits/) allow you to run thousands of containers concurrently. +- [Active-CPU pricing](/changelog/post/2025-11-21-new-cpu-pricing/) means that you only pay for used CPU cycles. +- [Easy connections to Workers and other bindings](/changelog/post/2026-03-26-outbound-workers/) via hostnames help you extend your Containers with additional functionality. +- [Docker Hub support](/changelog/post/2026-03-24-docker-hub-images/) makes it easy to use your existing images and registries. +- [SSH support](/changelog/post/2026-03-12-ssh-support/) helps you access and debug issues in live containers. + +The [Sandbox SDK](/sandbox/) provides isolated environments for running untrusted code securely, with a simple TypeScript API for executing commands, managing files, and exposing services. This makes it easier to secure and manage your agents at scale. Some additions since launch include: + +- [Live preview URLs](/changelog/post/2025-08-05-sandbox-sdk-major-update/) so agents can run long-lived services and verify in-flight changes. +- [Persistent code interpreters](/changelog/post/2025-08-05-sandbox-sdk-major-update/) for Python, JavaScript, and TypeScript, with rich structured outputs. +- [Interactive PTY terminals](/changelog/post/2026-02-09-pty-terminal-support/) for real browser-based terminal access with multiple isolated shells per sandbox. +- [Backup and restore APIs](/changelog/post/2026-02-23-sandbox-backup-restore-api/) to snapshot a workspace and quickly restore an agent's coding session without repeating expensive setup steps. +- [Real-time filesystem watching](/changelog/post/2026-03-03-sandbox-watch-file-events/) so apps and agents can react immediately to file changes inside a sandbox. + +For more information, refer to [Containers](/containers/) and [Sandbox SDK](/sandbox/) documentation. diff --git a/src/content/docs/containers/beta-info.mdx b/src/content/docs/containers/beta-info.mdx deleted file mode 100644 index b0877ec8f7ed8c3..000000000000000 --- a/src/content/docs/containers/beta-info.mdx +++ /dev/null @@ -1,75 +0,0 @@ ---- -pcx_content_type: reference -title: Beta Info & Roadmap -sidebar: - order: 9 ---- - -Currently, Containers are in beta. There are several changes we plan to make prior to GA: - -## Upcoming Changes and Known Gaps - -### Limits - -Container limits will be raised in the future. We plan to increase -both maximum instance size and maximum number of instances in an account. - -See the [Limits documentation](/containers/platform-details/#limits) for more information. - -### Autoscaling and load balancing - -Currently, Containers are not autoscaled or load balanced. Containers can be scaled manually -by calling `get()` on their binding with a unique ID. - -We plan to add official support for utilization-based autoscaling and latency-aware load balancing -in the future. - -See the [Autoscaling documentation](/containers/platform-details/scaling-and-routing) for more information. - -### Reduction of log noise - -Currently, the `Container` class uses Durable Object alarms to help manage Container shutdown. This -results in unnecessary log noise in the Worker logs. You can filter these logs out in the dashboard -by adding a Query, but this is not ideal. - -We plan to automatically reduce log noise in the future. - -### Dashboard Updates - -The dashboard will be updated to show: - -- links from Workers to their associated Containers - -### Co-locating Durable Objects and Containers - -Currently, Durable Objects are not co-located with their associated Container. When requesting a container, -the Durable Object will find one close to it, but not on the same machine. - -We plan to co-locate Durable Objects with their Container in the future. - -### More advanced Container placement - -We currently prewarm servers across our global network with container images to ensure quick start times. -There are times in which you may request a new container and it will be started in a location that -farther from the end user than is desired. We are optimizing this process to ensure that this happens -as little as possible, but it may still occur. - -### Atomic code updates across Workers and Containers - -When deploying a Container with `wrangler deploy`, the Worker code will be immediately -updated while the Container code will slowly be updated using a rolling deploy. - -This means that you must ensure Worker code is backwards compatible with the old Container code. - -In the future, Worker code in the Durable Object will only update when associated Container code updates. - -## Feedback wanted - -There are several areas where we wish to gather feedback from users: - -- Do you want to integrate Containers with any other Cloudflare services? If so, which ones and how? -- Do you want more ways to interact with a Container via Workers? If so, how? -- Do you need different mechanisms for routing requests to containers? -- Do you need different mechanisms for scaling containers? (see [scaling documentation](/containers/platform-details/scaling-and-routing) for information on autoscaling plans) - -At any point during the Beta, feel free to [give feedback using this form](https://forms.gle/CscdaEGuw5Hb6H2s7). diff --git a/src/content/docs/containers/examples/container-backend.mdx b/src/content/docs/containers/examples/container-backend.mdx index 6f4cda7bde349fc..0226f3339135b05 100644 --- a/src/content/docs/containers/examples/container-backend.mdx +++ b/src/content/docs/containers/examples/container-backend.mdx @@ -150,7 +150,6 @@ export default { async fetch(request, env) { const url = new URL(request.url); if (url.pathname.startsWith("/api")) { - // note: "getRandom" to be replaced with latency-aware routing in the near future const containerInstance = await getRandom(env.BACKEND, INSTANCE_COUNT); return containerInstance.fetch(request); } @@ -161,8 +160,8 @@ export default { ``` :::note -This example uses the `getRandom` function, which is a temporary helper that will randomly -select of of N instances of a Container to route requests to. +This example uses `getRandom`, which randomly selects one of a fixed number of Container +instances for each request. In the future, we will provide improved latency-aware load balancing and autoscaling. diff --git a/src/content/docs/containers/examples/stateless.mdx b/src/content/docs/containers/examples/stateless.mdx index 5607bdeef2cb73e..afb28ad5552f135 100644 --- a/src/content/docs/containers/examples/stateless.mdx +++ b/src/content/docs/containers/examples/stateless.mdx @@ -22,7 +22,6 @@ class Backend extends Container { export default { async fetch(request: Request, env: Env): Promise { - // note: "getRandom" to be replaced with latency-aware routing in the near future const containerInstance = await getRandom(env.BACKEND, INSTANCE_COUNT); return containerInstance.fetch(request); }, @@ -30,8 +29,8 @@ export default { ``` :::note -This example uses the `getRandom` function, which is a temporary helper that will randomly -select one of N instances of a Container to route requests to. +This example uses `getRandom`, which randomly selects one of a fixed number of Container +instances for each request. In the future, we will provide improved latency-aware load balancing and autoscaling. diff --git a/src/content/docs/containers/faq.mdx b/src/content/docs/containers/faq.mdx index 071b2d44f65c443..7a34f1d5730f694 100644 --- a/src/content/docs/containers/faq.mdx +++ b/src/content/docs/containers/faq.mdx @@ -7,8 +7,6 @@ sidebar: import { Render, WranglerConfig } from "~/components"; -Frequently Asked Questions: - ## How do Container logs work? To get logs in the Dashboard, including live tailing of logs, toggle `observability` to true @@ -47,7 +45,7 @@ instance is running, any future requests will be routed to the initial location. An Example: - A user deploys a Container. Cloudflare automatically readies instances across its Network. -- A request is made from a client in Bariloche, Argentia. It reaches the Worker in +- A request is made from a client in Bariloche, Argentina. It reaches the Worker in Cloudflare's location in Neuquen, Argentina. - This Worker request calls `MY_CONTAINER.get("session-1337")` which brings up a Durable Object, which then calls `this.ctx.container.start`. @@ -68,7 +66,17 @@ See [rollout documentation](/containers/platform-details/rollouts/) for details. ## How does scaling work? -See [scaling & routing documentation](/containers/platform-details/scaling-and-routing/) for details. +Containers scale by creating or addressing specific instances. For stateless routing across a +fixed number of interchangeable instances, use the `getRandom` helper. + +Refer to [scaling and routing](/containers/platform-details/scaling-and-routing/) for details. + +### Is built-in autoscaling for stateless applications available? + +Not today, though Cloudflare plans to add built-in autoscaling in a future release. + +Until then, use `getRandom` for simple stateless routing and specific instance IDs when you need +explicit control over container lifecycle. ## What are cold starts? How fast are they? @@ -80,7 +88,7 @@ this instance for the first time, it will result in a cold start. This will start the container image from its entrypoint for the first time. Depending on what this entrypoint does, it will take a variable amount of time to start. -Container cold starts can often be the 2-3 second range, but this is dependent +Container cold starts can often be in the 1-3 second range, but this is dependent on image size and code execution time, among other factors. ## How do I use an existing container image? @@ -92,8 +100,12 @@ See [image management documentation](/containers/platform-details/image-manageme All disk is ephemeral. When a Container instance goes to sleep, the next time it is started, it will have a fresh disk as defined by its container image. -Persistent disk is something the Cloudflare team is exploring in the future, but -is not slated for the near term. +Snapshots are coming soon, which allow the user to quickly persist and restore the disk +from an entire container or a directory. + +You can also use [FUSE](/containers/examples/r2-fuse-mount/) to persist disk +to R2 or other object storage backends. Though you should not expect native +SSD-like performance while using FUSE. ## What happens if I run out of memory? @@ -102,7 +114,7 @@ will be restarted. Containers do not use swap memory. -## How long can instances run for? What happens when a host server is shutdown? +## How long can instances run for? What happens when a host server is shut down? Cloudflare will not actively shut off a container instance after a specific amount of time. If you do not set `sleepAfter` on your Container class, or stop the instance @@ -120,28 +132,7 @@ will be rebooted elsewhere shortly after this. You can use [Worker Secrets](/workers/configuration/secrets/) or the [Secrets Store](/secrets-store/integrations/workers/) to define secrets for your Workers. -Then you can pass these secrets to your Container using the `envVars` property: - -```javascript -class MyContainer extends Container { - defaultPort = 5000; - envVars = { - MY_SECRET: this.env.MY_SECRET, - }; -} -``` - -Or when starting a Container instance on a Durable Object: - -```javascript -this.ctx.container.start({ - env: { - MY_SECRET: this.env.MY_SECRET, - }, -}); -``` - -See [the Env Vars and Secrets Example](/containers/examples/env-vars-and-secrets/) for details. +For implementation details, refer to [Environment variables and secrets](/containers/examples/env-vars-and-secrets/). ## Can I run Docker inside a container (Docker-in-Docker)? @@ -176,22 +167,4 @@ For a complete working example, see the [Docker-in-Docker Containers example](ht ## How do I allow or disallow egress from my container? -When booting a Container, you can specify `enableInternet`, which will toggle -internet access on or off. - -To disable it, configure it on your Container class: - -```javascript -class MyContainer extends Container { - defaultPort = 7000; - enableInternet = false; -} -``` - -or when starting a Container instance on a Durable Object: - -```javascript -this.ctx.container.start({ - enableInternet: false, -}); -``` +Refer to [Handle outbound traffic](/containers/platform-details/outbound-traffic/) for how to control outbound traffic and internet access. diff --git a/src/content/docs/containers/get-started.mdx b/src/content/docs/containers/get-started.mdx index 16ead0283e18393..a010264ca26ae93 100644 --- a/src/content/docs/containers/get-started.mdx +++ b/src/content/docs/containers/get-started.mdx @@ -241,29 +241,28 @@ This allows for multiple ways of using Containers: Container instances. :::note -Currently, routing requests to one of many interchangeable Container instances is accomplished -with the `getRandom` helper. +Today, routing requests to one of many interchangeable Container instances uses the +`getRandom` helper. -This is temporary — we plan to add native support for latency-aware autoscaling and load balancing in the coming months. +It randomly selects one of a fixed number of instances for each request. ::: ## View Containers in your Dashboard -The [Containers Dashboard](http://dash.cloudflare.com/?to=/:account/workers/containers) shows you helpful +The [Containers Dashboard](https://dash.cloudflare.com/?to=/:account/workers/containers) shows you helpful information about your Containers, including: - Status and Health - Metrics - Logs -- A link to associated Workers and Durable Objects -After launching your Worker, navigate to the Containers Dashboard -by clicking on "Containers" under "Workers & Pages" in your sidebar. +After launching your Worker, go to the Containers Dashboard by selecting +**Workers & Pages** > **Containers** in the dashboard sidebar. ## Next Steps To do more: - Modify the image by changing the Dockerfile and calling `wrangler deploy` -- Review our [examples](/containers/examples) for more inspiration -- Get [more information on the Containers Beta](/containers/beta-info) +- Review our [examples](/containers/examples/) for more inspiration +- Review the [Frequently Asked Questions](/containers/faq/) for current platform behavior and limitations diff --git a/src/content/docs/containers/index.mdx b/src/content/docs/containers/index.mdx index c454884427d89c1..c05798e73fb6a85 100644 --- a/src/content/docs/containers/index.mdx +++ b/src/content/docs/containers/index.mdx @@ -1,12 +1,10 @@ --- -title: Containers (Beta) +title: Containers order: 0 pcx_content_type: overview sidebar: order: 1 - badge: - text: Beta head: - tag: title content: Overview @@ -18,10 +16,8 @@ import { Feature, LinkTitleCard, Plan, - RelatedProduct, TabItem, Tabs, - Badge, WranglerConfig, LinkButton, } from "~/components"; @@ -136,14 +132,6 @@ regional placement, Workflow and Queue integrations, AI-generated code execution - - Learn about the Containers Beta and upcoming features. - - Learn about what limits Containers have and how to work within them. - + Connect to running Container instances with SSH through Wrangler. diff --git a/src/content/docs/containers/platform-details/architecture.mdx b/src/content/docs/containers/platform-details/architecture.mdx index bce9e60af07c5bf..255ef73c030e153 100644 --- a/src/content/docs/containers/platform-details/architecture.mdx +++ b/src/content/docs/containers/platform-details/architecture.mdx @@ -8,12 +8,12 @@ sidebar: ## Deployment After you deploy an application with a Container, your image is uploaded to -[Cloudflare's Registry](/containers/platform-details/image-management) and distributed globally to Cloudflare's Network. +[Cloudflare's Registry](/containers/platform-details/image-management/) and distributed globally to Cloudflare's Network. Cloudflare will pre-schedule instances and pre-fetch images across the globe to ensure quick start times when scaling up the number of concurrent container instances. Unlike Workers, which are updated immediately on deploy, container instances are updated using a rolling deploy strategy. -This allows you to gracefully shutdown any running instances during a rollout. Refer to [rollouts](/containers/platform-details/rollouts/) for more details. +This allows you to gracefully shut down any running instances during a rollout. Refer to [rollouts](/containers/platform-details/rollouts/) for more details. ## Lifecycle of a Request @@ -43,10 +43,11 @@ When a Durable Object instance requests to start a new container instance, the * with a pre-fetched image** is selected. :::note -Currently, Durable Objects may be co-located with their associated Container instance, but often are not. +Durable Objects and their associated Container instances are not guaranteed to run in the +same location. -Cloudflare is currently working on expanding the number of locations in which a Durable Object can run, -which will allow container instances to always run in the same location as their Durable Object. +Container placement is optimized for request routing and startup speed, so a Container may +start in a different location than its Durable Object. ::: Starting additional container instances will use other locations with pre-fetched images, @@ -64,7 +65,7 @@ this instance for the first time, it will result in a cold start. This will start the container image from its entrypoint for the first time. Depending on what this entrypoint does, it will take a variable amount of time to start. -Container cold starts can often be the 2-3 second range, but this is dependent +Container cold starts can often be in the 1-3 second range, but this is dependent on image size and code execution time, among other factors. ### Requests to running Containers @@ -81,7 +82,7 @@ This location will again be the nearest location to the originating request with Each container instance runs inside its own VM, which provides strong isolation from other workloads running on Cloudflare's network. Containers should be built for the `linux/amd64` architecture, and should stay within -[size limits](/containers/platform-details/limits). +[size limits](/containers/platform-details/limits/). [Logging](/containers/faq/#how-do-container-logs-work), metrics collection, and [networking](/containers/faq/#how-do-i-allow-or-disallow-egress-from-my-container) are automatically set up on each container, as configured by the developer. @@ -92,7 +93,7 @@ If you do not set [`sleepAfter`](https://github.com/cloudflare/containers/blob/m on your Container class, or stop the instance manually, the container will shut down soon after the container stops receiving requests. By setting `sleepAfter`, the container will stay alive for approximately the specified duration. -You can manually shutdown a container instance by calling `stop()` or `destroy()` on it - refer to the [Container package docs](https://github.com/cloudflare/containers/blob/main/README.md#container-methods) for more details. +You can manually shut down a container instance by calling `stop()` or `destroy()` on it. Refer to the [Container package docs](https://github.com/cloudflare/containers/blob/main/README.md#container-methods) for more details. When a container instance is going to be shut down, it is sent a `SIGTERM` signal, and then a `SIGKILL` signal after 15 minutes. You should perform any necessary @@ -102,8 +103,13 @@ cleanup to ensure a graceful shutdown in this time. All disk is ephemeral. When a Container instance goes to sleep, the next time it is started, it will have a fresh disk as defined by its container image. -Persistent disk is something the Cloudflare team is exploring in the future, but -is not slated for the near term. + +Snapshots are coming soon, which allow the user to quickly persist and restore the disk +from an entire container or a directory. + +You can also use [FUSE](/containers/examples/r2-fuse-mount/) to persist disk +to R2 or other object storage backends. Though you should not expect native +SSD-like performance while using FUSE. ## An example request diff --git a/src/content/docs/containers/platform-details/limits.mdx b/src/content/docs/containers/platform-details/limits.mdx index 822346da73d6faf..bf03df2baa85488 100644 --- a/src/content/docs/containers/platform-details/limits.mdx +++ b/src/content/docs/containers/platform-details/limits.mdx @@ -36,11 +36,12 @@ Custom instance types have the following constraints: For workloads requiring less than 1 vCPU, use the predefined instance types such as `lite` or `basic`. -Looking for larger instances? [Give us feedback here](/containers/beta-info/#feedback-wanted) and tell us what size instances you need, and what you want to use them for. +If you need larger instance sizes or higher account-level limits, contact your account team, file a +support ticket, or fill out [this form](https://forms.gle/CscdaEGuw5Hb6H2s7). ## Limits -While in open beta, the following limits are currently in effect: +The following limits currently apply: | Feature | Workers Paid | | --------------------------------------------------- | ---------------------------------------------- | diff --git a/src/content/docs/containers/platform-details/rollouts.mdx b/src/content/docs/containers/platform-details/rollouts.mdx index 228c9b96fb6a493..4ff1864f964497c 100644 --- a/src/content/docs/containers/platform-details/rollouts.mdx +++ b/src/content/docs/containers/platform-details/rollouts.mdx @@ -12,16 +12,19 @@ import { WranglerConfig, PackageManagers } from "~/components"; When you run `wrangler deploy`, the Worker code is updated immediately and Container instances are updated using a rolling deploy strategy. The default rollout configuration is two steps, where the first step updates 10% of the instances, and the second step updates the remaining 90%. -This can be configured in your Wrangler config file using the [`rollout_step_percentage`](/workers/wrangler/configuration#containers) property. +This can be configured in your Wrangler config file using the [`rollout_step_percentage`](/workers/wrangler/configuration/#containers) property. -When deploying a change, you can also configure a [`rollout_active_grace_period`](/workers/wrangler/configuration#containers), which is the minimum +When deploying a change, you can also configure a [`rollout_active_grace_period`](/workers/wrangler/configuration/#containers), which is the minimum number of seconds to wait before an active container instance becomes eligible for updating during a rollout. -At that point, the container will be sent at `SIGTERM`, and still has 15 minutes to shut down gracefully. +At that point, the container will be sent a `SIGTERM` signal and still has 15 minutes to shut down gracefully. If the instance does not stop within 15 minutes, it is forcefully stopped with a `SIGKILL` signal. If you have cleanup that must occur before a Container instance is stopped, you should do it during this 15 minute period. Once stopped, the instance is replaced with a new instance running the updated code. Requests may hang while the container is starting up again. +Because Worker code updates immediately while container instances roll out gradually, keep +changes backwards compatible across both versions until the rollout completes. + Here is an example configuration that sets a 5 minute grace period and a two step rollout where the first step updates 10% of instances and the second step updates 100% of instances: @@ -34,28 +37,23 @@ Here is an example configuration that sets a 5 minute grace period and a two ste "class_name": "MyContainer", "image": "./Dockerfile", "rollout_active_grace_period": 300, - "rollout_step_percentage": [ - 10, - 100 - ] - } + "rollout_step_percentage": [10, 100], + }, ], "durable_objects": { "bindings": [ { "name": "MY_CONTAINER", - "class_name": "MyContainer" - } - ] + "class_name": "MyContainer", + }, + ], }, "migrations": [ { "tag": "v1", - "new_sqlite_classes": [ - "MyContainer" - ] - } - ] + "new_sqlite_classes": ["MyContainer"], + }, + ], } ``` diff --git a/src/content/docs/containers/platform-details/scaling-and-routing.mdx b/src/content/docs/containers/platform-details/scaling-and-routing.mdx index 0dc76e10ec9bd59..1a9b8368b5b5fc7 100644 --- a/src/content/docs/containers/platform-details/scaling-and-routing.mdx +++ b/src/content/docs/containers/platform-details/scaling-and-routing.mdx @@ -5,13 +5,13 @@ sidebar: order: 6 --- -### Scaling container instances with `get()` +## Scale container instances with explicit IDs :::note This section uses helpers from the [Container class](/containers/container-class/). ::: -Currently, Containers are only scaled manually by getting containers with a unique ID, then +Today, Containers are scaled manually by getting containers with a unique ID, then starting the container. Note that getting a container does not automatically start it. ```typescript @@ -33,11 +33,10 @@ This behavior is very useful when you want explicit control over the lifecycle o For instance, you may want to spin up a container backend instance for a specific user, or you may briefly run a code sandbox to isolate AI-generated code, or you may want to run a short-lived batch job. -#### The `getRandom` helper function +### Use the `getRandom` helper function -However, sometimes you want to run multiple instances of a container and easily route requests to them. - -Currently, the best way to achieve this is with the _temporary_ `getRandom` helper function: +If you want to run multiple instances of a container and route requests between them, use the +`getRandom` helper function: ```javascript import { Container, getRandom } from "@cloudflare/containers"; @@ -51,15 +50,14 @@ class Backend extends Container { export default { async fetch(request: Request, env: Env): Promise { - // note: "getRandom" to be replaced with latency-aware routing in the near future - const containerInstance = getRandom(env.BACKEND, INSTANCE_COUNT) + const containerInstance = await getRandom(env.BACKEND, INSTANCE_COUNT); return containerInstance.fetch(request); }, }; ``` -We have provided the getRandom function as a stopgap solution to route to multiple stateless container instances. -It will randomly select one of N instances for each request and route to it. Unfortunately, it has two major downsides: +Use `getRandom` to route to multiple stateless container instances. It randomly selects one of N +instances for each request, which means: - It requires that the user set a fixed number of instances to route to. - It will randomly select each instance, regardless of location. diff --git a/src/content/docs/reference-architecture/diagrams/ai/ai-vibe-coding-platform.mdx b/src/content/docs/reference-architecture/diagrams/ai/ai-vibe-coding-platform.mdx index 1a1d72267fe34cd..91da9b73489ba80 100644 --- a/src/content/docs/reference-architecture/diagrams/ai/ai-vibe-coding-platform.mdx +++ b/src/content/docs/reference-architecture/diagrams/ai/ai-vibe-coding-platform.mdx @@ -11,7 +11,7 @@ description: Cloudflare's low-latency, fully serverless compute platform, Worker ## Introduction -An AI-powered coding platform (sometimes referred to as a [“vibe coding”](https://www.cloudflare.com/learning/ai/ai-vibe-coding/) platform) enables users to build applications by describing what they want in natural language. These platforms allow anyone to build applications by handling everything from code generation, testing and debugging, to project deployment. +An AI-powered coding platform (sometimes referred to as a [“vibe coding”](https://www.cloudflare.com/learning/ai/ai-vibe-coding/) platform) enables users to build applications by describing what they want in natural language. These platforms allow anyone to build applications by handling everything from code generation, testing and debugging, to project deployment. Building the infrastructure for such a platform introduces a unique set of challenges. AI-generated code is inherently untrusted and must be executed in a secure, sandbox to prevent abuse and ensure isolation between users. To support rapid, conversational development, the platform must provide near-instantaneous feedback loops with live previews and real-time debugging. Finally, the platform needs a way to deploy and host the thousands or millions of applications its users will create, without running up the costs of traditional server infrastructure. @@ -28,8 +28,9 @@ To get started with a reference implementation of an AI vibe coding platform imm ![Figure 2: Vibe Hosting Overview](~/assets/images/reference-architecture/ai-vibe-coding/vibe-hosting-overview.svg) To build an AI-powered coding platform, you will need these key components: + - **AI for Code Generation:** Integrate with AI models to interpret user prompts and automatically generate code. -- **Secure Execution Sandbox:** Provide a secure, isolated environment where users can instantly run and test untrusted, AI-generated code. +- **Secure Execution Sandbox:** Provide a secure, isolated environment where users can instantly run and test untrusted, AI-generated code. - **Scalable Application Deployment :** Deploy and host AI-generated applications at scale. - **Analytics & Observability:** Collect logs and metrics to monitor AI usage, application performance, and platform costs. @@ -37,9 +38,10 @@ To build an AI-powered coding platform, you will need these key components: #### Connecting to AI Providers for Code Generation -The first step is processing a user's natural language prompt and securely routing it to an AI model to generate code. +The first step is processing a user's natural language prompt and securely routing it to an AI model to generate code. + +When using various AI providers, you need visibility into costs, the ability to cache responses to reduce expenses, and failover capabilities to ensure reliability. [AI Gateway](/ai-gateway/) acts as a unified control point between your platform and AI providers to deliver these capabilities, enabling: -When using various AI providers, you need visibility into costs, the ability to cache responses to reduce expenses, and failover capabilities to ensure reliability. [AI Gateway](/ai-gateway/) acts as a unified control point between your platform and AI providers to deliver these capabilities, enabling: - A [unified access point](/ai-gateway/usage/chat-completion/) to route requests across LLM providers, allowing you to use [models](/workers-ai/models/) from a range of providers (OpenAI, Anthropic, Google, and others) - [Caching](/ai-gateway/features/caching/) for popular responses, so when someone asks to "build a todo list app", the gateway can serve a cached response instead of going to the provider (saving inference costs) - [Observability](/ai-gateway/observability/analytics/) into the requests, tokens used, and response times across all providers in one place @@ -47,20 +49,22 @@ When using various AI providers, you need visibility into costs, the ability to #### Making your AI better at building on Cloudflare -If you’re building an AI code generator and want it to be more knowledgeable about how to best build applications on Cloudflare, there are two tools we recommend using: +If you’re building an AI code generator and want it to be more knowledgeable about how to best build applications on Cloudflare, there are two tools we recommend using: + - **[Cloudflare Workers Prompt](/workers/get-started/prompting/#build-workers-using-a-prompt):** Structured prompt with examples that teach AI models about Cloudflare's APIs, configuration patterns, and best practices. Include these in your AI system for higher quality code output. -- **[Cloudflare’s Documentation MCP server](https://github.com/cloudflare/mcp-server-cloudflare/tree/main/apps/docs-vectorize):** If your AI tool supports [Model Context Protocol (MCP)](/agents/model-context-protocol/), connect it to Cloudflare's documentation MCP server to get up-to-date knowledge about Cloudflare’s platform. +- **[Cloudflare’s Documentation MCP server](https://github.com/cloudflare/mcp-server-cloudflare/tree/main/apps/docs-vectorize):** If your AI tool supports [Model Context Protocol (MCP)](/agents/model-context-protocol/), connect it to Cloudflare's documentation MCP server to get up-to-date knowledge about Cloudflare’s platform. ## Development environment for executing AI-generated code -Both [Sandboxes](/changelog/2025-06-24-announcing-sandboxes/) and [Containers](/containers/) provide secure, isolated environments for executing untrusted AI-generated code. They offer: +Both [Sandboxes](/sandbox/) and [Containers](/containers/) provide secure, isolated environments for executing untrusted AI-generated code. They offer: + - **Strong isolation and sandboxing controls** to prevent malicious or buggy code from affecting other instances - **Fast startup times** to enable rapid iteration cycles with real-time feedback - **Real-time output streaming** of logs and results for live progress updates and debugging - **Preview URLs** to allow users to test applications during development - **Global edge deployment** on Cloudflare's network for low-latency execution worldwide -**Sandboxes provide a fully-managed solution** that works out-of-the-box, with [pre-built APIs](/changelog/2025-08-05-sandbox-sdk-major-update/) for code execution, output formatting, and developer tools, making them ideal for most AI code execution use cases. +**Sandboxes provide a fully-managed solution** that works out-of-the-box, with [pre-built APIs](/sandbox/api/) for code execution, output formatting, and developer tools, making them ideal for most AI code execution use cases. ![Figure 3: Vibe Code Development - Sandbox SDK](~/assets/images/reference-architecture/ai-vibe-coding/ai-platform-sandbox.svg) @@ -72,20 +76,21 @@ Both [Sandboxes](/changelog/2025-06-24-announcing-sandboxes/) and [Containers](/ When building an AI-powered coding platform, you need to be able to deploy and host the thousands to millions of applications that the platform will generate. -[Workers for Platforms](/cloudflare-for-platforms/workers-for-platforms/) provides this infrastructure by enabling you to deploy unlimited applications, with each application running in its own isolated Worker instance, preventing one application from impacting others. +[Workers for Platforms](/cloudflare-for-platforms/workers-for-platforms/) provides this infrastructure by enabling you to deploy unlimited applications, with each application running in its own isolated Worker instance, preventing one application from impacting others. **With Workers for Platforms, you get:** + - **Isolation and multitenancy** — every application runs in its own dedicated Worker, a secure and isolated sandbox environment - **Egress control and usage limits** — Configure firewall policies for all outgoing requests through an [outbound worker](/cloudflare-for-platforms/workers-for-platforms/configuration/outbound-workers/) and [custom usage limits](/cloudflare-for-platforms/workers-for-platforms/configuration/custom-limits/) to prevent abuse - **Dedicated resources per project:** Attach a KV store or database to each application, enabling more powerful functionality while ensuring [resources](/cloudflare-for-platforms/workers-for-platforms/configuration/bindings/) are only accessible by the application they’re attached to. -- **Logging & Observability** across the platform to gather insights, monitor performance, and troubleshoot issues across applications +- **Logging & Observability** across the platform to gather insights, monitor performance, and troubleshoot issues across applications ![Figure 5: Complete Vibe Coding Platform](~/assets/images/reference-architecture/ai-vibe-coding/vibe-hosting-analytics.svg) ## Conclusion -Cloudflare provides a complete set of services needed for building AI-powered platforms that need to run, test, and deploy untrusted code at scale. +Cloudflare provides a complete set of services needed for building AI-powered platforms that need to run, test, and deploy untrusted code at scale. -Cloudflare has a template AI vibe coding platform that you can deploy, so you can get started with a complete example that handles everything from code generation, sandboxes development with a preview environment, and integration with Workers for Platforms for deploying and hosting the applications at scale. +Cloudflare has a template AI vibe coding platform that you can deploy, so you can get started with a complete example that handles everything from code generation, sandboxes development with a preview environment, and integration with Workers for Platforms for deploying and hosting the applications at scale. [![Deploy to Cloudflare Workers](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/vibesdk) diff --git a/src/content/docs/sandbox/index.mdx b/src/content/docs/sandbox/index.mdx index 0b405e3ac735699..d7f4bc6b5efb163 100644 --- a/src/content/docs/sandbox/index.mdx +++ b/src/content/docs/sandbox/index.mdx @@ -1,10 +1,8 @@ --- -title: Sandbox SDK (Beta) +title: Sandbox SDK pcx_content_type: overview sidebar: order: 1 - badge: - text: Beta head: - tag: title content: Overview @@ -348,14 +346,6 @@ Stateful coordination layer that enables Sandbox to maintain persistent environm View the SDK source code, report issues, and contribute to the project. - - Learn about the Sandbox Beta, current status, and upcoming features. - - With WebSocket transport enabled: + - The WebSocket upgrade counts as one subrequest - All subsequent SDK operations use the existing connection (no additional subrequests) - Ideal for workflows with many SDK operations per request diff --git a/src/content/docs/workers/wrangler/configuration.mdx b/src/content/docs/workers/wrangler/configuration.mdx index cfba132144c1983..59d4721915fb19b 100644 --- a/src/content/docs/workers/wrangler/configuration.mdx +++ b/src/content/docs/workers/wrangler/configuration.mdx @@ -1249,7 +1249,7 @@ The following options are available: - Build-time variables, equivalent to using `--build-arg` with `docker build`. If you want to provide environment variables to your container at _runtime_, you should [use secret bindings or `envVars` on the Container class](/containers/examples/env-vars-and-secrets/). - `rollout_active_grace_period` - - The minimum number of seconds to wait before an active container instance becomes eligible for updating during a [rollout](/containers/faq#how-do-container-updates-and-rollouts-work). At that point, the container will be sent at `SIGTERM` and still has 15 minutes to shut down before it is forcibly killed and updated. + - The minimum number of seconds to wait before an active container instance becomes eligible for updating during a [rollout](/containers/platform-details/rollouts/). At that point, the container will be sent a `SIGTERM` signal and still has 15 minutes to shut down before it is forcibly killed and updated. - Defaults to `0`. - `rollout_step_percentage`