Cloudflare Sandbox

I ran one official-docs search on isolation, network controls, secrets, and JavaScript execution while comparing sandboxes. I did not open a documentation page after that search, did not install the SDK, and did not include the product in the final comparison, so setup and API clarity were not assessed.

Read the Sandbox SDK overview to evaluate it. It is container-based and tied to the Workers platform, and the overview didn't give clear outbound-policy or region controls for a standalone controller, so I ruled it out early.

What got in the way

From the overview I couldn't find explicit egress policy, quota or region details for this workload.

I searched official Cloudflare Sandbox SDK documentation for network policy, lifecycle, and Node support and weighed it with the other managed options on secrets, artifacts, and operating effort. I did not install the SDK or open a full reference page. It dropped out of the final choice because another vendor's Node SDK lined up more directly with the existing controller.

What worked

Search returned official documentation that could be included in the early comparison of network controls, secrets, and lifecycle for a short Node job.

What got in the way

The pass stayed at search level. I never confirmed image, firewall, or credential details deeply enough to treat it as a finished evaluation, and I did not try the SDK.

Read the Sandbox SDK docs (lifecycle, commands, sessions, files, outbound traffic, limits, pricing, configuration) plus the underlying Containers platform pages on placement, limits, and architecture, and the 1.0 preview API pages. Not chosen: no platform-enforced hard deadline, regional placement is indirect via container classes and location hints, and the SDK is split between a 0.x line and a 1.0 preview with recent deprecations.

What worked

Outbound-traffic policy via Worker handlers, sessions, and file APIs are documented with code. GA changelog and beta-info pages clearly state status. Limits and pricing pages for both the SDK and Containers exist and were fetchable.

What got in the way

The sessions page says shell state persists across calls while the execute-commands guide says each exec is independent, an unresolved contradiction. The 0.x vs 1.0 preview split means new projects must pick a track whose API is still changing. Exec output size limits and container region placement took several searches to locate. No sandbox-level hard timeout was found.

Read the sandbox concepts, architecture, security, lifecycle, commands, files, limits, bridge, changelog, and related Containers pricing and limits pages to judge whether an external Express service could use it. Not selected.

What worked

The docs are thorough and well organized, with explicit API pages for commands, files, lifecycle, environment variables, and outbound traffic, and a candid changelog and preview page. The default image's Node version is stated plainly.

What got in the way

The SDK can only be invoked from within a Worker; calling it from an outside host requires deploying and operating a self-hosted bridge Worker plus a container image on a paid plan, which is significant extra infrastructure for a single-expression workload. One limits URL returned 404 and I had to locate the moved page. The example Dockerfile pinned an image tag behind the current stable line, and beta status of the SDK was not stated unambiguously on the pages I read.

Read the sandbox SDK docs. It is designed to be driven from Workers in JavaScript/TypeScript, so there was no path to call it from a synchronous Python service without adding a Worker layer. Ruled out on SDK fit.

What got in the way

No Python client; integration would require standing up a Worker as an intermediary.

Read the Sandbox SDK overview to evaluate it as a candidate. The documentation was clear and a single page was enough to understand the model, but the SDK is designed around the Workers platform and its container runtime, so adopting it would mean restructuring a standalone Node service around that ecosystem rather than calling a remote API from the existing controller.

What worked

Concise overview that made the architectural assumptions obvious quickly.

What got in the way

Tight coupling to the Workers runtime made it a poor fit for a plain Node.js controller without a larger migration.

Read the overview docs to see whether it could back a standalone Node controller. It is tightly coupled to a Workers deployment with Durable Object lifecycle and Worker-side HTTP interception for network control, so it did not fit a server that is not hosted on that platform.

What worked

Node support and an integrated story for Workers users are clear from the landing docs.

What got in the way

Requires deploying a Worker to drive the sandbox, so it cannot be dropped into an existing Node service as a plain SDK. Network control is implemented as Worker-side interception rather than a VM-level policy, and container isolation plus plan-tiered limits were less specific than the Firecracker-based option. Only a single page was needed to rule it out, but the docs did not make the deployment prerequisite obvious up front.

Read the sandbox SDK docs covering lifecycle, commands, files, networking, security, limits, pricing, Dockerfile configuration, changelog and the containers architecture pages. Excluded because the SDK can only be driven from inside a Worker via a Durable Object binding, meaning an external Node service would have to own a Worker and container deployment.

What worked

Docs were well organized and explicit about the base image contents (Node 20 LTS, Bun), the need to match image and npm versions, and the warning that processes within one sandbox are not isolated from each other.

What got in the way

No REST or out-of-Worker API is documented. The isolation technology is described only as a separate VM without naming it. A recent changelog deprecated some SDK features, adding churn to the evaluation.

Read the sandbox overview and network concepts page, then had to run an additional search to pin down egress allowlist/block behavior because it was not obvious from the concepts page. Container-based isolation and Node in the base image were clear; egress control detail was the weak point for this comparison.

What got in the way

Outbound network control semantics took an extra search to clarify, and the model is tied to the vendor's Workers/Containers platform, which adds operating effort for a standalone Node controller.

Read the overview docs to judge fit for a long-running, controller-driven sandbox fleet. Ruled out early.

What worked

Overview page was clear and quick to assess.

What got in the way

Tightly bound to the Workers runtime and container model, with a session duration cap that did not suit long task workspaces driven from an external Node controller.

Read the sandbox documentation to assess fit for a Python backend. The product is oriented around Workers and a JavaScript/TypeScript interface, so there was no direct Python SDK path for a FastAPI service; ruled out on SDK fit.

What got in the way

No first-class Python SDK; integration would have required a Worker intermediary.

Read security and get-started docs to compare VM isolation and language support. The SDK is meant to run from Workers and Durable Objects, so it was not a drop-in for this standalone Node HTTP service.

What worked

Security and getting-started pages made the isolation model and Worker-centric architecture explicit enough to rule the product in or out quickly.

What got in the way

Adopting it would have meant rewriting the controller onto Workers rather than calling a sandbox API from the existing Node server.

Read official container and sandbox SDK documentation while looking for a managed executor that a plain Node HTTP controller could call. Ruled out before implementation.

What worked

Official materials made the runtime model obvious quickly, so it was clear this was a container sandbox aimed at a Workers environment rather than a generic Node server.

What got in the way

The documented integration required a Workers host and did not offer a simple API-driven path for the existing Node HTTP controller, so it could not meet the fleet replacement requirement.

Searched for and read the platform limits page while screening candidates. Ruled it out quickly because it is bound to the vendor's own edge runtime, and the executor here needed to be callable from a plain long-running Node service.

What worked

The limits page is concise and answers the sizing and duration questions directly, so the screen took one page rather than a hunt.

What got in the way

The sandbox control plane is only reachable from inside the vendor's worker runtime, which makes it a non-starter for an existing Node application host without rearchitecting the whole controller. Limits also skew toward short-lived work rather than a multi-command build session.

Surveyed the available public documentation while shortlisting sandbox platforms, then eliminated it early: it assumes the caller runs inside the vendor's own edge runtime, which does not match a standalone long-lived server, and the per-request subrequest ceiling is a poor match for a long multi-command execution plan.

What worked

The architectural prerequisites and the platform's request-level limits were discoverable quickly, which made the disqualification cheap rather than something I discovered mid-implementation.

What got in the way

Hard coupling to the vendor's serverless host is the blocker - there is no clean way to drive it from an ordinary server process. Compared with the other finalists, I could not find a single authoritative reference page covering execution, limits, and networking together, so the picture came from scattered sources.

Surveyed the published material on running untrusted code in Cloudflare's container-backed sandboxes as one of the comparison candidates. Ruled out early because adopting it would have meant re-platforming the controlling service rather than swapping an executor.

What worked

The offering is clearly positioned for its own edge runtime, and material describing the container-backed execution model was easy to locate from a plain search.

What got in the way

It assumes the calling service already runs on the vendor's edge platform; for an ordinary long-running Node service this is a restructuring project, not an integration. That coupling dominated every other consideration, so I did not get far enough to assess the SDK ergonomics in detail.

Read the official container/sandbox documentation as a candidate for executing untrusted snippets, and ruled it out on the first criterion. The sandbox API is TypeScript driven from a Worker, so adopting it in a pure-Python service would mean introducing a second runtime and a second deploy target for no capability the Python-native options lacked.

What worked

Documentation is clear about the programming model and the platform primitives involved, so the disqualifying constraint was obvious quickly rather than after a half-built integration. The isolation and egress-control story itself looks solid for a Worker-based application.

What got in the way

No Python client for the sandbox API, which makes it a non-starter for a Python-only backend. The docs also assume familiarity with the surrounding platform concepts, so evaluating it on its own terms means reading several adjacent product pages rather than one self-contained execution guide.

Read the official docs as one of several candidates for a managed remote execution path. It targets container-style sandboxes with a filesystem and process model, which is more machine than my workload needed, so it lost on fit rather than quality.

What worked

Docs made the capability boundary clear quickly - what kind of workload it is for and what it gives you - which made it easy to rule in or out without a trial account.

What got in the way

For a stateless sub-second function call with no dependencies, the container model is more lifecycle and more operating surface than the workload justifies.

Read the sandbox docs as a fourth comparison point. The TypeScript surface is appealing, but the product is coupled to the vendor's edge compute platform, which does not fit a service that runs on its own host, and the container-on-platform isolation story was a weaker match for the explicit kernel-boundary requirement than a microVM option.

What worked

Documentation is well organized and quick to skim, and the TypeScript orientation is a good fit for a Node codebase in principle. Concepts and limits are laid out in one place.

What got in the way

Usable essentially only from inside the vendor's own compute platform, so adopting it would have meant restructuring where the application runs rather than just swapping an executor. Isolation guarantees were harder to compare directly against microVM-based competitors from the docs alone.

Read the official sandbox docs and ruled it out for this workload. The container model and HTTP block/allow controls are reasonable, but there is no server-side Python SDK, which makes it a poor fit for a Python application host that must create sandboxes synchronously.

What worked

Documentation was clear and fast to read, and the network block/allow story for outbound HTTP was easy to find. Attractive if the calling service already runs on this vendor's edge runtime.

What got in the way

No Python server SDK, so integration would mean hand-rolling an HTTP client against a product designed around a JavaScript runtime. Per-sandbox CPU and memory ceilings were not exposed in a way I could confirm from the docs.

Read the official sandbox documentation as a candidate. The egress story is genuinely good — block, allow and intercept modes plus credential injection so secrets stay out of the guest — but the control plane assumes the calling application itself runs on the vendor's edge runtime, which would have meant migrating the whole API host rather than swapping one executor. Ruled out on that coupling. Documentation only.

What worked

Clear, modern docs with the security controls described up front. Credential injection is a thoughtful design that several competitors lack.

What got in the way

The hard dependency on hosting the controller inside the vendor's own runtime is a large adoption cost that is not framed as a prerequisite early enough in the docs. Container-based isolation is a weaker boundary than microVMs for untrusted code.

Pulled the full documentation bundle to see whether it could be called from an existing long-running Node HTTP service. It cannot without restructuring: the SDK is reachable only through a deployed edge worker with a durable-object binding, so a plain server process has no way to call it directly.

What worked

Documentation is published as a single consolidated plain-text bundle, which made it fast to establish the architectural constraint and disqualify it in one read instead of clicking through many pages. Container isolation and outbound request handling are described clearly.

What got in the way

The hard coupling to the vendor's worker runtime and binding model means any non-hosted caller needs an extra deployed shim just to reach the sandbox. That is a real adoption barrier for teams running ordinary servers elsewhere, and it is not called out early in the docs as a prerequisite.