E2B: Sandboxes für KI-generierten Code, zwischen SDK und selbst gehosteter Infrastruktur
Open-source, secure environment with real-world tools for enterprise-grade agents.
Auf einen Blick
- Was ist das?
- E2B startet isolierte Cloud-Sandboxes, in denen Agenten Shell-Befehle, Python-Code oder eine Desktop-Sitzung ausführen. Das Repository liefert die SDKs, die eigentliche Infrastruktur liegt in einem separaten Repository und wird per Terraform ausgerollt.
- Für wen ist es gedacht?
- Einsetzen sollten E2B Teams, die LLM-Ausgaben ausführen müssen und dafür keine eigene Isolationsschicht bauen wollen; das Python-SDK (pip install e2b) und der Code Interpreter (pip install e2b-code-interpreter) sind der kürzeste Weg dorthin. Wer Azure oder generische Linux-Maschinen als Ziel hat, sollte nicht mit dem Self-Hosting beginnen, denn die README nennt beide ausdrücklich als nicht unterstützt.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem E2B löst und für wen es gedacht ist
Ein Agent, der Code schreibt, muss diesen Code irgendwo ausführen. Auf dem Host des Anwendungsentwicklers ist das keine Option, sobald das Modell Dateien löscht, Pakete nachlädt oder in einer Endlosschleife Rechenzeit verbrennt. E2B adressiert genau diesen Schritt: Es startet pro Aufgabe eine isolierte Umgebung in der Cloud und gibt dem aufrufenden Programm eine API, mit der es Befehle absetzt, Code ausführt oder eine Desktop-Sitzung steuert. Die README beschreibt das Projekt als Infrastruktur, die KI-generierten Code in sicheren Sandboxes ausführt.
Die Zielgruppe ist damit enger, als die Themenliste des Repositories vermuten lässt. Wer einen Chatbot baut, der nur Text zurückgibt, braucht kein E2B. Wer dagegen einen Code-Interpreter, einen Copilot mit Dateizugriff oder einen Agenten plant, der Browser öffnet und Screenshots macht, findet hier fertige SDKs statt einer selbstgebauten Container-Orchestrierung. Die drei Pakete spiegeln drei Anwendungsfälle: reine Shell- und Dateiarbeit, Ausführung von Code mit Rückgabe des Ergebnisses, und Interaktion mit einer grafischen Oberfläche.
Drei SDKs, ein Sandbox-Modell
Das Basispaket e2b exportiert eine Klasse Sandbox. Der Aufruf Sandbox.create() liefert ein Objekt, dessen Methode commands.run() einen Befehl ausführt und dessen Ergebnis über result.stdout gelesen wird. In Python ist Sandbox als Kontextmanager verwendbar (with Sandbox.create() as sandbox), in TypeScript wird das Objekt direkt gehalten. Das ist die gesamte sichtbare Abstraktion: kein Dockerfile im Anwendungscode, kein SSH, keine Portfreigabe.
Für Code-Ausführung kommt ein zweites Paket hinzu, @e2b/code-interpreter beziehungsweise e2b-code-interpreter. Hier heißt die Methode runCode() (Python: run_code()) und liefert ein Objekt, dessen text-Feld das Ergebnis enthält. Das Beispiel in der README führt x = 1; x += 1; x aus und gibt 2 aus. Der Unterschied zum Shell-Weg ist nicht kosmetisch: Der Code Interpreter hält einen Zustand über mehrere Aufrufe, was für mehrstufige Agenten relevant ist, die eine Variable in einem Schritt setzen und im nächsten weiterverwenden.
Das dritte Paket, @e2b/desktop oder e2b-desktop, erweitert die Sandbox um Maus, Tastatur, Screenshot, Anwendungsstart und Desktop-Streaming. Das README-Beispiel startet google-chrome und ruft anschließend screenshot() auf. Damit deckt E2B Computer-Use-Szenarien ab, in denen der Agent nicht über eine API, sondern über die Oberfläche einer Anwendung arbeitet. Wer nur rechnen lässt, braucht dieses Paket nicht, und die zusätzliche Abhängigkeit vergrößert die Angriffsfläche der eigenen Installation.
Vom API-Key zur laufenden Sandbox
Der Einstieg ist kurz. Für JavaScript lautet der Installationsbefehl npm i e2b, für Python pip install e2b. Danach wird ein API-Key benötigt, den die README über die Anmeldung auf e2b.dev und das Dashboard bezieht. Der Key gehört in die Umgebungsvariable E2B_API_KEY mit dem Präfix e2b_.
Das minimale Python-Beispiel aus der README lautet: from e2b import Sandbox, dann with Sandbox.create() as sandbox, darin sandbox.commands.run('echo "Hello from E2B!"') und die Ausgabe über print(result.stdout). Die JavaScript-Variante ist bis auf die fehlende Kontextverwaltung identisch. Wer Code ausführen will, installiert zusätzlich pip install e2b-code-interpreter und importiert Sandbox aus @e2b/code-interpreter statt aus e2b. Das ist eine Stolperstelle: Beide Pakete exportieren einen Namen Sandbox, und ein falscher Import führt dazu, dass runCode() nicht existiert. Die Desktop-Variante folgt demselben Muster mit pip install e2b-desktop.
Bemerkenswert ist, was in diesem Ablauf fehlt. Es gibt keinen Konfigurationsschritt für eine Region, keine Angabe zu Ressourcengrenzen und kein Timeout im gezeigten Beispiel. Die README verweist für alles Weitere auf die Dokumentation unter docs.e2b.dev. Wer wissen muss, wie lange eine Sandbox ohne Aktivität lebt oder wie viel Speicher sie bekommt, findet diese Angaben nicht im Repository, sondern muss die Dokumentationsseite aufrufen.
Self-Hosting: Terraform, zwei Clouds und zwei offene Lücken
Der wichtigste Absatz der README steht am Ende. E2B lässt sich selbst betreiben, und die Anleitung dafür liegt nicht in diesem Repository, sondern in e2b-dev/infra unter self-host.md. Ausgerollt wird mit Terraform. Als unterstützte Cloud-Anbieter nennt die README AWS und Google Cloud (GCP); Azure und eine allgemeine Linux-Maschine sind in der Liste ausdrücklich nicht abgehakt.
Das ist eine harte Einschränkung, keine Randnotiz. Wer in einer Azure-Umgebung arbeitet oder eigene Hardware betreibt, kann die Infrastruktur nach dem Stand der README nicht ohne Weiteres selbst betreiben. Auch die Trennung der Repositories ist praktisch relevant: Dieses Repository enthält die SDKs, die gegen eine API sprechen. Die Sandbox-Steuerung selbst liegt woanders. Ein Fehlerbericht über das Verhalten einer Sandbox gehört damit möglicherweise nicht in dieses Repository, und ein Beitrag zur Isolationsschicht erfordert einen Wechsel in e2b-dev/infra.
Der Lizenzhinweis ist Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Weitergabe des Lizenztextes und der Urheberrechtshinweise sowie eine Kennzeichnung geänderter Dateien. Wer die Infrastruktur forkt und als eigenen Dienst betreibt, sollte die Bedingungen im Detail prüfen. Eine rechtliche Bewertung kann dieser Artikel nicht liefern.
Wann E2B das falsche Werkzeug ist
Der naheliegende Fehler ist, E2B als allgemeine Container-Plattform zu behandeln. Es ist keine. Die API ist auf einen Agenten zugeschnitten, der eine Sandbox startet, etwas ausführt und sie wieder verwirft. Für lang laufende Dienste, Datenbanken oder Netzwerkdienste, die dauerhaft erreichbar sein müssen, ist das Modell nicht gedacht, und die README zeigt keinen Weg, eine Sandbox als dauerhaften Host zu betreiben.
Ein zweiter Grenzfall ist die Abhängigkeit von der gehosteten Steuerungsebene. Der schnellste Weg zu einer laufenden Sandbox führt über einen API-Key von e2b.dev. Das bedeutet, dass der eigene Agent ohne diesen Dienst nicht funktioniert. Wer Daten nicht aus der eigenen Umgebung geben darf, muss den Self-Hosting-Weg gehen, und der ist laut README auf AWS und GCP beschränkt. Zwischen diesen beiden Polen gibt es keinen dokumentierten Mittelweg.
Drittens: Der Nutzen der Isolation hängt davon ab, was in der Sandbox erreichbar ist. Die README beschreibt Sicherheit und Isolation als Eigenschaft des Systems, ohne Mechanismen zu nennen. Ob Netzwerkzugriff standardmäßig erlaubt ist, ob ausgehende Verbindungen gefiltert werden und wie Dateien zwischen Sandbox und Host ausgetauscht werden, lässt sich aus dem vorliegenden Material nicht beantworten. Wer eine belastbare Aussage zur Isolation braucht, muss die Dokumentation lesen und nicht die README.
Der Vergleich mit selbstgebauten Containern
Die realistische Alternative ist kein anderes Produkt, sondern der Eigenbau: Docker oder eine vergleichbare Laufzeit plus eine Bibliothek, die Container startet, Befehle absetzt und Ressourcen begrenzt. Der Unterschied liegt im Umfang der Abstraktion. Beim Eigenbau kontrolliert man das Image, das Netzwerk und die Lebensdauer selbst und kann die Umgebung exakt an die eigene Compliance-Vorgabe anpassen. Man schreibt dafür Start- und Aufräumlogik, behandelt Fehler beim Containerstart, kümmert sich um das Zurücksetzen des Zustands zwischen Aufgaben und baut die Ausführung von Code, die E2B über runCode() bereits mitliefert.
E2B tauscht diese Arbeit gegen eine feste Schnittstelle. Der Gewinn ist am größten, wenn mehrere Sprachen im Spiel sind, weil es für Python und JavaScript SDKs gibt, und wenn die Ausführung von Code mit Zustand gebraucht wird. Der Verlust zeigt sich, wenn die eigene Umgebung von der Vorgabe abweicht: Eigene Images, ungewöhnliche Ports oder eine Netzwerktopologie, die nicht der Annahme des Systems entspricht, lassen sich nicht durch einen Parameter im gezeigten Beispiel erledigen. Wer bereits eine funktionierende Container-Plattform im Haus hat, sollte den Wechsel zu E2B nur dann erwägen, wenn der Code-Interpreter oder die Desktop-Steuerung einen konkreten Aufwand erspart.
Wartung, Releases und was das für den Betrieb bedeutet
Die Release-Historie im vorliegenden Material zeigt mehrere Veröffentlichungen am selben Tag: e2b@2.49.0 und @e2b/python-sdk@2.49.0 am 2026-09-09, dazu e2b@2.48.0 am selben Datum. Die Versionsnummern von npm-Paket und Python-SDK laufen parallel, was die Zuordnung erleichtert. Die Pakete tragen das Präfix 2.x, und die README-Beispiele verwenden keine Versionsangabe. Wer in einer Produktionsumgebung arbeitet, sollte die Version pinnen, weil ein Sprung innerhalb der 2er-Reihe die Signatur von runCode() oder das Verhalten von commands.run() verändern kann.
Die Wartungslast liegt bei diesem Modell nicht nur im eigenen Code. Ändert sich die gehostete API, muss der Agent angepasst werden; betreibt man die Infrastruktur selbst, kommt die Pflege der Terraform-Konfiguration und der Sandbox-Images hinzu. Das Repository ist nicht archiviert und wird aktiv gepusht, was auf fortlaufende Arbeit hindeutet, aber keine Aussage über Stabilität der Schnittstellen erlaubt. Für die Lizenz gilt: Apache-2.0 verlangt die Beibehaltung der Hinweise, wenn Code weitergegeben wird. Wer die SDKs nur einbindet, hat damit wenig Berührungspunkte; wer die Infrastruktur forkt und verändert, muss die geänderten Dateien kennzeichnen.
Redaktionelles Fazit
Einsetzen sollten E2B Teams, die LLM-Ausgaben ausführen müssen und dafür keine eigene Isolationsschicht bauen wollen; das Python-SDK (pip install e2b) und der Code Interpreter (pip install e2b-code-interpreter) sind der kürzeste Weg dorthin. Wer Azure oder generische Linux-Maschinen als Ziel hat, sollte nicht mit dem Self-Hosting beginnen, denn die README nennt beide ausdrücklich als nicht unterstützt. Vor jedem Produktiveinsatz ist zu klären, ob das eigene Lastprofil ohne die gehostete Steuerungsebene auskommt, denn die self-host.md liegt im Repository e2b-dev/infra und nicht in diesem Repository.
Community-Notizen