E2B
AIGive AI agents disposable cloud machines with E2B sandboxes. Agents spawn secure micro-VMs from templates, pause and resume them to preserve state between turns, snapshot known-good checkpoints, and monitor metrics and logs across the fleet before killing sandboxes when work completes.
What This Integration Enables
An agent that writes code but has nowhere to run it is a suggestion engine. E2B closes that gap with disposable cloud micro-VMs, and this integration makes them a managed part of your automation rather than something a developer scripts by hand. Agents spawn sandboxes from templates, execute generated code in full isolation from your infrastructure, and read back logs and resource metrics to judge the result. Pause Sandbox and Resume Sandbox preserve full memory state, so a long-running task survives between agent turns and continues exactly where it stopped. Create Snapshot captures a configured sandbox as a reusable checkpoint that new sandboxes can launch from. The orchestration question with ephemeral compute is never how to start machines. It is who governs the fleet: which sandboxes are still doing work, which state is worth keeping, and who signs off before a machine and everything on it disappears. That is a [human-in-the-loop](/concepts/human-in-the-loop/) problem, and it is the part this connector treats as the product. Connector capabilities are built and verified against E2B's official API.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Generated code with a governed lifecycle
A coding agent produces a data-processing script. Instead of running it anywhere near production, the workflow calls Create Sandbox, executes the script inside the micro-VM, and pulls Get Sandbox Logs for the output and Get Sandbox Metrics for the resource profile. If the run succeeds, results flow downstream and the sandbox is flagged idle. The operator decides what happens next: Create Snapshot if the configured environment is worth keeping as a checkpoint, or Kill Sandbox if it is not. The code ran, the evidence was captured, and nothing was destroyed without a decision.
Tests in isolation on every push
A push lands in [GitHub](/integrations/github). The agent pulls the changed code, spins up a sandbox from the project's test template with Create Sandbox, runs the suite inside it, and reads the results with Get Sandbox Logs. Failures post to the engineering channel in [Slack](/integrations/slack) with the failing output attached; passes tear down silently. Test runs stop competing with anything else for compute, and a hostile or broken change can only break its own disposable machine.
Fleet hygiene with a person at the kill switch
On a daily schedule, an agent calls List Sandboxes for running and paused machines, pulls List Sandbox Metrics across the fleet, and builds the picture: which sandboxes are active, which have been idle for days, and what they are consuming. Get Team Metrics adds the capacity view of concurrent counts and start rates. The agent posts the idle list with its evidence and a recommendation per sandbox: pause, snapshot then kill, or kill. A person approves the list before anything is terminated, because an idle-looking sandbox is sometimes a paused investigation someone intends to resume.
Human-in-Loop Highlight
Kill Sandbox is irreversible: the sandbox's memory and filesystem are discarded the moment it runs, and E2B's own guidance is to snapshot first if anything inside matters. That is precisely the shape of decision an agent should stage but not make. When the fleet-hygiene agent finds a sandbox idle past the threshold, it does not kill it. It posts the case to the operator: "Sandbox sbx_9f2 (template: data-pipeline) has been paused for 6 days. Metrics show 4.2 GB on disk. Snapshot before killing, kill without snapshot, or leave it?" The operator knows whether that machine holds a half-finished migration or yesterday's scratch work. The agent brings the audit and the one-tap options; the human makes the only call that cannot be unmade.
Agent Capabilities
18 actionsSandboxes
9- Create Sandbox Spawns a secure, isolated micro-VM from a template and returns the sandbox ID. The starting point for giving an agent an ephemeral machine for code, tools, or a browser.
- List Sandboxes Lists sandboxes filtered by state and metadata, with paging. Used to find running or paused machines during fleet audits.
- Get Sandbox Retrieves a sandbox's template, state, CPU, memory, disk, network configuration, and lifecycle timestamps. Used to check what a machine is before acting on it.
- Kill Sandbox Permanently terminates a sandbox and discards its memory and filesystem. The gated action in this connector: teardown requires human sign-off, with Create Snapshot as the offered alternative.
- Pause Sandbox Pauses a running sandbox with full memory capture by default, so execution can continue exactly where it left off. Used to preserve state between agent turns.
- Resume Sandbox Resumes a paused sandbox with its preserved state and a fresh timeout. The sandbox keeps its original ID.
- Connect to Sandbox Connects to a sandbox by ID, resuming it if paused, and refreshes its timeout. Used when a workflow needs a live handle without knowing the current state.
- Set Sandbox Timeout Resets the auto-shutdown timer to a given number of seconds from now. Used as a keep-alive for long tasks or to shorten the life of a machine that should die sooner.
- Refresh Sandbox Extends a sandbox's lifetime by a duration on top of the current deadline. A lightweight keep-alive for tasks that run long in bursts.
Metrics and Logs
4- Get Sandbox Logs Retrieves a sandbox's log entries with level filtering and full-text search. Used to read what the agent's code actually printed, including the errors.
- Get Sandbox Metrics Returns time-series CPU, memory, and disk metrics for one sandbox. Used to confirm a run stayed inside limits and to spot runaway processes.
- List Sandbox Metrics Fetches the latest metrics for up to 100 sandboxes at once. Used to build the fleet view for hygiene and capacity reviews.
- Get Team Metrics Returns team-level time series of concurrent sandbox counts and start rates. Used to watch overall capacity and demand.
Snapshots
2- Create Snapshot Captures a sandbox's current state as a reusable, optionally named snapshot that can be launched later as a template. The insurance step before any teardown decision.
- List Snapshots Lists saved snapshots filtered by source sandbox or name. Used to find a checkpoint to resume or clone from.
Templates
3- List Templates Lists the team's sandbox templates with sizing, visibility, and latest build status. Used to pick the right base image before creating machines.
- Get Template Retrieves a template with its build history and statuses. Used to verify a template is healthy before a workflow depends on it.
- Delete Template Permanently deletes a template and all of its builds. Irreversible, so it runs only inside reviewed cleanup workflows; running sandboxes are unaffected.
Frequently Asked Questions
What can FlowRunner do with E2B?
FlowRunner agents can run Create Sandbox, List Sandboxes, and Get Sandbox in E2B, plus 15 more actions.
Does connecting E2B to FlowRunner require OAuth?
No. E2B connects to FlowRunner with an API key, no OAuth flow required.
Can E2B trigger a FlowRunner workflow automatically?
E2B doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with E2B
$100 in credits. No card required. Connect in minutes.