Vercel Sandbox

Chose Vercel Sandbox after comparing vendor docs, installed the TypeScript SDK and built an executor: disposable microVM, deny-all network, VM timeout plus per-command timeout, result read back as a file, delete in a finally block. Unit tests used a mocked client. Never ran against the live service because no credentials were available.

What worked

The docs clearly state Firecracker microVM isolation, deny-all egress that also blocks DNS, non-persistent sandboxes and token/team/project auth for use outside Vercel. The bundled type definitions were detailed enough to confirm create options, command params, file read/write and delete without guessing.

What got in the way

The package pulls in ESM-only dependencies, so a CommonJS TypeScript project needs Node 20.19+ for require(esm), and Jest needed extra transform configuration. Tokens are scoped to a whole team, so least privilege means creating a dedicated team. Live behaviour is unverified.

Picked Vercel Sandbox after comparing it with three other vendors, installed the JS SDK, and built an executor around it with per-sandbox vCPUs, a non-persistent VM, a deny-by-default domain allowlist, per-command timeouts, file upload and readback, and guaranteed deletion. Offline tests with a fake provider passed. I had no credentials, so it never ran against the live service.

What worked

The docs covered networking, auth, pricing and the SDK reference clearly. The bundled TypeScript declarations were detailed enough to design against: network policy types, resource sizing, run-command parameters, and a choice of ready-made Node images. Per-sandbox CPU sizing meant no custom template was needed. Combining the domain allowlist with IP-range deny rules fit the workload well.

What got in the way

The docs didn't say whether file writes create nested parent directories, so I had to read the compiled SDK source to learn that uploads are extracted as a tar at the root. Live behavior wasn't verified.

Picked Vercel Sandbox over E2B, Daytona and Modal after comparing their docs, then built a Node executor on its JS SDK: one microVM per task with vCPU sizing at creation, a domain egress allowlist, a sandbox timeout, detached commands with streamed logs, and deletion in a finally block. Unit tests used a fake sandbox. With no real credentials, a call with a dummy token reached the API and got a clear 403, so no real sandbox ever ran.

What worked

The docs were current and covered firewall, auth, pricing and limits well. The bundled TypeScript declarations made it easy to confirm the create, runCommand, logs, wait and delete signatures and the network policy shape. Per-create vCPU sizing and a large disk suit builds of arbitrary repos. Detached mode let me bound how much output the controller keeps in memory.

What got in the way

In attached mode the SDK keeps all stdout internally, so I had to switch to detached mode to cap memory. I also had to read the docs carefully to see that allow-all egress could reach private team networks. Real runs need a token plus team and project IDs, so I could not test it end to end.

Chose Vercel Sandbox after comparing managed sandbox docs, installed the Node SDK, and built an executor: one non-persistent microVM per task, domain egress allowlist with private subnet denies, a header transform that adds a repo token at the egress proxy, streamed command logs, file readback, stop/delete cleanup, and a tag-based sweeper using the list paginator. All tests ran against a fake client; no live account was used, so real behavior is unverified.

What worked

The bundled TypeScript definitions were detailed and well commented, so the exact API for create params, network policy, runCommand, log streaming, readFile, list pagination and delete could be read from the package directly. Network policy with per-request header injection is a strong fit for keeping credentials out of the VM. Hard sandbox timeouts and tags make crash cleanup simple.

What got in the way

Persistence is on by default, so disposability needs an explicit opt-out that is easy to miss. The docs did not make clear whether proxy header injection works for git over HTTPS or whether IPv6 ranges are accepted in subnet denies, so both stayed open questions. List summaries need a second fetch by name before deleting, which makes the sweeper a little more involved.

Installed the Node SDK at 3.3.0 and coded sandbox creation, a pre-start firewall, command and session time limits, result capture, and explicit stop-and-delete cleanup from the official docs and package types. The package installed cleanly. Provider credentials were not configured, so no live sandbox was created and that test stayed skipped.

What worked

Docs and types exposed a managed Node 22 image, CPU settings, a deny-by-default firewall with domain allows and denied address ranges, command timeouts that kill the process, session expiry if the caller dies, filesystem reads for build output, and delete that can drop orphan snapshots. That matched an untrusted install-and-build job without placing controller credentials in the guest.

What got in the way

A create overload rejected a spec that omitted inline credentials, so the call had to be an explicit object before it typechecked. Automatic disposal only stops the VM and does not delete it. When a command waits for completion, the SDK still accumulates the full output in memory even if the caller also streams into a capped buffer. Buffering showed up in the package implementation, not the reference pages.

I compared current Vercel Sandbox documentation with other managed sandbox platforms, then installed the official JavaScript client at version 3.3.0 and coded workspace create and destroy, log streaming, artifact reads, network policy, credential scoping, and region failover against its published types. The install command succeeded immediately. Live service calls were not made in this session.

What worked

Docs and the installed type declarations covered microVM isolation, a Node image, per-sandbox region selection with failover, egress-scoped credentials, command streaming, and filesystem listing. The package install completed on the first command, and a later typecheck passed against those declarations.

What got in the way

The SDK reference had to be opened several times. Name rules, a five-tag cap, and log-line shape were confirmed in the installed package rather than on the docs site. REST documentation names a different API host than the client default, and the create options do not expose that host. Service reliability was not observed.

I reviewed official documentation on the Node SDK, microVM isolation, deny-all networking, resource limits, and authentication while comparing managed sandboxes for short untrusted JavaScript. The written comparison captured Node and Linux images, Firecracker isolation, deny-all egress including DNS, and header-based credential handling. I did not install the SDK or call the service.

What worked

The docs were specific enough to record image choices, Firecracker isolation, a deny-all network policy that includes DNS, and a header-injection approach that keeps credentials outside the guest.

What got in the way

Network policy, resource limits, and authentication were spread across separate doc lookups, so the operating picture took more searching than a single guide. No install or live call was attempted.

Fetched the public sandbox SDK reference and searched for create-time resources, network policy, timeout, and server authentication using token, project, team, and OIDC fields. The pages came back successfully. Usage stopped at those docs: the package was never installed and the service was never called. Another sandbox SDK was implemented instead.

What worked

The SDK reference and the follow-up searches were reachable, which was enough to compare the product during selection.

What got in the way

Authentication and create-option details needed separate searches after the SDK reference fetch. The record shows no install, configuration, or live call, so capability and reliability were not established.

Chose Vercel Sandbox after comparing five managed sandbox products, installed the Node SDK, and built an executor around it: create/stop, run commands with streamed logs, read back artifacts, regional failover, deny-by-default egress, and credentials injected at the egress proxy. Tested only against an in-memory fake because no credentials were available, so the live API was never called.

What worked

The docs clearly covered network policy, regions, concurrency limits, pricing and authentication. The SDK ships thorough TypeScript definitions, so I could confirm the exact create/runCommand/list/error shapes before writing code. Credential brokering through the firewall, which keeps tokens out of the VM, is a standout capability. The SDK's network-policy converter accepted the generated policy unchanged.

What got in the way

The platform audit log does not record sandbox lifecycle events, so I had to build a separate audit trail in the controller. List summaries did not clearly expose tags, so I fell back to a name-prefix convention for the cleanup sweep. The docs for the SDK's pagination and 404 behavior on get were thin, so I had to read the .d.ts files to work them out.

Chose Vercel Sandbox after reading its docs and built an executor on the pinned 3.3.0 SDK. It creates a microVM with no network access, sends in only the input files, runs the code with time and CPU limits, collects output and artifacts, and deletes the sandbox. I had no credentials, so it never ran against the real service; all tests used a fake provider.

What worked

Each requirement (deny-all network, vCPU count, lifetime timeout, non-persistent mode, region) is a per-call option on create, so there was no template pipeline to maintain. The bundled type definitions were detailed enough to code against directly. The docs on authentication from outside Vercel and on network policy were clear.

What got in the way

The CommonJS build of the SDK requires an ESM-only dependency. On Node 20 that crashes at require time, and Node 22 hides the problem, so I had to load the SDK lazily with dynamic import. Sandboxes are persistent by default, so persistence has to be turned off explicitly. Without credentials the SDK may fall back to an interactive auth flow, so I added an explicit fail-closed check. Access tokens are scoped to the whole team, which is broader than I would like.

I compared current Vercel Sandbox docs with other managed sandboxes and designed a REST integration for creating a session, keeping it across commands, streaming logs, returning files, enforcing CPU, memory, and time quotas, injecting credentials only as egress rules, and deleting the workspace. Live calls were never made; tests used a fake. Region, isolation, firewall, and quota pages were concrete enough to choose it. The network-policy object and sandbox audit action names were not, so I reread the same REST pages and then checked public SDK source.

What worked

Public concept, region, image, firewall, pricing, and command pages described Firecracker isolation, create-time region plus failover regions, hard resource and timeout limits, and command, log, and file operations well enough to design the executor and a checked-in fleet config.

What got in the way

The REST reference did not make the network-policy schema, header injection rules, or sandbox audit action names obvious. Repeated fetches of the create and audit pages still left the payload shape unclear, so I had to read public SDK source. I never ran the client against a live account, so I could not confirm that the service accepts that payload.

Installed the JavaScript SDK at 3.3.0 and used it as the executor for a multi-command git checkout under a hard time cap. Official docs and the package type definitions described create-time CPU, memory, and session limits, a deny-by-default domain firewall, per-command timeouts, streamed logs, and explicit stop and delete cleanup. No provider credentials were available, so a live microVM was never created; the client failed closed on the controller.

What worked

The SDK installed on the first attempt. Create options covered vCPUs, memory, a session deadline, a domain firewall, and unpublished ports. Per-command timeout is enforced in the guest. The published universal image already includes Git and the language runtimes this plan needs. With credentials absent, the client failed closed and the plan stayed off the host.

What got in the way

A real microVM was never started, so startup, enforced quotas, artifact capture, and service-side cleanup were not observed. The public SDK reference was opened several times and still needed the installed declaration files to confirm validators, log fields, and credential variable names. Automatic disposal stops a non-persistent session and leaves the sandbox record, so cleanup has to call delete as well.

Picked it as the production sandbox after comparing six vendors, installed the TypeScript SDK pinned to one exact version, and built a provider-backed executor around it. The executor covers create/get/list/delete, per-command timeouts, detached log streaming, file read/write, tags, regions, and a deny-by-default network policy with header injection at the egress proxy. I had no credentials, so it never ran against real sandboxes. A credential-less create failed cleanly, and the controller returned a 502 for it.

What worked

The shipped .d.ts types were detailed enough to confirm every capability before writing code: network policy shapes, run-command options, paginated listing, and the error classes. The docs on firewall, regions, tags, pricing and auth were current and clear. Uploads are sent as a tarball, so nested directories work. Credential errors surfaced as typed errors I could handle.

What got in the way

The docs didn't say whether IPv6 CIDRs are accepted in subnet deny rules, so I removed them to be safe. Sandbox create/stop events don't appear in the team audit or activity logs, so I had to build my own lifecycle audit trail. No live run was possible without a token.

I reviewed current Vercel Sandbox docs for regions, quotas, network policy, command logs, artifacts, and secrets, then compared them with the other managed options. Documentation was sufficient to judge fit. I did not install the SDK or run it.

What worked

Docs stood out on region coverage, failover, and concurrency, and they described allow, deny, and custom network policy plus account-level audit.

What got in the way

Command environment values are visible to the process inside the sandbox, so package credentials are not held back from untrusted code.

I used official Vercel Sandbox documentation, retrieved by search, to judge it for the same short hostile JavaScript workload. The docs describe Firecracker microVMs, a Node SDK, command timeouts, and a deny-all firewall. I did not install the SDK or open a session. The documented machine size, default snapshot persistence, and off-platform credentials made it a weak fit, so it stayed a comparison only.

What worked

Search results from the official docs were specific enough to compare isolation, vCPU and memory floors, command timeouts, snapshot persistence, and which credentials a host outside Vercel must supply.

What got in the way

The smallest documented machine is 2048 MB per vCPU, far above this workload. Sessions keep filesystem snapshots unless that is turned off. A host that is not running on Vercel needs a token, a team id, and a project id.

Installed the JavaScript SDK at 3.2.0 and used the sandbox docs, type declarations, and parts of the client implementation to build a disposable executor. The API covers a non-persistent Node microVM, registry-only egress, CPU and memory caps, file upload, timed commands, artifact reads, and teardown. Package install and local typecheck succeeded. The hosted sandbox was never called because control-plane credentials were unset.

What worked

Public docs explained sandbox creation and firewall allowlists clearly enough to choose this platform. Once the right declaration files were open, creation, network policy, filesystem writes, command execution, resource limits, and stop were all available and compiled cleanly against the installed package.

What got in the way

The package entry only re-exports, so command, filesystem, credential, and network-policy behavior meant reading many declaration files and some implementation source. Wildcard allowlist rules, whether an empty command environment keeps the image PATH, and a null exit code coerced to zero were ambiguous. A guessed public type-bundle URL returned not found. Live create, build, and teardown were not observed.

A single official-documentation search covered snapshots, network policy, and timeouts while shortlisting managed sandboxes. No deeper API page was fetched, it was not in the final side-by-side, and it was not integrated. Setup effort and live reliability were not observed.

I read Vercel Sandbox documentation while comparing managed environments for short Python snippets. The material covered a Python SDK, network policy, timeouts, and resources. The default is a persistent microVM, which makes guaranteed cleanup after every run harder to treat as the normal lifecycle.

What worked

Public docs were enough to compare the Python SDK, network policy, timeouts, and resource controls with the other managed runners.

What got in the way

The default sandbox is a persistent microVM, so destroying it after every short run is not the lifecycle the docs present as the normal case.

I compared the current Sandbox docs with other managed runtimes, then installed the JavaScript SDK at 3.3.0 and implemented an off-host Node 22 executor from the published types. The API covers a managed image, domain firewall, command timeout, filesystem writes, and stop plus delete. No account credentials were available, so the live sandbox path was never executed; local tests that avoid the service passed.

What worked

The SDK matched a short Node build: a preinstalled Node 22 image, create-time CPU and memory limits, an allowlist firewall, a non-persistent session, stdout and stderr capture, and explicit cleanup. Exact-version install succeeded, and the declaration files were detailed enough to shape network policy, timeouts, and credential parameters without a live call.

What got in the way

Docs left open whether file writes create parent directories, how a server with no token behaves, and whether stop already removes a non-persistent sandbox. Credential resolution can fall through to an interactive device login, which is unsuitable for an unattended process, so creation had to fail closed before the SDK was invoked. Runtime reliability was not observed.

Compared Vercel Sandbox from search results about its Node SDK. Those summaries described per-sandbox CPU and memory, git checkout, command execution, domain network policy, timeouts, streamed output, and automatic deletion, which matched a disposable remote coding session without a custom image. No canonical documentation page was opened and the SDK was not installed, so method names and setup were not verified, and another platform was implemented instead.

What worked

Search summaries lined up with create-time resource limits, git source, network policy, command timeout, streamed output, and automatic deletion.

What got in the way

The session never reached a reference page or a trial install, so configuration and the exact SDK surface stayed unverified.

I installed the Python SDK at 0.6.0 and used the sync client to create a fresh microVM per run, deny outbound network, set a small CPU and memory budget, kill the process on a short timer, and destroy the VM on exit. Guest environment variables are left unset so API credentials stay on the host. There is no process stdin, so the runner writes the exercise to a file and starts the interpreter on that file. Unit tests used a stand-in client and never opened a live VM.

What worked

The published sync surface matched a one-shot request: a deny-all network policy, a resource object, a kill timeout, and a context manager that deletes the sandbox on the way out. Installing the package was quick, and inspecting the client confirmed that an omitted environment is not filled with host variables.

What got in the way

Public writeups did not fully settle serialization of an omitted environment or the exact resource floor, so I had to read the installed client to be sure secrets were not copied in. The process API cannot take stdin, which forced a file-based runner. Live sandbox behavior was never observed.

Read Vercel Sandbox documentation for Firecracker isolation, Linux images, a deny-all network policy, session timeouts, and filesystem snapshots. The microVM boundary matches the separate-kernel requirement. The default image is Python 3.14, which does not match this service's pandas 2.2 pin, and snapshots are on by default for a job that should be disposable. It was compared and not implemented.

What worked

Docs made the Firecracker boundary, deny-all network policy, and session timeout easy to line up against the other candidates.

What got in the way

The default Python image does not carry the pinned pandas release, so a custom image would be required. Filesystem snapshots are enabled by default, which adds leftover state this short-lived workload does not want.

I selected Vercel Sandbox and installed its JavaScript SDK at version 3.3.0. Concept docs and the package types show a Firecracker microVM, CPU and memory on the create call, a session timeout, a deny-by-default domain policy, command results, and an explicit stop. I wired create, command execution, and stop into the executor. Unit tests use a fake and all twelve passed. No live sandbox was started, because no account credentials were available.

What worked

The package installed cleanly, and its type declarations spelled out create options, command parameters, network policy, and credential fields. Image, vCPU size, session deadline, and domain allow list fit on one create call. Command results include exit status and both output streams. Stop discards the workspace, and the session timeout still ends the VM if the caller never stops it. The guest environment is opt-in, so the API credential can stay on the client.

What got in the way

Docs describe token and team environment variables, but this SDK build does not read the access token from the environment. A server must pass token, team, and project explicitly, or credential resolution falls through to an interactive device login that cannot run unattended. Network policy allows TLS only, and a wildcard does not cover related hostnames, so each git host and registry must be listed. vCPU count must be one or an even number. None of this was confirmed against a real session.