E2B Fragments: ein Next.js-Gerüst für KI-generierte Apps mit echter Sandbox-Ausführung

Welches Problem Fragments löst und für wen es gedacht ist

Ein Sprachmodell kann Code erzeugen. Es kann ihn nur nicht ausführen. Genau in dieser Lücke sitzt Fragments. Die Vorlage verbindet eine Chat-Oberfläche mit einer Laufzeitumgebung, in der der generierte Code tatsächlich startet, Pakete nachinstalliert und ein Ergebnis zurückliefert. Laut README ist das Projekt eine offene Variante von Anthropics Claude Artifacts, Vercel v0 oder GPT Engineer. Der Anspruch ist also nicht, ein Modell zu verbessern, sondern die Umgebung um das Modell herum bereitzustellen.

Die Zielgruppe lässt sich aus dem Aufbau ablesen. Wer Next.js 14 mit App Router und Server Actions kennt, findet sich in der Struktur zurecht. Wer zusätzlich shadcn/ui und TailwindCSS schon einmal angepasst hat, kann die Oberfläche ohne Einarbeitung verändern. Für reine Anwender ist das Projekt nicht gedacht: Es gibt keine Release-Artefakte, keinen Installer, keinen gehosteten Dienst zum Selbstbetreiben. Man klont das Repository und betreibt es selbst. Die Homepage fragments.e2b.dev dient als Referenz, wie das Ergebnis aussehen kann, nicht als Bezugsweg für eine eigene Instanz.

Sandbox statt Browser: der Ausführungspfad hinter der Oberfläche

Der zentrale Mechanismus ist die Auslagerung der Codeausführung aus dem Next.js-Prozess. Das README nennt das E2B SDK aus dem Repository e2b-dev/code-interpreter als Grundlage und beschreibt den Zweck mit den Worten, es diene dazu, generierten Code sicher auszuführen. Die Sandbox ist damit kein Detail, sondern die Komponente, die das Produkt von einem Chat-Interface unterscheidet.

Die zweite Ebene sind die Personas, intern als Templates geführt. Eine Persona beschreibt eine Umgebung: welche Bibliotheken vorhanden sind, welche Datei als Einstiegspunkt dient, auf welchem Port die Anwendung lauscht und welchen Hinweis das Modell bekommt. Das README führt als unterstützte Stacks einen Python-Interpreter, Next.js, Vue.js, Streamlit und Gradio auf. Jede dieser Umgebungen entsteht aus einem eigenen Container-Image, das über die E2B-CLI gebaut wird. Der Datenfluss ist damit gerichtet: Nutzereingabe geht an das Modell, das Modell erzeugt Dateiinhalte, diese landen in der Sandbox, die Sandbox startet den in e2b.toml hinterlegten Befehl, und das Ergebnis wird gestreamt an die Oberfläche zurückgegeben. Das README nennt Streaming ausdrücklich als Feature.

Für die Bearbeitung bestehender Dateien ist Morph eingeschaltet. Das README beschreibt die Integration als token-effizient, genau und schneller beim Editieren von Code. Das ist eine Herstellerbeschreibung, kein gemessener Wert. Wer die Aussage prüfen will, muss MORPH_API_KEY entfernen und den Unterschied selbst beobachten. Das README sagt, Morph sei standardmäßig aktiv.

Einrichtung: fünf Schritte und eine lange Liste von Schlüsseln

Der Einstieg folgt dem üblichen Muster. Zuerst git clone https://github.com/e2b-dev/fragments.git, dann cd fragments und npm i. Danach wird eine .env.local angelegt. Verpflichtend sind laut README nur zwei Dinge: ein E2B_API_KEY und ein Schlüssel für mindestens einen LLM-Anbieter. Alle anderen Variablen sind optional und schalten Zusatzfunktionen frei.

Die Anbieterliste in der Umgebungsdatei ist lang: OPENAI_API_KEY, ANTHROPIC_API_KEY, GROQ_API_KEY, FIREWORKS_API_KEY, TOGETHER_API_KEY, GOOGLE_AI_API_KEY, GOOGLE_VERTEX_CREDENTIALS, MISTRAL_API_KEY und XAI_API_KEY. Dazu kommen KV_REST_API_URL und KV_REST_API_TOKEN für Kurz-URLs und Rate Limiting, SUPABASE_URL und SUPABASE_ANON_KEY für Authentifizierung sowie NEXT_PUBLIC_POSTHOG_KEY und NEXT_PUBLIC_POSTHOG_HOST für Analytik. Für das Rate Limiting existieren zusätzlich RATE_LIMIT_MAX_REQUESTS und RATE_LIMIT_WINDOW. Wer keine Authentifizierung braucht, lässt die Supabase-Variablen einfach leer.

Zwei Schalter kehren die Logik um. NEXT_PUBLIC_NO_API_KEY_INPUT und NEXT_PUBLIC_NO_BASE_URL_INPUT sind auskommentiert, und das README vermerkt, dass sie die Eingabe von API-Schlüssel und Basis-URL im Chat abschalten, sobald sie aktiviert werden. NEXT_PUBLIC_HIDE_LOCAL_MODELS blendet lokale Modelle aus der Liste aus. Wer eine öffentlich erreichbare Instanz betreibt, sollte diese drei Variablen bewusst setzen, sonst können Besucher eigene Schlüssel und Endpunkte eintragen. Gestartet wird mit npm run dev, der Produktionsbau läuft über npm run build.

Eigene Personas: Dockerfile, e2b.toml und ein Eintrag in lib/templates.json

Der Anpassungspfad für Umgebungen ist im README Schritt für Schritt beschrieben. Voraussetzung ist die installierte und angemeldete E2B CLI. Danach legt man unter sandbox-templates/ einen neuen Ordner an und ruft e2b template init auf, was eine Datei namens e2b.Dockerfile erzeugt. Dieses Dockerfile wird angepasst; das README zeigt als Beispiel ein Streamlit-Image auf Basis von python:3.19-slim, das streamlit, pandas, numpy, matplotlib, requests, seaborn und plotly per pip installiert und den Code nach /home/user kopiert.

Der Startbefehl steht nicht im Dockerfile, sondern in e2b.toml. Das Beispiel lautet start_cmd = "cd /home/user && streamlit run app.py". Gebaut wird mit e2b template build --name <template-name>. Anschließend trägt man die Umgebung in lib/templates.json ein. Der Beispielblock für Streamlit enthält die Schlüssel name, lib, file, instructions und port, wobei port laut Kommentar null sein darf. Der Schlüssel des Eintrags ist die Template-ID. Zusätzlich kann unter public/thirdparty/templates ein Logo hinterlegt werden.

Hier fällt eine Ungenauigkeit auf, die beim Nachbauen Zeit kostet. Die Nummerierung der Schritte springt im README nach Schritt 7 zurück auf 4. Das ist ein redaktioneller Fehler, kein inhaltlicher, aber er macht die Reihenfolge beim ersten Durchlauf unklar. Ebenso widersprüchlich ist der Verweis auf die Modelldatei: Einmal wird lib/models.json genannt, im nächsten Absatz lib/models.ts. Wer Modelle ergänzt, muss selbst herausfinden, welche Datei im aktuellen Stand gilt.

Modelle und Anbieter: zwei Listen, ein Modus

Neue Modelle kommen über einen Eintrag in die Modelldatei hinzu. Das README zeigt das Format mit den Feldern id, name, provider und providerId, im Beispiel Mistral Large mit providerId ollama. Der Anbieter selbst wird in providerConfigs registriert. Das Beispiel für Fireworks lautet fireworks: () => createOpenAI({ apiKey: apiKey || process.env.FIREWORKS_API_KEY, baseURL: baseURL || 'https://api.fireworks.ai/inference/v1' })(modelNameString). Bemerkenswert ist, dass Fireworks über createOpenAI angebunden wird, also über eine OpenAI-kompatible Schnittstelle. Dasselbe Muster dürfte für andere Anbieter mit kompatibler API gelten, das README führt es aber nur an diesem einen Beispiel aus.

Für Anbieter, die kein natives Structured Output liefern, existiert die Funktion getDefaultMode. Das README zeigt, wie man für providerId fireworks den Wert 'json' zurückgibt. Das ist der einzige Hinweis auf die Fehlerquelle, die bei solchen Vorlagen am häufigsten auftritt: Wenn ein Anbieter das erwartete Format nicht zuverlässig erzeugt, bricht die Weiterverarbeitung ab, und der Modus muss pro Anbieter nachjustiert werden. Das README benennt diesen Zusammenhang nicht ausdrücklich, die Existenz der Funktion legt ihn aber nahe. Wer einen Anbieter außerhalb der acht genannten ergänzt, sollte mit diesem Parameter rechnen.

Wo Fragments an Grenzen stößt

Die deutlichste Einschränkung ist die Abhängigkeit von E2B. Ohne E2B_API_KEY startet kein generierter Code. Die Sandbox ist nicht optional, und das Projekt liefert keine Alternative, etwa einen lokalen Container-Lauf oder eine Ausführung im Browser. Wer die Vorlage ohne externen Dienst betreiben will, muss den Ausführungspfad selbst ersetzen. Das README behandelt diesen Fall nicht.

Dazu kommt die Abhängigkeit von Morph, die standardmäßig aktiv ist. Wer keine MORPH_API_KEY setzt, muss damit rechnen, dass die Bearbeitung anders läuft als in der Referenzimplementierung. Ob und wie stark sich das auswirkt, lässt sich aus dem Material nicht ableiten, und das README quantifiziert es nicht.

Ein dritter Punkt betrifft den Betrieb. Fragments erzeugt aus Nutzereingaben lauffähige Umgebungen. Ohne Rate Limiting und ohne Authentifizierung ist eine öffentlich erreichbare Instanz offen für Missbrauch, und beides ist nur optional vorgesehen. Die Variablen KV_REST_API_URL und KV_REST_API_TOKEN gehören zu Vercel oder Upstash KV; wer auf einer anderen Plattform hostet, muss dafür eine eigene Lösung finden. Für eine reine Vorführung oder einen internen Test ist das unerheblich. Für einen offenen Dienst ist es die wichtigste offene Frage vor dem Start.

Schließlich eignet sich Fragments nicht als Baustein für Anwendungen, die deterministisch antworten müssen. Das Ergebnis hängt vom gewählten Modell, vom Modus und von der Umgebung ab. Wer reproduzierbare Ausgaben braucht, ist mit einer festen Pipeline besser bedient.

Was andere anders machen: v0 und Claude Artifacts

Das README nennt die beiden naheliegenden Vergleichspunkte selbst. Claude Artifacts und Vercel v0 lösen dasselbe Grundproblem, aber mit umgekehrter Verteilung. Bei beiden ist die Ausführungsumgebung Teil des gehosteten Dienstes. Man wählt ein Modell aus einer kuratierten Liste, bekommt eine Oberfläche und kann die Umgebung nicht austauschen. Der Preis dafür ist, dass Modell, Laufzeit und Grenzen festgelegt sind.

Fragments dreht das um. Die Umgebung ist konfigurierbar, das Modell ist austauschbar, und der Betrieb liegt beim Nutzer. Dafür muss man die Sandbox selbst betreiben, die Schlüssel selbst verwalten und die Personas selbst bauen. Der Unterschied liegt also nicht im Funktionsumfang, sondern in der Verantwortung. Wer schnell ein Ergebnis sehen will, ist bei den gehosteten Varianten besser aufgehoben. Wer eine eigene Umgebung mit eigenen Bibliotheken braucht, zum Beispiel eine Streamlit-Installation mit einer bestimmten Paketliste, kommt mit einer festen Oberfläche nicht weiter. Genau für diesen Fall ist der Weg über sandbox-templates/ und lib/templates.json gedacht.

Lizenz, Wartung und der Aufwand beim Aktualisieren

Fragments steht unter Apache-2.0. Das erlaubt kommerzielle Nutzung und Veränderung, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen an Dateien gekennzeichnet werden. Wer die Vorlage als Grundlage für ein eigenes Produkt nimmt, sollte die NOTICE-Konventionen der Lizenz prüfen. Das ist keine Rechtsberatung, sondern der Hinweis darauf, dass die Pflichten an Bedingungen geknüpft sind und nicht an eine Zustimmung im Namen des Projekts.

Zum Wartungsaufwand lässt sich aus dem Material nur wenig Sagen. Es gibt keine abgerufenen Releases, und die letzte Aktualisierung des Standardzweigs liegt bei September 2026. Das Repository ist nicht archiviert. Wer die Vorlage forkt, übernimmt damit die Pflege der Abhängigkeiten: Next.js, React, TailwindCSS, shadcn/ui, das Vercel AI SDK und das E2B SDK bewegen sich alle weiter. Änderungen an einer dieser Bibliotheken können Anpassungen an den Server Actions oder an der Streaming-Schicht nach sich ziehen.

Zusätzlich entstehen laufende Kosten außerhalb des Repositories. E2B rechnet die Sandbox-Nutzung ab, der gewählte LLM-Anbieter rechnet pro Token ab, und Morph kommt bei aktiver Nutzung hinzu. Für eine interne Instanz mit wenigen Nutzern ist das überschaubar. Für einen offenen Dienst ist es die zweite offene Frage neben dem Rate Limiting, und sie lässt sich nicht durch eine Codeänderung beantworten, sondern nur durch eine Grenze im Betrieb.

Redaktionelles Fazit

Fragments passt zu Teams, die eine eigene Oberfläche für generierte Apps betreiben und die Ausführung in einer E2B-Sandbox bewusst in Kauf nehmen. Wer keinen E2B-Account will oder eine reine Chat-Oberfläche ohne Codeausführung braucht, ist hier falsch. Vor dem ersten Deploy sollte man die Dateien lib/templates.json und lib/models.ts prüfen und die nicht gesetzten Variablen NEXT_PUBLIC_NO_API_KEY_INPUT sowie NEXT_PUBLIC_HIDE_LOCAL_MODELS bewusst entscheiden, weil sie das Verhalten der Oberfläche direkt steuern.

Offizielle Quellen

1. e2b-dev/fragments on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README