Self-host on Vercel sandboxes

Vercel runs each Session as a persistent named sandbox created through the official @vercel/sandbox SDK (dynamically imported, so it must be installed). The driver reapplies a deny-by-default firewall policy before readiness, supports provider-side credential transforms and forwarding, and owner-validates hard deletion.

Prerequisites

VERCEL_TOKEN=         # required
VERCEL_TEAM_ID=       # required
VERCEL_PROJECT_ID=    # required

Configuration

Vercel is wired through the Runtime Host composition, not SANDBOX_PROVIDER. Use createVercelProvider, createVercelManagedRuntime, or createVercelManagedRuntimeDriver from @open-managed-agents/managed-runtime-vercel:

const driver = createVercelManagedRuntimeDriver({
  leaseTtlMs: 90_000,
  credentials: {
    token: process.env.VERCEL_TOKEN!,
    teamId: process.env.VERCEL_TEAM_ID!,
    projectId: process.env.VERCEL_PROJECT_ID!,
  },
  networkPolicy: () => ({
    // deny-by-default rule set reapplied before readiness
  }),
});

createOptions receives the allocation context and returns any VercelCreateOptions (image, resources, timeouts, ports, environment). networkPolicy returns a VercelNetworkPolicy — the provider’s deny-by-default matcher set, including path-scoped header transform and forward-proxy rules. The factory also accepts client, runtimeEnvironment, outputStore, outputKeyPrefix, credentialEgress, sessionInputs, and readiness.

Capabilities


Harness lanes	`ama_worker` only
suspendResume	supported (persistent filesystem + snapshot restore)
Workspace	`retained_runtime`, durable
Outputs	`final_collect`, durable
Process checkpoints	none
Credential egress	`unsupported`/`snapshot` by default