> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # Failproof AI Cloud selbst hosten > Stellen Sie die Failproof AI Control Plane in einem kundenverwalteten Kubernetes-Cluster bereit. Self-Hosting ist eine Enterprise-Bereitstellung. [Kontaktieren Sie Failproof AI](mailto:support@befailproof.ai), um eine Enterprise-Lizenz zu erhalten. ## Voraussetzungen * Kubernetes 1.27 oder neuer mit Cluster-Admin-Zugriff * `kubectl` mit Kustomize-Unterstützung * Helm 3 * Zugriff auf die privaten `ghcr.io/agenteye-enterprise`-Images * Zwei DNS-Namen: einer für das Dashboard und einer für die Ingestion * Persistenter Speicher für PostgreSQL und ClickHouse * cert-manager und Traefik oder eine gleichwertige Ingress- und Zertifikatsinfrastruktur, die in Ihren Overlay eingebunden wird * SMTP für produktives OTP-Login und Benachrichtigungen Der Quellbaum enthält einen AWS/EKS-orientierten Overlay sowie einen separaten GCP/GKE-Overlay. Vermischen Sie deren Anweisungen für Zertifikate, Load Balancer oder Backups nicht: GKE verwendet eine eigene DNS-01-, GCS- und Autoscaling-Konfiguration. ## Bereitstellungsreihenfolge Installieren Sie cert-manager und die öffentlichen/Dashboard-Ingress-Controller, überprüfen Sie deren Load Balancer und erstellen Sie anschließend den Namespace, Image-Pull-Credentials, Datenbank-Credentials, den Bootstrap-Admin-Key sowie Authentifizierungs- und SMTP-Secrets. Setzen Sie `INGEST_DOMAIN` und `DASHBOARD_DOMAIN` in der generierten Domain-Umgebungsdatei des Overlays und erstellen Sie DNS-Einträge, die auf die zugehörigen Load Balancer zeigen. Verwenden Sie den Customer/EKS- oder GCP-Overlay. Prüfen Sie die gerenderte Kustomize-Ausgabe, wenden Sie sie an und bestätigen Sie, dass alle Workloads und Zertifikate ihren gewünschten Zustand erreicht haben, bevor Sie Maschinen registrieren. Melden Sie sich als geschützter Admin an, erstellen Sie einen organisationsbezogenen Machine Key und senden Sie eine kleine Test-Session durch den öffentlichen Ingest-Endpunkt. ## Erforderliche und optionale Dienste | Komponente | Anforderung | | --------------------- | ------------------------------------------------------------------------------------------------------------------ | | ClickHouse | Erforderlich. Der Server verweigert den Start ohne seinen kanonischen Event Store. | | PostgreSQL | Erforderlich für Benutzer, Organisationen, gespeicherte Objekte und den Control-Plane-Zustand. | | Redis | Optional. Server und Dashboard fallen auf datenbankbasiertes Verhalten zurück, wenn nicht verfügbar. | | SMTP | Optional für die Entwicklung, erforderlich für produktive E-Mail-OTP- und Benachrichtigungslieferung. | | Evaluator | Optional. Die automatische Auswertung bleibt ohne `EVALUATOR_ENDPOINT` deaktiviert. | | Assistant/Audit-LLM | Optional. Assistant- und LLM-gestützte Audit-Funktionen bleiben inaktiv, bis eine LLM-Verbindung konfiguriert ist. | | Objektspeicher-Backup | Dringend empfohlen für PostgreSQL- und ClickHouse-Backup-Archive. | ### Audit-Kapazität und Fehlerbenachrichtigung Führen Sie Audits auf der dedizierten Audit-Agent-Bereitstellung aus, wenn verfügbar. Jeder Audit-Agent-Pod akzeptiert standardmäßig eine Untersuchung; skalieren Sie den Durchsatz über Replicas, anstatt die Parallelität pro Pod zu erhöhen, ohne gleichzeitig den Speicher zu vergrößern. Der Server kann `Server-Replicas × AUDIT_WORKERS` Audits gleichzeitig verarbeiten, daher sollte die Dispatcher-Kapazität groß genug sein, um die gesamte Audit-Agent-Flotte auszulasten. Wenn alle Audit-Agent-Slots belegt sind, wartet ein Audit und wiederholt den Versuch für bis zu einem Viertel seines Intervalls, maximal jedoch sechs Stunden. Wenn kein Slot frei wird, wird der Lauf ohne Befunde abgeschlossen und eine Fehler-E-Mail gesendet. Wiederholte „Belegt"-Fehler erfordern mehr Audit-Agent-Replicas oder weiter gestreute Zeitplan-Ankerpunkte. Wiederholte „Herunterfahren"-Fehler weisen auf instabile Pods oder ein sich wiederholendes Rollout hin, nicht auf unzureichende Kapazität. Fehlerbenachrichtigungen erfordern einen aktivierten E-Mail-Kanal und SMTP. Sie verwenden die Empfänger des Audits und fallen auf `alerts.email_default_recipients` zurück, wenn der Audit keinen E-Mail-Kanal hat. ## Bereitstellung verifizieren 1. Öffnen Sie die konfigurierte Dashboard-Domain, schließen Sie den Admin-OTP-Ablauf ab und bestätigen Sie den Organisationsnamen und den Slug. 2. Gehen Sie zu **Administration → Keys** und erstellen Sie einen eng begrenzten Machine Key. 3. Senden Sie eine Test-Session und bestätigen Sie diese unter **Observe → Events** und **Observe → Sessions**. 4. Testen Sie einen Alert-Kanal sowie, wenn konfiguriert, eine manuelle Auswertung und einen Audit. ```bash theme={null} kubectl get pods -n agenteye kubectl get certificates -n agenteye kubectl logs -n agenteye deploy/server --tail=100 fp --base-url https://failproof.example.com login fp --base-url https://failproof.example.com whoami fp --base-url https://failproof.example.com usage ``` Überprüfen Sie den öffentlichen Health-Endpunkt und eine authentifizierte `/v1`-Anfrage, bevor Sie Produktionsmaschinen registrieren. ## Authentifizierung und E-Mail Das Dashboard verwendet E-Mail und Einmalcodes. Ohne SMTP protokollieren Entwicklungsbereitstellungen OTP-Codes in der Serverausgabe. Wenn `SMTP_HOST` gesetzt ist, sind Benutzername, Passwort und Absender als Gruppe erforderlich, andernfalls verweigert der Server den Start. `SMTP_TLS` ist ein boolescher Wert. Der unterstützte verschlüsselte Transport ist STARTTLS, normalerweise auf Port 587; implizites SMTPS auf Port 465 wird vom aktuellen Server-Transport nicht unterstützt. Setzen Sie die öffentliche Dashboard-URL korrekt, da OTP-, Alert-, Incident- und Audit-E-Mails sie für Deep Links verwenden. Die Organisationsmitgliedschaft steuert, wer einen Code anfordern darf; jede Organisation kann ihre eigenen Mitglieder-Anmeldungen zusätzlich unter **Administration → Settings** einschränken. ## Anforderungen für Mehrmandantenfähigkeit Bevor Sie eine zweite Organisation erstellen, konfigurieren Sie ein starkes, stabiles ClickHouse-Ableitungsgeheimnis für Organisationen und halten Sie es auf allen Server-Replicas identisch. Eine Rotation ohne koordinierte Migration kann organisationsspezifische ClickHouse-Benutzer verwaisen lassen. Halten Sie den Instance-Admin-Listener intern. Die mitgelieferte Operator-Konsole ist optional und für `kubectl port-forward` konzipiert, nicht für öffentlichen Ingress. Ihre Aktivierung erfordert einen eigenen starken API-Key, ein Super-Admin-Postfach und eine funktionierende SMTP-Zweifaktor-Zustellung. ### Break-Glass-Organisations-CLI `agenteye-orgctl` wird im Server-Image mitgeliefert und kommuniziert direkt mit PostgreSQL und ClickHouse. Es ist verfügbar, wenn der öffentliche Server oder die Operator-Konsole nicht funktionieren. ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl org create --slug acme --name "Acme Corp" kubectl -n agenteye exec deploy/server -- agenteye-orgctl org list kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member add --org acme --email ops@acme.com --set admin --protected ``` Unterstützte Organisationsoperationen umfassen: Erstellen, Auflisten, Umbenennen, Soft-Delete, Wiederherstellen, ClickHouse-Benutzer-Reprovisioning, Abrechnungsdatumsverwaltung, Feature-Flags und unwiderrufliches Löschen. Mitgliederoperationen umfassen: Hinzufügen, Auflisten, Aktualisieren, Entfernen, Berechtigungsüberschreibungen und geschützten Admin-Status. Verwenden Sie Soft-Delete vor dem endgültigen Löschen. `org purge` ist unwiderruflich und erfordert, dass die Organisation zuerst gelöscht wurde. Geschützte Mitglieder können nicht über die normale Benutzerseite der Organisation entfernt oder zurückgestuft werden, bis ein Operator sie explizit aufhebt. ## Checkliste für die Produktionsbereitschaft * Ingest- und Dashboard-DNS werden zu den vorgesehenen, unterschiedlichen Ingress-Pfaden aufgelöst. * TLS ist gültig; verwenden Sie gegenseitiges TLS beim Ingest, wo Ihre Bereitstellung es erfordert. * PostgreSQL- und ClickHouse-Volumes haben Kapazitätswarnungen. * Backups umfassen beide Datenspeicher und verfügen über ein getestetes Wiederherstellungsverfahren. * Health-Checks warnen bei Ingest-Stille, fehlgeschlagenen Workloads, abgelaufenen Zertifikaten, Speicherdruck und veralteten Backups. * Strukturierte Logs werden gesammelt, ohne eine vorhandene Cluster-Log-Pipeline zu duplizieren. * Die Parallelität von Evaluator, Audit und Alert-Worker wurde nicht ohne gemessene Queue-Evidenz geändert. * Ein festgelegter Anwendungs-Release und ein Rollback-Verfahren sind vor Upgrades dokumentiert. Die Bereitstellungsmanifeste enthalten plattformspezifische Sicherheits- und Verfügbarkeitsannahmen. Überprüfen Sie gerenderte Ressourcen, Netzwerkrichtlinien, Ingress-Exposition, Secret-Referenzen, Storage-Klassen, Disruption-Budgets und Backup-Ziele mit Ihrem Plattformteam, bevor Sie sie anwenden.