Variablen & Secrets

Lizard speichert Konfiguration als Secrets. Sie gibt es in zwei Bereichen — Service (der Standard) und Projekt (--global) — und sie werden in einer festgelegten Prioritätsreihenfolge in die Umgebung Ihrer App zusammengeführt. Es gibt keinen globalen Bereich auf Workspace-Ebene.

Variablen setzen

lizard secrets set ist variadisch — Sie können eine oder mehrere auf einmal setzen. Standardmäßig schreibt es in den verknüpften Service:

lizard secrets set DATABASE_URL=postgres://… LOG_LEVEL=info
lizard secrets set API_KEY=sk_live_… --service api

Fügen Sie --global hinzu, um in den Bereich Projekt zu schreiben (jeder Service im Projekt sieht ihn):

lizard secrets set NODE_ENV=production --global

Auflisten, löschen, importieren

lizard secrets list                       # current scope
lizard secrets list --show                # reveal values
lizard secrets delete OLD_KEY ANOTHER_KEY # variadic; add -y in scripts
cat .env | lizard secrets import          # KEY=value lines from stdin

secrets import liest einfache KEY=value-Zeilen und behält Anführungszeichen als Teil des Werts bei. secrets delete fragt nach einer Bestätigung; übergeben Sie -y, wenn der Befehl außerhalb eines Terminals läuft.

Im Befehlsreferenz für lizard secrets finden Sie alle Flags.

Geltungsbereich

Verwenden Sie standardmäßig den Service-Bereich. Ein kompromittierter Service kann seine eigene Umgebung lesen — ein breiterer Bereich bedeutet, dass ohne Grund mehr Anmeldedaten offengelegt werden. Reservieren Sie --global für nicht geheime, nachweislich öffentliche Werte wie LOG_LEVEL, NODE_ENV, Feature-Flags oder ein Frontend-SENTRY_DSN. Wenn Sie unsicher sind, ob ein Wert ein Secret ist, behandeln Sie ihn als solches und begrenzen Sie ihn auf den Service.

Jeder Service erhält bereits eine DATABASE_URL und eine REDIS_URL aus den Postgres- und Redis-Add-ons des Projekts (laufend oder pausiert), mit der niedrigsten Priorität. Gibt es mehrere Add-ons desselben Typs, ist nicht festgelegt, welches Sie bekommen. Um ein bestimmtes Add-on auszuwählen oder dessen private URL zu verwenden, binden Sie sie statt mit --global pro Consumer mit einer Referenz:

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

Wenn sich die Werte des Add-ons ändern, übernimmt jeder Consumer den neuen Wert beim nächsten Deployment oder bei der nächsten Variablenänderung.

Priorität

Wenn derselbe Schlüssel an mehreren Stellen definiert ist, gilt: Der letzte Schreibvorgang gewinnt:

addon-issued env  <  project secrets  <  project env  <  app env  <  app secrets  <  platform vars

Also überschreiben App-Secrets Projekt-Secrets, und Plattformvariablen (PORT, LIZARD_SERVICE_NAME, LIZARD_PROJECT_ID, LIZARD_PUBLIC_DOMAIN, LIZARD_PRIVATE_DOMAIN) werden zuletzt angewendet und können nicht überschrieben werden. PORT wird nur gesetzt, wenn der Service einen HTTP-Port hat. Eine Variable PORT, die Sie setzen, ändert das Routing nur bei einem Service, dessen Port nie gesetzt wurde. Ein Service, den lizard up angelegt hat oder dessen Port mit --port, lizard port, containerPort oder im Dashboard gesetzt wurde, behält diesen Port, und Lizard überschreibt Ihr PORT damit. Um den Port zu ändern, führen Sie lizard port <n> aus und deployen neu. Siehe An welchen Port Lizard weiterleitet.

Build-Zeit vs. Laufzeit

Die meisten Variablenänderungen werden ohne Rebuild angewendet — der Service wird neu gestartet, um sie zu übernehmen, was ein paar Sekunden dauert. Ausnahmen sind Build-Zeit-Werte, die in das Image eingebettet werden:

• Das Ändern eines VITE_*- oder NEXT_PUBLIC_*-Werts mit lizard secrets set oder in den Einstellungen eines Service startet sofort einen Rebuild der betroffenen laufenden Services (bei --global aller laufenden Services). Eine Änderung auf der Secrets-Seite des Projekts im Dashboard startet sie nur neu; führen Sie danach lizard redeploy aus.
• Lizard bettet diese Werte als ENV-Zeilen ein, und zwar für GitHub-Services (das von lizardpack generierte Dockerfile oder das Dockerfile im Stammverzeichnis des Repos) sowie für Node-Services, die mit buildCommand / startCommand gebaut werden. Ein Service mit eigenem dockerfilePath oder einer, der ohne diese Befehle mit lizard up hochgeladen wurde, erhält zur Build-Zeit keine Lizard-Variablen; kein Service erhält Build-Args außer COMMIT_SHA. Für öffentliche Werte in diesen Fällen committen Sie sie in .env.production oder schreiben sie als ENV-Zeilen in Ihr Dockerfile. Für eine Node-App, die ohne eigenes Dockerfile hochgeladen wurde, funktioniert auch ein Build-Befehl.

Siehe Build-Pipeline → Rebuild-Trigger.

Überprüfen

Der Shell-Zugriff auf Services (lizard ssh) ist deaktiviert, prüfen Sie die Werte daher auf andere Weise:

lizard logs --build --service api          # warns about every empty ${{…}} reference
lizard secrets list --service api --show   # stored values
lizard secrets list --service api --ref    # addon keys and each service's LIZARD_* / PORT keys

--ref listet nicht die eigenen Variablen und Secrets eines anderen Service. Referenzen darauf funktionieren; prüfen Sie die Schlüssel mit lizard secrets list --service <target>.

Wenn ein erwarteter Wert nicht vorhanden ist, siehe Fehlerbehebung → ein Secret oder eine Referenz wird nicht angezeigt.

Lokale Entwicklung

Führen Sie einen Befehl lokal aus, wobei die Projekt- und Service-Secrets des Service eingefügt werden:

lizard run --service api -- node scripts/seed.js

Die Werte kommen so an, wie sie gespeichert sind: ${{…}}-Referenzen bleiben wörtlicher Text, und Plattformvariablen (PORT, LIZARD_*) werden nicht eingefügt. Für ein Skript, das die Datenbank benötigt, führen Sie es mit den echten Verbindungswerten des Add-ons aus:

lizard run --service postgres -- node scripts/seed.js

Siehe was lizard run einfügt.

Siehe auch

• Service-übergreifende Referenzen — lesen Sie die Werte eines Service aus einem anderen, ohne Anmeldedaten per Copy-paste zu duplizieren.
• lizard secrets — die vollständige Befehlsreferenz.

Aktualisiert 21. Oktober 2026