Mein Service wird deployt, wird aber nie healthy

Der Build ist erfolgreich und ein neuer Pod startet, aber der Deploy wird als fehlgeschlagen markiert oder die neue Version erhält nie Traffic.

Was das bedeutet

Der Health-Check der Plattform — eine TCP-Probe auf den Port deiner App — schlägt nie an, daher wird der Traffic nie auf den neuen Pod umgeschaltet. Lizard wartet etwa 30 Sekunden und markiert den Deploy dann als fehlgeschlagen. Ein Service, der bereits lief, liefert weiterhin seine vorherige Version aus, außer er hat ein angehängtes Volume: Dann stoppt zuerst sein alter Pod, und der Service ist nicht erreichbar, bis ein Deploy gelingt. Ein erster Deploy wird als abgestürzt angezeigt.

Warum das passieren kann

• Deine App lauscht nicht auf dem erwarteten Port. Lizard setzt eine PORT-Umgebungsvariable (Standard-Container-Port 3000) und prüft, ob deine App dort erreichbar ist. Wenn deine App fest auf einen anderen Port eingestellt ist oder nie einen Port bindet, schlägt der Health-Checks nie an. Ein Python-App ist der übliche Fall: gunicorn und uvicorn binden an 127.0.0.1, sofern du nichts anderes angibst, und die Probe kommt von außerhalb des Prozesses. Python-App-Hosting enthält die Zeile --bind 0.0.0.0:$PORT, die jedes Framework braucht.
• Der Service-Port passt nicht zum Image. Wenn lizard up einen Service aus einem Dockerfile ohne EXPOSE-Zeile anlegt, setzt es den Port 3000, auch wenn das Basis-Image auf einem anderen Port lauscht, etwa nginx auf 80. Eine Variable PORT ändert diesen Port nicht. Führe lizard port <n> aus und deploye neu, oder füge eine EXPOSE-Zeile hinzu. Siehe An welchen Port Lizard weiterleitet.
• Der Service ist versehentlich im Worker-Modus. Das Setzen von containerPort=0 versetzt einen Service in den Worker-Modus, wodurch der Health-Checks und die Registrierung beim Load Balancer vollständig übersprungen werden. Ein Service, der eigentlich HTTP bereitstellen soll, aber auf containerPort=0 umgestellt wurde, wird “erfolgreich” deployt und liefert dann einfach nie etwas aus — der Worker-Modus verdeckt das zugrunde liegende Startproblem, statt es sichtbar zu machen.

Mögliche Lösungen

Den aktuellen Port prüfen

lizard port --service api

Wenn hier worker mode ausgegeben wird, hat der Service containerPort=0. Setze ihn wieder auf einen echten Port zurück, wenn dieser Service HTTP bereitstellen soll:

lizard port 3000 --service api
lizard redeploy --service api

Bestätigen, dass deine App dort lauscht, wo Lizard es erwartet

Prüfe die Runtime-Logs auf Startfehler und auf die Adresse, auf der die App laut Log lauscht. Vergleiche sie mit dem Service-Port, den Lizard der App als PORT übergibt:

lizard logs --service api
lizard port --service api

Siehe auch

• Background Workers — wann containerPort=0 sinnvoll ist (und wann nicht).
• Bereitstellungen → lifecycle — wo der Health-Checks innerhalb eines Deploys stattfindet.

Aktualisiert 21. Oktober 2026