Solari vs Daytona: How to Migrate Your Sandbox Code

Somewhere in your codebase there is a file that creates a sandbox, runs a command inside it and deletes it afterwards. It works, the tests around it pass, and nobody on the team wants to rewrite it. Then a cost review or a new requirement says those sandboxes should run somewhere else.

Moving that code from Daytona to Solari leaves the file almost exactly as it is. Solari ships a Daytona-compatible SDK for TypeScript and Python: change one import, swap the API key, and the same calls create sandboxes, run commands, move files, use git, and snapshot and fork on Solari. This guide walks through the install, what carries over, what behaves differently and how to test the move.

Install the Package and Change the Import

The first step is adding the package next to your existing code. The Solari migration guide names it @solarisdk/daytona-compat for TypeScript and solari-daytona-compat for Python, imported as solari_daytona. Solari builds it from the vendor's public documentation, without the vendor's endorsement, against the SDK as documented in October 2026.

With the package installed, the code change is the import line and the key:

// before: import { Daytona } from "@daytona/sdk"
import { Daytona } from "@solarisdk/daytona-compat"

const daytona = new Daytona({ apiKey: process.env.SOLARI_API_KEY })
const sandbox = await daytona.create({ labels: { project: "demo" } })

// before: import { Daytona } from "@daytona/sdk"
import { Daytona } from "@solarisdk/daytona-compat"

const daytona = new Daytona({ apiKey: process.env.SOLARI_API_KEY })
const sandbox = await daytona.create({ labels: { project: "demo" } })

// before: import { Daytona } from "@daytona/sdk"
import { Daytona } from "@solarisdk/daytona-compat"

const daytona = new Daytona({ apiKey: process.env.SOLARI_API_KEY })
const sandbox = await daytona.create({ labels: { project: "demo" } })

Python follows the same pattern with DaytonaConfig. The package reads the key from the apiKey option first, then from the SOLARI_API_KEY environment variable, and the old vendor key is never sent to Solari. That is the whole code change for most projects; the next question is what the rest of the code can keep doing.

What Carries Over Unchanged

Most of the SDK surface works as before, which is why the import swap is enough for typical agent code. Sandboxes create with labels, names, environment variables, resources and auto-stop, and can be fetched, listed, started, stopped, deleted and forked. Commands run with a working directory, environment and timeout, and sessions carry cd and export from one command to the next, with background commands and streaming logs.

Files upload, download, search, move and change permissions, and git clones, commits, branches, pushes and pulls without ever putting credentials on a command line or in a URL. Snapshots, named images built from an Image or a Dockerfile, and preview links for a port all work. Commands still run as the daytona account in /home/daytona, so paths in existing scripts hold. The behaviours that do change are fewer, but they matter more.

What Behaves Differently

A handful of calls keep their names but act differently on Solari, and the table below sums up the lines that change.

Stop is a pause on Solari: a stopped sandbox keeps its memory, running processes and disk, and start resumes it where it was. Code that expects a stop to clear running processes needs a review. Fork and snapshots take about 25 to 40 seconds, keep memory as well as disk, and are billed as snapshot storage.

Lifetimes on Solari follow an idle window that restarts whenever the sandbox is used, so ttlMinutes raises an error; use autoStopInterval with a value above zero. Resources above 8 vCPU or 16 GiB are reduced to those limits with a warning. File operations run as root while commands do not, so a file written through the files API may need a new owner before a command writes to it.

Preview links carry a signed token, so treat the URL as a secret. The TypeScript package is ESM-only, so CommonJS code needs a dynamic import(). Beyond these differences sits a short list of features the layer does not cover.

What Raises an Error

Features outside the compatibility layer fail loudly, which makes them easy to find. Each raises SolariCompatUnsupported, a subclass of the SDK's base error that names the feature. The list covers PTY sessions, the code interpreter and computer use; LSP and SSH; network allow-lists and outbound proxy; volumes, the secrets service and warm pools; GPU, spot, regions and organisation sign-in; and archive, recover and resize.

Existing handlers for the base error catch these too. The full call-by-call list is the COMPAT.md file in each package, and it is the input for the test plan below.

How to Test the Migration

Testing the move is mostly a matter of running the existing suite against the new import. A practical order:

1. Search the code for calls on the unsupported list and in COMPAT.md, and decide what replaces each.

2. Run the suite on a branch with the new import and a Solari key.

3. Check the behaviour changes above: stop, ttlMinutes and file ownership.

4. Rebuild templates and snapshots made before the daytona account shipped, since those run as root with a one-time warning.

Once the suite is green, the last question is what the same workload costs.

What It Costs to Run

Pricing is often where the move starts, so it helps to compare like with like. Daytona says compute costs $0.0504 per vCPU hour and memory $0.0162 per GiB hour, with $200 in free compute to start, on its pricing page. The Solari pricing page sets sandboxes at $0.0245 per vCPU-hour and $0.0077 per GB-hour on the Professional plan, and $0.0175 and $0.0055 on Team.

The Free plan starts at $0 a month with $3 in monthly credits, and snapshot storage is free for the first 10 GB. For a team moving sandbox code today, that means the same SDK calls at a lower published vCPU and memory rate.

Choosing the Right Setup

The move comes down to three checks: the import and key, the behaviours that differ, and the calls on the unsupported list. Code that creates sandboxes, runs commands, moves files and uses git moves with the import swap; code that depends on stop clearing state, a hard lifetime, GPUs or volumes needs a change first. Daytona is the more established sandbox vendor with the larger ecosystem; Solari is the younger company and moves faster on speed and price. Solari also runs browsers and desktops from the same account, as the Solari launch post explains.

Get Started With Solari

Start with the package on a branch and run the existing tests against a Solari key. The site says sandboxes are ready in 90 ms, and the Professional vCPU rate above makes Solari the cheaper home for the same calls, with a Free plan to try it at no cost. Install the package and follow the migration guide to move the first sandbox today.

Related reading: how to migrate from E2B to Solari, E2B alternatives for AI code sandboxes, how to run untrusted agent code safely.