Solari vs Archil: How to Migrate Your Agent Sandboxes

In 2026, AI agents take on tasks that run for hours or days, and each new session starts with no memory of the last one. The work survives in files, so every agent needs storage that outlives the machine it runs on, right next to the place it runs its code.

Solari runs that sandbox work at lower per-hour CPU and memory rates than Archil publishes, and the move takes five steps: export each Archil disk, copy it into a Solari volume, rebuild your sandbox image as a Solari template, point your tool calls at a Solari sandbox, then test and cut over. Your files and your image move as they are; only the client code changes. This guide covers why teams move now, each step, what maps where and what behaves differently.

Why Move From Archil to Solari Now?

Archil built its platform around storage: a durable shared filesystem with sandboxes and serverless tool calls beside it. That fits a team whose agents mostly read and write files.

Agents in 2026 do more than that. In one task they run code, open live web pages and operate apps that have no API. On Solari all three jobs run from one account: the agent that writes a report in a sandbox can check a live site in a cloud browser or drive a Solari desktop, on the same API key and the same bill.

Leaving Archil is also straightforward, which removes the usual cost of vendor lock-in. Archil's data ownership guide says its sandboxes boot from standard OCI images and its disks export over an S3 API, so a move to Solari is mostly a matter of changing where your code runs.

How Do You Migrate From Archil to Solari?

The migration is five steps, and you can test each one on its own:

• Export each disk. A disk synced to your own bucket already holds every file as an ordinary Amazon S3 object, so there is nothing to export. A managed disk copies out with aws s3 sync against the disk's S3 endpoint. Symbolic links, FIFOs, sockets and device nodes do not come through that API, so for a disk that relies on them, mount it and copy with rsync instead.

• Create a volume per disk. A Solari volume is durable storage that outlives any single machine, mounted at a path you choose. Create one for each old disk, whether it belonged to a tenant, an agent or a job.

• Rebuild the image as a template. The old sandboxes boot from OCI images, and a Solari template can start from the same image with fromImage. Add your packages as run steps, and every sandbox starts with your tools already installed.

• Point the tool calls at a sandbox. A disk.exec call becomes commands.run on a Solari sandbox with the volume attached. For a bash tool that keeps its working directory and variables between calls, use a named shell.

• Test, then cut over. Run one agent task end to end on Solari and compare its output files with the same task on the old stack. Once they match, stop writing to the old disk and switch traffic.

The core of the new client code looks like this in TypeScript:

import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({
  apiKey: process.env.SOLARI_API_KEY!,
  baseUrl: process.env.SOLARI_BASE_URL!, // the Solari API host from the docs
})

// one volume per old disk
const vol = await sandboxes.volumes.create({ name: "agent-workspace" })

const sbx = await sandboxes.create({
  template: "tpl_...",   // built from your existing image
  volumes: [{ volumeId: vol.volumeId, path: "/data" }],
})
await sbx.connect()

const res = await sbx.commands.run("sh", {
  args: ["-c", "python summarize.py /data/matches.txt"],
})
console.log(res.exitCode, res.stdout)

import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({
  apiKey: process.env.SOLARI_API_KEY!,
  baseUrl: process.env.SOLARI_BASE_URL!, // the Solari API host from the docs
})

// one volume per old disk
const vol = await sandboxes.volumes.create({ name: "agent-workspace" })

const sbx = await sandboxes.create({
  template: "tpl_...",   // built from your existing image
  volumes: [{ volumeId: vol.volumeId, path: "/data" }],
})
await sbx.connect()

const res = await sbx.commands.run("sh", {
  args: ["-c", "python summarize.py /data/matches.txt"],
})
console.log(res.exitCode, res.stdout)

import { SandboxClient } from "@solarisdk/sandbox"

const sandboxes = new SandboxClient({
  apiKey: process.env.SOLARI_API_KEY!,
  baseUrl: process.env.SOLARI_BASE_URL!, // the Solari API host from the docs
})

// one volume per old disk
const vol = await sandboxes.volumes.create({ name: "agent-workspace" })

const sbx = await sandboxes.create({
  template: "tpl_...",   // built from your existing image
  volumes: [{ volumeId: vol.volumeId, path: "/data" }],
})
await sbx.connect()

const res = await sbx.commands.run("sh", {
  args: ["-c", "python summarize.py /data/matches.txt"],
})
console.log(res.exitCode, res.stdout)

The simplest way to fill a volume is to run the copy from inside the sandbox that mounts it. Add the AWS CLI to your template, then sync the old disk straight into the mount path:

# managed disk: copy out over its S3 API (endpoint from the old console)
aws s3 sync s3://<disk>/ /data --endpoint-url <disk-s3-endpoint>

# managed disk: copy out over its S3 API (endpoint from the old console)
aws s3 sync s3://<disk>/ /data --endpoint-url <disk-s3-endpoint>

# managed disk: copy out over its S3 API (endpoint from the old console)
aws s3 sync s3://<disk>/ /data --endpoint-url <disk-s3-endpoint>

What Maps Where?

Most concepts have a direct Solari counterpart, so the move is a rename more than a rewrite.

A persistent sandbox becomes a Solari sandbox that pauses when idle and resumes exactly as it was, memory and processes included. A disk checkpoint becomes a Solari snapshot, which saves disk and memory from a running machine and starts as many new copies as you need.

On Solari, a command that reaches its deadline returns with timedOut set instead of raising an error. Check that flag before you trust the exit code.

What Behaves Differently on Solari?

Three differences are worth checking before cutover:

• One machine per volume. Each Solari volume attaches to one machine at a time, and mounting one that is already attached elsewhere returns a 409. Give each agent or tenant its own volume, the same disk-per-agent layout many teams already run, and hand results between agents by copying files.

• Dedicated isolation for volumes. Solari's hardened isolation blocks all outbound network, and a volume is network storage. Mount volumes on dedicated isolation, the default, and keep hardened for the code you trust least.

• Public images for templates. Solari builds templates from public images on Docker Hub, GitHub Container Registry, Amazon ECR Public, Google Container Registry and Quay. Push your base image to one of them, or rebuild your private layers as run steps in the template.

What Does It Cost to Run on Solari?

Solari bills a sandbox for the CPU and memory it runs on, with self-serve rates down to $0.0245 per vCPU-hour and $0.0077 per GB-hour. Price one of your sandboxes at those rates and at the CPU and memory rates Archil publishes before you move.

Two costs belong to the move itself. Data transfer out of the old platform is billed at its standard rate, so the export of a large managed disk shows up on the last invoice, while a disk already synced to your own bucket skips the export. On Solari, a volume keeps its data and uses storage until you delete it, so remove the volumes a finished job is done with.

What Role Does Solari Play?

Solari is the infrastructure your agents run on: cloud browsers, sandboxes and desktops from one API. Your agent brings the logic; Solari gives it a machine to work in and storage that outlives the machine.

• A whole fleet at once. With Solari you can run up to 100,000 sandboxes at once, so a job that fans out across every tenant runs in one pass. Each sandbox mounts its own volume, so every agent writes to its own workspace.

• State that survives a pause. Pause saves memory and processes, and resume brings the sandbox back exactly as it was. Your agent can wait on a review or a slow tool and pick up where it stopped, and a stopped sandbox still keeps its files.

• Snapshots and forks. Prepare one machine, snapshot it, and start ready-to-go copies from that save point. Your agent can try several fixes at once and keep the one that passes.

• A browser next to the code. The agent that processes files in a sandbox can read the live web in a cloud browser that keeps its logins between runs. It can check its own output on the live page before it reports back.

Archil is the storage specialist, with a deeper filesystem that mounts across many compute providers; Solari is the compute specialist and moves faster on speed and price. Solari runs browsers, sandboxes and desktops under one API, so the sandbox you migrate today is the first piece of a larger agent stack.

What Comes Next for Agent Storage?

Today most teams pick a storage layer and a compute layer separately. Over the next year that changes in four ways:

• A workspace per session. Every agent session will get its own durable workspace the moment it starts. Keeping one will be one more API call, and cleaning it up will be another.

• State that travels. Snapshots that carry memory as well as disk will let an agent pick up a half-finished task on a fresh machine. Long tasks will stop depending on one machine staying alive.

• Files and the web in one task. Agents will save what they read on the web next to the code that processes it, inside a single task.

• Moves measured in hours. Open image formats and S3-compatible exports make switching providers an afternoon's work. Teams will choose compute per job, on speed and price.

What stays human is deciding what an agent may keep: which data it stores, how long it is retained and who can read it.

Get Started With Solari

Start with one agent: copy its disk into a volume, build the template from its image and run one task end to end before you move the rest. Solari is the fastest and cheapest way to run cloud browsers and VMs for long-running agents. Get started with a free account and start running your agents today.