Instanzdiagnose

Fehler einer selbstgehosteten Installation eingrenzen

Führen Sie den nur lesenden doctor aus dem tatsächlich installierten Release-Checkout und der geschützten Umgebung aus. Verwenden Sie --mode full mit Upstream-Compose-Pfad oder managed mit Anbieter-Datenbankverbindung. Er prüft Kompatibilität, Konfiguration, Container, DNS/TLS, Anwendung, Speicher und Scheduler. Migrationen und Storage brauchen die passende Verbindung. Schwärzung hilft, prüfen Sie Berichte dennoch vor Weitergabe. Liveness beweist weder Kontomailzustellung noch lesbare verschlüsselte Inhalte oder restaurierte Dateien.

pnpm self-host:doctor -- --mode full --env-file "$MINDDY_ENV_FILE" \
  --supabase-compose "$SUPABASE_DIR/docker/docker-compose.yml" --json

Symptome gezielt prüfen

Prüfen Sie bei allgemeinen 401 nach Restore, dass JWT, Anon- und Service-Role-Schlüssel zu demselben Stack gehören. Bei Uploadfehlern oder 404 vergleichen Sie Storage-Richtlinien, Objekte, Bytes und Schlüssel. Bei fehlenden Relationen erhalten Sie den ersten Migrationsfehler, prüfen Platte, Sperren und Ziel-URL und wiederholen Bootstrap erst nach Ursachenbehebung. Markieren Sie gescheiterte Migrationen nie manuell als ausgeführt. Prüfen Sie für Realtime Publikation, JWT, WebSocket-Proxy und Logs. Prüfen Sie bei inaktiven Cronjobs oder 401 Scheduler, kanonischen Origin und CRON_SECRET privat. Schlägt die Versionskompatibilität fehl, vergleichen Sie MINDDY_RELEASE mit einem Eintrag in deploy/self-hosted/compatibility.json und MINDDY_IMAGE mit diesem Eintrag oder dem geprüften unveränderlichen Digest. Der Installer übernimmt MINDDY_RELEASE aus der Bereitstellungsvorlage.

Wiederherstellbarkeit erhalten

Beheben Sie fehlendes Docker/CLI oder unvollständige API-Werte und wiederholen Sie den idempotenten Installer mit erhaltener Umgebung. Korrigieren Sie öffentliche Laufzeit-URLs und erstellen Sie die App neu, ohne OCI-Neubuild. Löschen Sie keine gefüllten Buckets, Daten oder Wurzelschlüssel wegen Warnungen. Optionale deaktivierte Funktionen können beabsichtigt sein. Geben Sie Support Version, Profil, Zeiten, kontrollierte Fehlercodes und bereinigte Diagnosen. Entfernen Sie Passwörter, Tokens, Authorization-Header, Cookies, private Objekt-URLs und Benutzerinhalte.

Bricht der erste Image-Download nach einem langen Fortschrittsprotokoll ohne Registry-Fehler ab, kann der Installer von v0.11.0 seinen Ausgabepuffer für Unterprozesse überschreiten. Spätere Installer laden leise mit einem größeren Puffer und brechen, falls die Ausgabe ihn dennoch überschreitet, mit einer ausdrücklichen Anweisung ab. Führen Sie in beiden Fällen compose pull --quiet im exakten Compose-Kontext der Installation aus und wiederholen Sie anschließend denselben Installer mit --skip-pull, um die geladenen Images zu verwenden und die Umgebung zu erhalten. Das behebt weder Registry- noch Signaturfehler. Meldet die Offline-Kompilierung eine abweichende jose-Version, halten Sie an. Die Werkzeuge von v0.11.0 verlangen 6.2.3, ihre direkte eingefrorene Abhängigkeit ergibt jedoch 6.2.12; besorgen Sie eine korrigierte Kombination aus Release und Werkzeugen, bevor Sie diese Installation abnehmen. In späteren Releases entspricht die Bindung der eingefrorenen Abhängigkeit, eine Abweichung bedeutet also, dass pnpm install --frozen-lockfile in diesem Checkout nicht abgeschlossen wurde. Lockern Sie die Identitätsprüfung nicht stillschweigend.

Auch der OCI-Runner von v0.11.0 startet nicht, weil agent-runner-storage.mjs im Runtime-Image fehlt; die Anwendung wird daher nie gesund. Spätere Releases entfernen diesen Runner und seine Code-Sandboxes. Aktualisieren Sie auf eine solche Release, statt Runner-Dateien einzubinden oder die Container-Isolation zu lockern.