Framework-Anleitungen
Stelle eine Framework-App aus dem Quellcode auf Lizard bereit. Wähle unten dein Framework und den Rendering-Modus, bereite den Produktions-Build vor und stelle dann mit Lizard CLI bereit oder verbinde ein GitHub-Repository. Server-Apps führen einen Prozess aus; statische Websites liefern die generierten Dateien über nginx aus.
Wähle dein Framework
Diese Einstellungen beschreiben die Standard-Projektlayouts in den verlinkten Anleitungen. Die Befehle gehen bei JavaScript-Projekten von npm aus. Benutzerdefinierte Ausgabepfade, Adapter und Build-Überschreibungen können das Ergebnis ändern. Wenn du stattdessen ein eigenes Image bauen möchtest, sieh dir Einen Docker-Container aus einem Dockerfile deployen an.
| Framework | Build | Laufzeit oder Ausgabe | Service-Port |
|---|---|---|---|
| Next.js | npm run build | next start über das Start-Skript | 3000 |
| Next.js statischer Export | npm run build | out/ über ein Dockerfile | 80 |
| React with Vite | npm run build | dist/ | 80 |
| Vue with Vite | npm run build | dist/ | 80 |
| Astro | npm run build | dist/ oder der eigenständige Node-Adapter | 80 statisch; 3000 Server |
| Nuxt | npm run build | node .output/server/index.mjs | 3000 |
| SvelteKit | npm run build | node build mit adapter-node | 3000 |
| Node.js (Express) | build-Skript, falls vorhanden | start-Skript | 3000 |
| FastAPI | Python-Abhängigkeiten installieren | uvicorn main:app --host 0.0.0.0 --port 8000 | 8000 |
| Django | Python-Abhängigkeiten installieren | Gunicorn mit deinem WSGI-Modul | 8000 |
| Streamlit | Python-Abhängigkeiten installieren | streamlit run app.py aus einem Procfile | 8501 |
| Go | go build zu einem statischen Binary | /app/server | 8080 |
| Ruby on Rails | Das von Rails generierte Dockerfile | Thruster und Puma oder nur Puma | 8080 bei Rails 8; 3000 bei Rails 7.1 und 7.2 |
| Docusaurus | npm run build | build/ | 80 |
| VitePress | npm run docs:build | docs/.vitepress/dist/ in dieser Anleitung | 80 |
| Hugo | hugo --minify | public/ | 80 |
Projekt vorbereiten
Führe die Befehle im Anwendungsverzeichnis aus. Committe den Quellcode, die Konfiguration und die Lock-Datei des Paketmanagers. Schließe .env, lokale Abhängigkeiten und lokale Build-Ausgabe von Uploads aus. Node-Projekte können die Node-Hauptversion in .nvmrc auswählen; der aktuelle Standard ist 22. Damit wird eine Hauptversion ausgewählt, keine genaue Patch-Version. Laufzeitversionen listet die Versionsdateien für Node.js, Python, Go und Ruby auf.
Installiere Lizard CLI und melde dich einmal an:
curl -fsSL https://lizard.build/install.sh | bash
lizard loginFühre unter Windows irm https://lizard.build/api/cli/install.ps1 | iex in PowerShell aus. Ein neues Konto startet ohne Tarif: Bis du die 7-tägige Pro-Testphase startest (Karte erforderlich), geben lizard add und lizard up einen Checkout-Link zurück. lizard billing start öffnet ihn.
Jede Anleitung verwendet ein neues Projekt und einen Service mit dem Namen web oder api. Erstelle diesen Service mit lizard add --service web (oder api) vor dem ersten Aufruf von lizard up --service. up --service wählt einen vorhandenen Service aus; ein fehlender benannter Service wird dadurch nicht erstellt. Prüfe bei einem bestehenden Projekt vor der Bereitstellung lizard status --json und lizard ps --json. Der Port muss zum Prozess im Container passen, der auf 0.0.0.0 lauschen muss.
Lizard CLI 0.3.95 und neuer schließen macOS-Archivmetadaten bei Uploads aus. Eine Einstellung für COPYFILE_DISABLE ist nicht erforderlich. Aktualisiere ältere CLI-Versionen, bevor du diesen Anleitungen folgst.
GitHub oder lokalen Quellcode wählen
Die Befehle in dieser Anleitung verwenden lizard up, um den aktuellen Ordner hochzuladen. Dieser Befehl stellt einen bestehenden Service auf Quellcode-Upload um. Wenn du git push to deploy beibehalten möchtest, verbinde GitHub stattdessen und verwende die Build-Einstellungen der Anleitung im Repository. Konfiguriere den Service-Port anhand der Tabelle: nginx lauscht bei einem Build mit Vite, Astro, SvelteKit, Docusaurus oder VitePress auf dem Port, den du festlegst, oder auf 3000, wenn du keinen festlegst.
Build-Einstellungen konsistent halten
Diese Anleitungen verwenden lizardpack-Erkennung, sofern nicht ein Dockerfile verlangt wird. Bestehende Überschreibungen in buildCommand oder startCommand haben Vorrang vor der Erkennung und dem Dockerfile im Repository; ein gesetzter dockerfilePath hat Vorrang vor beidem. Prüfe die Reihenfolge der Build-Entscheidung, bevor du die Build-Methode wechselst. Setze Skripte in package.json, wenn eine Anleitung dich dazu auffordert; das Hinzufügen einer CLI-Überschreibung ist ein anderer Build-Pfad.
Ein Release prüfen
Lies die Build-Logs, Laufzeit-Logs und die aktive URL. Teste eine interne Route, eine fehlende Route und jede API oder Formularaktion. Ein Prozess, der seinen Port öffnet, kann trotzdem eine fehlerhafte Seite ausliefern. Verwende für generierte Websites statische Routen und 404-Seiten, damit nicht für jede unbekannte URL die Startseite mit HTTP 200 zurückgegeben wird.
Laufzeitunterstützung bedeutet nicht gemeinsam genutzte Caches, persistente lokale Dateien oder jede Framework-Version. Sieh unter Limits, Storage und Wiederherstellung und bekannte Probleme nach, wenn deine App auf diese Funktionen angewiesen ist.
Sieh unter getestete Versionen und Cloud-Ergebnisse nach für die Bereitstellungsprüfungen vom 9. September 2026 und ihre Limits.
Aktualisiert