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

jiang dong — Wed, 29 Jul 2026 04:19:35 +0000

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

Client Request: E2B SDK sends request to gateway
Authentication: Gateway validates API key/JWT
Rate Limiting: Check request against rate limits
Routing: Select backend based on config/rules
Translation: Convert E2B protocol to backend API
Execution: Forward to selected backend
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)

DEV Community: jiang dong

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

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

Introduction

The Problem: Sandbox Vendor Lock-in

The Solution: E2BGateway

Key Features

1. Multi-Backend Support

2. Zero-Code Migration

3. Production-Ready Features

4. Full API Compatibility

Architecture Deep Dive

Core Components

Request Flow

Why Go?

Real-World Use Cases

Use Case 1: Cost Optimization

Use Case 2: Data Sovereignty

Use Case 3: Multi-Tenant AI Platform

Getting Started

Prerequisites

Installation

Configuration

Usage

What's Next?

Short Term

Long Term

Contributing

Conclusion

Quick Links

Article Metadata