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. Außerhalb von Git oder mit --no-gitignore wird 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 der Ordner noch nicht mit einem Projekt verknüpft ist, verknüpft up ihn mit dem Standardprojekt deines Kontos (dem ältesten Projekt in deinem persönlichen Workspace, bei neuen Konten <username>'s Project) und meldet das. Es fragt nicht nach, weder im Terminal noch in CI. Um in ein anderes Projekt zu deployen, führe zuerst lizard init --name <project> aus oder übergib --project <name>. lizard init --force verknüpft einen Ordner neu.

Ohne --service deployt up in den Service, der mit dem Ordner verknüpft ist. Ist keiner verknüpft, nimmt es den Namen aus package.json oder vom Ordner (im Terminal musst du ihn bestätigen). Hat das Projekt schon einen Service mit diesem Namen, deployt up in diesen, auch in einen GitHub-Service, den es auf sourceType=upload umstellt. Außerdem setzt es den Port dieses Service wie bei einem neuen: --port, die lokale EXPOSE-Zeile oder 3000. Sonst legt es den Service an. Mit --service <name> wählst du selbst; ein Name, den es noch nicht gibt, legt diesen Service an.

Häufige Flags

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

In CI deployt ein nicht verknüpfter Ordner ebenfalls in dein Standardprojekt. Um in ein bestimmtes Projekt zu deployen, verknüpfe es zuerst:

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

• lizard up — die vollständige Befehlsreferenz.
• Build-Pipeline — wie dein Stack erkannt und gebaut wird.

Aktualisiert 21. Oktober 2026