If you're building AI agents that execute code, you've probably heard of E2B. It's an awesome platform for running AI agent code in secure sandboxes. But there's a catch: you're locked into their cloud.
That was a problem for me. I needed flexibility to run sandboxes on my own Kubernetes cluster, switch between providers, and avoid being tied to a single vendor.
So I built ** E2BGateway** – an open-source gateway that lets you use the official E2B SDK with any sandbox backend.
In this article, I'll share why I built it, how it works, and how it can help you build more flexible AI agent systems.
When building AI agents, you often need to execute code in isolated environments. E2B provides excellent sandbox infrastructure, but integrating with it means:
os.environ["E2B_API_URL"] = "https://api.e2b.dev"
os.environ["E2B_API_KEY"] = "your-e2b-api-key"
from e2b_code_interpreter import Sandbox
sbx = Sandbox.create()
result = sbx.run_code("print('Hello E2B!')")
What if you want to:
You'd have to rewrite your entire codebase to use a different sandbox provider. That's vendor lock-in.
E2BGateway acts as an abstraction layer between your AI agents and sandbox backends:
Your AI Agent Code (E2B SDK)
↓
E2BGateway (you control this)
↓
┌───────────────────────────────────────┐
│ Choose Your Backend: │
│ • E2B Cloud (existing integration) │
│ • agent-sandbox (Kubernetes-native) │
│ • OpenSandbox (container-based) │
└───────────────────────────────────────┘
The magic? Your code doesn't change at all. Just point the E2B SDK at your gateway:
os.environ["E2B_API_URL"] = "https://api.e2b.dev"
os.environ["E2B_API_URL"] = "https://your-gateway.example.com"
from e2b_code_interpreter import Sandbox
sbx = Sandbox.create(template="code-interpreter")
result = sbx.run_code("print('Hello from E2BGateway!')")
sbx.kill()
E2BGateway supports multiple sandbox backends:
| Backend | Type | Use Case |
|---|---|---|
| E2B Cloud | ||
| SaaS | Quick start, managed service | |
| agent-sandbox | ||
| Kubernetes CRD | Self-hosted, K8s-native | |
| OpenSandbox | ||
| Container-based | Lightweight, flexible |
Already using E2B SDK? Migration is literally one line of code:
os.environ["E2B_API_URL"] = "https://your-gateway.com"
That's it. No code changes, no refactoring, no headaches.
Built for production workloads:
Implements the complete E2B REST API:
POST/GET/DELETE /api/v1/sandboxes
)POST /api/v1/sandboxes/{id}/code
)POST /api/v1/sandboxes/{id}/commands
)POST/GET /api/v1/sandboxes/{id}/files/*
)GET/POST/DELETE /api/v1/templates
)Let's dive into how E2BGateway works under the hood.
┌─────────────────────────────────────────┐
│ E2BGateway │
│ │
│ ┌──────────────────────────────────┐ │
│ │ Request Pipeline │ │
│ │ Auth → RateLimit → Router │ │
│ └──────────────┬───────────────────┘ │
│ │ │
│ ┌──────────────▼───────────────────┐ │
│ │ Protocol Translator │ │
│ │ E2B Protocol → Backend API │ │
│ └──────────────┬───────────────────┘ │
│ │ │
│ ┌──────────────▼───────────────────┐ │
│ │ Backend Adapters │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ E2B │ │ K8s │ ... │ │
│ │ └────┬────┘ └────┬────┘ │ │
│ └───────┼─────────────┼───────────┘ │
└──────────┼─────────────┼──────────────┘
│ │
▼ ▼
E2B Cloud Kubernetes Cluster
I chose Go for several reasons:
Problem: E2B Cloud costs are high for development/testing.
Solution: Use E2BGateway to route:
os.environ["E2B_API_URL"] = "https://dev-gateway.internal.com"
os.environ["E2B_API_URL"] = "https://prod-gateway.example.com"
Problem: Sensitive code can't leave your infrastructure.
Solution: Run E2BGateway entirely on-premises with agent-sandbox backend.
helm install e2bgateway ./deploy/helm/e2bgateway
Problem: Different tenants need different sandbox backends.
Solution: Use E2BGateway's routing rules to route tenants to appropriate backends.
routes:
- tenant: enterprise-corp
backend: agent-sandbox # Their own K8s cluster
- tenant: startup-inc
backend: e2b-cloud # Managed service
- tenant: default
backend: opensandbox # Shared infrastructure
Ready to try E2BGateway? Here's how to get started in 5 minutes.
git clone https://github.com/e2bgateway/e2bgateway.git
cd e2bgateway
make build
make run
Create a config file:
server:
port: 8080
backends:
- name: e2b-cloud
type: e2b
config:
api_url: https://api.e2b.dev
api_key: your-e2b-api-key
- name: k8s-sandbox
type: agent-sandbox
config:
kubeconfig: ~/.kube/config
routing:
default_backend: e2b-cloud
python
import os
os.environ["E2B_API_URL"] = "http://localhost:8080"
os.environ["E2B_API_KEY"] = "your-gateway-api-key"
from e2b_code_interpreter import Sandbox
sbx = Sandbox.create(template="code-interpreter")
result = sbx.run_code("""
import pandas as pd
df = pd.DataFrame({'A': [1, 2, 3], 'B': [4, 5, 6]})
print(df.describe())
""")
print(result.text)
sbx.kill()
That's it! You're now running sandboxes through E2BGateway.
I'm just getting started with E2BGateway. Here's what's on the roadmap:
E2BGateway is open source (Apache 2.0) and I'd love your help!
Ways to contribute:
Check out the repo: https://github.com/e2bgateway/e2bgateway
Vendor lock-in is a real problem in the AI agent ecosystem. E2BGateway gives you the flexibility to:
✅ Use the E2B SDK you already know
✅ Choose the sandbox backend that fits your needs
✅ Switch backends without rewriting code
✅ Run sandboxes on your own infrastructure
✅ Optimize costs and maintain data sovereignty
Whether you're building AI agents for production or experimenting with local LLMs, E2BGateway gives you the freedom to choose.
Give it a try: https://github.com/e2bgateway/e2bgateway
Let me know what you think! Drop a comment below or open an issue on GitHub.
P.S. E2BGateway has been submitted to awesome-go (PR #6533), awesome-kubernetes (PR #1130), and awesome-mcp-gateways (PR #67). If you find it useful, consider giving it a star! ⭐
Title: Why I Built E2BGateway: Solving AI Agent Sandbox Vendor Lock-in
Tags:
Cover Image: (Optional - use project logo or architecture diagram)
Canonical URL: https://github.com/e2bgateway/e2bgateway
Series: (Optional - if you plan to write more articles about E2BGateway)