Umgebungsvariablen

Kommt später: Die Befehle gooddeploy env … gibt es schon, die Plattform liefert die Verwaltung der Variablen aber noch nicht. Bis dahin enden sie mit „noch nicht verfügbar“ (Exit-Code 6), und goodDEV richtet Variablen für dich ein.

Überblick

gooddeploy env ls                               # Variablen anzeigen, Werte maskiert
gooddeploy env add DATABASE_URL --production    # Wert verdeckt eingeben
gooddeploy env rm DATABASE_URL --production     # Variable löschen
gooddeploy env pull                             # Werte der Previews nach .env.local

Jede Variable gilt für eine Umgebung: Previews oder Live (Produktion). Die Schalter sind bei allen Unterbefehlen gleich:

Namen bestehen aus Großbuchstaben, Ziffern und _ und beginnen nicht mit einer Ziffer, z. B. DATABASE_URL oder NEXT_PUBLIC_SITE_URL.

Variablen anzeigen: env ls

gooddeploy env ls

Variablen kunde-website
  NAME                  UMGEBUNG  ART       WERT    GEÄNDERT
  DATABASE_URL          Live      Laufzeit  ••••••  vor 30 min · Bernd
  NEXT_PUBLIC_SITE_URL  Previews  Build     ••••••  vor 2 h · Bernd

Werte zeigt gooddeploy nie an, auch nicht mit --json. Mit --preview oder --production siehst du nur eine Umgebung. gooddeploy env ohne Unterbefehl macht dasselbe wie env ls.

Variablen setzen: env add

gooddeploy env add DATABASE_URL --production
? Wert für DATABASE_URL (Eingabe verdeckt):

Den Wert gibst du nie als Argument an, denn er stünde sonst in der Shell-Historie. Im Terminal fragt gooddeploy verdeckt danach; in Skripten liest es den Wert von der Standardeingabe (ein abschließender Zeilenumbruch fällt weg, mehrzeilige Werte bleiben erhalten):

printf '%s' "$DATABASE_URL" | gooddeploy env add DATABASE_URL --production

gooddeploy env add NAME wert oder NAME=wert endet mit Exit-Code 1 und diesem Hinweis. Eine geänderte Variable wirkt mit dem nächsten Deployment.

Vorsicht bei NEXT_PUBLIC_

Next.js baut Variablen mit NEXT_PUBLIC_ in das JavaScript für den Browser ein; jeder Besucher kann sie lesen. Klingt der Name nach einem Geheimnis (SECRET, TOKEN, PASSWORD, API_KEY …), warnt gooddeploy mit ⚠. Ohne --build erinnert es außerdem daran, dass solche Variablen beim Build gebraucht werden.

Sofort anwenden mit --apply

Mit --apply erzeugt gooddeploy für eine Laufzeit-Variable sofort ein neues Deployment aus demselben Image, ohne neuen Build, und zeigt den Fortschritt bis „bereit“. Das dauert Sekunden statt Minuten.

• Bei --preview ist danach die neue Preview bereit.
• Bei --production fragt gooddeploy „Jetzt live schalten? (J/n)“ und schaltet wie promote um. Mit --yes ohne Rückfrage; ohne Terminal und ohne --yes nennt es nur den Befehl gooddeploy promote <id> --yes.

Build-Variablen brauchen immer einen neuen Build: --build --apply endet mit Exit-Code 1.

Variablen löschen: env rm

gooddeploy env rm DATABASE_URL --production

Die Variable verschwindet mit dem nächsten Deployment. Gibt es sie in der gewählten Umgebung nicht, endet env rm mit NOT_FOUND (Exit-Code 1).

Werte lokal nutzen: env pull

gooddeploy env pull                # Previews
gooddeploy env pull --production   # Live

env pull schreibt die Werte einer Umgebung in die Datei .env.local im aktuellen Ordner, so wie Next.js sie liest (NAME="wert", Zeilenumbrüche als \n). Die Datei ist nur für dich lesbar. Ist sie nicht von git ignoriert, warnt gooddeploy: Trag dann .env*.local in deine .gitignore ein.

Eine vorhandene .env.local überschreibt env pull nur nach Rückfrage bzw. mit --yes. Mit --json stehen im Ergebnis nur die Namen, nie die Werte.

Rechte

env ls braucht read, env add und env rm brauchen deploy, env pull braucht read:sensitive, weil es die Werte herausgibt (siehe Rechte).

Geheimnisse in Ausgaben

gooddeploy schreibt Werte nie in seine Ausgabe. Nennt eine Fehlermeldung der Plattform den gerade eingegebenen Wert, ersetzt gooddeploy ihn durch [maskiert], sobald er mindestens 6 Zeichen hat. Die Plattform selbst maskiert bekannte Werte in Build-Logs und Meldungen ebenso.