How to Migrate From E2B to Solari (2026 Guide)

The data-analysis agent has been stable for months. It opens a sandbox, runs pandas over an uploaded CSV, returns a chart and shuts the machine down. Now the team wants it on another provider, and the first question in the channel is how much of that code has to be rewritten.

Very little. Moving from E2B to Solari is mostly an import and an API key: Solari's compatibility packages expose the same sandbox and code-interpreter API on top of Solari sandboxes, and a call outside the packages' scope throws a clear error instead of failing quietly. This guide walks through what stays the same, the template to build, what differs and how to test the switch.

What Stays the Same

Start with what does not move, because it covers most of a typical codebase. Sandbox.create takes a template, metadata and envs as before, and connect, list, kill and setTimeout all work. pause() keeps memory and disk, connect resumes a paused sandbox, and snapshots and fork work too.

Commands and files carry over as well. commands.run throws CommandExitError on a non-zero exit, background commands work, a pseudoterminal opens with pty.create, and Python runCode keeps state between calls. Since the surface holds, the switch itself comes down to a few lines.

How to Switch the Import and the Key

The switch is a package swap and one environment variable. Install solari-e2b-compat from pip or @solarisdk/e2b-compat from npm, change the import and set SOLARI_API_KEY:

# before: from e2b_code_interpreter import Sandbox
from solari_e2b.code_interpreter import Sandbox

sbx = Sandbox.create()  # reads SOLARI_API_KEY
print(sbx.run_code("x = 1\nx + 1").text)

# before: from e2b_code_interpreter import Sandbox
from solari_e2b.code_interpreter import Sandbox

sbx = Sandbox.create()  # reads SOLARI_API_KEY
print(sbx.run_code("x = 1\nx + 1").text)

# before: from e2b_code_interpreter import Sandbox
from solari_e2b.code_interpreter import Sandbox

sbx = Sandbox.create()  # reads SOLARI_API_KEY
print(sbx.run_code("x = 1\nx + 1").text)

In TypeScript the import becomes @solarisdk/e2b-compat/code-interpreter. That package is ESM-only, so CommonJS code loads it with a dynamic import(), as the JavaScript modules guide describes.

Only a Solari key starting slr_ is ever used. An old E2B_API_KEY left in the environment is skipped with a warning and never sent anywhere. The first create after the switch also does something new: it builds a template.

How to Prepare the Code Interpreter Template

The data-analysis stack lives in a template, so it needs a moment of planning. Solari's equivalent is code-interpreter-v2, built into the organisation the first time Sandbox.create() runs without a template, in a few minutes billed as a template build.

Two processes that both find it missing each start a build, so prebuild it once with build_code_interpreter_template_sync() or buildCodeInterpreterTemplate(). It installs pandas, numpy, scipy, scikit-learn, matplotlib and other common libraries; an agent that needs spacy or opencv should build its own template and point SOLARI_CODE_INTERPRETER_TEMPLATE at it. With the template ready, a handful of behaviours still differ.

What Behaves Differently

The figure below lists the calls that work differently after the switch.

Timeouts are the change most teams notice. timeoutMs is a rolling idle window that resets on use rather than a fixed lifetime, so a long job that stays busy no longer needs a generous timeout.

File ownership comes next. Commands run as a non-root account, as before, with passwordless sudo for root, while file operations run as root, so a file written through files.write may need its owner changed before a command writes to it.

Callback timing is the last difference to plan for. Streaming callbacks fire after a run finishes rather than during it, so a live progress display needs a rework. Those behaviours are what the test run should exercise.

How to Test the Migration

Testing starts with the template and ends with the edge cases. Prebuild code-interpreter-v2, run the existing suite with a Solari key and watch for SolariCompatUnsupported, which the packages raise for calls outside their scope such as network rules, IAM tokens, the MCP gateway and webhooks.

Then pin the vendor SDK at the version the packages target, 2.59 for the core SDK and 2.9 for the code interpreter, and run one pause and connect cycle and one fork. Each package's COMPAT.md lists every call, so a suite that passes there is ready for traffic.

Choosing the Right Migration Path

For most codebases the move is an import, a key, a prebuilt template and three behaviour checks: the idle timeout, file ownership and callback timing. The compat packages let a team move traffic first and refactor later. Teams that want every Solari option can then move to the native sandboxes API, which adds isolation tiers and named shells, with browsers and desktops on the same account.

Get Started With Solari

Start by prebuilding the template and running the existing suite through the compat package. Solari has sandboxes ready in 90 ms, bills them at $0.0245 per vCPU-hour on the Professional plan, and includes $3 in monthly credits on the Free plan (pricing), so the first test run costs nothing. The introduction to Solari covers the rest of the account; create a free Solari account and run the first migrated sandbox today.

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