You can now use E2B and Encore to give coding agents isolated environments where they can build and verify complete backends, end-to-end, in your own cloud.

Real infrastructure in every sandbox

E2B gives your agent an isolated machine with its own filesystem, processes, network, and development tools (a sandbox). Encore, on the other hand, provides the primitives the agent builds with: databases, queues, buckets, caches, secrets, and cron jobs that run locally in that sandbox exactly as they will in production (in your AWS/GCP account).

Combining those two enables your agents to build against real infrastructure instead of mocks or stubs, with the confidence that the same declarations run unchanged in production.

It starts with the application declaring what it needs alongside the code, using Encore's Infrastructure SDK:

import { Topic } from "encore.dev/pubsub";
import { Bucket } from "encore.dev/storage/objects";
import { SQLDatabase } from "encore.dev/storage/sqldb";

// Encore runs local implementations of these resources inside the sandbox.
// When the application is deployed, Encore maps the same declarations to the
// infrastructure selected for that environment in your cloud. Provider choice,
// capacity, networking, and access policy stay outside the application code.
export const ordersDB = new SQLDatabase("orders", {
  migrations: "./migrations",
});

export const receipts = new Bucket("receipts", {
  versioned: false,
});

export interface OrderCreated {
  orderID: string;
}

export const orderCreated = new Topic<OrderCreated>("order-created", {
  deliveryGuarantee: "at-least-once",
});

When you run encore run inside the E2B sandbox, it starts up the local infrastructure required by those declarations, and the agent gets it running alongside the APIs without having to maintain a separate Docker Compose setup.

This gives you one sandbox that is useful for an entire end-to-end change, rather than just the code generation part. In practice, this means that an agent can change the database schema, restart the app, seed the data, call an endpoint, inspect the resulting trace, run integration tests, and so on.

Guardrails inside the sandbox

Much like how sandboxes keep agents from going haywire, Encore does a similar thing with its infrastructure primitives which keep agents from hallucinating infrastructure configuration the way they would with Terraform, YAML, or IAM policies.

For example, the OrderCreated topic declared above only accepts its declared event type:

await orderCreated.publish({
  orderID: 123, // Type error: orderID must be a string.
});

Given the primitives are type-safe, your agent is able to see the error on the line it just wrote, before the application even runs. The same thing happens with invalid resource declarations, which fail during encore check within the same loop it's working in, not after a deploy to a real cloud account.

One sandbox for every change

The above then naturally fits into a pull-request workflow:

1. A new issue or pull request creates an E2B sandbox from a prepared template and checks out the branch.
2. The agent runs encore run. Encore reads the application and starts its APIs and local infrastructure inside the sandbox.
3. The agent implements the change and runs encore check to validate its types, API contracts, and infrastructure declarations and then runs the test suite, exercising the running APIs, and inspecting their traces.
4. The agent posts the patch and the results of those checks to the pull request.
5. A developer reviews the behavior and decisions that cannot be derived from the code: whether the change matches the product requirement, handles sensitive data correctly, and should be allowed to reach production.
6. When the pull request closes, the sandbox is removed.

Your cloud, end to end

Both E2B and Encore can run in your own AWS or GCP account, so your code, data, and credentials stay there the whole way.

E2B offers BYOC deployment, where the sandbox runs inside your cloud using the same SDK and API as the hosted version so the agent works under your egress policy, and secrets stay scoped to the sandbox (instead of being passed to the model).

When the change is ready, Encore provisions the production infrastructure into that same AWS or GCP account, including networking and IAM, mapping the same declarations the agent built against locally, so the code does not end up changing on its way to production.

Essentially, it becomes a streamlined path from the agent's workspace to production, running end-to-end in your own cloud.

Starting an Encore workspace with E2B

You can start with an existing Encore application, or you can create one with encore app create.

If you want an agent to prepare the integration in an existing Encore app, give it this prompt:

If you want to do it manually - install the E2B JavaScript SDK in the process that creates agent workspaces:

npm install e2b

The SDK can create the sandbox, clone an application into it, and run the commands that prepare the backend:

import { Sandbox } from "e2b";

// Encore uses Docker for local databases, so start from a template with Docker installed.
const sandbox = await Sandbox.create("encore-docker");

await sandbox.commands.run("git clone https://github.com/your-org/your-app.git /home/user/app");

// commands.run() defaults to a 60s timeout, so lift it for the slow steps.
await sandbox.commands.run("curl -L https://encore.dev/install.sh | bash", { timeoutMs: 0 });
await sandbox.commands.run("npm install", { cwd: "/home/user/app", timeoutMs: 0 });

Start encore run as a background process so the agent can keep working while the backend runs. It will then use the same checks a developer would use locally:

$HOME/.encore/bin/encore run --listen=0.0.0.0:4000
encore check
encore test ./...
encore app show

It can also connect to the Encore MCP server to read API and infrastructure metadata, call endpoints, inspect local database state, and retrieve traces which gives the agent runtime feedback from the backend it is changing rather than asking it to judge the change from the diff alone.

Build the encore-docker template once with Docker, the Encore CLI, and the application dependencies installed and give it enough CPU and memory to run Docker workloads comfortably. New sandboxes can start from that common base, while the work and local infrastructure for each issue remain isolated.

Read about Encore's application model to see how the same infrastructure declarations work across local development and deployment.