E2B

E2B gives an AI application a Linux computer on which to run code, manipulate files and use software tools. A developer starts an isolated sandbox through a Python or JavaScript/TypeScript SDK, sends work into that environment and brings the results back to the application. The model can propose an action; E2B supplies the environment where that action runs. This makes it useful for coding agents, data-analysis assistants and other products that need more than a generated text response.

The service is especially relevant when different users or agent sessions need separate working environments. An application can create a sandbox for a task, install or preconfigure its dependencies, collect outputs, and decide whether to pause the environment or terminate it. Start with the official E2B website and documentation to understand the runtime, SDKs and hosted service.

What E2B adds to an agent application

A language model can describe a calculation without executing it. E2B lets the surrounding application execute generated code and return an observed result. For example, an assistant asked to summarize a CSV can upload the file to a sandbox, run analysis code, retrieve a table or chart, and use those outputs in its reply. A coding agent can work with a repository, run commands and inspect failures inside its own environment.

The developer controls the connection between the model and the sandbox. E2B's model integration guide describes using tool calls to send code for execution and return results. The runtime can fit different model providers and frameworks; choosing the model, defining allowed tools and building the conversation loop remain application decisions. A successful command is evidence of that command's result, not proof that the model understood the user's broader request.

This separation is useful when an existing application already has authentication, a chat interface and model routing. It can add a controlled execution tool without replacing the rest of the product. Conversely, a team looking for a finished no-code assistant should expect integration work: E2B provides developer infrastructure rather than the complete user experience.

Commands, files and returned artifacts

E2B's SDK quickstart shows creating a sandbox and running a shell command. Filesystem methods let the application read and write files, including multiple files in a request. Those capabilities support practical sequences such as uploading a dataset, writing a script, executing it and downloading the resulting artifact. The file read and write guide documents this part of the interface.

A useful integration treats outputs as structured work products. Separate the generated script from the original upload and from the result. Preserve the command's output or error alongside the artifact so a failure is visible. If a data assistant produces a chart, the application should also make clear which input file and transformation produced it. Otherwise a polished visualization can conceal an empty dataset, unintended filtering or an incorrect aggregation.

The Code Interpreter workflow covers running generated analysis code and handling text, errors and chart results. It illustrates an important design choice: the application can distinguish runtime errors from successful results instead of asking the model to invent an answer when execution fails. That gives developers a place to implement retries, request clarification or show a readable failure message.

For a coding workflow, files and commands also provide the basis for inspecting a repository and running its existing checks. The agent still needs an appropriate task boundary. Asking it to change a specific parser and run the relevant tests is easier to review than giving it an unrestricted mandate to improve an entire codebase.

Templates make environments reproducible

Custom templates define how a sandbox starts. E2B documents choosing a base image, setting environment variables, copying files, installing dependencies and configuring a start command. Templates can be created through the CLI or SDK. Read the template quickstart before designing an environment that depends on particular packages or background services.

The purpose is consistency across sessions. A data product might prepare an environment with its approved analysis libraries and a helper script that validates uploaded columns. A code-review service might prepare the tooling needed by its target repository. Starting each request from a defined environment avoids relying on whatever packages happen to have been installed during an earlier conversation.

Keep template design separate from user-specific data. Reusable dependencies belong in the template; an individual customer's upload should be introduced into that customer's session. Long-lived credentials should not be baked into an image. Pinning dependency versions and keeping a record of the template used for a result are sensible engineering practices when reproducibility matters.

Templates also create maintenance work. A base image or package can become outdated, and a template that builds successfully may still lack a runtime prerequisite. Evaluate startup behavior, actual commands and output formats together. A representative task is more informative than a template build that never exercises the tools the agent will use.

Session lifecycle, pausing and persistence

A sandbox has a lifecycle that the application must manage. It can create an environment, reconnect to it, pause it, resume it or kill it. Timeouts influence what happens when work is no longer active. E2B's lifecycle documentation explains these controls and distinguishes continuous running time from the lifetime of a persisted environment.

Pausing can preserve both filesystem and memory state, including running processes and loaded variables, for later resumption. The persistence guide also describes a filesystem-only option that resumes through a fresh boot. These are different choices: a conversational analysis session may benefit from keeping its loaded data, while another application may prefer restarting processes from saved files.

Choose that behavior deliberately. A user who returns to an analysis should know whether previous files and calculations remain available. A new user should never inherit a previous user's workspace. Store the relationship between application user, task and sandbox ID on the trusted side of the application, and check authorization before reconnecting.

Persistence also requires a cleanup policy. E2B documents indefinite retention for paused sandboxes until explicit deletion. Pausing is therefore not the same as deleting a customer's data. A product that promises deletion after a task must terminate or remove the relevant resources according to its own policy, including copies it exported elsewhere.

Network boundaries and credential handling

E2B sandboxes have outbound internet access by default. Developers can disable it or configure more selective rules. The network guide describes allow and deny controls for outbound traffic. A sandbox used only for calculations on an uploaded file may not need external access; one that installs packages or calls a specific API may need a narrower set of destinations.

Inbound access deserves separate attention. The data-analysis guide explains that the Code Interpreter server can be reachable through the sandbox's public URL and documents disabling public traffic so the application controls execution. A publicly accessible preview and a private execution endpoint serve different purposes. Decide which interfaces a user should see and which should remain available only to the application's trusted backend.

E2B also documents a secret-management system that injects credentials into matching outbound HTTPS requests outside the sandbox. The environment can reference a named secret instead of receiving its raw value as an environment variable. This reduces one route by which code inside the sandbox could read a credential. The destination still receives the credential, so destination trust and narrowly scoped permissions remain important.

These controls support a security design; they do not decide that design automatically. Developers must choose what data to upload, which operations to expose and what credentials a task needs. Avoid giving an experimental agent access to unrelated production systems merely because its compute environment is isolated.

A concrete workflow for a data assistant

Consider a small business application that helps users inspect sales exports. Begin with a limited request: summarize monthly revenue from one CSV, identify missing values and produce a chart. The interface should ask which column represents revenue and how refunds should be treated if the file does not make those definitions clear.

1. Create a sandbox from a template containing the approved analysis dependencies, with a timeout and network policy appropriate for the task.
2. Write the user's file into the session and provide the model with column names and a precise analysis request rather than unrelated customer records.
3. Expose a code-execution tool that sends the proposed analysis to the sandbox and collects results or errors.
4. Check row counts, missing values and totals before presenting the monthly chart. Show the assumptions used for currencies, dates and refunds.
5. Retrieve the chart and any summary table into the application's artifact storage. Pause the session if the user should continue exploring, or terminate it when the task and retention policy require that.

This is an example integration, not a claim that E2B supplies a sales-analysis application. Its value here is the execution environment and SDK surface. The developer still builds upload validation, authorization, the model tool definition, result presentation and deletion behavior.

Test the workflow with awkward files as well as a clean example. Include missing headers, malformed dates, unexpected currencies and empty inputs. Observe whether the product asks a useful question or quietly makes an assumption. That evaluation checks the application assembled around E2B, including the model and scripts, rather than measuring the sandbox in isolation.

Who should consider E2B

E2B suits developers building agent products that need temporary computers on demand. Relevant teams include coding-agent builders, analytics-product developers, platform engineers adding execution tools and researchers studying tool-using agents. Python and JavaScript/TypeScript interfaces let it fit common backend stacks without requiring every agent implementation to share a single orchestration framework.

It can also help a team keep experimental task execution separate from its application server. Generated code can run in a task environment while the trusted backend manages users, billing and access. That architecture still needs controls on what information crosses the boundary and which results the backend accepts.

It is less suitable for someone who wants a ready-made spreadsheet interface or a complete application builder with no integration work. Those users may prefer an end-user product. A platform team should evaluate E2B alongside its current infrastructure, especially if it already operates a mature execution service and has requirements around regional deployment, resource types or internal networking.

Pricing, access and operational limitations

E2B offers a Hobby entry plan with one-time introductory usage credits, a paid Pro plan and custom Enterprise arrangements. Hosted sandbox compute is billed by running time and resource configuration. A free entry plan or introductory balance should therefore not be interpreted as unlimited free execution. Consult the pricing page and billing and limits guide for current terms.

Plan limits cover matters such as concurrent sandboxes, continuous runtime, resource ceilings and API request rates. The billing guide says the Pro subscription increases limits rather than adding usage credits. Budget for compute and model calls separately: the model producing a script and the sandbox executing it are different services. Include idle running sessions and repeated failed attempts in workload estimates.

The runtime is available as open-source software, while the hosted cloud service has its own commercial access model. Self-hosting is an infrastructure project, with operational responsibilities that a managed service otherwise handles. Check the official repository and deployment information before assuming that an open-source license means a production installation requires no work or ongoing expense.

Execution also does not establish analytical correctness. A script can finish without errors while using the wrong definition of revenue or modifying the wrong file. Resource limits, dependency issues and network failures can interrupt tasks. Design an explicit failure path, capture relevant logs and require appropriate review before applying outputs to important business decisions or source code.

Frequently asked questions

Does E2B provide the language model?

E2B supplies sandbox infrastructure and integration interfaces. Developers connect the model or agent stack they choose and decide how tool calls reach the environment. Model access and charges should be assessed separately.

Can a session continue after a user leaves?

The application can pause and resume a sandbox using the documented persistence controls. It must keep the correct session ID, authorize reconnection and choose whether memory or only filesystem state should survive.

Can an agent use the internet?

Outbound access is enabled by default and can be disabled or restricted. Configure it for the task and review inbound exposure separately; public previews and private execution services require different access decisions.

What should a first evaluation demonstrate?

Use one representative task that uploads input, executes work, returns a useful artifact and cleans up correctly. Include a deliberate failure and a repeated session. Check task correctness, authorization, persistence behavior and total running cost before broadening the integration.