Solari vs Vercel Sandbox: How to Migrate Your Agent Sandboxes

In 2026, the sandbox has become part of every agent stack. Software teams now hand more of their coding to agents, and every task an agent runs needs a sandbox of its own, so the sandbox provider sits under everything a team hands off.

Solari is cheaper per sandbox hour than Vercel Sandbox at list price, and it keeps memory and processes across a pause. Moving is a call-by-call swap: install @solarisdk/sandbox, replace the Vercel OIDC token with a Solari API key, and map each call to its Solari sandbox equivalent. This guide covers why teams move, the five steps, what behaves differently and how to test before cutover.

Why Move From Vercel Sandbox to Solari?

Vercel Sandbox fits teams whose apps already deploy on Vercel: the sandbox signs in with the project's OpenID Connect token and bills on the same account. Teams look elsewhere when the agent outgrows that setup, usually for one of three reasons:

• The bill grows with the fleet. The same 4 vCPU, 8 GB machine costs less per hour on Solari than on Vercel Sandbox at list price. Vercel bills CPU only while it is busy, so an agent that mostly waits on model calls narrows the gap; run a week of your own usage through both before you decide.

• The agent needs to keep its place. A persistent Vercel sandbox snapshots its filesystem when it stops and restores it on the next resume, so running processes start again from nothing. Solari pause saves memory and processes, and resume brings the sandbox back exactly as it was.

• The agent needs a browser too. An agent that builds a web app has to open it, and an agent that researches has to read the live web. Solari runs browsers, sandboxes and desktops on one account and one API key, so the second job needs no second vendor.

How Do You Migrate From Vercel Sandbox to Solari?

The migration takes five steps, and none of them touches your agent's logic:

• Install the SDK. Add @solarisdk/sandbox in TypeScript or solari-sandbox in Python, next to @vercel/sandbox while you test. Keeping both lets you run the same task on each provider and compare the output.

• Swap the credentials. Put a Solari API key in the SOLARI_API_KEY environment variable in place of the token from vercel env pull. The SandboxClient takes the key and Solari's API base URL in its constructor.

• Size the machine explicitly. Vercel derives memory from the vCPU count, while Solari takes cpu and memMb as separate options. Set both to match the machine your agent uses today, because code that sizes a worker pool from available memory will notice any difference.

• Map the calls. Replace each Vercel call with its Solari counterpart from the table below. Most are a rename plus a change in how the result is read.

• Run the test pass. Run a hello-world task, then your existing suite, then the pause and resume paths your agent depends on. Fix each failure before the cutover deploy.

The create-and-run path, before and after:

// before
import { Sandbox } from "@vercel/sandbox"

const sandbox = await Sandbox.create({ resources: { vcpus: 2 } })
const result = await sandbox.runCommand("uname", ["-a"])
console.log(result.exitCode, await result.stdout())

// before
import { Sandbox } from "@vercel/sandbox"

const sandbox = await Sandbox.create({ resources: { vcpus: 2 } })
const result = await sandbox.runCommand("uname", ["-a"])
console.log(result.exitCode, await result.stdout())

// before
import { Sandbox } from "@vercel/sandbox"

const sandbox = await Sandbox.create({ resources: { vcpus: 2 } })
const result = await sandbox.runCommand("uname", ["-a"])
console.log(result.exitCode, await result.stdout())

// after
import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({
  apiKey: process.env.SOLARI_API_KEY!,
  baseUrl: process.env.SOLARI_BASE_URL!, // Solari's API base URL
})
const sbx = await sandboxes.create({ template: "base", cpu: 2, memMb: 4096 })
await sbx.connect()
const res = await sbx.commands.run("uname", { args: ["-a"] })
console.log(res.exitCode, res.stdout)

// after
import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({
  apiKey: process.env.SOLARI_API_KEY!,
  baseUrl: process.env.SOLARI_BASE_URL!, // Solari's API base URL
})
const sbx = await sandboxes.create({ template: "base", cpu: 2, memMb: 4096 })
await sbx.connect()
const res = await sbx.commands.run("uname", { args: ["-a"] })
console.log(res.exitCode, res.stdout)

// after
import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({
  apiKey: process.env.SOLARI_API_KEY!,
  baseUrl: process.env.SOLARI_BASE_URL!, // Solari's API base URL
})
const sbx = await sandboxes.create({ template: "base", cpu: 2, memMb: 4096 })
await sbx.connect()
const res = await sbx.commands.run("uname", { args: ["-a"] })
console.log(res.exitCode, res.stdout)

Which Vercel Sandbox Calls Map to Solari?

Every call most agent code makes on Vercel Sandbox has a direct counterpart on Solari:

Commands return a plain result on Solari. commands.run resolves to { exitCode, stdout, stderr }, so await result.stdout() becomes res.stdout. For a long-running process, commands.start returns a handle with streamed output, stdin and kill.

Ports work differently. Vercel asks you to declare ports at create; on Solari, previewUrl(port) returns a signed URL for any port the sandbox serves, valid for an hour, and a tunnel opens every port at once. Treat both like credentials and keep them out of logs.

Network rules map to isolation tiers. A sandbox with a deny-all network policy becomes a Solari sandbox with isolation: "hardened", a microVM of its own with all outbound network blocked. Keep the default "dedicated" tier when the agent needs to install packages or call APIs.

Custom images become templates. Rebuild an image your agent starts from as a Solari template, so every sandbox starts with its packages already installed.

What Happens to State, Snapshots and Timeouts?

Lifecycle is the biggest change in behaviour, and it works in your agent's favour. On Solari an idle sandbox pauses by default instead of shutting down, and resume brings back its memory and processes. The default idle timeout is two hours; idleTimeoutMs changes it per sandbox, and lifecycle: { onTimeout: "kill" } suits throwaway jobs.

A Solari snapshot is a disk and memory image taken while the sandbox runs, so a machine restored from it starts with its processes already running. Code that restarted services in an onResume callback can usually drop that step. Take the snapshot while the sandbox is running, then pause it.

A stopped Solari sandbox keeps its files, not its running state. A prepared sandbox forks into many, so an agent can try several fixes in parallel from the same starting point.

How to Test the Migration

Run a hello-world first: create a sandbox, write a script with files.write, run it with commands.run, print stdout and the exit code, then stop the sandbox. If that passes, the key, the base URL and the import are right.

Next, run your existing suite on Solari with the inputs you use today and compare the outputs file by file. Then exercise the paths your agent depends on most: pause and resume mid-task, snapshot and fork, and open the app your agent serves through a preview URL. With those green, the cutover is a deploy.

What Role Does Solari Play?

Solari is the infrastructure your agent runs on: AI sandboxes, cloud browsers and computer desktops from one API. Your agent brings the logic; Solari gives it a machine to work in.

• A fresh machine for every task. Solari creates a sandbox in one API call and lets it go when the task ends, so you can give every attempt a clean machine. Nothing one task leaves behind reaches the next.

• A fleet, not a handful. With Solari you can run up to 100,000 sandboxes at once, so you can give every repository, customer or test case its own machine. The fleet grows with your workload.

• Isolation you choose. Every Solari sandbox is a microVM of its own by default, separated by a hypervisor, and the hardened tier blocks all outbound network for the code you trust least. Your agent's code never shares a machine with another organization.

• Browsers and desktops on the same account. An agent that builds a web app can check it in a Solari cloud browser, and a computer-use agent can operate a Solari desktop with a full graphical screen. Both run on the same API key and the same bill as the sandbox.

Vercel is the more established platform with the larger developer ecosystem; Solari is the younger company and moves faster on speed and price. Solari runs all three surfaces under one account and one API, so the sandbox you move today is the first piece of a larger agent stack.

What Comes Next for Agent Sandboxes?

Today most teams treat their sandbox provider as a fixed choice. Over the next year that changes in four ways:

• Switching becomes routine. Sandbox APIs are converging on the same few calls, which weakens vendor lock-in. Teams will choose a provider per job on speed and price, the way they already pick a model per task.

• Agents that wait without losing their place. Long-running agents will pause between steps and resume with their memory intact. A review that takes an afternoon will no longer keep a machine running all afternoon.

• Branching as the default way to explore. Agents will split one prepared machine into several and run competing fixes side by side. Review moves from reading one attempt to choosing the best of several.

• Code, browser and desktop in one task. Agents will build in a sandbox, check the result in a real browser and finish the job in a desktop app. All three will sit behind one key.

What stays human is the judgment around the migration: what the agent may reach on the network, which workloads justify a dedicated machine, and the review of the code it ships.

Get Started With Solari

Start with one agent task, run it on Solari and on Vercel Sandbox side by side, and compare the output and the bill before you move the rest. Solari is the fastest and cheapest way to run cloud browsers and VMs for coding agents. Get started with a free account and start running your agents today.