Logs, Checks und Datenbank

Kommt später: gooddeploy logs und gooddeploy checks report liefert die Plattform; Postgres (gooddeploy db …) noch nicht. Bis dahin endet db mit „noch nicht verfügbar“ (Exit-Code 6). Auf einer Plattform ohne gespeicherte Checks endet auch checks report so.

Logs ansehen: logs

gooddeploy logs                       # Live-Version
gooddeploy logs --env preview         # Previews
gooddeploy logs k7m2q9xa              # ein bestimmtes Deployment
gooddeploy logs k7m2q9xa --build      # sein Build-Log
gooddeploy logs --since 10m --follow  # letzte 10 Minuten, dann live weiter

Läuft deine Anwendung auf mehreren Servern, steht vor jeder Zeile der Server in eckigen Klammern, z. B. [node-1] GET / 200. Mit --follow (kurz -f) zeigt gooddeploy neue Zeilen, bis du mit Strg+C abbrichst; das endet normal mit Exit-Code 0.

Mit --json kommt je Zeile ein JSON-Objekt mit line, node, stream und at. Geheimnisse aus deinen Umgebungsvariablen erscheinen in Logs als [maskiert].

Eigene Checks melden: checks report

Neben den eingebauten Prüfungen (Build, Health, Smoke) kann deine CI eigene Checks an ein Deployment melden, z. B. das Ergebnis von E2E-Tests:

gooddeploy checks report k7m2q9xa e2e pending
npm run test:e2e        # Tests gegen die Preview
gooddeploy checks report k7m2q9xa e2e success --url "$CI_JOB_URL" --description "42 Tests grün"

Der Zustand ist pending, success oder failure; eine neue Meldung ersetzt die vorige. Die eingebauten Namen build, health, smoke und tests setzt nur die Plattform; eine Meldung unter diesen Namen lehnt sie mit VALIDATION_FAILED ab. Check-Namen bestehen aus Kleinbuchstaben, Ziffern, -, _ und . (z. B. e2e). --url muss eine http(s)-Adresse sein, --description höchstens 500 Zeichen lang. Dafür braucht der Zugangscode das Recht deploy.

Pflicht-Checks legst du in gooddeploy.json unter checks.required fest (z. B. ["e2e"]). Fehlt einer oder ist er nicht grün, lehnt promote ab (REQUIRED_CHECK_MISSING bzw. REQUIRED_CHECK_FAILED). Die eingebauten Checks build, health und smoke sind immer Pflicht; sie laufen bei jedem Deploy von selbst. Ein Deployment, das vor dem Update der Plattform gebaut wurde, hat sie noch nicht: Deploye es einmal neu, bevor du es live schaltest. Das gilt auf Plattformen, die Checks speichern (gooddeploy.de ab 0.0.2); auf allen anderen kommt es später.

Datenbank: db info und db dump

gooddeploy db info

Postgres kunde-website
  UMGEBUNG  DATENBANK              GRÖSSE   VERBINDUNGEN
  Live      kunde_website_prod     12,0 MB  3
  Previews  kunde_website_preview  300 KB   0

Live und Previews haben je eine eigene Datenbank. gooddeploy db ohne Unterbefehl macht dasselbe wie db info.

gooddeploy db dump                       # kunde-website-prod-2026-10-18.dump
gooddeploy db dump -o vor-update.dump    # eigener Dateiname

db dump lädt eine Sicherung der Live-Datenbank im Format von pg_dump -Fc herunter. Die Datei ist nur für dich lesbar; eine vorhandene Datei überschreibt gooddeploy nie, und ein abgebrochener Download hinterlässt keine halbe Datei. Einspielen kannst du sie z. B. in eine lokale Datenbank:

pg_restore --no-owner -d meine_lokale_db kunde-website-prod-2026-10-18.dump

db info braucht read, db dump braucht read:sensitive (siehe Rechte).

Verbindung aus deiner App: DATABASE_URL und DATABASE_URL_UNPOOLED

Hat dein Projekt eine Datenbank, setzt gooddeploy in jeder Version zwei Variablen, Previews und Live jeweils mit ihrer eigenen Datenbank:

Beide nutzen denselben Zugang und dieselbe Datenbank; nur der Weg ist anders. Über DATABASE_URL teilt sich deine App wenige Verbindungen, jede Transaktion kann eine andere bekommen. Das reicht für Abfragen, aber nicht für Sperren über mehrere Transaktionen, SET für die ganze Verbindung oder LISTEN. Genau das brauchen Migrations-Werkzeuge wie prisma migrate. Über DATABASE_URL_UNPOOLED behält eine Verbindung ihre Sitzung bis zum Ende; davon gibt es je Datenbank nur wenige gleichzeitig, also nicht für den normalen Betrieb nutzen.

Mit Prisma 6 trägst du beide in schema.prisma ein; prisma migrate deploy nimmt dann von selbst die direkte Verbindung:

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DATABASE_URL_UNPOOLED")
}

Ein start-Skript wie prisma migrate deploy && next start führt gooddeploy nicht aus: Es startet Next.js mit node server.js. Wie du Migrationen ausrollst, wie Prisma 7 und Drizzle eingerichtet werden, wie du lokal entwickelst und welche Grenzen der Pool hat, steht in Datenbank in deiner App nutzen.

Die Namen sind dieselben wie bei Vercel und Neon; eine App, die dort läuft, braucht dafür keine Änderung. Setzt du eine der beiden Variablen selbst (gooddeploy env add), gilt dein Wert, und gooddeploy warnt dich dabei.