E2B vs Northflank (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 reach outside systems through a short, fixed set of built in routes. A cloud harness pushes to Git through a proxy that limits its credentials to the harness branch and refreshes them automatically, workload identity issues short lived tokens for AWS, Google Cloud and Azure, and workflow message steps post to Slack, a webhook or a pull request comment. Any other API key can be added to outbound requests at egress so the agent's code never holds it, but the tools that use it are the customer's own code, and agents get no integration catalog or tool framework.

Sourcenorthflank.com/product/sandboxesread 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

Workflows chain builds, deployments, job runs, backups, conditions, approvals and messages in a visual editor or as JSON, with sequential, parallel and loop control and child workflows that can wait for completion, and the cloud agent loop carries agent built changes through previews, staging and production this way. A job can run an agent and the workflow waits for its result. These steps orchestrate releases and infrastructure around the agents, while the agent's own reasoning steps, hand offs and retries stay inside the customer's harness or code.

Sourcenorthflank.com/docs/v1/application/release/configure-workflowsread 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

Work starts from Git events, schedules and webhooks. Workflows and preview blueprints run on a push, a pull request, a tagged release, a completed check suite, a pull request label, a cron schedule no more often than every 10 minutes, or a GET or POST to a webhook URL, with the branch, commit and pull request passed into the run. Jobs also run on cron schedules or on demand through the API, so an agent job can start on a timer or when another system calls it.

Sourcenorthflank.com/docs/v1/application/release/configure-workflowsread 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 is part of the platform. Volumes, S3 buckets mounted through FUSE and managed Postgres, MySQL, MongoDB or Redis hold data that an agent's code can read and write, and any vector store or retrieval layer is something the customer deploys on top of them.

Sourcenorthflank.com/product/sandboxesread 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

State outlives a single run. A cloud harness keeps its home directory on a 5 to 100 GB volume through restarts and pauses, sandboxes keep attached volumes across pause and resume, and S3 buckets mounted through FUSE keep data after a sandbox is deleted. Northflank's stateful agent example gives each agent a managed Postgres database for memory and resumes its session against it. That memory is a database and volume the customer's own agent code writes and reads, with no memory layer of stated scope and lifetime managed by the platform.

Sourcenorthflank.com/product/sandboxesread 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

Release workflows can wait on people. An approval step holds a workflow until the required number of approvals is given from its run page, so an agent built change can be stopped before it reaches staging or production, and cloud harness pushes are confined to the harness's own branch. Nothing holds an agent's direct API, CLI or MCP actions for review, since those run with whatever the token's role permits.

Sourcenorthflank.com/docs/v1/application/release/configure-workflowsread 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

Northflank holds SOC 2 Type II and ISO 27001 and supports HIPAA, with reports in its trust center. Fine grained roles grant create, read, update and delete permissions per resource type, can be limited to or excluded from projects, and drive API tokens, which inherit their role's permissions. Owner, admin and default roles come preset, organization roles span teams and can follow directory groups, and Enterprise adds SAML and OIDC single sign on with SCIM and just in time provisioning. Team policies limit which coding agents may run and can keep a harness private to its creator.

Sourcenorthflank.com/docs/v1/application/secure/use-role-based-access-controlread 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

Every sandbox, job and harness streams logs and reports CPU, memory and network metrics through the dashboard and API, and workflow, job and template runs keep their run details.

On Enterprise, audit logs record every action from the UI, API and CLI, templates, release flows, Git events and the system, with the acting user, origin, affected resources, a before and after diff and the parent events that caused it, at organization, team, project and resource level, and forward to S3.

Log sinks, alerts and notifications to Slack, email, Teams or webhooks come on paid plans. An agent's prompts and tool calls inside its harness are not traced.

Sourcenorthflank.com/docs/v1/application/observe/audit-logsread 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

Projects run in one of more than 17 Northflank Cloud regions, chosen at creation and fixed afterwards, with GPU sandboxes in GPU enabled regions. BYOC runs the same sandboxes and harnesses in the customer's own AWS, Google Cloud, Azure, Oracle, Civo, CoreWeave or Nebius account, with Kata microVM support for harnesses, and Northflank also manages bare metal, OpenShift and VMware clusters. Enterprise can run the control plane itself inside the customer's infrastructure, air gapped if needed, so no platform data leaves the network.

Sourcenorthflank.com/docs/v1/application/sandboxes/sandboxes-on-northflank-cloudread 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

Cloud harnesses come preset for Claude Code, Codex, OpenCode, Pi and Cursor, or start empty for other tooling, and a Northflank skill and plugin teach coding agents the platform. Stack templates deploy common applications in one step, and templates and preview blueprints package infrastructure and releases for reuse. These are configured third party agents and building blocks a developer assembles, not prebuilt agents of Northflank's own.

Sourcenorthflank.com/product/cloud-agentsread 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 agent and the model behind it. A harness runs Claude Code, Codex, OpenCode, Pi or Cursor signed in with the customer's own API key or account, or starts empty for other tooling, and team policies decide which of those agents a team may run. Models can also be self hosted on GPUs from L4 to B200 for inference beside the agents, and Northflank routes no model traffic of its own.

Sourcenorthflank.com/product/cloud-agentsread 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

Every resource is reachable from outside through a REST API, a CLI, and JavaScript and Python clients, with endpoints for sandboxes, harnesses, jobs, workflows, templates, secrets, volumes and audit logs, plus exec, file copy, log tailing and metrics. A hosted MCP server takes a team API token as a bearer header and lets Claude Code, Codex, Cursor or OpenCode deploy services, manage jobs and databases and inspect resources. Templates and GitOps define the same resources as code.

Sourcenorthflank.com/docs/v1/api/introductionread 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 is no scoring, test case or quality gate for an agent's behavior. Sandboxes run reinforcement learning rollouts and evaluations at more than 50,000 environments in parallel from one image with shared volumes, but the rewards and scores come from the customer's own code.

Sourcenorthflank.com/product/sandboxesread 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

Browser agents run on a browser image the customer picks, such as headless Chromium from browserless, with one sandbox per session that the agent drives over the private network through the DevTools protocol, behind egress rules set by domain. Northflank supplies the isolated compute and networking for it, not a browser or desktop of its own.

Sourcenorthflank.com/product/sandboxesread 2026-11-05