So deployen Sie eine Cursor-App mit PostgreSQL

Um eine Cursor-App mit PostgreSQL zu deployen, führen Sie die Anwendung auf einem Host aus, erstellen Sie eine Datenbank, verbinden Sie sie über eine server-seitige DATABASE_URL, und wenden Sie Ihre Schema-Migrationen an. Cursors Agent kann dies über die Lizard CLI erledigen. Nach dem Deployment prüfen Sie die öffentliche URL und bestätigen, dass ein Datensatz eine frische Browser-Sitzung und ein erneutes Deployment übersteht.

Dieser Leitfaden richtet sich an eine Next.js-Anwendung, die Sie bereits lokal ausführen. Er nutzt Lizard für die App und Managed Postgres für die Datenbank. Sie können die Prompts in Cursors Desktop-Agent verwenden, dessen Plan prüfen und die von Ihnen genehmigten Schritte ausführen lassen.

Was muss vom Laptop weg?

Betrachten Sie eine Aufgaben-App: Sie fügen eine Aufgabe hinzu, markieren sie als erledigt und kommen später wieder. Das Veröffentlichen der Seite ist nur ein Teil des Bereitstellungen. Der Server muss die Datenbank erreichen, die Tabellen müssen existieren, und neue Anfragen müssen die gespeicherten Daten lesen können.

Ihre lokale Datenbank und die .env.local-Datei wandern nicht mit einem GitHub-Push mit. Entscheiden Sie, welche Daten Sie behalten müssen. Eine frische Datenbank eignet sich für eine neue App; das Verschieben einer bestehenden Datenbank erfordert einen separaten Export- und Import-Plan.

1. Produktions-Build in Cursor prüfen

Öffnen Sie den Anwendungsordner in Cursor. Bitten Sie den Agenten, das Projekt zu prüfen, bevor er die Deployment-Einstellungen ändert:

Prepare this Next.js app for deployment with PostgreSQL. Read its package.json,
lockfile, Next.js configuration, database client, and migration files.

Run the existing checks and production build using this project's package
manager. Identify the start command, port, required environment-variable
names, and production migration command. Do not print secret values.

Check whether any page queries the database during the build. Explain what
must be available at build time and what the app can read at request time.
Show any fixes needed before deploying.

Ein Entwicklungsserver kann funktionieren, während der Produktions-Build fehlschlägt. Für ein standardmäßiges Next.js-Node.js-Deployment nutzt der Build next build und der Server next start. Static Export und Standalone Output benötigen andere Start-Einstellungen. Folgen Sie dem Next.js-Deployment-Leitfaden für die Konfiguration, die Ihre App nutzt.

Behalten Sie die Lockfile in der Versionsverwaltung. Halten Sie Datenbank-Zugangsdaten daraus fern. Eine Variable wie NEXT_PUBLIC_DATABASE_URL würde ein Secret an den Browser preisgeben: Next.js bindet NEXT_PUBLIC_*-Werte zur Build-Zeit in das Client-JavaScript ein. Nutzen Sie eine rein server-seitige DATABASE_URL. Die Next.js-Dokumentation zu Umgebungsvariablen erklärt den Unterschied.

2. Cursor die aktuellen Deployment-Anweisungen geben

Cursors Agent kann Terminal-Befehle ausführen. Installieren Sie die Lizard CLI in Cursors Terminal, falls sie noch nicht verfügbar ist:

npm install -g @lizard-build/cli

Bitten Sie dann den Agenten, folgendes auszuführen und einzulesen:

lizard skills get core --json

Der Befehl liefert den Leitfaden, der zur installierten CLI passt. Dieser Workflow nutzt die CLI direkt; Sie müssen keinen MCP-Server konfigurieren. Falls Lizard eine Authentifizierung anfordert, schließen Sie den Anmelde-Link ab, bevor Sie fortfahren.

Fügen Sie diesen Deployment-Prompt in Cursor ein:

Deploy this app with Lizard and Managed Postgres. First read the full output
of `lizard skills get core --json`. Check the current project link and git
remote, then show me the target project, service, region, and resources.
Wait for approval before creating resources or changing a live service.

If this app has a GitHub remote, connect that repository without starting
the first build. If it has no GitHub remote, use local source upload.

Create or select the intended database. Set DATABASE_URL on the app service
using a reference to that database's actual name. Configure the app's other
required variables and its reviewed production migration command before
deploying. Keep secret values out of the chat and repository.

Use the build settings this project needs. Read build and runtime logs,
check the final deployment status, and return the public URL. Test the
app's database-backed action and report what passed or failed.

Der Coding-Agent-Leitfaden enthält die vollständigen Befehle für beide Quellpfade. Halten Sie diesen Leitfaden bereit, während Sie die Arbeit des Agenten prüfen.

3. Postgres vor dem ersten Bereitstellen verbinden

Ein Service kann erfolgreich bauen und dann bei seiner ersten Datenbank-Anfrage fehlschlagen. Konfigurieren Sie die Verbindung, bevor Sie diesen ersten Build oder Release starten.

Für einen neuen Service namens web im vorgesehenen verknüpften Projekt, mit der App im Stammverzeichnis des GitHub-Repositorys, sieht der Verbindungsschritt so aus. Ersetzen Sie YOUR_ORG/YOUR_REPO durch Ihr Repository:

lizard add --repo YOUR_ORG/YOUR_REPO --name web --no-deploy --json
lizard add postgres --json
lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service web --json

Nutzen Sie einen bestehenden Service oder eine bestehende Datenbank weiter, wenn dies das vorgesehene Ziel ist. Das Beispiel geht davon aus, dass die neue Datenbank postgres heißt. Gibt Lizard einen anderen Namen zurück, verwenden Sie diesen in der Referenz. Die einfachen Anführungszeichen verhindern, dass Ihre Shell ${{...}} interpretiert.

--no-deploy lässt Zeit, die Datenbank, den Migrations-Befehl und andere erforderliche Einstellungen zu konfigurieren. Bei einem Monorepo oder einem anderen Branch setzen Sie zusätzlich das App-Verzeichnis und den Branch, bevor Sie deployen. Details finden Sie unter Managed Postgres.

Falls Sie kein GitHub-Remote haben, kann der Agent einen leeren Service erstellen und den lokalen Quellcode mit lizard up hochladen. Für einen GitHub-Service nutzen Sie dessen GitHub-Deployment-Flow für spätere Updates: lizard up ändert den Service auf hochgeladenen Quellcode. Die beiden Pfade sind separate Entscheidungen.

4. Das Schema anwenden, das Ihre App erwartet

Das Erstellen von PostgreSQL erzeugt noch nicht die Tabellen Ihrer App. Ein Verbindungsfehler und ein Fehler wegen fehlender Tabellen erfordern unterschiedliche Lösungen.

Nutzen Sie das Migrations-Tool, das bereits im Projekt ist. Für Prisma-Projekte mit committeten Migrations-Dateien wendet prisma migrate deploy ausstehende Migrationen in der Produktion an. Prisma empfiehlt, dies über den Deployment-Prozess auszuführen. Es generiert keinen Prisma Client, daher benötigt der Build weiterhin jeden Generierungsschritt, den Ihr Projekt erfordert. Die Prisma-Deployment-Dokumentation deckt dieses Setup ab.

Lassen Sie Cursor den preDeployCommand des Services mit dem geprüften Migrations-Befehl konfigurieren. Stellen Sie sicher, dass das gebaute Image die Migrations-Dateien, das erforderliche CLI-Paket und dessen Konfiguration enthält. Falls die Migration eine Datenbankverbindung braucht, muss diese verfügbar sein, wenn der Befehl läuft. Vermeiden Sie einen Development-Reset-Befehl gegen Daten, die Sie behalten müssen.

Next.js kann auch während des Builds einer Seite Daten lesen. Eine für den laufenden Server konfigurierte Datenbankverbindung beweist nicht, dass eine Build-Time-Abfrage gelingt. Bitten Sie Cursor zu prüfen, wann jede Abfrage läuft, und das Rendering-Verhalten zu nutzen, das die Seite braucht. Der Next.js Self-Hosting-Leitfaden behandelt Laufzeit- und Build-Time-Verhalten.

5. Gespeicherte Daten an der öffentlichen URL prüfen

Lesen Sie das Deployment-Ergebnis und öffnen Sie dessen HTTPS-URL. Testen Sie das Feature, das Postgres braucht, statt nach dem Laden der Startseite aufzuhören.

Für eine Aufgaben-App nutzen Sie diese Sequenz:

1. Erstellen Sie eine Aufgabe mit einem wiedererkennbaren Namen, z. B. deployment-check-0909.
2. Laden Sie die Seite neu und bestätigen Sie, dass die Aufgabe erscheint.
3. Öffnen Sie ein privates Browser-Fenster, melden Sie sich ggf. beim selben Konto an, und prüfen Sie die Aufgabe erneut. Das deckt Apps auf, die nur im Browser-Speicher sichern.
4. Deployen Sie eine kleine Code-Änderung über denselben Quellpfad. Bestätigen Sie, dass die Aufgabe noch existiert und Sie sie aktualisieren können.

Passen Sie die Prüfung an Ihre App an: Eine Buchung, Notiz oder Formular-Eingabe kann denselben Zweck erfüllen. Nutzen Sie Testdaten und prüfen Sie, dass jedes Konto nur auf seine eigenen Datensätze zugreifen kann, bevor Sie Benutzer einladen.

Falls eine Prüfung fehlschlägt, geben Sie Cursor die fehlgeschlagene Aktion und bitten Sie den Agenten, die Service-Logs zu prüfen:

lizard logs --build --service web --json
lizard logs --service web --json
lizard ps --json

Der erste Befehl liest Build-Logs, der zweite Anwendungs-Logs. Halten Sie die Logs-Referenz offen für Filter und Fehlersuche.

Warum funktioniert eine Cursor-App lokal, scheitert aber nach dem Deployment?

Die deployte App kann andere Variablen, eine neue Datenbank oder einen anderen Start-Befehl haben. Ordnen Sie das Symptom dem passenden Prüfen zu:

Bitten Sie den Agenten, die in den Logs gezeigte Ursache zu beheben. Wiederholte Bereitstellungen mit derselben Konfiguration beheben keine fehlende Variable oder Tabelle.

Was kostet das Hosten der App und von Postgres?

Lizard nutzt Pay-as-you-go ohne monatliches Abo. Neue Konten erhalten 10 $ Gratis-Guthaben, gültig für 31 Tage. Gekaufte Credits verfallen nicht. Die Ressourcennutzung wird vom Kontoguthaben abgebucht; der Auflade-Bildschirm zeigt eventuelle Zahlungsgebühren vor der Bestätigung an. Siehe aktuelle Preise und Zahlungsbedingungen.

Die Anwendung und Managed Postgres verbrauchen beide Ressourcen. Lizard berechnet nur für aktive Ressourcen, mit Kosten für CPU, Speicher, Storage und ausgehenden Traffic gemäß den Plan-Bedingungen. Das Stoppen einer App stoppt keine separate Datenbank, und beibehaltene Volume-Storage kann weiterhin Kosten verursachen.

Messen Sie App und Datenbank gemeinsam unter der erwarteten Last. Ein Test-Guthaben ist ein Weg, das Deployment zu testen; es ist kein Versprechen auf dauerhaft kostenloses Hosting oder feste monatliche Kosten für jede App.

Fragen vor dem Bereitstellen

Muss ich meine App aus Cursor exportieren?

Bei einem lokalen Projekt liegen Ihre Quelldateien bereits im Projektordner. Deployen Sie diesen Code über ein verbundenes GitHub-Repository oder einen lokalen Upload. Prüfen Sie, dass die Quelle die zum Bauen und Ausführen nötigen Dateien enthält.

Zahlt ein Cursor-Abo für Lizard-Hosting?

Nein. Cursor und Lizard sind getrennte Dienste. Dieser Workflow nutzt Cursor, um die Lizard CLI zu bedienen; das Lizard-Konto bezahlt für die deployte App und Datenbank nach seinem eigenen Plan.

Kann ich meine bestehende PostgreSQL-Datenbank behalten?

Ja, wenn der deployte Server sie erreichen kann und ihre Verbindungseinstellungen den Anforderungen des Datenbank-Anbieters genügen. Konfigurieren Sie den server-seitigen Connection-String, prüfen Sie den Netzwerkzugriff, und führen Sie dieselben Anwendungstests aus. Sie müssen keine weitere Datenbank erstellen, nur um diesen Workflow zu nutzen.

Brauche ich eine eigene Domain vor dem Bereitstellen?

Beginnen Sie damit, die öffentliche Adresse zu prüfen, die Lizard für Ihren Web-Service zurückgibt. Sobald sie funktioniert, folgen Sie den Anweisungen für Custom Domains, um Ihren Hostnamen zu verbinden und die DNS-Einträge zu verifizieren. Falls Ihre App Login-Callbacks nutzt, aktualisieren Sie diese URLs ebenfalls.

Öffnen Sie Ihr Projekt in Cursor und starten Sie mit dem Vorbereitungs-Prompt oben. Für die exakte Deployment-Sequenz nutzen Sie den Coding-Agent-Leitfaden.