BereitstellungAus lokalem Code deployen

Bereitstellung aus lokalem Code

Mit lizard up lädst du das aktuelle Verzeichnis direkt hoch, etwa wenn der Code nicht auf GitHub liegt oder du Änderungen schnell testen willst. Die CLI packt das Verzeichnis als Tarball und sendet es zum Bauen und Bereitstellen an die Build-Knoten. Welche Befehle jeder Stack braucht, steht in den Anleitungen für React, Vue, Astro, SvelteKit, Hugo, Docusaurus, VitePress, FastAPI und Streamlit.

Das aktuelle Verzeichnis bereitstellen

lizard up
  • Lädt das aktuelle Verzeichnis als Tarball hoch. Innerhalb eines Git-Repositorys wird .gitignore beachtet (deaktivierbar mit --no-gitignore). Außerhalb von Git werden nur eine feste Liste von Build- und Abhängigkeitsordnern (node_modules, .git, dist, .next, build, __pycache__, .venv, venv, .cache, coverage, .turbo, .vercel) sowie .DS_Store, *.pyc, *.pyo und *.log übersprungen, sodass .env-Dateien hochgeladen werden. Führe zuvor git init aus oder lagere Secrets aus.
  • 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 --project <name> an up zu übergeben). Das schützt davor, dass ein Tippfehler ein leeres Projekt erzeugt.

Häufige Flags

FlagZweck
-s, --service <name>Einen bestehenden Service ansprechen
--build-command <cmd>Den Build-Befehl überschreiben
--start-command <cmd>Den Start-Befehl überschreiben
--pre-deploy-command <cmd>Zu Beginn jedes Containers vor dem Start-Befehl ausführen; erfordert --start-command (siehe Build-Konfiguration)
--port <number>Container-Port (0 = Worker-Modus)
--region <code>Region für einen neuen Service (wird bei bestehenden Services ignoriert)
-d, --detachBereitstellung starten und beenden, ohne Logs zu streamen
-c, --ciCI-freundliche Ausgabe
--no-gitignoreAlles hochladen und .gitignore ignorieren
lizard up --service api --start-command "node server.js" --port 8080

Build-/Start-Befehle festlegen

Wenn du --build-command oder --start-command übergibst, wird der Befehl im Service gespeichert und der Service wechselt auf den Pfad mit dem synthetisierten Dockerfile, sofern dockerfilePath nicht gesetzt ist. Auf diesem Pfad werden Procfile und package.json scripts.start nicht gelesen — setze den Start-Befehl daher explizit. 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 api

Headless / CI

Für nicht interaktive Abläufe verknüpfe das Projekt vor der Bereitstellung ausdrücklich:

export LIZARD_TOKEN=liz_xxx   # create one with: lizard keys create <name>
lizard init --name my-project
lizard up --ci --service api

Wann 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

Von GitHub deployenAus einem Dockerfile deployen

Aktualisiert