Summary
vercel() sandbox backend ignores the runtime option and always runs vercel/eve:latest.
When a sandbox is defined with defineSandbox({ backend: vercel({ runtime: "python3.13" }) }), the requested runtime is silently dropped. The Vercel binding hardcodes the base image to vercel/eve:latest and does not forward runtime to the @vercel/sandbox SDK create() call, so the sandbox never runs the requested runtime — with no error or warning.
Version
eve 0.13.1
Where (from the published dist)
dist/src/execution/sandbox/bindings/vercel-create-sdk.js sets __image: VERCEL_EVE_SANDBOX_IMAGE (= "vercel/eve:latest") on the SDK create.
runtime does not appear in that create path (it is not forwarded from vercel({ runtime }) to the SDK).
Reproduce
defineSandbox({ backend: vercel({ runtime: "python3.13" }) }).
- In a tool:
const s = await ctx.getSandbox(); await s.run({ command: "cat /etc/os-release; python3 --version" }).
- Observed: the base is
vercel/eve:latest (currently Ubuntu) with its own bundled Python — NOT the python3.13 runtime that was requested.
Impact
- Silent option drop —
runtime is accepted by vercel() but ignored at create time; no error/warn. A footgun: callers believe they're on the runtime they asked for.
- Wrong base for native-toolchain workloads — anything that depends on the requested runtime's base (packages, package manager, Python version) gets
vercel/eve:latest instead. (Concretely: a bootstrap that assumed the python3.13 base's tooling broke because vercel/eve:latest lacks bzip2.)
- Reproducibility —
vercel/eve:latest is a mutable tag with no way to pin a digest, so the sandbox base can drift between deploys (we observed it as a different distro than expected). For workloads that must reproduce results exactly, an unpinnable base is a real problem.
Ask
Either honor the runtime option in the Vercel binding, or document explicitly that vercel() always uses vercel/eve:latest and expose a way to (a) select the runtime and (b) pin the base image by digest for reproducible builds.
Summary
vercel()sandbox backend ignores theruntimeoption and always runsvercel/eve:latest.When a sandbox is defined with
defineSandbox({ backend: vercel({ runtime: "python3.13" }) }), the requestedruntimeis silently dropped. The Vercel binding hardcodes the base image tovercel/eve:latestand does not forwardruntimeto the@vercel/sandboxSDKcreate()call, so the sandbox never runs the requested runtime — with no error or warning.Version
eve
0.13.1Where (from the published dist)
dist/src/execution/sandbox/bindings/vercel-create-sdk.jssets__image: VERCEL_EVE_SANDBOX_IMAGE(="vercel/eve:latest") on the SDK create.runtimedoes not appear in that create path (it is not forwarded fromvercel({ runtime })to the SDK).Reproduce
defineSandbox({ backend: vercel({ runtime: "python3.13" }) }).const s = await ctx.getSandbox(); await s.run({ command: "cat /etc/os-release; python3 --version" }).vercel/eve:latest(currently Ubuntu) with its own bundled Python — NOT thepython3.13runtime that was requested.Impact
runtimeis accepted byvercel()but ignored at create time; no error/warn. A footgun: callers believe they're on the runtime they asked for.vercel/eve:latestinstead. (Concretely: a bootstrap that assumed the python3.13 base's tooling broke becausevercel/eve:latestlacksbzip2.)vercel/eve:latestis a mutable tag with no way to pin a digest, so the sandbox base can drift between deploys (we observed it as a different distro than expected). For workloads that must reproduce results exactly, an unpinnable base is a real problem.Ask
Either honor the
runtimeoption in the Vercel binding, or document explicitly thatvercel()always usesvercel/eve:latestand expose a way to (a) select the runtime and (b) pin the base image by digest for reproducible builds.