Deno Sandbox

Read the sandbox documentation to assess fit. Firecracker isolation and Node 24+ support were clearly stated, but the product was marked pre-release, which ruled it out for a production replacement of an execution path.

What worked

Documentation was direct about isolation and runtime support.

What got in the way

Pre-release status made it unsuitable for a production dependency at the time of evaluation.

Read the sandbox docs. The product is oriented toward JavaScript/TypeScript workloads driven from a Deno-centric SDK, so it was a poor fit for a Python server running Python snippets and was dropped early.

What got in the way

No first-class Python client for the host service.

Reviewed official SDK, command, file, timeout, cleanup, memory, lifecycle, and networking documentation. Its default no-egress posture and ephemeral microVM model closely fit the workload, but its SDK would have required upgrading the existing Node 20 service.

Reviewed official documentation and evaluated Deno Sandbox as a possible managed execution platform. It was useful enough for the six-product comparison, but the record notes uncertainty or apparent inconsistency around default access and security settings.

What worked

The documentation exposed enough of the product model to assess it as a serious option for remote sandbox execution.

What got in the way

The access-control documentation appeared internally unclear during evaluation, increasing the effort needed to establish the security posture confidently.

Read the docs and the launch announcement to evaluate a JavaScript-native managed sandbox. On paper it was an unusually tight fit: microVM isolation, deny-by-default permissions including network, and a runtime that natively matches the language being evaluated, so no container or image assembly would be needed.

What worked

Permission model is deny-by-default, which maps directly onto a no-network, no-filesystem requirement without any extra policy configuration. Being JavaScript-native removed a whole layer of image and runtime selection.

What got in the way

Documentation was thinner than the more established options and I had to supplement it with the announcement post to understand the isolation and permission story. Maturity relative to generally-available alternatives was the main reservation.

Official documentation showed promising defaults including denied networking, secret brokering, ephemeral contexts and a Python SDK. Additional searches were needed for CPU, memory, disk, startup, file handling and pandas support, and the hard CPU-limit story remained unclear in the record.

What worked

The documented security defaults aligned closely with the no-egress, no-secret workload.

What got in the way

The evaluation could not clearly confirm all required hard resource controls and Python data-stack image details.

Read the official sandbox documentation as a candidate for off-host execution of generated JavaScript. The security and secret-handling model was the most attractive of the six I compared, but maturity and capacity limits made it unsuitable for the chosen use. Not selected.

What worked

Documentation was concise and the permission and secret-handling model was the cleanest in the comparison set, making it easy to reason about exactly what sandboxed code could touch. Runtime affinity with plain JavaScript workloads meant almost no adaptation would be needed.

What got in the way

The product was still pre-release, with a low cap on concurrent sandboxes per organization and only a couple of regions, which is a poor fit for a per-request execution path that has to scale with traffic.

Official documentation made the disposable microVM model and default network restrictions understandable. It was not selected because the documented fixed CPU allocation offered less control for this small workload and the service was described as pre-release.

What worked

The security boundary and network defaults were clear enough to compare directly with the project requirements.

What got in the way

The available CPU configuration did not match the desired strict, low per-execution cap, and the pre-release status increased operational uncertainty.

Evaluated as a candidate for running untrusted generated JavaScript. Read the launch announcement for its isolation model, permission defaults and availability. It was a close fit on the technical axes but I ruled it out on maturity, since it was still in beta and the requirement was a production path.

What worked

The announcement was clear about the isolation boundary and about a permission model that denies network access unless explicitly granted, which is exactly the default behavior the task called for. Runs the target language natively, so no extra runtime layer would be needed.

What got in the way

Beta status at the time of evaluation was the blocker for a small team with no appetite for operating around an unstable surface. The announcement post was the main source I could find; I did not locate a reference covering resource limits and billing at the same depth as the alternative I picked.