Von GitHub deployen

Verbinde ein GitHub-Repository, und Lizard (lizard.build) baut und deployt deine App bei jedem Push in den verfolgten Branch neu: git push to deploy. Führe lizard add -r owner/repo aus, um den Service zu erstellen; bei einem privaten Repository verbinde zuerst die Lizard GitHub App mit lizard git connect. Das ist der empfohlene Weg, eine App auszuführen, die du auf GitHub verwaltest. Für Code ohne Remote deploye stattdessen von lokalem Code.

Einen Service aus einem Repo erstellen

lizard add -r your-org/your-app

Das erstellt einen github-source-Service und startet den ersten Build im Hintergrund: Lizard klont das Repo und erkennt den Stack (lizardpack). Der Befehl gibt keine URL aus. Verfolge den Build mit lizard logs --build --service <name>; sobald er live ist, zeigt lizard ps die URL. Nützliche Flags:

Private Repositories

Verbinde die Lizard GitHub App einmal pro Account, um Zugriff auf private Repos zu gewähren:

lizard git connect
lizard git status        # show connection + repo status

Du kannst den Repository-Zugriff auch auf der Seite GitHub-Integration im Dashboard verbinden und verwalten (lizard open).

Einen bestehenden Service auf ein Repo verweisen lassen

Um einen Service auf eine Git-Quelle umzustellen (oder Repo/Branch zu ändern):

lizard service set api \
  --set sourceType=github \
  --set repoUrl=https://github.com/your-org/your-app \
  --set branch=main

Das Ändern eines Build-Felds baut einen laufenden Service neu. Ein redeploy danach bricht diesen Build ab und startet einen neuen. Ein abgestürzter oder noch nie bereitgestellter Service braucht lizard redeploy.

Hinweis: lizard up erzwingt immer sourceType=upload. Verwende es nicht, um einen Git-gestützten Service zu aktualisieren — pushe zum Remote oder verwende stattdessen lizard redeploy. In einem Ordner ohne verknüpften Service wählt up den Service, der nach dem Ordner oder der package.json benannt ist; in einem Klon des Repos kann es deinen GitHub-Service so auf einen Upload umstellen.

Automatische erneute Bereitstellung bei Push

Sobald repoUrl gesetzt ist, lösen Pushes zum passenden branch über den GitHub-Webhook automatisch eine erneute Bereitstellung aus. Verbinde die Lizard GitHub App (lizard git connect), damit Lizard Push-Events für das Repository erhält. Um festzulegen, welche Pushes eine erneute Bereitstellung auslösen:

• rootDirectory — nur ein Unterverzeichnis bauen (Monorepos).
• watchPatterns — nur dann erneut bereitstellen, wenn passende Pfade geändert werden.

lizard service set api --set watchPatterns='apps/api/**,packages/**'

Damit Pushes nicht mehr deployen, schalte Auto-deploy in den Einstellungen des Service im Dashboard aus. Ein pausierter Service ignoriert Pushes ebenfalls, bis du ihn fortsetzt.

Branches wechseln

lizard git checkout api staging      # move the `api` service to the `staging` branch and redeploy

Monorepos

Für ein Repo, das mehrere Apps enthält, erstelle einen Service pro App und setze dessen rootDirectory auf den Unterpfad:

lizard add -r your-org/monorepo -n api --no-deploy
lizard service set api --set rootDirectory=apps/api
lizard redeploy --service api

Wenn dein aktuelles Verzeichnis eine Sub-App in einem Repo ist, dessen Elternverzeichnis bereits verknüpft ist, füge den Service im Projekt des übergeordneten Verzeichnisses hinzu und setze rootDirectory auf den Unterpfad des aktuellen Verzeichnisses.

Siehe auch

• Build-Pipeline — wie dein Stack erkannt und gebaut wird.
• Framework-Anleitungen: Build-Befehle und Ports für Next.js, Nuxt, Django, FastAPI, Rails, Go und weitere.
• Mit einer Dockerfile deployen: wenn das Repo ein eigenes Dockerfile hat.
• Von lokalem Code deployen — wenn du kein Remote hast.
• lizard git — die vollständige Befehlsreferenz für connect, status und checkout.
• Den Host nach der Anwendung wählen — wie du dies auf ein Repo verweist, das ein Agent geschrieben hat.

Aktualisiert 21. Oktober 2026