Deployment aus Claude Code: ein praktischer Lizard-Workflow

Claude Code kann eine Anwendung deployen, indem es die Tools eines Hosting-Anbieters in deiner Entwicklungsumgebung verwendet. Mit Lizard kann der Agent das Projekt inspizieren, die Lizard CLI zum Deployment nutzen, Abhängigkeiten konfigurieren und den Live-Service prüfen. Der Host führt die Anwendung nach Ende der Coding-Session weiter aus.

Das nützliche Ergebnis ist ein funktionierender Benutzer-Flow unter einer Live-URL, nicht nur ein Befehl, der erfolgreich beendet wird. Dieser Leitfaden prüft die Lizard CLI und die verlinkte Dokumentation per 9. September 2026.

Dem Agenten den richtigen Kontext geben

Starte mit einem Repository, das baut und einen Produktions-Start-Befehl hat. Identifiziere den Workspace und das Projekt, das es besitzen soll, ob es eine Datenbank oder einen Worker braucht, und ob das Deployment eine Testkopie erstellt oder einen bestehenden Service ändert.

CLI installieren und die versionszugehörigen Anweisungen lesen:

npm install -g @lizard-build/cli
lizard skills get core --json
lizard status --json

Falls Authentifizierung nötig ist, lizard login verwenden und den Browser-Sign-in abschließen. Für die wiederverwendbaren Agenten-Anweisungen dem Lizard Skill Repository folgen. Claude Codes eigener Überblick beschreibt, wie es mit einem Codebase und Tools zusammenarbeitet.

Der Agent sollte die bestehende Konfiguration inspizieren, bevor er etwas hinzufügt. Eine Runtime-Version, ein Dockerfile oder ein Start-Befehl, der bereits im Projekt ist, sind bessere Belege als ein aus dem Framework-Namen geratener Befehl.

Ein Prompt, der die Deployment-Aufgabe definiert

Gib dem Agenten eine begrenzte Anweisung wie:

Deploye dieses Repository in das bestehende Lizard-Projekt my-project als Test-Service. Lese den aktuellen Lizard CLI-Leitfaden und prüfe zuerst die Build- und Start-Befehle. Nutze die GitHub-Quelle, falls das Repository ein erreichbares GitHub-Remote hat. Konfiguriere die Services, die diese App tatsächlich braucht. Verifiziere die Live-URL, Logs und einen echten Anwendungs-Flow. Berichte die deployte Revision und jeden fehlgeschlagenen Prüfen.

Ersetze das Projekt und die Umgebung durch das beabsichtigte Ziel. Gebe explizit an, wann ein Produktions-Service oder eine Domain geändert werden soll. Der Agent sollte keine Produktions-Datenbank-Migration aus einer Anfrage ableiten, eine Testkopie zu veröffentlichen.

Git-Deployment oder Source-Upload wählen

Nutze die GitHub-Integration des Repositorys, wenn spätere Commits Bereitstellungen auslösen sollen. Der GitHub-Deployment-Leitfaden behandelt Verbindung und Service-Setup. Prüfe den getrackten Branch und das Root-Verzeichnis für ein Monorepo.

Für ein lokales Projekt ohne geeignetes GitHub-Remote ist Source-Upload verfügbar. Nach Auswahl des richtigen Workspaces können ein neues Beispiel-Projekt und ein neuer Service nutzen:

lizard init --name my-project
lizard add --service api
lizard up --service api

Diese Namen sind Beispiele. Für ein bestehendes Projekt den aktuellen Link mit lizard status --json bestätigen und den bestehenden Service auswählen. Erstelle nicht einfach ein weiteres Projekt oder schalte einen Git-gebackenen Service auf Upload um, nur um das Lesen seiner Einstellungen zu vermeiden.

Lizard führt den gehosteten Build durch. Je nach Projekt- und Service-Konfiguration kann es das Dockerfile des Repositorys nutzen oder eines über den unterstützten Build-Pfad generieren. Lies die Deployment-Dokumentation und halte die Einstellungen im Konfigurationsreferenz wiederholbar.

Die Datenbank bewusst verbinden

Managed Postgres zu erstellen beweist nicht, dass die Anwendung sie erreichen kann. Die Anwendung muss die Verbindungsvariable lesen, die du setzt. Für ein Projekt mit einem Service namens api und dessen erstem PostgreSQL-Add-on namens postgres lautet die Referenz:

lizard add postgres
lizard secrets set 'DATABASE_URL=${{postgres.DATABASE_URL}}' --service api

Nutze den tatsächlichen Namen des Add-ons, falls er abweicht. Konfiguriere jeden Consumer-Service, einschließlich Worker, mit den Variablen, die er braucht. Führe Migrationen als kontrollierten Release-Schritt aus und bestätige einen Anwendungs-Lese- und Schreibzugriff gegen die intendierte Datenbank. Siehe Variablen-Referenzen und Managed Postgres.

Für Uploads Speicher wählen, der den Lebenszyklus überdauert, den deine App braucht. Für einen Worker prüfen, dass er den Broker erreichen und Restarts handhaben kann. Vermeide, die erfolgreiche Erstellung von Ressourcen als abgeschlossenes Application-Setup zu behandeln.

Das Ergebnis von außen prüfen

Strukturierte Ausgabe für Diagnostik nutzen:

lizard status --json
lizard logs --service api --json
lizard logs --service api --build --json
lizard metrics --service api --json

Dann die Live-URL abrufen und einen echten Flow ausüben. Bei einer kleinen API könnte das Authentifizierung gefolgt von Schreiben und Lesen sein. Für ein Frontend eine Route prüfen, die direkt per URL erreicht wird, sowie durch client-seitige Navigation.

Falls das Deployment fehlschlägt, den gemeldeten Fehler nutzen, um den nächsten Prüfen zu wählen:

Ein Agent sollte einen ungelösten Fehler melden, statt Erfolg aus dem Build-Log zu erklären. Der Python-Hosting-Leitfaden gibt Beispiele für Start-Befehl-Probleme.

Die Kosten des Workflows verstehen

Dein Coding-Abo und die Hosting-Rechnung bezahlen unterschiedliche Teile der Arbeit. Lizard nutzt pay as you go ohne monatliches Abo. Die Preisseite listet Ressourcen-Raten und Zahlungsbedingungen. Ein Test-Service, eine Datenbank oder eine Sandbox können nach Ende der Coding-Session weiter Ressourcen verbrauchen.

Ressourcen-Limits setzen und Nutzung prüfen. Temporäre Ressourcen stoppen oder entfernen, wenn sie nicht mehr gebraucht werden, durch deinen normalen Freigabeprozess. Nicht davon ausgehen, dass das Schließen von Claude Code eine bereits deployte Anwendung stoppt.

FAQ

Hostet Claude Code die App? Das Deployment-Ziel tut das. Claude Code nutzt Tools, um den Code vorzubereiten und zu deployen; der Hosting-Anbieter führt die resultierende Anwendung aus.

Kann ich ein bestehendes GitHub-Repository deployen? Ja, wenn Lizard darauf zugreifen kann. Repository, Branch und Service durch den Git-Deployment-Workflow konfigurieren, dann die deployte Revision verifizieren.

Verbinden sich Datenbanken automatisch? Die Datenbank provisionieren, die Variable konfigurieren, die die Anwendung liest, und die Verbindung testen. Das sind separate Prüfungen.

Kann derselbe Workflow mit einem anderen Coding-Agenten funktionieren? Ein Agent, der die benötigten Tools nutzen kann, kann dieselben Deployment-Prüfungen folgen. Lies dessen eigene Berechtigungs- und Tool-Setup, statt anzunehmen, dass sich jede Umgebung wie Claude Code verhält.

Wie weiß ich, dass das Deployment abgeschlossen ist? Live-URL, erwartete Revision, gesunder Prozess und sinnvolles Anwendungs-Verhalten bestätigen. Ein erfolgreicher Build allein reicht nicht.