Echtzeit-Vorschau: Wie VULK Ihre App live rendert

Aktualisiert am 18. Juli 2026 — neu geschrieben rund um die aktuelle Architektur: Firecracker-microVMs, der Flutter-Build-Service und die PHP + Python Runtimes, die im Juli 2026 live gingen.

Wie rendert VULK Ihre App live?

Die vollständige Antwort: Während die KI generierte Dateien streamt, pusht VULK sie zu einem dedizierten Preview-Service, der Ihre App in einer Firecracker-microVM ausführt — einer echten, isolierten virtuellen Maschine mit eigenem Kernel, Dateisystem und Netzwerk, aus einem Warm-Pool gezogen, sodass sie sich in Sekunden verbindet. In der microVM läuft ein echter Vite-Dev-Server mit Hot Module Replacement für Ihre React-App; die laufende App wird in ein Iframe im Editor proxied. Flutter-Apps gehen durch eine separate Build-then-Serve-Pipeline (flutter build web, ~20–60 Sekunden pro Build), und seit Juli 2026 laufen auch PHP- und Python-Apps live in eigenen microVM-Runtimes.

Das ist keine Simulation und keine Browser-Sandbox: Es ist Ihre tatsächliche Anwendung auf echter Server-Infrastruktur, auf Ihren Bildschirm gestreamt. Diese Geschwindigkeit ermöglicht die definierende Zahl der Plattform — der Median-Builder geht in 47 Sekunden von der Anmeldung zur laufenden generierten App (VULK-Plattformdaten, Juli 2026, N = 11.355 Projekte).

Warum ist die Vorschau das harte Problem der KI-App-Generierung?

Wenn ein KI-Generator Code produziert, müssen Sie das Ergebnis sofort sehen. Die meisten Plattformen wählen einen von zwei Ansätzen: einen statischen Screenshot oder das Kompilieren des Codes im Browser mit Tools wie WebContainers oder Sandpack. Beide haben erhebliche Grenzen.

Statische Screenshots sind offensichtlich unzureichend — man kann nicht mit ihnen interagieren, scrollen, Buttons klicken oder Funktionalität testen. Browser-basierte Kompilierung ist besser, bringt aber eigene Probleme: große Downloads für die Toolchain, begrenzte Node.js-API-Unterstützung, keine Backend-Ausführung, langsame Cold-Compiles, hoher Speicherverbrauch und Sandbox-Restriktionen, die viele npm-Pakete brechen.

VULK wählt den dritten Ansatz: server-seitige Vorschau auf isolierten microVMs. Sie kostet mehr im Betrieb — echte Infrastruktur statt Browser des Nutzers — aber sie ist der einzige Ansatz, bei dem „die Vorschau funktioniert" verlässlich „die App funktioniert" bedeutet.

Was passiert zwischen Generierung und sichtbarer App?

Schritt 1: Code-Generierung. Das KI-Modell streamt seine Antwort und produziert Dateien in vulkAction-XML-Tags. Sobald eine Datei fertig ist, extrahiert VULK Pfad und Inhalt.

Schritt 2: MicroVM-Zuweisung. Dateien gehen an den Preview-Service (webapp.vulk.dev), der Ihr Projekt an eine Firecracker-microVM aus einem vorab gebooteten Warm-Pool anbindet. Jede microVM ist eine echte virtuelle Maschine — Isolierung auf Hardware-Ebene, kein geteilter Container — mit einem Rootfs-Image passend zu Ihrem Projekt (Basis-Web-Image, 3D-fähiges Image oder Voll-Image mit schwereren Abhängigkeiten vorinstalliert).

Schritt 3: Abhängigkeiten und Server-Start. In der VM installieren Abhängigkeiten gegen vorab gecachte node_modules-Layer — der langsamste Schritt einer kalten Vorschau, für gängige Stacks auf Sekunden verkürzt. Für React + Vite Projekte startet der Vite-Dev-Server; für die anderen Stacks der jeweils passende Runtime.

Schritt 4: Iframe-Rendering. Die laufende Anwendung wird durch eine eindeutige URL proxied und in einem Iframe im VULK-Editor angezeigt. Sie bekommen die vollständige, laufende Anwendung — keinen Teil-Render.

Schritt 5: Hot Reload bei Edits. Modifiziert ein Follow-up-Prompt Dateien, werden nur die geänderten in die VM gepusht. Vites Hot Module Replacement aktualisiert das Iframe ohne Full-Reload — Sie sehen Änderungen in unter einer Sekunde, meist ohne Component-State zu verlieren.

Schritt 6: Suspend und Resume. Inaktive Vorschauen werden suspendiert, um Ressourcen freizugeben, und bei Bedarf fortgesetzt — die Rückkehr zu einem Projekt bedeutet keinen Neuaufbau.

Wie previewt jede Plattform tatsächlich?

Verschiedene Stacks laufen durch genuin unterschiedliche Pipelines — die ehrliche Karte pro Plattform:

Die letzten beiden Zeilen zählen. Metro-gebündeltes React Native kann nicht wahrheitsgetreu in einer Web-Vorschau laufen, und Shopify-Code braucht Shopifys Admin- und Storefront-Runtime. Statt diese Renderings zu faken, sagt der Editor Ihnen exakt, wie Sie sie dort ausführen, wo sie wirklich laufen. Eine Vorschau, der man nicht trauen kann, ist schlimmer als keine.

Warum schlägt server-seitig die Browser-Kompilierung?

Backend-Code läuft wirklich. VULK-generierte Full-Stack-Apps enthalten echte APIs und Datenbankzugriff — und 62% aller generierten Apps enthalten ein SQL-Schema (VULK-Plattformdaten, Juli 2026). Browser-Sandboxes können dieses Backend nicht ausführen; sie mocken es oder überspringen es. In VULKs Vorschau testen Sie den gesamten Flow: Registrierung, Login, Datenerstellung, API-Calls.

Keine Sandbox-Grenzen. Browser-basierte Tools emulieren Node.js in einem Service Worker; manche npm-Pakete scheitern stumm, native Module funktionieren nicht, Dateisystemzugriff ist beschränkt. Eine microVM ist eine echte Linux-Umgebung — keine dieser Grenzen existiert.

Konsistent über Geräte hinweg. Der Build läuft auf dem Server — ein Budget-Chromebook und ein MacBook Pro bekommen identische Preview-Performance, und mobile Browser, wo In-Browser-Kompilierung quälend bis unmöglich ist, funktionieren einwandfrei.

Isolierung auf Hardware-Ebene. Firecracker-microVMs isolieren auf der Virtualisierungsschicht — dieselbe Technologie wie AWS Lambda. Die Endlosschleife eines Nutzers kann die Vorschau eines anderen nicht berühren, und eine abgestürzte VM wird automatisch recycelt.

Akkurates Rendering. Das Iframe lädt von einer echten URL, serviert von einem echten Server — was Sie in der Vorschau sehen, entspricht dem, was Nutzer in Produktion sehen.

Was sehen Sie während der Generierung?

VULK lässt Sie nicht warten, bis die gesamte Generierung fertig ist. Die Vorschau aktualisiert progressiv: Sobald die Basisdateien (index.html, main.tsx, package.json) existieren, startet der Dev-Server; während Komponentendateien einströmen, triggert der File-Watcher Hot-Updates. Sie sehen die App in Echtzeit entstehen — erst das Layout, dann Komponenten, dann Styles.

Dieses progressive Rendering gibt frühes Feedback. Geht die KI in die falsche Richtung, sehen Sie es in Sekunden und stoppen die Generierung, statt zu warten. Und nach der Generierung lädt VULKs Render-Gate dieselbe laufende Vorschau in einer echten Chromium-Instanz und lässt Generierungen durchfallen, die eine leere Seite oder eine Error-Boundary rendern — die Vorschau ist nicht nur für Ihre Augen, sie ist Teil der Verifizierung.

Wo liegen die Grenzen der Vorschau?

Cold Starts. Ungecachte Abhängigkeiten können bei der ersten Generierung 10–30 Sekunden Installation kosten. Folgeläufe im selben Projekt nutzen Caches und sind deutlich schneller.

Flutter hat Build-Latenz. ~20–60 Sekunden pro Build (echtes flutter build web), kein Hot-Reload zwischen Builds — akkurates Rendering auf Kosten der Iterationsgeschwindigkeit.

Kein natives Mobile-Rendering. Flutter previewt als Flutter Web — funktional akkurat, visuell nah, aber finale Gerätetests gehören auf ein Gerät. React Native hat noch gar keine In-Editor-Vorschau.

Ressourcen-Limits. Jede microVM hat CPU- und Speicher-Caps für faires Teilen; extrem schwere Workloads (große Datensätze, komplexe Simulationen) können sie erreichen.

Netzwerk-Isolierung. Preview-Umgebungen können aus Sicherheitsgründen keine beliebigen externen Dienste aufrufen. Drittanbieter-API-Calls scheitern in der Vorschau und funktionieren nach dem Deploy.

Was passiert zwischen Vorschau und Produktion?

Die Vorschau ist kein separater Build Ihrer App — es ist derselbe Code in einer Entwicklungsumgebung. Beim Klick auf Deploy nimmt VULK denselben Code, führt einen Produktions-Build aus (vite build) und liefert die Ausgabe in 10–30 Sekunden zu Cloudflare Pages. Was Sie getestet haben, bekommen Ihre Nutzer — plus Minifizierung, Tree Shaking und Asset-Optimierung.