How to Run a Fleet of VMs for AI Agents (2026 Guide)

Agents have outgrown the single computer. Coding agents now run every task in its own isolated VM, and research agents split one question across subagents that work in parallel. Agent work runs on fleets of machines that code starts, uses and releases.

Running a fleet of VMs for AI agents comes down to three habits: build the machine once and copy it from a snapshot, pause every copy the moment it goes quiet, and size your limit on running VMs to the fleet's peak. Solari runs Computer Desktops and AI Sandboxes as VMs your agent starts by API. This guide covers why fleets stall, the steps to run one, what Solari does for it, and where agent fleets go next.

Why Do VM Fleets Stall Before They Get Slow?

A VM fleet stalls on capacity, not on start time. A Solari virtual machine is ready usually in about a second, so a fleet rarely waits on the create call. It waits on your limit on running VMs, and every idle machine that holds a slot leaves a task in the queue.

Agent work used to mean one long session on one machine. Most backlogs an agent clears today are embarrassingly parallel: a list of vendor portals, a set of repositories, a batch of reports, each task independent of the others. One machine per task is the natural shape, and the number of machines running at once sets how fast the backlog clears.

Two states count against that limit: a VM that is running and a VM that is parked with its CPUs frozen. A paused VM does not count, and resuming it counts again. That one rule decides how far a fleet stretches, which is why most of the steps below are about pausing.

How Do You Run a Fleet of VMs for AI Agents?

You run a fleet by preparing one machine, copying it per task and handing slots back the moment a copy goes quiet. These are the steps, in the order a growing fleet meets them:

• Build the machine once. Prepare one VM with the apps your agent needs installed, open and signed in, then save it with a snapshot. A Solari snapshot holds the machine's full disk and memory image, and the source keeps running while it is taken. Setup then costs you once instead of once per task.

• Copy it per task. Start each worker with the fromSnapshot option on create. Every copy is fully independent, so a mistake in one task's run never touches another. Copies inherit the snapshot's memory layout, so a source VM created with extra memory needs the same memMb on every copy.

• Pause copies the moment they go quiet. Set an idle timeout with pause as the action. Every action and open connection resets the clock; when it runs out, the VM saves its state and gives its slot to the next task. Without timeoutMs set, a VM pauses after 30 minutes idle, which is generous for a fleet clearing a backlog, so set a shorter one.

• Park for model calls, then hand the slot back. With parkAfterMs set, a VM's CPUs freeze during short waits such as an LLM response, while its slot and live view stay held. Pair it with hibernateAfterParkedMs so a long park escalates to a full pause and frees the slot. The guide to long jobs on VMs covers both settings in depth.

• Never power off from inside. Running poweroff or shutdown inside a VM deletes it along with its disk, and it cannot be resumed. A worker that wants its machine back pauses it instead.

• Re-attach from any worker. Every VM has a stable id, and connect(id) re-attaches to it from any process and resumes it if it was paused. A coordinator can hand a half-finished task to a fresh worker without rebuilding the machine.

The fan-out is one snapshot call on the prepared machine, then a create per task, run together with Promise.all:

const snapId = await prepared.snapshot("portal-ready")
const fleet = await Promise.all(
  vendors.map(() => desktops.create({ template: "default", fromSnapshot: snapId })),
)

const snapId = await prepared.snapshot("portal-ready")
const fleet = await Promise.all(
  vendors.map(() => desktops.create({ template: "default", fromSnapshot: snapId })),
)

const snapId = await prepared.snapshot("portal-ready")
const fleet = await Promise.all(
  vendors.map(() => desktops.create({ template: "default", fromSnapshot: snapId })),
)

A snapshot is tied to the template build it was taken on. If a restore is refused after a template update, prepare and snapshot a fresh machine; retrying the same snapshot will not help.

What Does Solari Do for a VM Fleet?

Solari is the infrastructure a VM fleet runs on: desktops for agents that need a screen and sandboxes for agents that only run code, from one account and one API. Your agent brings the logic; Solari starts, copies and pauses the machines.

• A fleet as wide as your backlog. With Solari you can run up to 100,000 sandboxes or desktops at once. A backlog of thousands of tasks clears in one pass instead of a queue that runs overnight.

• Fast resumes. A same-host resume took about 1.3 seconds on staging, five trials, once the pause had finished saving. Pausing aggressively costs your agent little waiting, so you can hand slots back after every task without slowing the fleet.

• A screen for computer use. Every Solari desktop comes with a live view over VNC, plus mouse, keyboard and screenshot control for computer use models. Treat each streamUrl, controlUrl and VM id as a credential: anyone holding one can watch, drive and run commands as root, so keep them out of logs, tickets and chat.

• Copies that cost little to keep. Solari bills snapshot storage at $0.05 per GB-month after the first 10 GB across your organization. Deleting a superseded snapshot stops its charge the same day, so a fleet that rebuilds its base machine weekly keeps only the copy it uses.

• Spend that stops at zero. Solari bills sandboxes and VMs by size, per vCPU-hour and GB-hour, from one credit balance, and a desktop hour comes to $0.060 on the $200 monthly plan. At a zero balance new desktops stop launching and there is no end-of-month overage charge. A runaway loop stops at the balance instead of becoming an invoice.

Sandboxes share the desktops' lifecycle, so every step above works the same for a fleet that only runs code. Solari sandboxes are about 1.3x faster than E2B over a full lifecycle and almost 3x cheaper per sandbox hour. Solari also runs cloud browsers on the same account and bill as your desktops and sandboxes, so a fleet that also reads the web needs no second vendor.

Where Are VM Fleets for AI Agents Going Next?

Most agent fleets today are a loop around a create call. Over the next year that changes in four ways:

• Fleets that size themselves. An orchestrator agent will decide how many machines a job needs, start them and release them, the way a lead agent spawns subagents for research today.

• Fork instead of rebuild. Agents will snapshot a machine mid-task and fork it to try several approaches at once, keeping the copy that worked.

• Paused by default. A machine waiting on a model will pause on its own and wake on the next request, and paying for idle VMs will stop being normal.

• Desktops, sandboxes and browsers in one job. Computer-use agents will drive desktops while sandboxes run the code and browsers read the web, inside the same fleet.

What stays human is the judgement around the fleet: which backlog it works on, which results ship, and when a run that looks finished needs a second look. The teams that win will set the fleet's policy once and spend their attention on the results.

Get Started With Solari

Start with one backlog: prepare a desktop for the first task, snapshot it, and launch a small batch of copies with pause as their idle action. Solari is the fastest and cheapest way to run cloud browsers and VMs for agent fleets. Get started with a free account and start running your agents today.