Grain and E2B: the hub and the runtime

The relationship in one line

E2B is runtime infrastructure and Grain is the artifact hub around the output. A sandbox gives an agent a machine, filesystem and process boundary for a session. A Grain workspace keeps the files the agent produced, publishes them at a durable address, and can add Postgres, logins, scheduled jobs and controlled sharing. In Grain's paid cloud mode, the runtime beneath that workspace is an E2B microVM. Using Grain does not turn E2B into a publishing product, and using E2B directly does not create Grain's workspace, sharing or comment loop.

What each layer owns

When you need both

Use both when an agent-built app needs managed cloud execution and a lasting place for people to use the result. Consider an agent that builds a weekly support report. It reads source files, generates a small app, writes a scheduled refresh job and needs a database for reviewed items. E2B provides the isolated microVM where the cloud workspace runs. Grain provides the workspace identity, published URL, files, Postgres database, schedule, access mode and comments. The runtime can sleep or change while the artifact remains the thing your team recognizes. This is also the default relationship inside Grain's paid cloud workspaces: you work with the Grain surface while E2B supplies the underlying sandbox runtime.

When you need only one

Use E2B directly when you are building an agent platform and need programmable sandbox creation, execution and teardown. You may want to choose session limits, stream process output or build your own storage and publishing layer. In that case, Grain would add an opinionated artifact workflow you may not need. Use Grain without managing E2B when your job starts after a coding agent has made something useful. A local workspace can publish a static page or app without you writing sandbox lifecycle code. Choose this route when the desired result is a URL for teammates, not a sandbox API for developers. Grain is not a general substitute for E2B's SDK, and E2B is not a substitute for a persistent artifact hub.

How it fits together

1. Start with the artifact job. In a project folder, ask your coding agent: Build a support-trends app from the sample tickets. Add a Postgres table for reviewed themes and a weekly refresh job. Keep the interface usable at mobile width. This describes the thing people need, not the infrastructure.
2. Create the workspace. Run grain init. Grain creates a workspace for the current folder and writes MCP configuration to .mcp.json, .codex/config.toml and .cursor/mcp.json. Your configured agent can now use the workspace tools.
3. Let the agent write and test. The agent creates the page and app files. In a paid cloud workspace, the processes run inside the E2B-backed microVM. If you integrate E2B directly instead, your own application creates the sandbox and decides how files leave it.
4. Publish the files. Run grain push to send the current workspace contents. Execution and publication are separate steps: the runtime proves the code can run, while the push establishes what belongs in the workspace.
5. Name a useful state. Run grain checkpoint -m "support report ready for review". The checkpoint gives the team a clear state to discuss before later agent changes.
6. Open access deliberately. Run grain share --public for an open review link, or grain share --password <pw> for password access. Grain returns the share URL. Readers open the artifact rather than the sandbox session.
7. Close the feedback loop. Readers leave comments on the artifact. The agent can read those comments and revise the files in the same workspace, followed by another push and checkpoint.

Frequently asked questions