Baue einen Lovable-Klon an einem Tag mit Lizard Sandboxes

Ein Lovable-Klon braucht einen Ort, um den generierten Code auszuführen. Das Modell schreibt Dateien, installiert Abhängigkeiten, prüft Builds und startet einen Preview-Server. Jedes Kundenprojekt benötigt einen eigenen Workspace.

Mit Lizard Sandboxes erstellt dein Backend diesen Workspace über das Lizard SDK, sendet ihm Dateien, führt Befehle aus und gibt eine private Preview-URL zurück. Du kannst loslegen, ohne Server zu kaufen oder eine Flotte von Maschinen zu reservieren.

Für einen Entwickler, der React und Node.js kennt und mit einem App-Template startet, ist ein Tag ein realistisches Ziel für ein kleines MVP: einen Prompt eingeben, eine React-App generieren, die Preview öffnen und Änderungen anfordern. Zahlungen, Team-Zugriff und ein vollständiges Deployment-Produkt erfordern mehr Arbeit.

Was wir auf Lizard getestet haben

Am 15. Oktober 2026 haben wir den Ausführungs-Workflow in Small Firecracker Sandboxes in us-east-1 mit dem Lizard SDK 0.1.69 ausgeführt.

Der erste erfolgreiche Durchlauf dauerte etwa 22 Sekunden von der Erstellung der Sandbox bis zum Erhalt einer funktionierenden Preview. Das umfasste die Installation von Node.js und npm, den Upload des Starters, die Installation der Abhängigkeiten und den Build der App. Dies ist ein einzelner Smoke-Test, kein Startup-Benchmark.

Der Test deckte auch zwei Fehler im ersten Entwurf auf. Das Sandbox-Objekt stellt seine ID als sandbox.sandboxId bereit. Und die erhaltene interpreter-Sandbox enthielt weder Node.js noch npm. Der untenstehende Code installiert eine feste Node.js-Version vor der Ausführung des Builds.

Wir haben den Ausführungs- und Preview-Workflow getestet. Der untenstehende Ein-Tages-Zeitplan ist ein Build-Plan; wir haben weder die Erstellung eines kompletten SaaS-Produkts gestoppt noch die Ausgabequalität eines externen Modells getestet.

Halte die erste Version klein

Starte mit einem einzigen React- und Vite-Template. Lass Nutzer einfache Dashboards, Landingpages oder interne Tools mit Beispieldaten erstellen.

Das erste Release benötigt einen Login, eine Projektliste, eine Chatbox, Build-Ausgaben und eine funktionierende Preview. Speichere Quelldateien, damit Nutzer später zurückkehren können.

Halte die Liste der Abhängigkeiten fest. Gib dem Modell eine bekannte Auswahl an Paketen und lass es einige wenige Quelldateien bearbeiten. Das erleichtert die Behebung fehlgeschlagener Builds.

Eine nützliche erste Anfrage ist:

Build a dashboard for a small gym. Show monthly revenue,
active members, and upcoming classes. Use sample data.

Sobald die Preview funktioniert, sende eine Folgeanfrage, um einen Mitgliederfilter hinzuzufügen oder zu ändern. Das gibt dir einen konkreten Pfad zum Testen.

Behalte die Kontrolle im Backend

Dein Backend verwaltet die Modellverbindung, den Lizard-API-Schlüssel und die Zuordnung zwischen Nutzern und Projekten.

User prompt
    |
Your backend: sign-in, project access, model calls
    |
Lizard SDK
    |
Sandbox: source files, dependencies, build, preview
    |
Private preview URL returned to the project owner

Speichere den Eigentümer, die Sandbox-ID, die Konversation und die gespeicherte Dateiversion in deiner Datenbank. Prüfe die Eigentümerschaft vor jeder Operation, einschließlich dem Lesen von Logs und dem Öffnen einer Preview.

Behalte Plattform-Zugangsdaten in deinem Backend. Generierter Code benötigt weder deinen Lizard-API-Schlüssel noch den Schlüssel des Modellanbieters.

Bitte das Modell für die erste Version um eine strukturierte Ausgabe mit appTsx und appCss. Validiere beide Strings und setze ein Limit für die Antwortgröße. Dein Backend schreibt sie in feste Pfade, src/App.tsx und src/App.css. Es kontrolliert Paketdateien, das Lockfile und Build-Skripte.

Teile dem Modell mit, welche Imports der Starter unterstützt. Wenn ein Build fehlschlägt, gib die relevante Fehlerausgabe zurück und erlaube maximal zwei Reparaturversuche. Zeige den Fehler danach dem Nutzer an.

Eine Sandbox erstellen und ihre Preview öffnen

Installiere die getestete SDK-Version in deinem Node.js-Backend:

npm install @lizard-build/sdk@0.1.69

Erstelle einen Schlüssel, der auf das Lizard-Projekt deines Builders beschränkt ist:

lizard keys create lovable-builder --project YOUR_PROJECT_ID --json

Setze LIZARD_API_KEY und LIZARD_PROJECT_ID in der Backend-Umgebung. Das SDK liest deinen Lizard CLI-Login nicht aus und lädt auch nicht selbstständig eine .env-Datei.

Bereite einen vertrauenswürdigen React- und Vite-Starter mit einem Lockfile und einem funktionierenden npm run build-Skript vor. Unser Test nutzte React 19.2.0, Vite 7.1.12, TypeScript 5.9.3 und Python 3.11.16. Halte die Abhängigkeiten in deinem eigenen Starter aktuell und teste erneut, wenn du sie aktualisierst.

Die untenstehende Funktion akzeptiert diesen Starter als Map von relativen Dateipfaden zu Dateiinhalten. Lade ihn aus Dateien, die du kontrollierst. Akzeptiere starterFiles nicht vom Modell oder aus einer nicht authentifizierten Anfrage.

Der Setup-Schritt zielt auf die in diesem Test verwendete Linux x64-Sandbox ab. Er lädt Node.js 22.23.3 von nodejs.org herunter und prüft das Archiv gegen die Release-Prüfsumme. Führe das Setup aus, bevor du den Workspace an generierten Code übergibst.

import { Lizard } from '@lizard-build/sdk'
import { setTimeout as delay } from 'node:timers/promises'

const project = process.env.LIZARD_PROJECT_ID
if (!project) throw new Error('LIZARD_PROJECT_ID is required')

const lizard = new Lizard({ project })

export async function createPreview(
  starterFiles: Record<string, string>,
  appTsx: string,
  appCss: string,
) {
  const sandbox = await lizard.create('interpreter', {
    size: 'small',
    timeoutMs: 10 * 60 * 1000,
    metadata: { purpose: 'lovable-article-smoke-20261015' },
  })

  try {
    const info = await sandbox.getInfo()
    if (info.runtime !== 'firecracker') {
      throw new Error('This workflow requires Firecracker')
    }

    const setup = await sandbox.process.exec(['/bin/bash', '-lc', `
set -euo pipefail
version=v22.23.3
archive=node-$version-linux-x64.tar.xz
if [ "$(node --version 2>/dev/null || true)" != "$version" ] || ! command -v npm >/dev/null; then
  cd /tmp
  curl -fsSLO "https://nodejs.org/dist/$version/$archive"
  curl -fsSL "https://nodejs.org/dist/$version/SHASUMS256.txt" | grep "  $archive$" | sha256sum -c -
  tar -xJf "$archive" -C /usr/local --strip-components=1
fi
node --version
npm --version
python --version
`], { timeoutMs: 120_000 })
    if (setup.exitCode !== 0) throw new Error(setup.stderr || setup.stdout)

    for (const [path, content] of Object.entries(starterFiles)) {
      await sandbox.fs.write(`/workspace/app/${path}`, content)
    }
    await sandbox.fs.write('/workspace/app/src/App.tsx', appTsx)
    await sandbox.fs.write('/workspace/app/src/App.css', appCss)

    for (const command of [['npm', 'ci'], ['npm', 'run', 'build']]) {
      const result = await sandbox.process.exec(command, {
        workdir: '/workspace/app',
        timeoutMs: 120_000,
      })
      if (result.exitCode !== 0) {
        throw new Error(result.stderr || result.stdout)
      }
    }

    const server = await sandbox.process.exec(
      ['/bin/bash', '-lc', 'nohup python -m http.server 3000 --bind 0.0.0.0 ' +
      '--directory dist > /tmp/preview.log 2>&1 < /dev/null &'],
      { workdir: '/workspace/app' },
    )
    if (server.exitCode !== 0) throw new Error(server.stderr)

    const route = await sandbox.exposePort(3000)
    for (let attempt = 0; attempt < 15; attempt++) {
      const response = await fetch(`https://${route.hostname}`, {
        headers: { 'X-Lizard-Access-Token': route.accessToken },
        signal: AbortSignal.timeout(3_000),
      }).catch(() => null)

      const ready = response?.ok
      await response?.body?.cancel()
      if (ready) {
        return { sandboxId: sandbox.sandboxId, previewUrl: route.url }
      }
      await delay(500)
    }
    throw new Error('Preview did not become ready')
  } catch (error) {
    await sandbox.kill()
    throw error
  }
}

Rufe createPreview(starterFiles, result.appTsx, result.appCss) auf, nachdem du die Modellantwort validiert hast. Speichere die zurückgegebene sandboxId beim Projekt des Nutzers und gib previewUrl erst nach einer Zugriffsprüfung zurück.

Die URL enthält ein Access-Token. Halte es aus öffentlichen Logs und Analytics heraus. Es gewährt Zugriff auf die freigegebenen Ports der Sandbox, behandle es also wie ein Passwort.

Dieses Beispiel liefert das gebaute Frontend mit dem HTTP-Server von Python aus. Nutze dies für eine private Entwicklungs-Preview. Belasse die initiale App auf einer Route oder verwende Hash-Routing. Das Produktions-Hosting sollte ein separates Deployment sein.

Die Lizard SDK-Referenz behandelt Befehle, Dateien, private Ports und Sandbox-Lebenszyklus-Operationen.

Folgeänderungen und gespeicherte Projekte handhaben

Verbinde dich über lizard.connect(sandboxId) erneut mit der Projekt-Sandbox. Lies die genehmigten Quelldateien, sende sie mit der nächsten Anfrage des Nutzers an das Modell, validiere die Antwort, schreibe die Änderungen und führe den Build erneut aus.

Unser Test änderte die Überschrift und fügte ein Beispiel-Mitglied hinzu. Nach dem erneuten Bauen und Neuladen derselben Preview-URL zeigte der Browser die neue Version an und ihr Filter funktionierte.

Speichere Quelldateien nach jedem erfolgreichen Build. Nutze einen privaten Bucket, um Quellcode-Bundles in Managed Object Storage zu speichern, und behalte Projektdatensätze in Managed Postgres. Diese Backend-Dienste laufen getrennt vom Preview-Workspace.

Ein Nutzer, der nach Ablauf der Sandbox zurückkehrt, benötigt eine neue Sandbox. Stelle den gespeicherten Quellcode und den Starter wieder her und baue dann neu. Wir haben dies verifiziert, indem wir den bearbeiteten Quellcode in eine zweite Sandbox geladen und die resultierende App in einem Browser geöffnet haben.

Persistent Volumes sind eine weitere Option, um Workspace-Dateien zu behalten. Jedes Volume wird an jeweils eine Sandbox angehängt. Behalte eine externe Kopie wertvoller Dateien, da der Speicher auf einem einzelnen Knoten liegt. Details zum Sandbox-Speicher

Generierten Code mit Firecracker isolieren

Lizard Sandboxes unterstützen Firecracker-MicroVMs mit eigenem Kernel. Das Beispiel prüft die Laufzeitumgebung, bevor es Abhängigkeiten installiert oder die App ausführt.

Ältere Volumes oder Snapshots können die Container-Laufzeitumgebung nutzen. Wenn dein Produkt Firecracker erfordert, behalte die Laufzeitprüfung bei, wenn du Restore- oder Volume-Unterstützung hinzufügst. Laufzeit-Details

Erstelle für jedes aktive Kundenprojekt eine separate Sandbox. Halte Produktions-Datenbank-Zugangsdaten und Plattform-Schlüssel außerhalb dieses Workspaces. Eine Sandbox kann Netzwerkanfragen stellen, daher könnte generierter Code jedes Geheimnis nach außen senden, das du dort ablegst.

Liefere Previews auf einem separaten Browser-Origin getrennt von deiner Haupt-App aus. Für ein MVP hält das Öffnen der privaten Preview in einem neuen Tab die Integration einfach. Überprüfe iframe-Berechtigungen und validiere Nachrichten, falls du Previews später einbettest.

Teste mit zwei Accounts, bevor du Nutzer einlädst. Das Ändern einer Projekt-ID darf es einem Account nicht ermöglichen, die Dateien, Logs oder die Preview-URL des anderen zu lesen. Firecracker übernimmt die Ausführungsgrenze; deine Anwendung kümmert sich um den Nutzerzugriff.

Was kostet der Betrieb eines Lovable-Klons?

Small kostet $0.0162 pro Stunde für 2 vCPU, 4 GB RAM und 5 GB lokale Festplatte. Lizard rechnet die Laufzeit sekundengenau ab.

Bei zehn Minuten pro Sitzung:

Dies sind Compute-Schätzungen. Lizard Pro kostet $19 pro Monat, wobei $19 an Nutzung inklusive sind; die Nutzung darüber hinaus erfolgt als pay as you go. Die siebentägige Testphase beinhaltet $5 an Nutzung und erfordert eine Kreditkarte. Preise geprüft am 15. Oktober 2026. Aktuelle Preise

Modell-Tokens, Backend-Hosting, Datenbanken und persistenter Speicher beeinflussen ebenfalls deine Gesamtkosten. Erfasse die Modellnutzung und Sandbox-Zeit pro Projekt, bevor du deine eigenen Preise festlegst.

Du vermeidest den Kauf von Servern oder die Reservierung von Kapazitäten, bevor du Nutzer findest. Laufende Leerlaufzeiten kosten dennoch Geld. Pausiere oder beende ungenutzte Sitzungen; für beibehaltenen Speicher können weiterhin Gebühren anfallen.

Das Beispiel setzt eine Lebensdauer von zehn Minuten. Befehle verlängern diese Frist nicht. Füge deinem Backend eine Richtlinie für inaktive Sitzungen und einen Stop-Button hinzu und rufe sandbox.kill() auf, wenn eine Sitzung endet, nachdem ihr Quellcode gespeichert wurde. Lebenszyklus-Referenz

Ein Ein-Tages-MVP-Plan

Dieser Zeitplan setzt voraus, dass du bereits einen Web-App-Starter mit Authentifizierung hast.

Prüfe die gesamte User Journey, bevor du Tester einlädst: eine App erstellen, eine Änderung anfordern, die Sitzung schließen und das gespeicherte Projekt erneut öffnen. Ein fehlgeschlagener Build sollte einen nützlichen Fehler ausgeben und seine Sandbox freigeben.

Starte mit einem Template und einer funktionierenden Preview. Lizard Sandboxes und das Lizard SDK bieten die Ausführungs-, Datei- und Lebenszyklus-Kontrollen für dieses erste Release.