Why I Built E2BGateway: Solving AI Agent Sandbox Vendor Lock-in

A developer built E2BGateway, an open-source gateway that allows AI agents to use the official E2B SDK with any sandbox backend, avoiding vendor lock-in. The gateway supports multiple backends including E2B Cloud, Kubernetes-native agent-sandbox, and container-based OpenSandbox, requiring only a one-line change to the E2B_API_URL environment variable.

If you're building AI agents that execute code, you've probably heard of E2B https://e2b.dev . 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: Your code is now tied to E2B Cloud 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: Before E2B Cloud only os.environ "E2B API URL" = "https://api.e2b.dev" After any backend os.environ "E2B API URL" = "https://your-gateway.example.com" Same code works everywhere 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: Development environment os.environ "E2B API URL" = "https://dev-gateway.internal.com" Production environment 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. Deploy on your Kubernetes cluster helm install e2bgateway ./deploy/helm/e2bgateway All sandboxes run on your infrastructure No data leaves your network Problem : Different tenants need different sandbox backends. Solution : Use E2BGateway's routing rules to route tenants to appropriate backends. e2bgateway.yaml 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. Clone the repository git clone https://github.com/e2bgateway/e2bgateway.git cd e2bgateway Build make build Run locally make run Create a config file: config.yaml 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 Point to your gateway os.environ "E2B API URL" = "http://localhost:8080" os.environ "E2B API KEY" = "your-gateway-api-key" Use E2B SDK as normal 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 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 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 https://github.com/e2bgateway/e2bgateway Series : Optional - if you plan to write more articles about E2BGateway