Migrating from E2B to Naive

• Every sandbox lives behind an E2B_API_KEY, its own dashboard, and its own billing — disconnected from wherever the agent’s email, cards, secrets, and KYC live.
• The key is all-or-nothing: anything holding it can spawn a box and commands.run() arbitrary shell. There is no per-action gate — no “this agent may run code but a human must approve a shell session.”
• “Who let this agent execute that, and what else can it touch?” is answered in E2B for sandboxes, and in unrelated systems for everything else. The box has no shared accountability with the rest of the agent’s footprint.

• The tenant user that owns the workload is the same user that owns its email inboxes, its cards, its vault secrets, and its KYC.
• The agent never holds a cloud key. Naive owns the underlying cloud credentials and scopes every task to your tenant — the same model as Apps.
• Whether an agent may spin up a workload at all, and whether opening a shell (exec/ssh) freezes for human approval, is decided by that user’s Account Kit at execution time — and every shell session is transcript-logged.

​

Concept map

​

Before / after: the core path

import { Sandbox } from "e2b"; // needs E2B_API_KEY

// Spin up an ephemeral box from a template (default 5-min timeout)
const sandbox = await Sandbox.create({ timeoutMs: 300_000 });

// Run a shell command — anything holding the key can do this
const res = await sandbox.commands.run('python3 -c "print(2 + 2)"');
console.log(res.stdout); // "4\n"

await sandbox.kill();
// → the box is an island behind your E2B account + key. No per-action gate,
//   and no shared identity with the agent's email, cards, or vault.

import { Naive } from "@usenaive-sdk/server";

const naive = new Naive({ apiKey: process.env.NAIVE_API_KEY! });
const client = naive.forUser("acme"); // same id space as your own users

// A long-running container from ANY Docker image. The agent holds no cloud key.
const box = await client.compute.create({
  name: "runner",
  type: "service",
  image: "python:3.12-slim",
  command: ["sleep", "infinity"], // keep it alive so we can exec into it
});

// exec is approval-gated by default and transcript-logged.
// Returns a managed exec session — connect for command output; it is not inline stdout.
const session = await client.compute.exec(box.id, 'python3 -c "print(2 + 2)"');
// → { sessionId, streamUrl, tokenValue } (shape per SDK) — use streamUrl + tokenValue to read output

await client.compute.destroy(box.id);
// → the SAME `client` also owns this user's email, cards, vault, and KYC.

• You bring the image; you hold no key. E2B spins up from a template under your E2B_API_KEY. Naive runs any Docker image you pass, on cloud credentials it owns — the agent never holds a cloud key.
• The box is long-running, not auto-killed. An E2B sandbox auto-kills at its timeoutMs. A Naive service runs until you stop (scale to zero) or destroy it. Use a job for run-to-completion work.
• exec is a governed action. A commands.run in E2B is ungated. On Naive, exec/ssh is sensitive: depending on the Account Kit it may return pending_approval and is transcript-logged.
• The id is your identity, not a separate account. In E2B the key scopes E2B. In Naive the same forUser(id) handle also owns the agent’s email, cards, vault, and KYC.

​

The workflow that actually changes: running model-generated code

import { Sandbox } from "@e2b/code-interpreter";

const sandbox = await Sandbox.create();

// Stateful kernel: variables persist across runCode calls; rich outputs returned
const exec = await sandbox.runCode(`
import numpy as np
print(np.arange(5).sum())
`);
console.log(exec.logs.stdout); // ["10\n"]
// exec.results can include charts/images/dataframes

await sandbox.kill();

// Use an image that already has the runtime (e.g. a Jupyter/numpy image),
// then exec the model-generated snippet as a process.
const box = await client.compute.create({
  name: "py-runner",
  type: "service",
  image: "jupyter/scipy-notebook:latest", // numpy etc. preinstalled
  command: ["sleep", "infinity"],
});

const code = "import numpy as np; print(np.arange(5).sum())";
const session = await client.compute.exec(box.id, `python3 -c ${JSON.stringify(code)}`);
// Connect to session.streamUrl with session.tokenValue to capture process output.

// No stateful kernel and no structured chart/result objects — capture text
// from the exec stream (or write artifacts to a mounted store and read them back yourself).
await client.compute.destroy(box.id);

• No stateful kernel. Each exec is a fresh process — variables do not persist between calls the way they do across runCode invocations. Hold state in the image’s filesystem or an external store.
• No rich result objects. runCode returns structured results (charts, dataframes); exec returns a managed session — read process output from the stream. If you rely on inline charts/images, that is a gap.
• The win is custody, not ergonomics. The runtime, its secrets, and its shell now live under one identity with execution-time approval and a unified log — not behind a standalone key.

​

Minimal viable migration

npm install @usenaive-sdk/server

​

Consolidate further once you’re on Naive

// One key (or org) isolates sandboxes — and only those.
const sandbox = await Sandbox.create({
  // E2B_API_KEY in the environment
  envs: { OPENAI_API_KEY: process.env.OPENAI_API_KEY! },
});
await sandbox.commands.run("python3 analyze.py");

// The card, the vault secrets, the email inbox, and the KYC for this customer's
// agent live in entirely separate systems with their own tenancy — and any
// secret you injected into the box is one you manage and rotate yourself.

// One tenant user per customer isolates *every* primitive.
const acme = await naive.users.create({
  external_id: dbCustomer.id,
  email: dbCustomer.email,
});

const client = naive.forUser(acme.id);

// Run code, with secrets injected from the same identity's encrypted store:
const box = await client.compute.create({ name: "runner", type: "service", image: "python:3.12-slim", command: ["sleep", "infinity"] });
await client.compute.setSecret(box.id, "OPENAI_API_KEY", "sk-...");
await client.compute.exec(box.id, "python3 analyze.py");

// The SAME client owns this customer's email inbox, card, vault, and KYC —
// one identity, isolated end to end.
await client.email.createInbox({ local_part: "agent" });
await client.cards.create({ name: "Ops", spending_limit_cents: 25_000, provider: "managed_virtual" });

​

Gain #1 — one identity across primitives

• With E2B, the agent’s sandboxes are an island behind an API key, and any secret you inject is one you store, rotate, and protect yourself. With Naive, naive.forUser(acme.id) is a single handle to compute and email and cards and vault and KYC.
• The container’s secrets are not loose env vars — they are encrypted under the identity that owns everything else. Tear the customer down from one place; sibling tenants can never read each other’s workloads, secrets, cards, or logs.

​

Gain #2 — execution-time permission enforcement

• Whether an agent may run compute at all, and whether opening a shell freezes for human review, is policy on the identity — not a key scope you manage in a second console, and not a check you hand-write.

// A starter tier: agents may run jobs, but opening a shell must be approved by a human.
const starter = await naive.accountKits.create({
  name: "Starter",
  primitives_config: {
    compute: { enabled: true, requiresApproval: true }, // exec/shell freezes for approval
    cards: { enabled: false },                            // no card for this tier
  },
});
await naive.accountKits.assignUser(starter.id, acme.id);

• The agent’s code is identical for every tier — client.compute.exec(...), client.compute.create(...). Whether the call runs is decided at execution time:
  • Creating a workload and exec/ssh are sensitive. With approval on, the call returns { status: "pending_approval", approval_id } and runs only after a human approves it.
  • The agent holds no cloud key. Naive owns the underlying cloud credentials; the workload is scoped to your tenant, so a leaked agent key can’t spawn boxes on your raw cloud account.
  • Shell access is transcript-logged over a managed exec channel (no port 22, no SSH keys).

​

Gain #3 — unified accountability

• Every workload, run, exec, and shell session for a customer lands in one per-user activity log — alongside their email, card, vault, and KYC events, not in a separate E2B dashboard:

const { events } = await naive.forUser(acme.id).logs.query({ limit: 50 });
// "what did this agent run, for whom?" — compute, email, cards, vault, one timeline

• That is the question that is hard to answer when code execution lives in E2B, secrets live in your own manager, cards live in Stripe, and email lives somewhere else. Under Naive it is a single query.

​

What does not map yet

​

Where to go next

• compute primitive — service / job / schedule, secrets, logs, shell
• compute SDK sub-client — typed method signatures
• compute CLI — create / run / logs / ssh / exec
• Queue — pair a service with a queue for a cheap autoscaling worker
• Apps — the same “agent never holds a cloud key” model for managed infra
• Account Kits and Approvals — the policy model behind execution-time governance and exec approval
• Tenant users — the identity that owns the compute, email, cards, and vault

​

Related reading (blog)

• Why consolidate agent infra on one governed identity — migration thesis behind this guide
• Building AI Agents Into Your SaaS — tenant user anchor for every migration
• How To Build An Agentic Data Pipeline Platform — compute + queue tutorial