Bekannte Probleme
Diese Seite listet Verhalten von Lizard auf, das Sie prüfen sollten, bevor Sie sich auf einen Workflow verlassen: Pause und Ablauf von Sandboxen, Redeploys, die keine Rollbacks sind, Vorrang des Dockerfile und behobene Probleme mit dem Datum ihrer Überprüfung. Ein zur Prüfung eingereichter Code-Fix ist keine Garantie für einen laufenden Dienst.
Pause und Ablauf von Sandboxen
connect setzt eine pausierte oder gestoppte Sandbox nicht fort, und Fork gibt bei angehängtem Volume HTTP 409 zurück, bei einer Pod-Sandbox HTTP 501; siehe den Lebenszyklus von Sandboxes.
Eine Pause schließt offene Netzwerkverbindungen. Lassen sich die Prozesse nicht speichern, läuft die Sandbox weiter und meldet den Grund in pauseError. Eine pausierte Sandbox lässt sich nur auf ihrem eigenen Node fortsetzen; fällt dieser Node aus, geht der pausierte Zustand verloren.
Nach dem Stopp einer Sandbox bleiben nur Dateien auf einem angehängten Volume aus Persistent Volumes unter /workspace erhalten, und Volumes liegen auf einem einzelnen Knoten. Exportieren Sie Dateien, die einen Knotenausfall überstehen müssen. Siehe Speicher und Abrechnung.
Redeploy ist kein Rollback
lizard redeploy baut die ausgewählte Quelle mit der aktuellen Konfiguration erneut. Dabei wird kein vorheriger Build ausgewählt. Ein fehlgeschlagener Build und ein fehlgeschlagener Start haben unterschiedliche Auswirkungen; prüfen Sie den aktiven Dienst und seine Logs, bevor Sie einen Wiederherstellungsschritt wählen. Gehen Sie nicht davon aus, dass jede Runtime bei einem fehlgeschlagenen Start weiterhin das alte Release ausliefert.
Vorrang des Dockerfile
Explizite Build- oder Start-Befehle haben Vorrang vor einem Dockerfile im Repository. Entfernen Sie diese Überschreibungen, wenn Sie dockerfilePath auswählen. Schon eine Aktualisierung der Einstellungen kann einen Build starten, prüfen Sie daher die Ereignisse, bevor Sie ein weiteres Redeploy auslösen. Siehe Fehlerbehebung für Dockerfile.
Vorlagen und MCP
Die Verfügbarkeit von Vorlagen hängt von Region und Pool-Kapazität ab, und die öffentliche CLI bietet keinen Upload eigener Vorlagen. Prüfen Sie die Werkzeugversionen in der Sandbox. Der Katalog steht unter Laufzeit und Vorlagen.
Lizard Skill verwendet Lizard CLI und stellt keinen MCP-Transport bereit. Für MCP-Clients verwenden Sie den gehosteten Lizard MCP Server; siehe Lizard MCP. Das Hosting eines eigenen entfernten MCP-Servers ist ein separates Application-Deployment; siehe den Leitfaden.
Änderungen am Service-Port: behoben und verifiziert am 2026-09-09
Die Prüfung vom 7. September ergab HTTP 503, nachdem ein Upload-Dienst von Port 3000 auf 80 geändert wurde, obwohl ein bereiter Prozess vorhanden war. Der Fix in Produktion wendet den gewählten Port jetzt auf den laufenden Dienst an und behält einen expliziten Port beim Upload und beim Rebuild bei. Eine Live-Prüfung der Portänderung war am 9. September erfolgreich. Prüfen Sie nach einem Deployment sowohl die öffentliche URL als auch den Zustand des Dienstes.
Upload-Archive und Exit-Codes bei fehlgeschlagenen Builds: behoben
Lizard CLI 0.3.95 schließt macOS-._*-Metadateneinträge aus Source-Uploads aus und gibt bei fehlgeschlagenen Cloud-Builds einen Exit-Code ungleich null zurück. Aktualisieren Sie ältere CLI-Versionen; COPYFILE_DISABLE wird nicht mehr benötigt. Die Framework-Prüfungen decken Uploads von macOS mit der aktuellen CLI ab.
Ein erfolgreicher Build allein beweist noch nicht, dass die App funktioniert. Prüfen Sie nach dem Deployment die öffentliche URL, Routen, Formulare und Datenoperationen.
Aktualisiert