Bereitstellung aus lokalem Code
Wenn dein Code nicht auf GitHub liegt — oder du einfach schnell iterieren willst — lade das aktuelle Verzeichnis direkt mit lizard up hoch. Dabei wird dein Arbeitsverzeichnis als Tarball gepackt, an die Build-Knoten gesendet und bereitgestellt.
Das aktuelle Verzeichnis bereitstellen
lizard up- Lädt das aktuelle Verzeichnis als Tarball hoch und beachtet dabei
.gitignore(deaktivierbar mit--no-gitignore). - Erzwingt
sourceType=upload. - Streamt Build-Logs über SSE und gibt nach Abschluss die Live-URL aus.
Wenn das Verzeichnis noch nicht mit einem Projekt verknüpft ist, führt up zuerst init aus. In einem TTY ist das interaktiv; in einem non-TTY (CI) wird nicht stillschweigend ein Projekt erstellt — stattdessen gibt es einen Fehler und die Aufforderung, lizard init --name <project> auszuführen (oder --name zu übergeben). Das schützt davor, dass ein Tippfehler ein leeres Projekt erzeugt.
Häufige Flags
| Flag | Zweck |
|---|---|
-s, --service <name> | Einen bestimmten Service ansprechen/erstellen |
--build-command <cmd> | Den Build-Befehl überschreiben |
--start-command <cmd> | Den Start-Befehl überschreiben |
--pre-deploy-command <cmd> | Vor jeder Bereitstellung einmal ausführen (z. B. Migrationen) |
--port <number> | Container-Port (0 = Worker-Modus) |
--region <code> | Region für die Bereitstellung |
-d, --detach | Bereitstellung starten und beenden, ohne Logs zu streamen |
-c, --ci | CI-freundliche Ausgabe |
--no-gitignore | Alles hochladen und .gitignore ignorieren |
lizard up --service api --start-command "node server.js" --port 8080Build-/Start-Befehle festlegen
Wenn du --build-command oder --start-command übergibst, wechselt der Service auf den Pfad mit dem synthetisierten Dockerfile. Auf diesem Pfad werden Procfile und package.json scripts.start nicht gelesen — setze den Start-Befehl daher explizit (oder füge ein CMD in dein eigenes Dockerfile ein). Siehe Build-Pipeline. Besonders oft tritt das bei Python auf: Django, Flask und FastAPI benötigen jeweils eine andere Zeile für gunicorn oder uvicorn.
Einen Upload-Service erneut bereitstellen
lizard up lädt erneut hoch und baut neu. Um den letzten Upload mit den aktuellen Variablen neu zu bauen, ohne erneut hochzuladen:
lizard redeploy --service apiHeadless / CI
Für nicht interaktive Abläufe verknüpfe das Projekt vor der Bereitstellung ausdrücklich:
export LIZARD_TOKEN=lzd_xxx
lizard init --name my-project
lizard up --ci --service apiWann GitHub stattdessen besser ist
Upload eignet sich hervorragend für schnelle Iterationen und Situationen ohne Remote. Für alles, was langfristig läuft, ist eine GitHub-Quelle die bessere Wahl, damit Pushes automatisch neu bereitgestellt werden und du eine saubere Bereitstellungshistorie erhältst.
Siehe auch
lizard up— die vollständige Befehlsreferenz.- Build-Pipeline — wie dein Stack erkannt und gebaut wird.