Solari vs Blaxel: How to Migrate Your Agent Sandboxes

Coding agents no longer finish in one call. They coordinate with other agents, stop to wait on a test run or a reviewer, then pick the work back up, and the sandbox under them has to hold that state while they wait.

Moving those agents from Blaxel to Solari takes one SDK swap and a handful of call changes. You rebuild your image as a Solari template, replace the create, process and file calls, and map standby to pause and resume. This guide covers why teams switch, the steps, what behaves differently and how to test before cutover.

Why Move From Blaxel to Solari?

The same agent that runs 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. Solari sandboxes restore from memory snapshots instead of booting, so an agent that takes a fresh machine per task spends its time on the task.

Solari also puts the pause in your hands. Blaxel says its sandboxes move to standby when no connection is active and allocate CPU from the memory you set; on Solari a sandbox pauses after the idle time you set, or the moment your code calls pause().

How Do You Migrate to Solari?

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. The same key later covers browsers and desktops.

• Rebuild your image as a template. A Solari template is built from a base OS with apt, pip, run and env steps, or straight from a public image on Docker Hub or GHCR. A custom image usually carries over as is.

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

• Replace process and file calls. process.exec becomes commands.run for a command that finishes, or commands.start for a long-running process with streamed output. fs.read and fs.write become files.readText and files.write.

• Map standby to pause. Set idleTimeoutMs with lifecycle: { onTimeout: "pause" }, or call pause() and resume() yourself. Pause saves memory and processes, and resume brings the sandbox back exactly as it was.

• Move volumes and previews. Create each volume once with sandboxes.volumes.create and attach it by volumeId at create. previewUrl(port) replaces previews and returns a signed public URL for your app's port.

The create and exec change in TypeScript:

// before
import { SandboxInstance } from "@blaxel/core"
const box = await SandboxInstance.create({ name: "agent", image: "blaxel/base-image:latest", memory: 4096 })
const out = await box.process.exec({ command: "python main.py", waitForCompletion: true })

// after
import { SandboxClient } from "@solarisdk/sandbox"
const sandboxes = new SandboxClient({ apiKey: process.env.SOLARI_API_KEY! })
const sbx = await sandboxes.create({ template: "base", cpu: 2, memMb: 4096 })
await sbx.connect()
const res = await sbx.commands.run("python", { args: ["main.py"] })

// before
import { SandboxInstance } from "@blaxel/core"
const box = await SandboxInstance.create({ name: "agent", image: "blaxel/base-image:latest", memory: 4096 })
const out = await box.process.exec({ command: "python main.py", waitForCompletion: true })

// after
import { SandboxClient } from "@solarisdk/sandbox"
const sandboxes = new SandboxClient({ apiKey: process.env.SOLARI_API_KEY! })
const sbx = await sandboxes.create({ template: "base", cpu: 2, memMb: 4096 })
await sbx.connect()
const res = await sbx.commands.run("python", { args: ["main.py"] })

// before
import { SandboxInstance } from "@blaxel/core"
const box = await SandboxInstance.create({ name: "agent", image: "blaxel/base-image:latest", memory: 4096 })
const out = await box.process.exec({ command: "python main.py", waitForCompletion: true })

// after
import { SandboxClient } from "@solarisdk/sandbox"
const sandboxes = new SandboxClient({ apiKey: process.env.SOLARI_API_KEY! })
const sbx = await sandboxes.create({ template: "base", cpu: 2, memMb: 4096 })
await sbx.connect()
const res = await sbx.commands.run("python", { args: ["main.py"] })

In Python the client is SyncSandboxClient from solari_sandbox, with the same calls in snake case.

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. A command written as one string runs as sh with -c and the string, so pipes and redirects keep working.

What Behaves Differently on Solari?

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

• Size is two settings. Solari sandboxes take cpu and memMb separately and reject an oversize request instead of quietly shrinking it. Your agent always gets the machine it asked for.

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

• Snapshots are named save points. A Solari snapshot captures disk and memory from a running sandbox, and revert() or fromSnapshot rewinds a machine or forks ready copies. Take your snapshot while the sandbox runs, then pause it; resume first whenever you want a new one.

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

• 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 depends on: pause and resume, take a snapshot, fork a machine from it, and delete the snapshot once its children 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 logic; Solari gives it a machine to work in.

• A clean machine for every task. Solari starts sandboxes fast enough to give each task a fresh machine. Your agent never inherits files or processes from the last run.

• Forks for parallel attempts. One prepared snapshot becomes as many independent machines as you need. Your agent can try several fixes at once and keep the one that passes.

• 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 and desktops on the same key. An agent that builds a web app can open a cloud browser or a Solari desktop to check the result. It runs on the same account and bill as the sandbox.

Blaxel says its sandboxes resume from standby with their full state intact, which suits agents that sit idle for long stretches between bursts. Blaxel is the more established sandbox vendor with a larger ecosystem; Solari is the younger company and moves faster on speed and price.

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. Teams will move providers per workload.

• Agents that wait without holding a machine. Long-running agents will pause between steps and pick up where they stopped. An hour-long review 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 and browser in one task. Coding agents will test what they build in a real browser or on a desktop, with both on the same account.

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

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 sandboxed coding agents. Get started with a free account and start running your agents today.