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 deine App live?
Die vollständige Antwort: Während die KI generierte Dateien streamt, pusht VULK sie zu einem dedizierten Preview-Service, der deine 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 deine 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 deine tatsächliche Anwendung auf echter Server-Infrastruktur, auf deinen 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, musst du 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 dein 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 deinem 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. Du bekommst 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 – du siehst Ä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 Karte pro Plattform:
| Plattform | Preview-Mechanismus | Typische Latenz |
|---|---|---|
| React + Vite | Firecracker-microVM, Vite-Dev-Server, HMR | Sekunden; Hot-Reloads unter einer Sekunde |
| Three.js-Spiele | Dieselbe microVM-Pipeline; WebGL rendert im Canvas deines Browsers | Wie React |
| Flutter | Build-then-Serve: flutter build web auf dediziertem Build-Service |
~20–60s pro Build |
| PHP / Laravel | microVM mit php-fpm 8.3 + nginx (live seit Juli 2026) | Sekunden |
| Python (FastAPI/Flask/Django/Streamlit) | microVM mit automatisch erkanntem Start-Kommando (live seit Juli 2026) | Sekunden |
| React Native / Expo | ✅ Expo Go auf deinem Gerät | Expo Go |
React Native + Expo nutzt Expo Go für Vorschauen und Tests auf iOS und Android. Shopify-Themes und -Apps laufen in der Shopify-Umgebung mit den dafür vorgesehenen Werkzeugen.
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 testest du 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 du in der Vorschau siehst, entspricht dem, was Nutzer in Produktion sehen.
Was siehst du während der Generierung?
VULK lässt dich 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. Du siehst 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, siehst du es in Sekunden und stoppst 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 deine Augen, sie ist Teil der Verifizierung.
Was passiert zwischen Vorschau und Produktion?
Die Vorschau ist kein separater Build deiner 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 veröffentlicht die Ausgabe in 10–30 Sekunden auf dein-projekt.vulk.space. Was du getestet hast, bekommen deine Nutzer – plus Minifizierung, Tree Shaking und Asset-Optimierung.
FAQ
Ist die Vorschau eine echte laufende App oder eine Simulation?
Eine echte laufende App. Dein Code läuft in einer Firecracker-microVM – einer isolierten virtuellen Maschine mit eigenem Kernel – mit einem echten Vite-Dev-Server (oder php-fpm oder uvicorn, je nach Stack). Das Iframe im Editor ist ein Fenster auf diesen Live-Server.
Wie schnell erscheinen Edits in der Vorschau?
Für React + Vite Projekte: unter einer Sekunde – nur geänderte Dateien werden in die VM gepusht, und Vites Hot Module Replacement aktualisiert die laufende App ohne Reload, meist unter Erhalt des Component-States. Bei Flutter triggert jeder Edit einen frischen ~20–60s-Build.
Welche Plattformen unterstützen eine Live-Vorschau?
React + Vite und Three.js nutzen Live-Web-Vorschauen. Flutter nutzt eine kompilierte Web-Vorschau. PHP und Python laufen in ihren eigenen Laufzeitumgebungen. React Native + Expo nutzt Expo Go für Vorschauen und Tests auf iOS und Android. Shopify-Themes und -Apps laufen in der Shopify-Umgebung mit den dafür vorgesehenen Werkzeugen.
Läuft die Vorschau auch mein Backend und meine Datenbank?
Ja. Full-Stack-Generierungen führen ihre API und ihren Datenbankzugriff in der Preview-Umgebung aus – Login, Registrierung und Datenpersistenz sind vor dem Deploy testbar, was Browser-Sandbox-Vorschauen strukturell nicht können. 62 % der VULK-Apps enthalten ein SQL-Schema (VULK-Plattformdaten, Juli 2026) – das ist der Normalfall, nicht der Randfall.
Warum nicht einfach WebContainers wie manche anderen Tools?
Browser-basierte Kompilierung begrenzt, was laufen kann (kein echtes Backend, Paket-Inkompatibilitäten, Safari- und Mobile-Probleme, hoher Speicherverbrauch). Server-seitige microVMs kosten mehr im Betrieb, führen aber alles aus, auf jedem Gerät, mit Isolierung auf Hardware-Ebene. Hinter jeder Vorschau steht echte Infrastruktur. Pläne ab Builder 25 €/Monat.
Sieh deine nächste Idee laufen, bevor dein Kaffee kalt wird: vulk.dev.



