Google Antigravity: Wie du deine App in Produktion deployst

Deploye deine Antigravity-App auf eine öffentliche HTTPS-URL, verbinde ihre Datenbank und prüfe, ob sie echte Daten speichert. Mit Lizard kann der Agent das Deployment direkt aus demselben Projekt starten, in dem du die App gebaut hast.

1. Vorbereiten: Öffne dein Projekt in Antigravity und installiere den Lizard Skill.
2. Ziel wählen: Melde dich bei Lizard an und benenne das Projekt und den Service für das Deployment.
3. Deployen: Lass den Agenten die App, Datenbank und nötige Secrets konfigurieren, dann von GitHub oder deiner lokalen Quelle deployen.
4. Ergebnis prüfen: Öffne die öffentliche URL, erstelle einen Datensatz und lade neu. Prüfe Login, Uploads und Worker, falls deine App sie nutzt.

Deployen aus dem Antigravity-Chat

Nach der Installation des Lizard Skill gib dem Agenten diese Anfrage. Ersetze my-project durch dein Ziel:

Lese die aktuelle Lizard CLI-Anleitung. Prüfe dieses Repository und deploye eine Testkopie in das Lizard-Projekt my-project. Nutze das bestehende Build-Setup. Konfiguriere die Datenbank und alle Worker, die die App braucht. Wenn ein GitHub-Repository verbunden ist, nutze es; sonst lade den lokalen Source hoch. Gib die öffentliche URL, den deployten Revision und die Ergebnisse eines Seiten-Prüfungen sowie eines Datenbank-Schreib-/Lese-Tests zurück. Sag mir, welche Prüfungen fehlgeschlagen sind.

Falls der Agent die CLI braucht, installiere sie und lade ihre Anleitung:

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

Führe Browser-Sign-in durch, falls angefordert. Für eine bestehende Produktions-App benenne den Service und die Domain, die sich vor dem Deployment ändern können. Halte Secrets in den Service-Einstellungen, außerhalb von Repository und Browser-Bundle.

Ein erfolgreiches Ergebnis: Die öffentliche URL lädt, die App erreicht die vorgesehene Datenbank, und ein Datensatz überlebt einen Seiten-Reload. Ein Build, der als „successful“ markiert ist, prüft diese Flows nicht allein.

Wir veröffentlichen diese Anleitung bei Lizard. Wir haben den CLI-Workflow am 14. September 2026 geprüft; die weiterführenden Hosting-Referenzen unten wurden zuletzt am 9. September 2026 geprüft.

Was Antigravity zum Deployment beiträgt

Google beschreibt Antigravity als agentische Entwicklungsumgebung, deren Agenten über Editor, Terminal und Browser arbeiten können. Diese Fähigkeiten können helfen, ein Deployment vorzubereiten und zu prüfen. Die Produktions-Runtime gehört trotzdem dem Host, den du wählst. Googles Antigravity-Einführung.

Deployment-Integrationen können sich ändern. Prüfe Antigravitys aktuelle Dokumentation und das Hosting-Tool, das du nutzen willst. Nimm nicht an, dass ein Feature in der IDE bedeutet, dass jede Datenbank, jeder Worker oder jede Deployment-Anforderung bereits konfiguriert ist.

Die wichtige Wahl ist nicht, welches Tool die Dateien erzeugt hat. Sondern was die resultierende Anwendung zum Laufen braucht.

Identifiziere, was deine App enthält

Lass das Repository vom Agenten inspizieren und ein kurzes Deployment-Inventar erstellen:

• Framework, Runtime-Version und Dependency-Lockfile.
• Build-Befehl, Output-Verzeichnis und Produktions-Start-Befehl.
• Web-Services, APIs, Worker und geplante Tasks.
• Datenbank-Engine und die Variablen für die Verbindung.
• Hochgeladene Dateien, lokale Dateisystem-Schreibzugriffe und nötige Persistenz.
• Login-Provider, Callback-URLs, Payment-Webhooks und andere externe Services.

Das deckt gängige Prototyp-Annahmen auf, bevor du einen Host wählst. Ein Frontend kann eine hartcodierte Entwicklungs-API-URL enthalten. Ein generiertes Backend kann Daten in einer lokalen Datei halten. Ein Background-Task läuft vielleicht nur, solange der Entwicklungsprozess offen ist.

Wähle den Host passend zur Anwendung

Lizard ist eine Option für Web-Services, Worker und verwaltete Datenservices über die Lizard CLI. Vercel kann einen Frontend-fokussierten Workflow passen; lies unseren Vercel-Vergleich für Runtime- und Billing-Unterschiede. Cloud Run bietet Services, Jobs und Worker-Pools mit unterschiedlichen Zwecken. Cloud Run-Übersicht.

Wenn Google Cloud bereits dein Ziel ist, beschreibt Googles Cloud Run MCP Codelab einen tool-basierten Deployment-Workflow. Lizard zu wählen ist eine Hosting-Entscheidung, keine von Antigravity geforderte Voraussetzung.

Nutze die richtige Quelle für das Deployment

Wenn das Projekt ein zugängliches GitHub-Repository hat, verbinde dieses Repository und den gewünschten Branch mit dem Service. Das gibt späteren Commits einen wiederholbaren Weg zum Deployment. Prüfe das Root-Verzeichnis in einem Monorepo. Folge der GitHub-Integrationsanleitung.

Für Code, der nur lokal existiert, nutze den Source-Upload-Workflow. Der Agent sollte das gewünschte Projekt und den Service explizit auswählen oder erstellen, bevor er hochlädt. Er sollte ein bestehendes Git-Deployment nicht stillschweigend durch eine hochgeladene Kopie ersetzen.

In beiden Fällen halte generierte Dateien und Secrets aus der Versionskontrolle raus. Ein Produktions-Build sollte das Lockfile des Repositorys und eine mit der Anwendung kompatible Runtime-Version nutzen.

Mache Daten und Konfiguration explizit

Managed Postgres bereitzustellen ist nur der erste Teil eines Datenbank-Setups. Setze die Verbindungsvariable, die die Anwendung liest, und führe ihre Migrationen in einem kontrollierten Release-Schritt aus. Teste Schreiben und Lesen mit der vorgesehenen Datenbank.

Wenn die App einen Worker nutzt, führe ihn als separaten Service mit eigenem Befehl und relevanten Variablen aus. Bei Dateien unterscheide temporäre Arbeit von Daten, die einen Restart oder Redeployment überleben müssen. Nutze passenden Speicher und teste diesen Lebenszyklus.

Frontend-Variablen verdienen besondere Aufmerksamkeit: Werte, die in ein Browser-Bundle landen, sind öffentlich. Packe keine Datenbank-Passwörter oder Server-API-Secrets in Frontend-Build-Einstellungen. Halte serverseitige Secrets beim Service, der sie braucht.

Verifiziere einen echten Produktions-Flow

Öffne die deployte URL direkt in einer frischen Browser-Session. Teste Routes, ohne dich auf einen Tab zu verlassen, der noch Entwicklungsstate hat. Prüfe dann die Flows, die die App Nutzern verspricht.

Bei Payment-Integrationen nutze den Testmodus des Anbieters vor einer echten Transaktion. Bei E-Mail prüfe eine Test-Zustellung und die darin enthaltenen Links. Prüfe Logs und Ressourcennutzung nach dem Test, statt eine optisch korrekte Seite als finales Ergebnis zu werten.

Schätze Hosting-Kosten getrennt vom Coding

Entwicklungstool und Produktionsservices haben unterschiedliche Kosten. Rechne alle Web-Prozesse, Worker, Datenbanken, Storage und Traffic in die Hosting-Schätzung ein. Lizard nutzt pay as you go ohne monatliches Abonnement. Prüfe Ressourcenpreise, Trial-Credit-Ablauf und Zahlungsgebühren in den Lizard-Preisen; andere Hosts können Plan-Gebühren und Kontingente haben.

Ein Low-Traffic-Service kann trotzdem Speicher verbrauchen, während er auf Arbeit wartet. Ein request-getriebener Host kann Compute herunterskalieren, aber für behaltene Daten oder andere Services weiter abrechnen. Nutze gemessenes Verhalten, statt anzunehmen, dass ein Prototyp unbegrenzt in ein Free-Tier passt.

FAQ

Hostet Antigravity meine App automatisch? Die App braucht ein Produktionsziel. Antigravity kann beim Nutzen von Deployment-Tools helfen, aber prüfe, welcher Service die App läuft und welche Ressourcen er erstellt hat.

Kann ich deployen, ohne jeden Befehl manuell einzutippen? Ein Agent mit den nötigen Tools kann den Workflow fahren. Du musst das Ziel, Credentials und erlaubte Änderungen aber festlegen und das gemeldete Ergebnis prüfen.

Warum klappt der Preview, aber die deployte App scheitert? Häufige Ursachen: Development-only-Commands, fehlende Variablen, falscher Port, unerreichbare Datenbank oder Callback-URL, die noch auf localhost zeigt. Fang bei Build- und Runtime-Logs an.

Kann ich meine bestehende Datenbank behalten? Ja, wenn der deployte Service sie sicher erreichen kann und Latenz sowie Transferkosten akzeptabel sind. Teste diesen Pfad, bevor du die Daten ebenfalls verschiebst.

Was soll nach dem ersten Deployment passieren? Halte den Release-Prozess wiederholbar, überwache Fehler und Nutzung, und teste Backups. Die CLI-Konfigurationsreferenz und die Support-Seite geben die nächsten Schritte für Lizard.