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.

DATABASE_URL und REDIS_URL jedes laufenden Postgres- und Redis-Add-ons erreichen bereits jeden Service im Projekt, und zwar mit der niedrigsten Priorität. 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. Wenn Sie PORT selbst setzen, ändert sich beim nächsten Deployment der Port, an den Lizard routet, es sei denn, der Port wurde mit lizard port festgelegt.

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 startet sofort einen Rebuild der betroffenen laufenden Services (bei --global aller laufenden Services).
• 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, setzen einen Build-Befehl oder schreiben sie in Ihr Dockerfile.

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    # reference templates you can use

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 9. Oktober 2026