E2B vs Fly.io Sprites (2026)

An agent in a sandbox reaches other systems through a built in MCP gateway that runs inside the sandbox and exposes more than 200 tools from the Docker MCP Catalog (Airtable, GitHub, Browserbase, Exa and others) or custom MCP servers through one interface. Credentials are passed as secrets that resolve at egress instead of living in the sandbox.

Sourcedocs.e2b.dev/mcp-gatewayread 2026-11-03

Agents call outside services through connectors without holding the credentials. An organization stores a credential once, by OAuth for services such as GitHub or with a key, and the Sprite reaches the service through Fly.io's gateway, which identifies the calling Sprite, checks the connector's access policy and attaches the credential.

The catalog holds more than 40 connectors, including GitHub, Slack, Notion, OpenAI, Anthropic, OpenRouter, Supabase, Neon, Composio and S3 compatible storage, a Custom API connector covers any token authenticated HTTP API, and a connector refuses every Sprite until a policy grants access by name, label or endpoint.

Sourcedocs.fly.io/sprites/concepts/connectorsread 2026-11-05

There is no workflow logic in E2B itself. The customer brings its own orchestration framework, and E2B provides the machine an agent's steps run on (commands, background processes, code contexts), not a runtime that sequences, branches, retries or routes those steps. Forking a sandbox copies its state, which is compute, not workflow logic.

Sourcee2b.dev/llms.txtread 2026-11-03

There is no workflow logic for an agent's steps. Services keep long running processes up, restart them when they crash and start them in dependency order, and a Tasks API keeps a Sprite awake until work finishes, but sequencing, branching and retrying an agent's work stay in the customer's code or framework.

Sourcedocs.fly.io/sprites/concepts/servicesread 2026-11-05

A sandbox can start without the customer's code calling it. With auto resume set, a paused sandbox resumes when activity arrives, so an agent served from a sandbox starts on an inbound request, and E2B's guides deploy agent gateways this way, for example OpenClaw answering Telegram. Sandbox lifecycle events are also pushed to the customer's webhook, signed. There is no scheduler.

Sourcedocs.e2b.dev/sandbox/auto-resumeread 2026-11-03

A request to a Sprite's URL wakes it without the customer's code calling it. If the Sprite's HTTP service is not running when the request arrives, the proxy starts it and forwards the request, so an agent or app served from a Sprite answers traffic while costing nothing in compute between requests. There is no scheduler or webhook.

Sourcedocs.fly.io/sprites/concepts/servicesread 2026-11-05

There is no retrieval structure over the customer's content, since E2B runs the agent's code. Files uploaded to a sandbox or volume are storage the agent's code can read, not an index a query returns, and the MCP gateway's tools reach outside knowledge sources owned by others.

Sourcee2b.dev/llms.txtread 2026-11-03

No retrieval index or knowledge base over the customer's content comes with Sprites. Files an agent reads live on the Sprite's disk, and any retrieval runs in the customer's own code.

Sourcedocs.sprites.devread 2026-11-05

An agent's working state carries across sessions. A paused sandbox resumes exactly as it was, with filesystem and memory, running processes and loaded variables, and is kept until it is killed. Snapshots and forks copy that state, volumes, in private beta, keep files across sandboxes, and code contexts keep interpreter variables between executions, which the agent's code reads to continue its task. This is machine state the developer manages, with no memory layer of stated types or scope that can be reviewed, edited or deleted as memory.

Sourcedocs.e2b.dev/sandbox/persistenceread 2026-11-03

An agent's working state carries across sessions as machine state. A Sprite's disk keeps files, packages, repositories and databases stored on disk through every sleep, a warm pause keeps memory and running processes, and checkpoints copy the filesystem in about a second, with automatic checkpoints in the background and the last five mounted read only. An agent can checkpoint and restore its own Sprite. This is machine state the developer manages, not a memory layer of stated scope that can be reviewed or deleted as memory.

Sourcedocs.fly.io/sprites/concepts/checkpointsread 2026-11-05

There is no approval step, consent checkpoint or escalation to a person for work inside an E2B sandbox. Egress control (allow and deny lists for each sandbox, a proxy the customer runs that fails closed, and access tokens on public URLs) limits what an agent's code can reach, but that is isolation the developer configures, not a point where a person reviews the agent's action.

Sourcee2b.dev/enterpriseread 2026-11-03

Work in a Sprite has no approval step, consent checkpoint or escalation to a person. Connector policies, the outbound allowlist and MCP tokens limited to Sprites with a set name prefix restrict what an agent can reach, and an MCP client may ask before destructive tools run, but nothing on Fly.io's side holds an action for review.

Sourcedocs.fly.io/sprites/integrations/remote-mcpread 2026-11-05

E2B holds SOC 2 Type II, with the report under NDA in its trust center at trust.e2b.dev, and signs HIPAA Business Associate Agreements on Enterprise plans. Its controls protect the sandbox. Every sandbox is its own Firecracker microVM with its own kernel, egress can be allowed or denied for each sandbox, secrets are injected at the egress proxy so no sandbox holds them, and public sandbox URLs can require an access token. Who inside a customer's organization can do what has no published control yet, since E2B lists single sign on, SCIM and role based access as planned.

Sourcee2b.dev/securityread 2026-11-03

Sprites run in Fly.io organizations, which have admin and member roles and can require single sign on through Google or GitHub. Organization tokens authenticate the command line tool, the API and the SDKs, MCP access is granted by OAuth with tokens limited by default to Sprites with a set name prefix, Sprite URLs are private to the organization unless made public, and connector credentials are stored encrypted outside the machine. Fly.io offers SOC 2 Type II and a HIPAA package with a BAA signed in advance on its paid plans, without saying whether they extend to Sprites.

Sourcedocs.fly.io/security/ssoread 2026-11-05

The record covers the sandbox, not the agent. Every lifecycle event is available through an events API and delivered as a signed webhook, sandbox metrics report CPU and memory use, template builds keep logs, and on Enterprise OpenTelemetry metrics and logs export to the customer's OTLP endpoint. Prompts, tool calls, retrieved knowledge and outputs cannot be inspected step by step in E2B, since the agent's reasoning runs outside the sandbox, and there is no audit log of user actions apart from the runtime.

Sourcee2b.dev/enterpriseread 2026-11-03

The machine is measured and the agent's steps are not. Service logs are kept with timestamps and read through the API, the command line tool and the MCP server, usage endpoints break compute and storage down by organization and by Sprite, managed connectors show usage over 24 hours, 7 days or 30 days, and exec sessions can be reattached after a disconnect. There are no traces or audit trail of what an agent did.

Sourceapi.sprites.dev/openapi.jsonread 2026-11-05

Three deployment modes share the same SDK, CLI and API. E2B Cloud defaults to Google Cloud us-west1, and AWS us-west-2 and us-east-1 and Google Cloud europe-west1 and asia-southeast1 are available on request on every plan. With BYOC on AWS, Google Cloud or Azure on Enterprise, the data plane runs in the customer's own cloud account. E2B Embed packages the Apache-2.0 runtime for a single node self hosted install, and a private cloud option is in development.

Sourcedocs.e2b.dev/faq/egress-ip-rangesread 2026-11-03

Sprites run on Fly.io's hosted platform with no choice of region and no self hosted option. Creating a Sprite takes a name and URL settings only.

Sourceapi.sprites.dev/openapi.jsonread 2026-11-05

Starting points ship with the platform, including sandbox templates for Claude Code, a desktop, Docker and web app stacks, a cookbook of examples ready to run, setup guides for more than thirty agents and frameworks, and open source reference apps, Surf, a computer use agent, and Fragments, a builder that turns a prompt into an app. These are environments and examples a developer builds from, not a browsable catalog of agents a customer adopts.

Sourcedocs.e2b.dev/llms.txtread 2026-11-03

Starting points come as a ready image, plugins and framework integrations. Each Sprite starts from Ubuntu with Node.js, Python, Go, Rust, Java and other languages and AI command line tools preinstalled, plugins connect Claude Code, Codex, Cursor, OpenCode and other coding agents, and integrations cover Google ADK, the OpenAI Agents SDK, Pydantic AI and TanStack AI. These are tools a developer builds with, not prebuilt agents a business adopts.

Sourcefly.io/sprites/ecosystemread 2026-11-05

Compute is what E2B provides for agents, with the customer bringing its own model and orchestration framework. Sandboxes connect to any LLM and to agents and frameworks such as Claude Code, Codex, the OpenAI Agents SDK, the Vercel AI SDK, LangChain, CrewAI, Mastra and Google ADK. E2B imposes no model, so model choice stays with the customer.

Sourcee2b.dev/llms.txtread 2026-11-03

The customer chooses the agents and models. Any coding agent or framework can run in a Sprite, and connectors reach OpenAI, Anthropic, OpenRouter, Fireworks, Hugging Face, Ollama Cloud and other model providers with the organization's own keys, or through a managed option for OpenRouter.

Sourcefly.io/sprites/ecosystemread 2026-11-05

Outside systems can call E2B through Python and JavaScript/TypeScript SDKs, a CLI, a REST API described by a published OpenAPI 3.1 specification, and custom sandbox templates the customer builds, tags and versions. A public MCP server serves E2B's documentation to agents.

Sourcee2b.dev/llms.txtread 2026-11-03

Sprites are managed through a REST API with a public OpenAPI specification, Python, JavaScript, Go and Elixir SDKs and the sprite command line tool. A hosted MCP server at sprites.dev/mcp, authorized by OAuth, enumerates, creates and destroys Sprites and runs commands, checkpoints, network policy, services and service logs inside them, and an agent inside a Sprite reaches the same controls through a local management socket.

Sourcedocs.fly.io/sprites/integrations/remote-mcpread 2026-11-05

There are no fixtures, scoring, quality gates or comparison of agent runs. E2B is where evaluations and reinforcement learning run, not how they are scored. It lists reinforcement learning among its workloads and runs NVIDIA NeMo Gym environments in sandboxes, but the datasets, reward functions and scoring belong to the customer's framework.

Sourcee2b.dev/llms.txtread 2026-11-03

There are no test cases, scoring or quality gates for an agent's behavior. Sprites can host evaluation and training environments such as Hugging Face OpenEnv through an experimental provider, with the scoring in the customer's own harness.

Sourcedocs.fly.io/sprites/integrations/agent-sdksread 2026-11-05

Agents control real desktops hosted by E2B. E2B Desktop sandboxes are Ubuntu machines with an XFCE desktop and preinstalled applications, and the Desktop SDK gives the agent screenshots, mouse, keyboard and scroll, with a live VNC stream so a person can watch. A cloud browser can also run in a sandbox, and Surf is E2B's open source computer use agent built on it.

Sourcedocs.e2b.dev/use-cases/computer-useread 2026-11-03

No browser or desktop for an agent to drive comes with Sprites. The Steel Browser Tools connector returns scraped web content, screenshots and PDFs without browser sessions, and an agent that needs to drive a browser installs and runs one itself inside the Sprite.

Sourcefly.io/sprites/ecosystemread 2026-11-05