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

Introduction

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.

The Problem: Sandbox Vendor Lock-in

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:

• Run sandboxes on your own Kubernetes cluster?
• Switch to a different provider?
• Use multiple backends for different workloads?
• Avoid cloud costs by using existing infrastructure?

You'd have to rewrite your entire codebase to use a different sandbox provider. That's vendor lock-in.

The Solution: E2BGateway

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()

Key Features

1. Multi-Backend Support

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

2. Zero-Code Migration

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.

3. Production-Ready Features

Built for production workloads:

• ✅ Authentication & Authorization
• ✅ Rate Limiting
• ✅ Audit Logging
• ✅ OpenTelemetry Observability
• ✅ Dynamic Routing & Load Balancing
• ✅ Failover & High Availability

4. Full API Compatibility

Implements the complete E2B REST API:

• Sandbox lifecycle (POST/GET/DELETE /api/v1/sandboxes)
• Code execution (POST /api/v1/sandboxes/{id}/code)
• Shell commands (POST /api/v1/sandboxes/{id}/commands)
• File operations (POST/GET /api/v1/sandboxes/{id}/files/*)
• Template management (GET/POST/DELETE /api/v1/templates)
• WebSocket channels for streaming

Architecture Deep Dive

Let's dive into how E2BGateway works under the hood.

Core Components

┌─────────────────────────────────────────┐
│           E2BGateway                    │
│                                         │
│  ┌──────────────────────────────────┐  │
│  │  Request Pipeline                │  │
│  │  Auth → RateLimit → Router      │  │
│  └──────────────┬───────────────────┘  │
│                 │                       │
│  ┌──────────────▼───────────────────┐  │
│  │  Protocol Translator            │  │
│  │  E2B Protocol → Backend API     │  │
│  └──────────────┬───────────────────┘  │
│                 │                       │
│  ┌──────────────▼───────────────────┐  │
│  │  Backend Adapters               │  │
│  │  ┌─────────┐  ┌─────────┐       │  │
│  │  │ E2B     │  │ K8s     │ ...   │  │
│  │  └────┬────┘  └────┬────┘       │  │
│  └───────┼─────────────┼───────────┘  │
└──────────┼─────────────┼──────────────┘
           │             │
           ▼             ▼
      E2B Cloud    Kubernetes Cluster

Request Flow

1. Client Request: E2B SDK sends request to gateway
2. Authentication: Gateway validates API key/JWT
3. Rate Limiting: Check request against rate limits
4. Routing: Select backend based on config/rules
5. Translation: Convert E2B protocol to backend API
6. Execution: Forward to selected backend
7. Response: Translate and return response

Why Go?

I chose Go for several reasons:

• Performance: Low-latency HTTP handling (critical for gateway)
• Concurrency: Excellent WebSocket support with goroutines
• Kubernetes: Native client-go integration
• Deployment: Single binary, easy to containerize
• Ecosystem: Rich HTTP/routing libraries

Real-World Use Cases

Use Case 1: Cost Optimization

Problem: E2B Cloud costs are high for development/testing.

Solution: Use E2BGateway to route:

• Production traffic → E2B Cloud (managed, reliable)
• Development traffic → Self-hosted Kubernetes (cost-effective)

# Development environment
os.environ["E2B_API_URL"] = "https://dev-gateway.internal.com"

# Production environment
os.environ["E2B_API_URL"] = "https://prod-gateway.example.com"

Use Case 2: Data Sovereignty

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

Use Case 3: Multi-Tenant AI Platform

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

Getting Started

Ready to try E2BGateway? Here's how to get started in 5 minutes.

Prerequisites

• Go 1.21+ (for building from source)
• Docker (for containerized deployment)
• Kubernetes cluster (for agent-sandbox backend)

Installation

# Clone the repository
git clone https://github.com/e2bgateway/e2bgateway.git
cd e2bgateway

# Build
make build

# Run locally
make run

Configuration

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

Usage

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.

What's Next?

I'm just getting started with E2BGateway. Here's what's on the roadmap:

Short Term

• [ ] More backend adapters (Firecracker, gVisor)
• [ ] Enhanced routing rules (by template, by workload)
• [ ] Dashboard for monitoring and management
• [ ] More examples and integrations

Long Term

• [ ] Multi-cluster support
• [ ] Auto-scaling based on sandbox demand
• [ ] Advanced scheduling (GPU sandboxes, etc.)
• [ ] Integration with more AI frameworks

Contributing

E2BGateway is open source (Apache 2.0) and I'd love your help!

Ways to contribute:

• 🐛 Report bugs and issues
• 💡 Suggest new features
• 📝 Improve documentation
• 🔧 Submit pull requests
• 🌟 Star the repo to show support

Check out the repo: https://github.com/e2bgateway/e2bgateway

Conclusion

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.

---

Quick Links

• 📦 GitHub: https://github.com/e2bgateway/e2bgateway
• 📚 Documentation: https://github.com/e2bgateway/e2bgateway/tree/main/docs
• 🏗️ Architecture: https://github.com/e2bgateway/e2bgateway/blob/main/docs/design/README.md
• 🚀 Getting Started: https://github.com/e2bgateway/e2bgateway/blob/main/docs/guides/getting-started.md

---

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! ⭐

---

Article Metadata

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

Tags:

• showdev
• opensource
• golang
• kubernetes
• ai
• artificialintelligence

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)

Comments

[jiang dong]

+1