# Ein Secret oder Verweis erscheint nicht in meinem Service Du hast ein Secret oder einen `${{name.KEY}}`-Verweis gesetzt, erneut bereitgestellt, und der laufende Service sieht den erwarteten Wert trotzdem nicht. ## Was das bedeutet Der von dir gesetzte Wert ist nie in die zusammengeführte Umgebung des Service gelangt — oder etwas anderes in der Zusammenführung hat ihn überschrieben, bevor die App gestartet wurde. ## Warum das passieren kann - **Das Verweisziel oder der Schlüssel existiert nicht.** Ein Verweis auf einen fehlenden Service-/Add-on-Namen oder auf einen Schlüssel, den dieses Add-on nicht bereitstellt, wird zu einem **leeren String** aufgelöst, statt das Deployment fehlschlagen zu lassen. Es gibt keinen Fehler als Hinweis — der Service startet einfach mit einem leeren Wert. - **Etwas mit höherer Priorität hat ihn überschrieben.** Werte werden in einer festen Reihenfolge zusammengeführt — `addon-issued env < project secrets < project env < app env < app secrets < platform vars` — daher kann ein projektbezogenes (`--global`) Secret stillschweigend von einem servicebezogenen Secret mit demselben Schlüssel verdeckt werden, und Plattformvariablen (`PORT`, `LIZARD_SERVICE_NAME`, `LIZARD_PROJECT_ID`, `LIZARD_PUBLIC_DOMAIN`) haben immer Vorrang und können überhaupt nicht überschrieben werden. - **Du hast einen Build-Zeit-Wert geändert, aber keinen neuen Build ausgeführt.** Die meisten Variablenänderungen werden ohne Rebuild übernommen — der Service startet neu, um sie zu übernehmen. `VITE_*`- und `NEXT_PUBLIC_*`-Werte sind die Ausnahme — sie werden in die gebauten Assets eingebettet, daher übernimmt ein einfacher Neustart keinen neuen Wert; der Service braucht einen frischen Build. ## Mögliche Lösungen ### Prüfe, was der laufende Service tatsächlich sieht Das ist maßgeblich — es zeigt die Umgebung des Live-Containers, nicht das, von dem du glaubst, dass du es gesetzt hast: ```bash lizard ssh --service api -- env | grep DATABASE_URL ``` Wenn der Schlüssel fehlt oder leer ist, ist das Verweisziel bzw. der Schlüssel falsch, oder für diesen Geltungsbereich ist nichts gesetzt. Prüfe den Add-on- oder Service-Namen mit `lizard ps` noch einmal und den Schlüssel anhand der [dokumentierten Variablen](https://lizard.build/de/docs/addons) des Addons. ### Prüfe auf eine Kollision zwischen Geltungsbereichen Liste Secrets in beiden Geltungsbereichen auf und vergleiche sie: ```bash lizard secrets list --service api --show lizard secrets list --global --show ``` Denke daran: **App-Secrets überschreiben Projekt-Secrets** — wenn ein servicebezogener Wert für denselben Schlüssel existiert, hat er Vorrang vor allem, was mit `--global` gesetzt wurde. ### Nach einer Änderung zur Build-Zeit neu bauen Wenn der geänderte Schlüssel `VITE_*` oder `NEXT_PUBLIC_*` ist, löse einen echten Rebuild statt eines Neustarts aus: ```bash lizard redeploy --service api ``` Siehe [Build-Zeit vs. Laufzeit](https://lizard.build/de/docs/variables#build-time-vs-runtime) und [Build-Pipeline → was einen Rebuild auslöst](https://lizard.build/de/docs/concepts/build-pipeline#what-triggers-a-rebuild). ## Siehe auch - [Variablen & Secrets](https://lizard.build/de/docs/variables) — Geltungsbereiche und Priorität. - [Service-übergreifende Verweise](https://lizard.build/de/docs/variables/references) — Verweissyntax und Auflösung.