Solari vs Sail: How to Migrate Your Agent Sandboxes

Coding agents now stay on the job for hours. The length of task an AI agent can finish on its own has been doubling at a steady pace, so the machine under a coding agent holds a repo, its packages and its shell state across a full day of work.

Moving those agents from Sailboxes to Solari takes one SDK swap and a short list of call changes. You rebuild your image as a Solari template, replace the create, exec and file calls, and map checkpoints to snapshots and sleep to pause. This guide covers why teams switch, the steps, what behaves differently and how to test before cutover.

Why Move From Sail to Solari?

Teams move for two reasons: start speed, and every surface an agent needs on one account.

A long-running agent starts and wakes machines all day. A Solari machine starts usually in about a second, and Sail says a Sailbox starts or resumes in under 3 seconds. Across hundreds of tasks a day, that difference decides whether your agent waits on its machine or on its model.

The same agent that writes code now opens a website to check the result, and sometimes drives a desktop app. Each extra vendor adds a key, a bill and an SDK, which is how vendor lock-in spreads across a stack. Solari runs sandboxes, cloud browsers and desktops from one API, so your agent gets all three on one account and one bill.

How Do You Migrate From Sail to Solari?

Install the Solari SDK, rebuild your image as a template, and swap the create, exec, file and checkpoint calls. Most agents need only the first four steps:

• Install the SDK and set the key. Add @solarisdk/sandbox in TypeScript or solari-sandbox in Python, and set SOLARI_API_KEY where SAIL_API_KEY lived. The same key later covers browsers and desktops.

• Rebuild your image as a template. A Solari template starts from a base OS with apt, pip, run and env steps, or straight from a public image on Docker Hub or GHCR. If your Sailbox image is public, point the template's fromImage at it and add your setup steps.

• Replace the create call. sail.Sailbox.create(app=..., name=...) becomes sandboxes.create with a template, a cpu count and memMb. Call connect() on the result before you run anything.

• Replace exec and file calls. sb.exec(...).wait() becomes commands.run, which returns the exit code, stdout and stderr in one result. sb.fs.read and sb.fs.write become files.readText and files.write.

• Map checkpoints and sleep. checkpoint() becomes snapshot(), and a new machine from a checkpoint becomes create with fromSnapshot. For sleep, set idleTimeoutMs with lifecycle: { onTimeout: "pause" }, or call pause() before a long model call and resume() after it.

• Move exposed ports. A Sailbox ingress port becomes previewUrl(port), which returns a signed public URL for the port your app serves. The URL carries a token that expires, so call it again for a fresh one.

The create and exec change, before and after:

# before: Sail's Python SDK
import sail

app = sail.App.find(name="agents", mint_if_missing=True)
sb = sail.Sailbox.create(app=app, name="agent-1")
result = sb.exec("python main.py").wait()
print(result.stdout)

# before: Sail's Python SDK
import sail

app = sail.App.find(name="agents", mint_if_missing=True)
sb = sail.Sailbox.create(app=app, name="agent-1")
result = sb.exec("python main.py").wait()
print(result.stdout)

# before: Sail's Python SDK
import sail

app = sail.App.find(name="agents", mint_if_missing=True)
sb = sail.Sailbox.create(app=app, name="agent-1")
result = sb.exec("python main.py").wait()
print(result.stdout)

// after: Solari's TypeScript SDK
import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({ apiKey: process.env.SOLARI_API_KEY! })
const sbx = await sandboxes.create({ template: "base", cpu: 4, memMb: 8192 })
await sbx.connect()
const res = await sbx.commands.run("python", { args: ["main.py"] })
console.log(res.stdout)

// after: Solari's TypeScript SDK
import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({ apiKey: process.env.SOLARI_API_KEY! })
const sbx = await sandboxes.create({ template: "base", cpu: 4, memMb: 8192 })
await sbx.connect()
const res = await sbx.commands.run("python", { args: ["main.py"] })
console.log(res.stdout)

// after: Solari's TypeScript SDK
import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({ apiKey: process.env.SOLARI_API_KEY! })
const sbx = await sandboxes.create({ template: "base", cpu: 4, memMb: 8192 })
await sbx.connect()
const res = await sbx.commands.run("python", { args: ["main.py"] })
console.log(res.stdout)

What Changes in Your Code?

Most calls map one to one; the differences sit in the arguments.

commands.run takes a program and its arguments, not a shell line. Sail runs a string command through /bin/sh -lc, so wrap any command with pipes or redirects as sh with -c and the string, and it keeps working.

What Behaves Differently on Solari?

These change how a call works, not whether it works:

• Size is set up front. A Solari sandbox takes cpu from 1 to 8 and memMb up to 16 GB, and rejects an oversize request instead of quietly shrinking it. Sail bills by what a Sailbox consumes, so many Sail scripts never set a size; pick one per agent type when you migrate.

• Timeouts return instead of throwing. A command that hits its deadline comes back with timedOut: true. Check it before you trust the exit code.

• Pause is yours to call. Sail says Sailboxes sleep on their own while an agent waits on a Sail inference call. On Solari a sandbox pauses after the idle time you set or when your code calls pause(), with any model you use, and pause saves memory and processes, so resume brings the sandbox back exactly as it was.

• Snapshots are named save points. A Solari snapshot captures disk and memory from a running sandbox while it keeps working. revert() rewinds the same machine, and fromSnapshot starts as many independent copies as you need; a paused machine must resume before you snapshot it.

• Stored snapshots are cheap. They cost $0.05 per GB-month, with the first 10 GB free. You can keep a prepared snapshot for every agent type you run.

• Ids and URLs are credentials. Whoever holds a sandbox id, its control URL or a signed preview URL can run commands as root in that machine. Keep them out of logs, tickets and client-side code.

How to Test the Migration

Create a sandbox from your new template, write main.py with files.write, run it with commands.run, print stdout and the exit code, then kill the sandbox. If that passes, the key, the template and the client are right.

Then run your agent's suite and exercise the state paths it relied on in Sail: pause and resume in the middle of a task, take a snapshot after setup, start a copy from it, and delete the snapshot once its copies are gone. With those green, the cutover is a deploy.

What Role Does Solari Play?

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

• Fleets on demand. Solari lets you "run one agent or a fleet of thousands in parallel." An eval sweep or a batch of coding tasks starts at once instead of queueing.

• Isolation you choose. Every Solari sandbox is a microVM of your own by default, and the hardened tier blocks all outbound network for the code you trust least. You never share a machine with another organization.

• Browsers that stay signed in. An agent that researches on the web opens a Solari cloud browser on the same key. With a Solari profile it signs in once, and every later session reopens the same cookies.

• Desktops for screen work. Models with computer use operate apps through a screen, clicking and typing like a person. Solari desktops give them a full Linux computer on the same account and bill as the sandbox.

What Comes Next for Agent Sandboxes?

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

• Switching gets cheaper. Sandbox APIs are converging on the same calls: create, run, files, pause and snapshot. Teams will pick a provider per workload, not once per year.

• Idle time priced near zero. Long-running agents will pause between steps and pick up where they stopped. An hour spent waiting on a model will stop costing an hour of compute.

• Forks as the default way to explore. Agents will fork one snapshot into several machines and try several approaches at once. The one that passes the tests ships.

• Code, web and screen in one task. Coding agents will test what they build in a real browser or on a desktop. Both will sit on the same account as the sandbox.

What stays human is the judgment around the move: which agents migrate first, what each one may reach, and the review of the code it ships.

Get Started With Solari

Choose Solari when your agents need fast starts, pause and resume under your own control, and browsers or desktops next to the sandbox. Stay with Sail when your model already runs on Sail's inference and automatic sleep during those calls is the saving you want. Sail is the specialist that pairs sandboxes with its own model inference; Solari is the broader platform and moves faster on speed and price.

Start with one agent: rebuild its image as a template, swap the create and exec calls, and run its suite on Solari before you move the rest. Solari is the fastest and cheapest way to run cloud browsers and VMs for long-running coding agents. Get started with a free account and start running your agents today.