The coding agent was handed a shell on the staging server to fix a failing migration. It fixed the migration, then decided the disk looked cluttered and deleted a cache folder the billing service still read from. The patch was fine; the incident review took the rest of the week.
A coding agent installs packages, rewrites files and runs whatever command it thinks will help, so it belongs on a machine where none of that reaches anything else. That machine is a sandbox: an isolated Linux computer created for the job, given the code, then paused or thrown away. Solari runs AI Sandboxes from the same account as its browsers and desktops, and this guide covers the two ways to wire a coding agent to one, plus the network rule that decides between them.
Decide Where the Agent Loop Runs
The first choice is not about the sandbox at all but about where the model loop lives. In the outside pattern, the loop runs on your own server and treats the sandbox as a tool: each step the model proposes becomes a commands.run call, and the output goes back into the next prompt. In the inside pattern, a coding agent CLI is installed in the sandbox and works there on its own, calling its model API and moving through the repository like a developer at a terminal.
The figure sets the two patterns side by side.
The outside pattern gives tighter control, since nothing inside the sandbox ever holds a credential for the model. The inside pattern is quicker to adopt, because an existing agent CLI runs unchanged. Either way, the setup starts with the machine itself.
Build the Machine Once With a Template
A coding agent wastes its first minutes installing tools unless the machine already has them, and a custom template fixes that. The Solari templates guide builds one from a recipe of apt packages, pip packages, shell commands, environment variables and a working directory, applied in that order. The sketch below builds a template with Node and a placeholder agent CLI, then starts a sandbox from it:
Custom templates need a paid plan; on the Free plan the build is refused before anything runs. A template can also start from a public OCI image on registries such as docker.io and ghcr.io. Keep secrets out of the recipe: an env step is saved with the template, and every command in every sandbox built from it sees the value.
Where that secret goes instead depends on the network, which is the next decision.
Choose the Isolation Tier
The isolation tier decides what the sandbox can reach, and it is the rule that trips people up. In the Solari sandboxes API, the default dedicated tier is a microVM of its own, the hardened tier is the same machine with all outbound network blocked, and a cheaper shared tier runs sandboxes as process trees inside a shared VM.
A hardened sandbox fits the outside pattern best, since the code it runs cannot send anything anywhere; the repository arrives through files.write or an upload instead of a clone. An inside agent cannot work there, because it has to reach its model API, so it runs on dedicated. The shared tier suits neither, since it refuses file operations and streamed commands, which a coding agent depends on.
With the tier chosen, the agent can be started.
Start the Agent So It Outlives the Client
An inside agent can work for a long time, and the call that starts it decides whether it survives a dropped laptop connection. commands.run gives each command a 10-minute deadline by default, which ends most real coding tasks early. A background execution, started with POST /sandboxes/:id/executions, runs on a channel the gateway owns, so the process, its output and its exit status survive the client disconnecting.
The model API key goes in that call's env, so it reaches the agent's process as an environment variable without being saved in the template. For an agent CLI that draws a full-screen interface, pty.create opens a real pseudoterminal that can be written to, resized and watched. A sandbox runs at most 16 executions at once, room for the agent plus its test and build processes.
Once the agent is working, the remaining job is handling what it produces.
Review and Ship the Agent's Work
The agent's output leaves the sandbox the way a developer's would, through Git or the files surface. git.push takes a personal access token that travels as environment variables of that single command, never in the URL, .git/config or the process arguments. When a reviewer wants to see the change running, previewUrl(port) returns a signed link to the agent's dev server that stays valid for an hour.
Both the preview link and the sandbox itself are credentials. On Solari, whoever holds a sandbox id can run commands as root in it until it is killed or expires, so ids stay out of logs, tickets and prompt history. Once the review closes, the sandbox is paused or killed, and the VM and sandbox lifecycle explains what a pause keeps.
Choosing the Right Setup
The setup comes down to where the model loop runs and what the sandbox may reach. Keep the loop outside and use a hardened sandbox when the agent is custom and the code is untrusted; run an existing agent CLI inside a dedicated sandbox built from a template when adoption speed matters more. In both, start long work as a background execution and scope every credential to a single call. The sandbox-per-task guide covers snapshots and forks, and the Solari introduction shows how the same account adds a browser for checking work in a real page.
Get Started With Solari
The first step is to run the agent CLI in a dedicated sandbox on the base template, then move the setup into a custom template once it works. Solari sandboxes are ready in 90 ms, and over a full sandbox lifecycle Solari is about 1.3x faster than E2B and almost 3x cheaper per sandbox hour. Create a free Solari account and the Free plan's credits cover the first sandbox.
