Hobby ist kostenlos und enthält ein einmaliges Guthaben von 100 $ sowie eine Stunde Grenze für die durchgehende Laufzeit. Pro kostet 150 $ im Monat zusätzlich zur Nutzung, mit 24 Stunden Grenze und 100 gleichzeitigen Sandboxes inklusive, mit Add-ons bis 1.100. Die Nutzung kostet 0,000014 $ pro vCPU-Sekunde und 0,0000045 $ pro GiB-Sekunde, und pausierte oder beendete Sandboxes werden nicht berechnet.

Kann ich Daten in der EU halten?

Ja, ab Pro und nach einer Anfrage beim Support. Der EU-Cluster läuft in der Google-Cloud-Region europe-west1, Hobby-Sandboxes laufen in den USA. Die Doku sagt, wo Sandboxes laufen, aber keine der Seiten, die ich gelesen habe, nennt eine Region für Snapshots und Logs des EU-Clusters. Frag das deshalb schriftlich nach.

Kann ich E2B selbst hosten?

Ja, mit E2B Embed, einem Paket unter Apache-2.0, das den gesamten Stack auf einer Linux-Maschine mit KVM betreibt und sich mit Docker Compose, Terraform oder Kubernetes installieren lässt. Es ist ein Produkt für eine Maschine. Die Embed-README nennt drei andere Wege, E2B zu betreiben, wenn du mehr brauchst: eine Private Cloud, BYOC und E2B Cloud.

Unterstützt E2B GPU-Workloads?

Nein. E2B-Sandboxes laufen nur auf CPU und werden nach vCPU und RAM dimensioniert. Es gibt keine GPU-Option in den SDKs, der CLI, der API oder einer Template-Definition.

E2B-Test: microVM-Sandboxes für Agenten-Code

E2B ist ein gehosteter Dienst, der Code für KI-Agenten in einer isolierten Linux-Sandbox ausführt, eine pro Lauf, mit SDKs für Python und JavaScript, um diese Sandboxes zu erstellen, zu steuern, zu pausieren und zu beenden. Nimm ihn, wenn dein Produkt Code ausführt, den ein Modell geschrieben hat, und du keinen microVM-Host selbst betreiben willst. Lass ihn, wenn du eine GPU brauchst oder die Daten dein eigenes Netz nie verlassen dürfen – dann ist E2B Embed auf einem eigenen Server die ehrliche Antwort. Gegenüber Docker in Eigenregie bekommst du eine stärkere Grenze und deutlich weniger Betriebsaufwand, und gegenüber Modal oder Daytona liegt der echte Unterschied im Sandbox-Modell, nicht im Zähler. Für die Sicherheitsseite ist die Checkliste für Agenten-Sandboxes der richtige Startpunkt.

Was es ist

E2B stellt Sandboxes bereit: isolierte Linux-virtuelle Maschinen, in denen ein Agent Code ausführen, Daten verarbeiten und Werkzeuge aufrufen kann. Die Vertragspartnerin ist FoundryLabs, Inc., eine Delaware-Corporation, und der verwaltete Dienst läuft auf Google Cloud.

Eine Firecracker-microVM pro Sandbox. Jede Sandbox ist eine Firecracker-microVM, kein Container. Sie startet einen eigenen Kernel, und der Hypervisor trennt sie von anderen Sandboxes und vom Host. E2B-Sandboxes laufen auf einem LTS-Kernel 6.1, und Templates, die am 27. November 2025 oder später gebaut wurden, laufen mit 6.1.158.
Zwei SDK-Familien. Installiere e2b-code-interpreter für Python oder @e2b/code-interpreter für JavaScript, wenn du Code ausführen willst, oder e2b (pip oder npm) für das Sandbox-SDK selbst. Das E2B-SDK-Repository steht unter Apache-2.0.
Nur CPU. Sandboxes werden nach vCPU und RAM dimensioniert. Es gibt keine GPU-Option in den SDKs, der CLI, der API oder einer Template-Definition.
Drei Regionen. US (us-west1) ist bei jedem Tarif der Standard. EU (europe-west1) und APAC (asia-southeast1) brauchen den Pro-Tarif oder höher und eine Anfrage beim Support.
Compliance-Unterlagen. E2B hat einen SOC-2-Type-II-Bericht. Der Bericht, eine DPA-Vorlage und ein Penetrationstest werden über das Zugangsformular des Trust Centers angefordert.

So funktioniert es

Der Code des Agenten läuft nie in deinem Prozess. Das SDK ruft die E2B-API auf, die eine Sandbox auf einem Knoten startet oder eine pausierte fortsetzt. Ausgaben, Fehler und Dateien kommen zum Aufrufer zurück. Der Teil, der E2B mehr als einen Container-Host macht, liegt darunter: Eine Pause sichert Speicher und Dateisystem der Sandbox als Snapshot, damit die nächste Fortsetzung denselben Prozess weiterlaufen lässt.

Jeder Lauf bekommt seine eigene microVM. Eine Pause sichert Speicher und Festplatte, und eine Fortsetzung führt denselben Prozess weiter.

Erste Schritte

Setze E2B_API_KEY in der Umgebung, installiere e2b-code-interpreter und führe dieses Skript aus. Es führt ein Snippet aus, gibt die Ausgabe aus und beendet die Sandbox in einem finally-Block, damit ein Fehler keine Sandbox bis zum Timeout abrechnen lässt.

from e2b_code_interpreter import Sandbox

sbx = Sandbox.create(timeout=300)  # seconds; the default is 5 minutes
try:
    execution = sbx.run_code('print(sum([3, 5, 8]) / 3)')
    print(execution.logs)
finally:
    sbx.kill()                     # billing stops now, not at the timeout

Das Timeout ist in Sekunden in Python und als timeoutMs in Millisekunden in JavaScript angegeben. Ohne Angabe lebt eine Sandbox fünf Minuten, und nach Ablauf wird sie standardmäßig beendet, nicht pausiert. Das Execution-Objekt enthält die Logs und den Wert des letzten Ausdrucks, und genau das liest ein Agent, bevor er den nächsten Schritt geht.

Pause, Fortsetzung und Templates

Der Lebenszyklus unterscheidet E2B von einem Container-Host. Eine Sandbox hat ein Timeout, standardmäßig fünf Minuten, und die Standardaktion nach Ablauf ist beenden. Setze innerhalb von lifecycle onTimeout auf pause, damit Dateisystem und Speicher erhalten bleiben (on_timeout in Python), und autoResume, damit die Sandbox beim nächsten SDK-Aufruf oder HTTP-Request wieder aufwacht (auto_resume in Python). Die automatische Pause bleibt bestehen: Eine Sandbox, die wieder aufwacht und erneut ausläuft, pausiert erneut.

Pausieren sichert alles, was läuft. Dateien, laufende Prozesse und geladene Variablen bleiben erhalten. Eine Pause dauert etwa vier Sekunden pro GiB RAM, eine Fortsetzung etwa eine Sekunde.
Eine pausierte Sandbox läuft nie ab. E2B behält sie unbegrenzt und löscht sie nicht von selbst. Sie wird nicht für Rechenzeit abgerechnet und zählt nicht zur Grenze für gleichzeitige Sandboxes. Nur ein Beenden entfernt sie.
Eine Pause setzt die Laufzeituhr zurück. Die Grenze für durchgehende Laufzeit liegt bei einer Stunde im Hobby-Tarif und bei 24 Stunden im Pro-Tarif. Pause und Fortsetzung starten das Fenster neu, so behält ein langlebiger Agent dieselbe Sandbox.
Netzwerkverbindungen überleben eine Pause nicht. Ein Server in der Sandbox ist während der Pause nicht erreichbar, und Clients müssen sich nach der Fortsetzung neu verbinden.
Pause nur für das Dateisystem. Mit mode='filesystem' wird nur die Festplatte gesichert. Die nächste Fortsetzung startet die Sandbox neu, und der Speicherzustand ist verloren. Das passt, wenn der Zustand in Dateien liegt.

Templates sind die andere Hälfte. Ein Template ist eine Sandbox-Definition im Code: Basis-Image, Pakete, Umgebungsvariablen, Dateien und ein Startbefehl. E2B baut sie einmal zu einem Snapshot. Der Startbefehl läuft beim Build und wird mitgespeichert, daher läuft der Prozess schon, wenn aus dem Template eine Sandbox entsteht. Laut Doku lädt ein gespeicherter Sandbox-Zustand in etwa 80 ms, und Templates starten schneller als Snapshots, weil das Gast-Betriebssystem neu startet, bevor der langlebige Prozess erfasst wird.

from e2b import Template, default_build_logger, wait_for_timeout

template = (
    Template()
    .from_base_image()
    .pip_install(['pandas', 'matplotlib'])
    .set_envs({'REPORT_DIR': '/home/user/reports'})
    .set_start_cmd('python -m http.server 8000', wait_for_timeout(5_000))
)

Template.build(
    template,
    'analytics-v1',
    cpu_count=2,
    memory_mb=1024,
    on_build_logs=default_build_logger(),
)

Eine Sandbox startest du mit Sandbox(template='analytics-v1') in Python oder Sandbox.create('analytics-v1') in JavaScript. Builds können bis zu eine Stunde laufen, im Hobby- und im Pro-Tarif sind 20 gleichzeitig möglich, und die Anzahl der Templates ist nicht begrenzt. E2B sagt, dass Speicher für Templates später Geld kosten könnte. Frag also nach, bevor du hunderte kundenspezifische Templates baust.

Code Interpreter und Kontrollen

Der Code Interpreter ist der Anwendungsfall, für den E2B gebaut ist. run_code führt Code in der Sandbox aus und gibt eine Execution zurück. Code-Kontexte erlauben es, mehrere Ausführungen gleichzeitig in einer Sandbox laufen zu lassen, jede in ihrem eigenen Kontext. Die Sicherheit ist die zweite Hälfte. Der Internetzugang ist standardmäßig an, also übergib allow_internet_access=False für Code, der nie nach außen darf, oder schränke ihn mit Allow- und Deny-Listen ein. API-Schlüssel speicherst du als Secret: Der Egress-Proxy ergänzt den Wert bei passenden ausgehenden HTTPS-Requests, und die Sandbox hält nur einen Verweis. Gilt auch hier E2Bs eigene Warnung: Gib Zugangsdaten nur an Ziele weiter, denen du vertraust, denn das Ziel erhält den Wert und könnte ihn in seiner Antwort an die Sandbox weitergeben. Das Bedrohungsmodell dahinter steht in Prompt-Injection-Muster.

Kosten und Betrieb

Der Preis wird pro Sekunde für die vCPUs und den RAM berechnet, die einer Sandbox zugewiesen sind, nicht für das, was sie tatsächlich nutzt. Die aktuellen Sätze sind 0,000014 $ pro vCPU-Sekunde (0,0504 $ pro Stunde) und 0,0000045 $ pro GiB-Sekunde (0,0162 $ pro GiB-Stunde). Die Festplatte ist inbegriffen, pausierte oder beendete Sandboxes werden nicht berechnet. Die FAQ sagt, dass die Sätze der Übersicht halber angegeben sind und sich ändern können, und nennt die Preisseite als maßgebliche Quelle. Prüfe also beide am Tag des Kaufs.

Merkmal	Hobby	Pro	Enterprise
Grundpreis	0 $ im Monat	150 $ im Monat	Individuell
Gratisguthaben	100 $, einmalig	Kein Zusatzguthaben beim Upgrade	Individuell
Max. vCPU und RAM	8 vCPU, 8 GiB	8 oder mehr, auf Anfrage	Individuell
Max. durchgehende Laufzeit	1 Stunde	24 Stunden	Individuell
Gleichzeitige Sandboxes	20	100, mit Add-ons bis 1.100	1.100 oder mehr
Startrate für Sandboxes	1 pro Sekunde	5 pro Sekunde	Individuell
EU-Region	Nein	Ja, auf Anfrage	Ja

Entscheidend ist die Rechnung: Läufe pro Tag mal Sekunden pro Lauf. Die Standard-Sandbox hat 2 vCPU und 512 MiB, sie kostet etwa 0,109 $ pro Stunde oder 0,0027 $ für einen 90-Sekunden-Lauf. Tausend solche Läufe am Tag ergeben etwa 2,72 $ pro Tag, also ungefähr 82 $ im Monat, vor der Pro-Gebühr von 150 $, die du für EU-Hosting oder für mehr als 20 gleichzeitige Sandboxes brauchst.

Zu Listenpreisen ist E2B nicht das günstigste Rechenangebot. Modal rechnet pro physischem Kern, den es mit zwei vCPU-Äquivalenten beschreibt, mit 0,00003942 $ pro Kernsekunde und 0,00000222 $ pro GiB-Sekunde. Zählt man einen Kern als zwei vCPUs, kostet dieselbe Standard-Sandbox dort etwa 0,146 $ pro Stunde, und Modal rechnet zusätzlich GPU-Zeit ab. Die Preisseite von Daytona nennt 0,0504 $ pro vCPU-Stunde und 0,0162 $ pro GiB-Stunde, dieselben Sätze wie bei E2B. Die Wahl zwischen den dreien hängt also am Sandbox-Modell, an den Regionen und am Papierkram.

Self-Hosting ist E2B Embed, ein Paket unter Apache-2.0 im Runtime-Repository, das der Changelog am 14. September 2026 angekündigt hat. Es betreibt den gesamten E2B-Stack auf einer Maschine: die Control Plane, die Sandboxes, den Speicher für Templates und Snapshots sowie die Telemetrie. Du installierst es mit Docker Compose auf einem Linux-Host, den du besitzt, mit Terraform für eine VM bei Google Cloud, AWS oder Azure oder auf einem Knoten eines Kubernetes-Clusters. Alles bleibt auf einer Maschine, und da jedes Image und jede Binärdatei, die der Stack lädt, öffentlich ist, braucht er weder einen E2B-Account noch ein Token. Der Aufwand ist trotzdem real.

Linux mit KVM. Embed braucht Linux auf x86-64 oder arm64 mit KVM, oder eine VM mit aktivierter verschachtelter Virtualisierung. Ubuntu 24.04 ist der empfohlene Host, mit Kernel 6.8 oder neuer auf x86-64.
Dimensionierung. E2B empfiehlt 12 GiB RAM und 20 GiB freien Speicherplatz. Eine Pause braucht freien Platz in der Größe des Sandbox-Speichers plus 1 GiB Reserve, und die Anleitung nennt für den Stack etwa zwei Minuten auf einer VM mit 8 vCPU und 32 GiB, kleinere Hosts brauchen länger.
Betrieb. Der Knoten betreibt Redis und ClickHouse, dazu Datenbanken, die das Setup migriert und befüllt. Backups, Updates, Monitoring und der KVM-Host gehören dir.
Klartext-HTTP. Embed antwortet ohne eigenes TLS, daher gehört es in dein Netz, hinter deinen eigenen Proxy.
Eine Maschine. Embed ist bewusst eine Maschine. Brauchst du mehr, nennt die README drei andere Wege, E2B zu betreiben: eine Private Cloud, BYOC und E2B Cloud.

Für ein EU-Unternehmen hat die Datenfrage vier Teile, und die öffentliche Doku beantwortet nur einige davon. Den größeren DSGVO-Rahmen für Modell-APIs findest du in DSGVO und Datenresidenz bei LLM-APIs.

Wo Sandboxes laufen. Bei Google Cloud: europe-west1 für EU-Kunden ab Pro, und us-west1 für alle im Hobby-Tarif, wo keine EU-Wahl angeboten wird.
Wo der Rest liegt. Die Sicherheits-FAQ sagt, dass der Speicher der Standardverschlüsselung ruhender Daten von Google Cloud folgt und E2B keine eigene Verschlüsselungsschicht ergänzt. Der BYOC-Vergleich sagt, dass Templates, Snapshots und Runtime-Logs im verwalteten Tarif in E2B Cloud liegen. Keine der Seiten, die ich gelesen habe, nennt aber eine Region für Snapshots und Logs des EU-Clusters.
Der Papierkram. Die DPA-Vorlage, der SOC-2-Bericht und der Penetrationstest werden über das Zugangsformular des Trust Centers angefordert. Ein unterschriebener DPA und Änderungen an den Standardbedingungen laufen über den Support, und so auch die Liste der Unterauftragsverarbeiter. Artikel 28 DSGVO verlangt einen Auftragsverarbeitungsvertrag und die vorherige gesonderte oder allgemeine schriftliche Genehmigung der Unterauftragsverarbeiter. Die Liste ist also Pflicht, nicht optional.
Übermittlungen. Die Vertragspartnerin von E2B ist eine Delaware-Corporation. Wenn Support oder Entwickler außerhalb der EU auf personenbezogene Daten zugreifen können, brauchst du einen Übermittlungsmechanismus nach Artikel 46 DSGVO, meist die Standardvertragsklauseln im Auftragsverarbeitungsvertrag.

Wo es zu kurz greift

Leerlauf wird berechnet. Eine laufende Sandbox wird abgerechnet, ob gerade Code läuft oder nicht. Setze Timeouts und automatische Pausen bewusst, und nutze Lifecycle-Webhooks, die die Ausführungszeit beendeter und pausierter Läufe mitliefern.
Ratenlimits und Startgeschwindigkeit. Listen-Endpunkte erlauben 10 Anfragen pro Sekunde im Hobby-Tarif und 20 im Pro-Tarif, jeweils pro Endpunkt und Projekt. Gestartet werden im Hobby-Tarif eine Sandbox pro Sekunde und im Pro-Tarif fünf, und das begrenzt, wie schnell ein Fan-out anlaufen kann. Anfragen über dem Limit kommen mit 429 und einem Retry-After-Header zurück, und SDK 2.49.1 und neuer wiederholen automatisch.
Eine Pause kann abgelehnt werden. Der Knoten, auf dem die Sandbox läuft, schreibt unter Umständen noch den vorherigen Snapshot derselben Sandbox. Wo E2B die Änderung aktiviert hat, lautet die Antwort HTTP 503, und die Sandbox läuft mit intaktem Zustand weiter. Anderswo schlägt die Pause mit HTTP 500 fehl, bis die Ausrollung die Region erreicht, und E2B rollt sie Region für Region aus. Das JavaScript-SDK wirft ServiceBusyError, das Python-SDK ServiceBusyException, dein Code muss also erneut versuchen.
Keine feste Egress-Adresse. Ausgehender Verkehr verlässt das Netz über wechselnde öffentliche IPs, und E2B veröffentlicht keinen Adressbereich, auch nicht im Enterprise-Tarif. Eine Allow-Liste auf der Gegenseite hat nichts Stabiles, womit sie abgleichen könnte, also brauchst du einen Proxy unter deiner Kontrolle mit fester Adresse.
Volumes sind eine Private Beta. Volumes überleben Sandboxes, aber Dateisperren können hängen, Mounts sind beim Erstellen festgelegt, Snapshots werden nicht unterstützt, und Volumes gibt es nur in den USA und der EU.
Das SDK ändert sich schnell. E2B akzeptiert seit dem 1. August 2026 keine Access-Tokens mehr, älterer Code muss also mit E2B_API_KEY authentifizieren. Der Changelog erscheint wöchentlich, deshalb solltest du SDK- und CLI-Versionen in der Produktion festlegen.

Fazit

Nimm E2B, wenn dein Produkt Code, den ein Modell geschrieben hat, als Funktion ausführt, du eine microVM pro Lauf willst, ohne einen Hypervisor zu betreiben, und Pause und Fortsetzung mit Speicher brauchst statt nur Neustarts. Es ist das falsche Werkzeug für GPU-Arbeit, für ein Skript, das einmal am Tag läuft, und für Daten, die auf eigenen Maschinen bleiben müssen, es sei denn, ein Embed-Knoten reicht. Fang im Hobby-Tarif an, um das SDK und das Pausenmodell kennenzulernen, und wechsle in den Pro-Tarif, bevor personenbezogene Daten in eine Sandbox gelangen. Für die breitere Designfrage ist die Checkliste für Agenten-Sandboxes das Dokument, das ich zuerst durchgehen würde.

Option	Isolation	Ca. $ pro Stunde, 2 vCPU und 512 MiB	EU-Option
E2B	Firecracker-microVM mit eigenem Kernel	0,109 $ zu den Nutzungspreisen	Gemeinsamer EU-Cluster, ab Pro
Modal	gVisor oder eine VM-Laufzeit mit eigenem Kernel	0,146 $, wenn ein Kern als zwei vCPUs zählt	Ein EU-Regionscode in der Regionsdoku, für Sandboxes nicht bestätigt
Daytona	Dedizierter Kernel pro Sandbox, laut Doku	0,109 $ zu denselben Stundensätzen	Gemeinsame Region Europa (eu)
Docker auf eigenen Hosts	Kernel-Namespaces und cgroups auf dem Host-Kernel	Dein VM-Preis plus deine Zeit	Was du selbst baust

Modal, wenn dein Team dort ohnehin Python-Batchjobs und GPU-Arbeit betreibt. Die Sandboxes laufen auf gVisor oder einer VM-Laufzeit mit eigenem Kernel, die Standard-Maximallaufzeit beträgt fünf Minuten, die sich mit einem Timeout von bis zu 24 Stunden erhöhen lässt.
Daytona, wenn du Sandboxes in einer gemeinsamen Region Europa willst und die Startzeit unter 90 ms mit deiner eigenen Last messen möchtest. Die Doku beschreibt einen dedizierten Kernel pro Sandbox.
Docker auf eigenen Hosts, wenn du wenige Agentenjobs am Tag auf einer VM laufen lässt, die du schon betreibst, und der Code dir gehört. Die Sicherheitsdoku von Docker baut die Grenze aus Kernel-Namespaces, cgroups und Capabilities auf, und für Code, den ein Modell geschrieben hat, würde ich mich darauf allein nicht verlassen.

E2B-Test: Firecracker-Sandboxes für Agenten-Code, nach Sekunden abgerechnet

Das Wichtigste in Kürze