Solari vs Boat: How to Migrate Your Agent Sandboxes

In 2026, teams pick the computer their agents run on with the same care as the model. Coding agents now finish tasks that take people hours, and each one needs a virtual machine of its own that keeps its repo, its packages and its open processes from one step to the next.

If your agents run on Boat today, switching to Solari is mostly a translation job: swap the SDK, rebuild your environment as a template, and rename a handful of calls. Below are the reasons teams switch, each step with before-and-after code, the differences to plan for and a test plan for cutover.

Why Move From Boat to Solari?

Teams move for three reasons: state that survives a wait, browsers that start as sessions of their own, and every surface an agent needs on one account.

Boat stops a sandbox one hour after create or resume by default and cuts off the jobs that run, and Boat says a stop "does not keep memory or running programs". Solari keeps a waiting agent's work in place instead, so an agent that waits on a person or a slow model call picks up mid-task rather than rebuilding its state.

A Boat agent opens Chromium inside its VM. Solari browsers are ready in 8 ms as sessions of their own, so a research step can open a fresh browser for every task without starting a machine first.

Solari also runs sandboxes, cloud browsers and desktops from one API. The agent that writes code can browse the web and operate a screen on one key and one bill.

How Do You Migrate From Boat to Solari?

Install the Solari SDK, rebuild your environment as a template, then swap the create, command, file and snapshot 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 BOAT_API_KEY lived. The same key later covers browsers and desktops.

• Rebuild your environment as a template. A Solari template starts from a base OS and adds apt, pip, run, env and workdir steps, or starts from a public image on Docker Hub or GHCR. Move the repo clones and setup scripts from your Boat environment into run steps, and every sandbox starts with your tools already installed.

• Replace the create call. Boat creates a sandbox with boat.create and waits on it with wait_until_ready. On Solari, sandboxes.create takes a template, a cpu count and memMb, and connect() opens the machine; set idleTimeoutMs where you used ttl_seconds.

• Replace command and file calls. boat.command(...) becomes commands.run, which returns the exit code, stdout and stderr in one result. read_text and write_text become files.readText and files.write; Boat paths are relative to the home folder, so make them absolute.

• Map saved snapshots and forks. A Boat saved snapshot is a disk snapshot under a name. save_saved_snapshot becomes snapshot(), and create(var_from=...) or fork() becomes create with fromSnapshot, so each copy is an independent machine you can snapshot and fork again.

• Move exposed ports and agents. host_port(port) becomes previewUrl(port), a signed public URL whose token expires, so call it again for a fresh one. If you drove Claude Code or Codex with boat prompt, install the agent's CLI in a template run step and start it with commands.start, which streams its output.

The create and command change, before and after:

# before: Boat's Python SDK
boat = BoatApi(client)
sandbox_id = boat.create(create_sandbox_request=CreateSandboxRequest(ttl_seconds=1800)).sandbox.id
wait_until_ready(boat, sandbox_id)
out = boat.command(sandbox_id, CommandRequest(command="python main.py")).actual_instance
print(out.exit_code, out.stdout)

# before: Boat's Python SDK
boat = BoatApi(client)
sandbox_id = boat.create(create_sandbox_request=CreateSandboxRequest(ttl_seconds=1800)).sandbox.id
wait_until_ready(boat, sandbox_id)
out = boat.command(sandbox_id, CommandRequest(command="python main.py")).actual_instance
print(out.exit_code, out.stdout)

# before: Boat's Python SDK
boat = BoatApi(client)
sandbox_id = boat.create(create_sandbox_request=CreateSandboxRequest(ttl_seconds=1800)).sandbox.id
wait_until_ready(boat, sandbox_id)
out = boat.command(sandbox_id, CommandRequest(command="python main.py")).actual_instance
print(out.exit_code, out.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("sh", { args: ["-c", "python main.py"] })
console.log(res.exitCode, 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("sh", { args: ["-c", "python main.py"] })
console.log(res.exitCode, 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("sh", { args: ["-c", "python main.py"] })
console.log(res.exitCode, 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 command string. Boat runs the string you pass, so wrap any command with pipes or redirects as sh with -c and the string, as in the example above, and it keeps working.

A Solari command that hits its deadline returns with timedOut: true instead of throwing. Check it before you trust the exit code, and pass timeoutMs for long builds.

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 reducing it. Map each Boat size to a cpu and memMb pair once, per agent type.

Idle time ends a session, not the clock. A Solari sandbox pauses after the idleTimeoutMs you set passes with no activity, or when your code calls pause(). A busy machine does not time out in the middle of a task.

Running services stay running. On Boat, programs end at a stop and enabled systemd services start again on resume. On Solari, pause saves memory and processes, and resume brings the sandbox back exactly as it was, so a dev server or file watcher started once is still there.

Snapshots hold memory too. A Solari snapshot captures disk and memory from a running sandbox while it keeps working, and revert() rewinds the same machine to it. A paused machine must resume before you snapshot it. Stored snapshots cost $0.05 per GB-month, with the first 10 GB free.

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, the same care Boat asks for its desktop and file URLs.

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 Boat: pause in the middle of a task and resume, take a snapshot after setup, start two copies 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 supports up to 100,000 concurrent browsers on a custom contract, so an eval sweep or a batch of research tasks starts at once instead of queueing. The same contract covers sandboxes and desktops at fleet scale.

• Machines in about a second. A Solari machine starts usually in about a second. A fan-out from one prepared snapshot starts working almost as soon as you ask for it.

• Browsers that stay signed in. An agent that checks its work on the web opens a Solari cloud browser on the same key, over Playwright or any client that speaks CDP. 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 with a live view you can watch and take over, on the same account and bill as the sandbox.

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

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

Boat is the focused VM product built around coding agents; Solari is the broader platform and moves faster on start time and fleet scale.

Start with one agent: rebuild its environment as a template, swap the create and command 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.