Deployment - FailproofAI

Diese Anleitung beschreibt das Deployment des AgentEye-Servers und Dashboards in der Produktion.

Architekturübersicht

  [ KI-Agent-Maschinen ]                 [ Ihre Infrastruktur ]

    Python SDK
       |  schreibt JSONL                     +----------------------+
       v                                +--->| PostgreSQL 15+       |
 agenteye-collector --HTTP--+           |    | (relationale Ablage) |
                            |           |    +----------------------+
                            v           |
                       +--------+       |    +----------------------+
                       | Server |<------+--->| ClickHouse 24+       |
                       +--------+       |    | (Events / Analytik)  |
                            ^           |    +----------------------+
                        API |           |
                            |           |    +----------------------+
                      +-----------+     +- - >| Redis 7+ (optional) |
                      | Dashboard |           +----------------------+
                      +-----------+

Server: Rust-HTTP-Dienst; empfängt Event-Batches, schreibt sie in ClickHouse und verwaltet den relationalen Zustand in PostgreSQL.
Dashboard: Next.js-Webanwendung; liest und schreibt ausschließlich über die Server-API.
agenteye-collector: wird auf Agent-Maschinen eingesetzt, nicht auf dem Server-Host.
Postgres 15+: ERFORDERLICH. (Ab Version 14 in der Multi-Tenant-Version angehoben; das Org-Mitgliedschaftsschema verwendet einen ON DELETE SET NULL-Fremdschlüssel mit Spaltenliste, der Postgres 15+ erfordert. Postgres vor der Bereitstellung dieser Version aktualisieren.) Speichert den OLTP-Zustand: api_keys, users, sessions, evaluation_jobs (Warteschlange), dashboards, saved_queries, otp_codes sowie die Multi-Tenant-Tabellen orgs, org_memberships, org_settings.
ClickHouse 24+: ERFORDERLICH. Der Analyse-Store für alle eingehenden Events. Engine: ReplacingMergeTree, nach Monat partitioniert, geordnet nach (session_id, ts, dedup_key). Der Server verbindet sich über CLICKHOUSE_URL; die mitgelieferte deploy/base/clickhouse/ enthält eine leistungsoptimierte Einzelknoten-Konfiguration. Multi-Tenant-Anforderung: Die mitgelieferte Konfiguration aktiviert SQL-Zugriffsverwaltung + users_without_row_policies_can_read_rows=false, damit der Server pro Organisation einen schreibgeschützten ClickHouse-Benutzer und eine Zeilenrichtlinie erstellen kann (die engine-seitig erzwungene Isolationsgrenze für den SQL-Editor und den KI-Agenten). Wenn Sie eine eigene ClickHouse-Konfiguration verwenden, übernehmen Sie diese Einstellungen (siehe deploy/base/clickhouse/configmap.yaml).
Redis 7+: optional als gemeinsamer Cache- und Rate-Limit-Backend. Server und Dashboard verbinden sich beide über REDIS_URL. Ist Redis nicht vorhanden, fallen beide auf Postgres-only-Pfade zurück. Siehe Redis (optionaler Cache) weiter unten.

Server

Image herunterladen

echo $AGENTEYE_TOKEN | docker login ghcr.io -u x --password-stdin
docker pull ghcr.io/agenteye-enterprise/server:beta-latest

Aktuelle Builds werden unter beta-latest veröffentlicht; latest wird nur stabilen Releases zugewiesen. Für die Produktion sollten Sie einen konkreten :v<version>-Tag festlegen; siehe Verfügbare Image-Tags.

Umgebungsvariablen

Variable	Erforderlich	Standardwert	Beschreibung
`DATABASE_URL`	Ja	keiner	Postgres-DSN. Standard-libpq-Verbindungszeichenfolge mit Schema `postgres://`. Unterstützt `?sslmode=require` und andere libpq-Parameter. Das Passwort darf keine `/`, `+` oder `=` enthalten; verwenden Sie `openssl rand -hex` zum Generieren URL-sicherer Passwörter.
`ADMIN_KEY`	Nein	keiner	Bootstrap-Admin-API-Schlüssel. Wird bei jedem Start mit allen Berechtigungen per Upsert gesetzt. Rotation durch Ändern des Werts und Neustart.
`LISTEN_ADDR`	Nein	`0.0.0.0:8080`	TCP-Adresse zum Binden
`MAX_BODY_BYTES`	Nein	`134217728` (128 MB)	Maximale Anfrage-Body-Größe
`ADMIN_EMAIL`	Nein	keiner	Bootstrap-Admin-Benutzer-E-Mail. Wird bei jedem Start per Upsert mit allen Berechtigungen gesetzt und als geschützt markiert: kann weder deaktiviert noch über Dashboard/API in seinen Berechtigungen geändert werden. Um den Bootstrap-Admin zu wechseln, ändern Sie `ADMIN_EMAIL` und starten neu; die neue E-Mail-Adresse wird als geschützt per Upsert gesetzt, die vorherige behält ihren Schutz, bis er manuell in der Datenbank aufgehoben wird.
`ALLOWED_EMAILS`	Nein	keiner (alle blockiert)	Kommagetrennte Liste erlaubter E-Mail-Adressen für Benutzererstellung und Anmeldung. Unterstützt exakte Adressen (`user@example.com`) und Domain-Wildcards (`@example.com`). Wenn nicht gesetzt, können keine Benutzer erstellt werden oder sich anmelden. Nur beim ersten Start:* Befüllt die Zulassungsliste der Standard-Org beim ersten Start; danach ist die Seite `/<org>/settings` jeder Org die maßgebliche Quelle, und Änderungen dieser Umgebungsvariablen haben keine Wirkung mehr.
`SMTP_HOST`	Nein	keiner	SMTP-Serverhostname für den Versand von OTP-E-Mails. Wenn nicht gesetzt, werden OTP-Codes stattdessen nach stdout geloggt.
`SMTP_PORT`	Nein	`587`	SMTP-Serverport
`SMTP_USERNAME`	Nein	keiner	SMTP-Authentifizierungs-Benutzername
`SMTP_PASSWORD`	Nein	keiner	SMTP-Authentifizierungspasswort
`SMTP_FROM`	Nein	keiner	Absender-E-Mail-Adresse für OTP-E-Mails
`SMTP_TLS`	Nein	STARTTLS	STARTTLS wird verwendet, sofern nicht explizit deaktiviert: `false` oder `0` sendet Klartext (kein TLS); jeder andere Wert — einschließlich nicht gesetzt — aktiviert STARTTLS.
`DASHBOARD_URL`	Nein	integrierter Standard	Dashboard-Ursprung zum Erstellen des OTP-E-Mail-Magic-Links sowie der Incident-Magic-Links in Alert-Benachrichtigungen. Wenn nicht gesetzt, fällt er auf einen integrierten Standard zurück (und bei OTP zuerst auf den vom Dashboard abgeleiteten Request-Ursprung). Setzen Sie dies für Split-Domain-Setups, damit E-Mail- und Slack/Incident-Links auf Ihr Dashboard zeigen. Siehe E-Mail-Magic-Link-URL weiter unten; die meisten Betreiber müssen dies nicht setzen.
`SESSION_TTL_SECS`	Nein	`86400` (24 h)	Dashboard-Sitzungsdauer in Sekunden. Nur beim ersten Start: Nach dem ersten Deployment per Org über `/<org>/settings` bearbeitbar.
`OTP_TTL_SECS`	Nein	`600` (10 min)	OTP-Code-Gültigkeitsdauer in Sekunden. Nur beim ersten Start: Nach dem ersten Deployment per Org über `/<org>/settings` bearbeitbar.
`REDIS_URL`	Nein	keiner	Optionales gemeinsames Cache- und Rate-Limit-Backend, z. B. `redis://redis:6379/0`. Wenn gesetzt, cacht der Server authentifizierte API-Key-Lookups, das `/models`-Aggregat des Dashboards, die Session-Liste und die Env-List-Facette; außerdem wird das OTP-Request-Rate-Limiting von Postgres COUNT auf Redis INCR umgestellt. Wenn nicht gesetzt oder nicht erreichbar, läuft der Server ohne Cache (das OTP-Limit fällt auf Postgres zurück, alle anderen Cache-Aufrufe fallen auf die Quelle zurück). Siehe Redis (optionaler Cache) weiter unten.
`CLICKHOUSE_URL`	Ja	keiner	Basis-URL der ClickHouse-Instanz, z. B. `http://clickhouse:8123`. Der Server wendet sein Events-Schema bei jedem Start auf diese Datenbank an und verweigert den Start, wenn ClickHouse nicht erreichbar ist. Siehe ClickHouse (erforderlicher Analyse-Store) weiter unten.
`CLICKHOUSE_DATABASE`	Nein	`agenteye`	ClickHouse-Datenbankname (Schema). Der Server erstellt ihn beim Start, falls er nicht existiert.
`ORG_CH_SECRET`	Nein (single-tenant) / Ja (multi-org)	Entwicklungsstandard	HMAC-Schlüssel, aus dem das ClickHouse-Passwort jedes Tenants pro Organisation abgeleitet wird. Der SQL-Editor und das `run_query` des KI-Agenten werden als schreibgeschützter ClickHouse-Benutzer der Org ausgeführt, dessen Zeilenrichtlinie die Tenant-Isolation in der Engine erzwingt. Single-Tenant-Deployments starten problemlos mit dem integrierten Entwicklungsstandard; bevor Sie eine zweite Org anlegen, MÜSSEN Sie einen starken, stabilen Wert setzen, da der CLI `agenteye-orgctl org create` die Ausführung mit dem integrierten Entwicklungsstandard verweigert. Eine Rotation führt dazu, dass alle ClickHouse-Benutzer der Org verwaisen, bis beim nächsten Start eine erneute Provisionierung erfolgt (der Boot-Zeit-Abgleich heilt dies automatisch). Halten Sie den Wert geheim und über alle Replikate hinweg unverändert. Die Org-Provisionierung selbst ist nur für Betreiber; siehe Organisationen (Multi-Tenancy) weiter unten.
`DEFAULT_ORG_NAME`	Nein	`Default`	Anzeigename, der für die integrierte Standard-Org gesetzt wird. Nur beim ersten Start und nur solange die Org noch ihre frisch migrierte generische Identität trägt, wird er beim Start angewendet und danach ignoriert. Sobald Sie die Org umbenennen (`agenteye-orgctl org rename`), ist die Umbenennung maßgeblich und diese Umgebungsvariable hat keine weitere Wirkung.
`DEFAULT_ORG_SLUG`	Nein	`default`	URL-Slug für die integrierte Standard-Org, der Dashboard-Pfad, unter dem sie erreichbar ist (`/<slug>/…`). Gleiche Nur-beim-ersten-Start/nur-unberührt-Semantik wie `DEFAULT_ORG_NAME`. Muss 1–40 Kleinbuchstaben und Ziffern mit einzelnen internen Bindestrichen sein und darf kein reserviertes Wort sein; ein ungültiger Wert wird ignoriert (die Org behält `default`). Ermöglicht es einem Single-Tenant-Install, z. B. unter `/acme` statt `/default` erreichbar zu sein, ohne einen Post-Deploy-CLI-Schritt.
`RUST_LOG`	Nein	`info`	Log-Ausführlichkeit (`debug`, `warn`, `error`, `agenteye_server=trace`)
`EVALUATOR_ENDPOINT`	Nein	keiner	Basis-URL Ihres Evaluator-Dienstes (z. B. `http://evaluator:9000`). Wenn nicht gesetzt, ist die gesamte Evaluierungspipeline ein No-op; es werden keine Queue-Zeilen geschrieben, keine Worker laufen. Siehe Evaluation Suite.
`EVALUATOR_TOKEN`	Nein	keiner	Wird als `Authorization: Bearer <token>` an den Evaluator gesendet. Muss mit dem Wert übereinstimmen, mit dem der Evaluator-Dienst konfiguriert ist. Nur optional, wenn Ihr Evaluator ohne Token konfiguriert ist.
`EVALUATOR_WORKERS`	Nein	`2`	Parallelität: Anzahl der Worker-Tasks pro Server-Instanz, die Evaluierungen dispatchen. Kann sicher über mehrere horizontal skalierte Server ausgeführt werden.
`EVALUATOR_CLAIM_BATCH`	Nein	`4`	Maximale Anzahl von Evaluierungen, die ein einzelner Worker pro Tick beansprucht. Batches werden gleichzeitig dispatcht, sodass die Gesamtparallelität an Ihrem Evaluator-Endpunkt `EVALUATOR_WORKERS × EVALUATOR_CLAIM_BATCH` beträgt.
`EVALUATOR_POLL_IDLE_SECS`	Nein	`2`	Wie lange ein Worker zwischen Dispatch-Versuchen schläft, wenn nichts fällig ist.
`EVALUATOR_POLLING_INTERVAL_SECS`	Nein	`10`	Endgültiger Fallback-Takt (Sekunden) für `GET /evaluate/{id}`-Polls, wenn der Evaluator weder ein `next_poll_secs` pro Response noch ein `default_poll_interval_secs` von `GET /config` zurückgibt.
`EVALUATOR_REQUEST_TIMEOUT_MS`	Nein	`30000`	Pro-HTTP-Request-Timeout gegenüber dem Evaluator (Millisekunden).
`EVALUATOR_MAX_ATTEMPTS`	Nein	`5`	Nach dieser Anzahl fehlgeschlagener Versuche wird eine Evaluierung als terminaler `error` (oder `timeout`, wenn die Fehler Request-Timeouts waren) erfasst.
`EVALUATOR_CONFIG_REFRESH_SECS`	Nein	`300` (5 min)	Wie oft der Server `GET /config` vom Evaluator neu abruft.
`EVALUATOR_MAX_POLL_DURATION_SECS`	Nein	`3600` (1 h)	Maximale Wall-Clock-Zeit, während der eine Session in der Poll-Warteschlange verbleiben darf, bevor AgentEye sie als `timeout` beendet. Schützt vor einem Evaluator, der dauerhaft `pending` zurückgibt.
`ALERT_WORKERS`	Nein	`1`	Parallelität: Anzahl der Worker-Tasks pro Server-Instanz, die Alert-Regeln auswerten. Siehe Alerts.
`ALERT_CLAIM_BATCH`	Nein	`16`	Maximale Anzahl von Alerts, die ein einzelner Worker pro Tick beansprucht.
`ALERT_POLL_IDLE_SECS`	Nein	`5`	Wie lange ein Alerts-Worker schläft, wenn die Warteschlange leer ist.
`ALERT_REQUEST_TIMEOUT_MS`	Nein	`15000`	Pro-Trigger-Auswertungs-Timeout (ClickHouse-Abfragen + ausgehende Kanal-HTTP).
`ALERT_MAX_ATTEMPTS`	Nein	`5`	Aufeinanderfolgende transiente Fehler, bevor ein Alert nach normalem Takt statt exponentiellem Backoff neu geplant wird.
`AUDIT_WORKERS`	Nein	`1`	Parallelität: Anzahl der Worker-Tasks pro Server-Instanz, die Audits ausführen. Siehe Audits.
`AUDIT_CLAIM_BATCH`	Nein	`1`	Maximale Anzahl fälliger Audits, die ein einzelner Worker pro Tick beansprucht. Eine agentische Untersuchung ist eine lange Schleife, daher ist der Standard 1.
`AUDIT_POLL_IDLE_SECS`	Nein	`30`	Wie lange ein Audits-Worker schläft, wenn kein Audit fällig ist.
`AUDIT_REQUEST_TIMEOUT_MS`	Nein	`30000`	Pro-Policy-Query-Timeout gegenüber ClickHouse (Millisekunden).
`AUDIT_LLM_TIMEOUT_MS`	Nein	`1440000`	Timeout für den agentischen Untersuchungsaufruf an den KI-Assistenten-Dienst. Ein vollständiger Agent-Loop läuft mehrere Minuten; halten Sie diesen Wert ÜBER dem eigenen `AGENTEYE_AUDIT_TIMEOUT_MS` des Agenten, damit der Agent seine Teilergebnisse zurückgibt, bevor der Server aufgibt.
`AUDIT_MAX_ATTEMPTS`	Nein	`5`	Aufeinanderfolgende transiente Fehler, bevor ein Audit nach normalem Takt statt exponentiellem Backoff neu geplant wird.
`AGENTEYE_AGENT_URL` / `AGENTEYE_AGENT_TOKEN`	Nein	—	Die agentische Untersuchung des Audits ruft den KI-Assistenten-`agent`-Dienst auf und nutzt dabei dieselbe Verbindung wie der Assistent — setzen Sie diese beiden also auch auf dem Server (die mitgelieferten Manifeste/Compose tun das). Beide gesetzt ⇒ Audits führen die KI-Untersuchung durch; eines fehlt ⇒ Audits laufen nur mit Policy (der deterministische SQL-Policy-Pass läuft trotzdem), unabhängig vom `llm_enabled`-Flag des Audits. Der Agent muss außerdem ein LLM konfiguriert haben — siehe assistant.md.

KI-Assistenten-Dienst — Audit- und Sandbox-Einstellungen. Die agentische Untersuchung und ihre In-Pod-Python-Sandbox werden auf dem Agent-Dienst (nicht dem Server) konfiguriert, alle mit dem Präfix AGENTEYE_AUDIT_* und alle optional:

Variable	Standard	Bedeutung
`AGENTEYE_AUDIT_MAX_STEPS`	`200`	Maximale Agenten-Turns pro Untersuchung.
`AGENTEYE_AUDIT_TIMEOUT_MS`	`1200000`	Wall-Clock für eine Untersuchung (20 Min.). Muss unter dem `AUDIT_LLM_TIMEOUT_MS` des Servers bleiben.
`AGENTEYE_AUDIT_MAX_CONCURRENCY`	`1`	Gleichzeitige Untersuchungen pro Agent-Pod (getrennt vom Budget des Chat-Assistenten).
`AGENTEYE_AUDIT_SANDBOX_TIMEOUT_MS` / `_MEM_MB` / `_CPU_SECS` / `_OUTPUT_MAX_BYTES` / `_SCRIPT_MAX_BYTES`	`20000` / `768` / `10` / `64000` / `64000`	Pro-Skript-Limits für die Bubblewrap-Sandbox.

Sandbox-Plattformanforderung. Die Audit-Code-Sandbox führt das Python des Modells in einem Bubblewrap-Jail aus, das unprivilegierte User-Namespaces benötigt. Der Agent-Pod muss die clone()-Flags erlauben — setzen Sie seccompProfile: Unconfined (k8s) oder security_opt: [seccomp:unconfined] (compose) auf dem Agenten. Wenn der Node-Kernel unprivilegierte User-Namespaces deaktiviert (z. B. bei einigen GKE-COS-Images), schlägt der Sandbox-Preflight fehl und der Auditor degradiert automatisch auf SQL-only — kein Fehler, nur sandbox_available: false im /health des Agenten.

Starten

Setzen Sie DATABASE_URL in Ihrer Umgebung und übergeben Sie es dann an den Container:

docker run -d --restart unless-stopped \
  --name agenteye-server \
  -e DATABASE_URL="$DATABASE_URL" \
  -e ADMIN_KEY="$ADMIN_KEY" \
  -p 8080:8080 \
  ghcr.io/agenteye-enterprise/server:beta-latest

Der Server führt Datenbankmigrationen automatisch beim Start durch; kein separater Migrationsschritt erforderlich.

Health-Check

GET /health    # Liveness  - immer {"status":"ok"} sobald der Prozess läuft
GET /ready     # Readiness - 200 wenn Postgres + ClickHouse erreichbar, sonst 503

Keine Authentifizierung erforderlich. Verwenden Sie /health für Liveness-Probes und /ready für Readiness-/Load-Balancer-Probes. /ready prüft die harten Abhängigkeiten, ohne die der Server nicht bedienen kann (Postgres + ClickHouse), sodass ein laufender Server, der seine Datenbank nicht erreicht, aus der Rotation genommen und als NotReady angezeigt wird; Redis wird gemeldet, schlägt aber nie bei der Readiness-Prüfung fehl. In den mitgelieferten Kubernetes-Manifesten zeigt die Readiness-Probe bereits auf /ready, während Liveness auf /health bleibt. Siehe enterprise-docs/health-monitoring.md für das vollständige Bild, einschließlich optionalem Kubernetes-nativen Pod-Fehler-Alerting an Slack.

E-Mail-Magic-Link-URL

OTP-Login-E-Mails enthalten eine Ein-Tap-Schaltfläche Dashboard öffnen. Ein Klick darauf bringt den Benutzer auf /login?token=<code>&email=<address>; das Dashboard tauscht dieses Paar gegen eine Session aus und leitet zur App weiter, ohne manuelle Code-Eingabe. Der Server löst den Dashboard-Ursprung für den Link-Aufbau in drei Ebenen auf:

X-AgentEye-Dashboard-Url-Header: Wird automatisch vom /api/auth/otp/request-Proxy des Dashboards aus seinem eigenen öffentlichen Ursprung gesetzt. In einem Same-Origin-Deployment (Server und Dashboard teilen sich einen Host hinter einem Ingress, der Proxy-Header weiterleitet) ist keine Konfiguration erforderlich.
DASHBOARD_URL-Umgebungsvariable: Setzen Sie diese, wenn Ihr Dashboard auf einem anderen Ursprung erreichbar ist als dem, den der OTP-Request-Endpunkt des Servers sieht (getrennte api.example.com / app.example.com), oder wenn Ihr Ingress den öffentlichen Host nicht in den Dashboard-Pod weiterleitet (sodass request.nextUrl.origin sonst auf eine Wildcard-Bind-Adresse wie 0.0.0.0:3000 aufgelöst würde). Beispiel: DASHBOARD_URL=https://app.example.com.
Standard: https://app.befailproof.ai, wird nur verwendet, wenn keines der oben genannten vorhanden ist.

Der Header-Wert wird validiert: Nur https://*- und Loopback-(http://localhost*, http://127.0.0.1*)-Ursprünge werden akzeptiert, und Wildcard-Bind-Adressen (0.0.0.0, [::]) werden auch mit dem https://-Schema abgelehnt. Alles andere fällt auf Ebene 2 zurück. Setzen Sie es auf einem laufenden Cluster mit einem Einzeiler; keine Datei, kein Kustomize-Rebuild:

kubectl set env deployment/server -n agenteye \
  DASHBOARD_URL=https://app.example.com

Dies löst ein Rollout aus; die neuen Pods übernehmen den Wert beim ersten Request. Beachten Sie, dass das Override nur im Deployment lebt; ein nachfolgendes kustomize build | kubectl apply gegen den Overlay löscht es, sofern Sie dieselbe Umgebungsvariable nicht in den server-env.yaml-Patch Ihres Overlays aufnehmen.

Dashboard

Image herunterladen

docker pull ghcr.io/agenteye-enterprise/dashboard:beta-latest

Umgebungsvariablen

Variable	Erforderlich	Standardwert	Beschreibung
`AGENTEYE_SERVER_URL`	Ja	keiner	Basis-URL des Servers, z. B. `http://localhost:8080`
`AGENTEYE_API_KEY`	Ja	keiner	API-Schlüssel, den das Dashboard zur Authentifizierung gegenüber dem Server verwendet. Benötigt alle Berechtigungen (Admin-Schlüssel empfohlen).
`AE_LOG_LEVEL`	Nein	`info`	Server-seitige Log-Ausführlichkeit: `debug`, `info`, `warn`, `error`. Auf `debug` setzen, um Upstream-Request/Response-Zeilen und Session-Validierungs-Traces bei der Diagnose zu sehen.
`AE_LOG_JSON`	Nein	auto	`1` erzwingt JSON-per-Zeile-Ausgabe; `0` erzwingt menschenlesbare Ausgabe. Wenn nicht gesetzt, wird JSON automatisch aktiviert, wenn `NODE_ENV=production`. JSON wird in der Produktion empfohlen, damit Logs mit `jq` oder einem Log-Aggregator sauber geparst werden können.
`AE_ANALYTICS_DISABLED`	Nein	keiner	Auf `1`/`true` setzen, um die anonyme Produktnutzungs-Telemetrie des Dashboards zu deaktivieren. Siehe Telemetrie & Datenschutz weiter unten.
`REDIS_URL`	Nein	keiner	Optionales gemeinsames Cache-Backend, z. B. `redis://redis:6379/0`. Wenn gesetzt, cacht das Dashboard `validateSession()`-Ergebnisse über Replikate hinweg und teilt den Next.js-Fetch-Cache für die Latenz-Aggregat-/Env-List-Proxy-Routen. Edge-seitige OTP-Request- und Verify-Rate-Limits verwenden ebenfalls Redis, wenn vorhanden (offen fallend, wenn Redis nicht erreichbar; das serverseitige Limit ist der Sicherheits-Backstop). Siehe Redis (optionaler Cache) weiter unten.
`AGENTEYE_AGENT_URL`	Nein	keiner	Basis-URL des optionalen KI-Assistenten-`agent`-Dienstes, z. B. `http://agent:9100`. Nicht setzen, um den Assistenten vollständig auszublenden: Im Dashboard erscheint keine Assistent-Blase. Siehe enterprise-docs/assistant.md.
`AGENTEYE_AGENT_TOKEN`	Nein	keiner	Gemeinsames Geheimnis, das das Dashboard dem `agent`-Dienst präsentiert. Muss mit dem auf dem Agenten konfigurierten `AGENTEYE_AGENT_TOKEN` übereinstimmen. Siehe enterprise-docs/assistant.md.

Starten

docker run -d --restart unless-stopped \
  --name agenteye-dashboard \
  -e AGENTEYE_SERVER_URL="http://your-server-host:8080" \
  -e AGENTEYE_API_KEY="$ADMIN_KEY" \
  -p 3000:3000 \
  ghcr.io/agenteye-enterprise/dashboard:beta-latest

Telemetrie & Datenschutz

Das Dashboard sendet anonyme Produktnutzungs-Analytics an den Analytics-Dienst von Exosphere (PostHog): welche Dashboard-Seiten aufgerufen werden und eine Handvoll UI-Aktionen wie das Erstellen eines API-Schlüssels oder das Neubewerten einer Session. Dieses Nutzungssignal gibt Aufschluss darüber, welche Features priorisiert werden.

Keine Agenten-, Session- oder Event-Daten verlassen je Ihre Infrastruktur. Nur die Dashboard-UI-Nutzung wird gemeldet. Seiten-URLs werden vor dem Senden von Identifikatoren bereinigt, und Betreiber werden nur durch eine undurchsichtige interne ID identifiziert, niemals per E-Mail.
Telemetrie ist standardmäßig aktiviert. Um sie vollständig zu deaktivieren, setzen Sie AE_ANALYTICS_DISABLED=1 auf dem Dashboard-Container und starten neu.
Analytics werden an den eigenen /ingest-Pfad des Dashboards gesendet, den das Dashboard als Reverse-Proxy an PostHog (https://us.i.posthog.com) weiterleitet. Anfragen zunächst first-party zu halten bedeutet, dass Browser-Werbeblocker sie nicht blockieren. Der Dashboard-Container benötigt ausgehenden Zugriff auf PostHog; wenn dieser blockiert ist, funktioniert die Telemetrie still nicht und das Dashboard ist nicht beeinträchtigt.

KI-Assistent (optional)

Ein im Dashboard integrierter KI-Assistent ermöglicht es Ihrem Team, Fragen zu ihren Agent-Daten in natürlicher Sprache zu stellen (Sessions zusammenfassen, SQL für den /queries-Editor entwerfen und gespeicherte Abfragen in Dashboard-Kacheln umwandeln), ohne das Dashboard zu verlassen. Er läuft als separater interner agent-Container (auf dem Claude Agents SDK), der nur vom Dashboard erreichbar ist, und bleibt deaktiviert, bis Sie einen LLM-Endpunkt konfigurieren. Um ihn zu aktivieren, setzen Sie auf dem agent-Dienst eine LLM-Verbindung (Portkey über PORTKEY_API_KEY + einen Modell-Katalog-Slug AGENTEYE_AGENT_MODEL=@<slug>/<model>, direktes Anthropic über ANTHROPIC_API_KEY, ein anderes Gateway über ANTHROPIC_BASE_URL, oder Bedrock/Vertex), einen dedizierten Datenschlüssel und ein gemeinsames AGENTEYE_AGENT_TOKEN, das mit dem Dashboard übereinstimmt. Dashboard-Benutzer benötigen außerdem die agent:use-Berechtigung. Für den Datenschlüssel des Assistenten müssen Sie nichts manuell anlegen: Wählen Sie ein zufälliges Geheimnis, setzen Sie es als AGENTEYE_API_KEY auf dem agent und als AGENT_API_KEY auf dem server, und der Server befüllt es beim Start mit einem festen Berechtigungssatz. Sein Datenzugriff ist schreibgeschützt (events:read, evaluations:read, dashboards:read, queries:read), und er besitzt zusätzlich genehmigungsgepflegte Authoring-Scopes (dashboards:write, queries:write, queries:run), damit er gespeicherte Abfragen entwerfen und validieren sowie Dashboard-Kacheln im Auftrag des Benutzers erstellen kann; alle SQL-Abfragen laufen weiterhin über die schreibgeschützte ClickHouse-Rolle der Org, sodass dies erweitert, was der Assistent erstellen kann, nicht welche Daten er erreichen kann. Die Scopes sind im Code festgelegt und können nicht durch Konfiguration erweitert werden. Dieser Schlüssel ist geschützt; er kann nicht über die API deaktiviert oder regeneriert werden, nur durch Ändern des Werts und Neustart rotiert werden. Verwenden Sie niemals den Admin-/Dashboard-Schlüssel dafür. Vollständige Einrichtung, die vollständige Umgebungsvariablen-Referenz, Telemetrie-Optionen und das Sicherheitsmodell finden Sie in enterprise-docs/assistant.md.

ClickHouse (erforderlicher Analyse-Store)

ClickHouse hält Ihre Dashboards bei hohen Event-Volumina reaktionsfähig und ermöglicht es dem /queries-SQL-Editor, Events, Evaluierungen und Sessions in einem einzigen Store zu verknüpfen. Es ist der erforderliche kanonische Store für alle eingehenden Events, alle terminalen Evaluierungsergebnisse und die abgeleiteten Per-Session-Aggregate. PostgreSQL enthält die relationalen/veränderlichen Zustandstabellen (api_keys, users, otp_codes, evaluation_jobs, dashboards, saved_queries); die analytische Oberfläche lebt in ClickHouse, damit die Dashboard-Rollups und Ihre eigenen SQL-Abfragen sie nativ scannen und verknüpfen können, ohne datenbankübergreifende Round-Trips. Der Server verweigert den Start ohne CLICKHOUSE_URL.

Schema

Beim Server-Start werden drei ClickHouse-Objekte erstellt, alle idempotent (CREATE IF NOT EXISTS):

agenteye.events: ReplacingMergeTree(ingested_at), partitioniert nach toYYYYMM(ts), geordnet nach (session_id, ts, dedup_key). Doppelte Einfügungen (Collector-Wiederholungen) werden beim Merge auf eine einzelne Zeile reduziert; der Server berechnet einen deterministischen SHA-256-dedup_key für jedes Event, sodass Wiederholungen sicher sind.
agenteye.evaluations: ReplacingMergeTree(ingested_at), partitioniert nach toYYYYMM(finished_at), geordnet nach (session_id, finished_at, dedup_key). Einmal pro terminalem Evaluierungsergebnis durch die Evaluierungspipeline geschrieben. Gleiches Dedup-Key-Modell wie events.
agenteye.agent_sessions: ein VIEW über agenteye.events, keine physische Tabelle. Jede Spalte wird abgeleitet (started_at = min(ts), last_event_at = max(ts), ended_at = max(if event_type='agent_end', ts, NULL), event_count = count(), usw.). Kein Pro-Event-Upsert und kein separates Backfill; der View reflektiert automatisch, was in events enthalten ist.

Für Rückwärtskompatibilität mit gespeicherten Abfragen, die analytics.evaluations / analytics.sessions referenzieren, erstellt der Server außerdem eine analytics-ClickHouse-Datenbank mit Views über die agenteye.*-Tabellen; analytics.events, analytics.evaluations, analytics.agent_sessions, analytics.sessions werden alle korrekt aufgelöst.

Konfiguration

Das mitgelieferte docker-compose und deploy/base/clickhouse/ liefern einen für AgentEye’s Workload optimierten ClickHouse-Dienst:

2 GiB angefordert / 4 GiB Limit Arbeitsspeicher im mitgelieferten Base-Overlay (für kleine POC/Staging-Knoten dimensioniert); Produktionskunden sollten aufwärts skalieren — der empfohlene Mindestbedarf ist 2c / 4Gi Request, 6c / 8Gi Limit. max_server_memory_usage_to_ram_ratio=0.9
5 GiB Mark-Cache + 8 GiB unkomprimierter Cache
background_pool_size=16, background_merges_mutations_concurrency_ratio=2
MergeTree: parts_to_throw_insert=3000, parts_to_delay_insert=1500, non_replicated_deduplication_window=1000
local_io_method=auto (io_uring auf unterstützten Kerneln)
fsync_metadata=0: akzeptabel wegen At-Least-Once-Ingest + ReplacingMergeTree-Dedup
query_log aktiviert mit 30-Tage-TTL; query_thread_log entfernt (teuer bei hohem QPS)
max_execution_time=30 für benutzerseitige Abfragen
100 GiB PVC im StatefulSet-Template (Kunden-Overlays SOLLTEN dies für die Produktion auf eine schnelle SSD-Storage-Class überschreiben)

Backups

Ihr vollständiger Datensatz wird nächtlich in einem einzelnen wiederherstellbaren Archiv gesichert, sodass ein Cluster- oder Speicherverlust behebbar ist. ClickHouse wird automatisch durch den täglichen agenteye-backup-CronJob gesichert, der PostgreSQL und ClickHouse in einem Durchgang sichert. ClickHouse wird über seine HTTP-API gelesen: agenteye.events und agenteye.evaluations werden im ClickHouse-nativen Format gesichert (die Views und Zeilenrichtlinien werden beim Server-Start neu erstellt, sodass die Tabellendaten das vollständige Bild sind) und zusammen mit dem Postgres-Dump in ein einzelnes komprimiertes Archiv gebündelt, das in Ihren Objektspeicher hochgeladen wird. Ziel-Bucket und Cloud-Anmeldedaten werden pro Overlay konfiguriert. Siehe den Abschnitt Backups in enterprise-docs/kubernetes-deployment.md für Upload-Konfiguration und Wiederherstellungsschritte.

Redis (optionaler Cache)

Redis ist ein optionales gemeinsames Cache- und Rate-Limit-Backend, das von Server und Dashboard verwendet wird. Mit Redis und gesetztem REDIS_URL auf beiden Diensten:

Server cacht authentifizierte API-Key-Lookups, die /events/environments- und /evaluations/environments-Listen, das /events/latency_aggregate-Rollup (die schwerste Abfrage, die das Dashboard pollt), die /sessions-Liste und wechselt das OTP-Request-Rate-Limiting von Postgres COUNT(*) zu Redis INCR + EXPIRE.
Dashboard cacht validateSession()-Ergebnisse, damit die 10–20 authentifizierten API-Aufrufe, die ein typischer Seitenaufruf ausgibt, alle eine gemeinsame Upstream-Session-Prüfung teilen. Es begrenzt außerdem OTP-Request und OTP-Verify am Dashboard-Edge per Rate-Limiting.

Beide Dienste degradieren graceful, wenn Redis nicht erreichbar ist. Jeder Cache-Aufruf gibt innerhalb eines begrenzten Timeouts Err zurück und der Aufrufer fällt auf die Quelle zurück (Postgres auf dem Server, der upstream Rust-Server auf dem Dashboard). OTP-Rate-Limiting fällt auf dem Server auf den Postgres-COUNT(*)-Pfad zurück (die Sicherheitseigenschaft bleibt erhalten); das Edge-OTP-Limit des Dashboards fällt offen, während das serverseitige Limit weiterhin gilt. Redis-Ausfall verschlechtert die Latenz, nicht die Korrektheit.

Konfiguration

Das docker-compose-Bundle enthält bereits einen Redis-Dienst und verdrahtet REDIS_URL=redis://redis:6379/0 in Server und Dashboard. Um ein externes Redis zu verwenden, setzen Sie REDIS_URL auf Ihren Endpunkt und entfernen Sie den redis-Dienst aus der Compose-Datei.

Arbeitsspeicher und Persistenz

Das mitgelieferte Redis-Image läuft mit --appendonly yes --appendfsync everysec --maxmemory 256mb --maxmemory-policy allkeys-lru. AOF-Persistenz bedeutet, dass der Cache Container-Neustarts überlebt; everysec ist die richtige Balance zwischen Haltbarkeit und Leistung, da der Verlust der letzten Sekunde an Cache-Schreibvorgängen harmlos ist. LRU-Eviction begrenzt das Speicherwachstum.

Wann Redis NICHT eingesetzt werden sollte

Einzelinstanz-Dev/QA. Die In-Process-Caches des Servers allein liefern den größten Per-Replikat-Vorteil; Redis fügt das Cross-Replikat-Sharing hinzu, das Einzelinstanz-Setups nicht benötigen.
Air-Gapped-Installationen, bei denen der Betriebsaufwand für einen weiteren Dienst den Latenz-Gewinn überwiegt.

Docker Compose (empfohlen)

Eine docker-compose.yml ist im agenteye-enterprise/releases-Repository verfügbar. Sie startet Postgres, den Server und das Dashboard mit einem einzigen Befehl.

GITHUB_TOKEN=$AGENTEYE_TOKEN gh release download \
  --repo agenteye-enterprise/releases \
  --pattern 'docker-compose.yml' \
  --dir ./agenteye
cd agenteye

Standards über .env überschreiben:

# Verwenden Sie URL-sichere Passwörter (keine /, + oder = Zeichen).
# Generieren mit: openssl rand -hex 24
POSTGRES_PASSWORD=ihr-db-passwort
ADMIN_KEY=ihr-admin-geheimnis

# Dashboard-Authentifizierung
ADMIN_EMAIL=admin@ihrefirma.com
ALLOWED_EMAILS=*@ihrefirma.com

# SMTP für OTP-E-Mails (weglassen, um OTP-Codes nach stdout zu loggen)
# SMTP_HOST=smtp.ihranbieter.com
# SMTP_PORT=587
# SMTP_USERNAME=ihr-smtp-benutzer
# SMTP_PASSWORD=ihr-smtp-passwort
# SMTP_FROM=noreply@ihrefirma.com

RUST_LOG=info

docker compose up -d

Stoppen (behält Datenvolume):

docker compose down

Stoppen und alle Daten löschen:

docker compose down -v

Betriebseinstellungen

Eine kleine Gruppe betrieblicher Einstellungen, die früher durch Umgebungsvariablen festgelegt waren, sind jetzt pro Organisation über die /<org>/settings-Seite des Dashboards bearbeitbar; jede Org konfiguriert ihre eigenen. Änderungen werden innerhalb von Sekunden wirksam, ohne Neustart und ohne erneutes Deployment.

Einstellung	Bootstrap-Umgebungsvariable	Was sie steuert
Erlaubte Anmeldungen	`ALLOWED_EMAILS`	E-Mails (oder `*@domain.com`-Wildcards), die berechtigt sind, ein OTP zu empfangen und als Benutzer hinzugefügt zu werden
Standard-Benutzerberechtigungen	`DEFAULT_USER_PERMISSIONS`	Kommagetrennte Berechtigungs-Token, die vorausgewählt sind, wenn ein Admin + neuer Benutzer öffnet. Jedes Token muss einer der unter API-Schlüsselberechtigungen aufgelisteten Zeichenfolgen entsprechen. Standardmäßig das `standard`-Preset: schreibgeschützter Zugriff plus die alltäglichen On-Call-Aktionen (Re-Evaluierungen auslösen, Abfragen ausführen, Incidents bestätigen, den Assistenten nutzen).
Sitzungsdauer	`SESSION_TTL_SECS`	Wie lange ein Dashboard-Login gültig bleibt, bevor eine erneute Authentifizierung erforderlich ist. Das Dashboard prüft die Upstream-Session alle 5 Sekunden, sodass eine Berechtigungsänderung unter `/<org>/users` beim nächsten Request des betroffenen Benutzers wirksam wird, ohne erneute Anmeldung.
Einmalcode-Dauer	`OTP_TTL_SECS`	Wie lange ein OTP / Magic-Link verwendbar bleibt
Alert-Benachrichtigungskanäle	`ALERTS_ENABLED_CHANNELS`	Kommagetrennte Liste von Kanal-Arten, die der Alert-Dispatcher verwenden darf: `email`, `slack`, `webhook`. Die Per-Alert-Konfiguration wird weiterhin unter `/<org>/alerts/<id>` erstellt, aber der Dispatcher filtert jede ausgehende Zustellung durch diesen Satz; ein hier deaktivierter Kanal schließt mit einer `skipped_disabled`-Audit-Zeile kurz. Der `dashboard`-Kanal (der lokale Audit-Insert) ist immer erlaubt. Standardmäßig alle drei aktiviert.

Wie der Bootstrap funktioniert

Einstellungen werden pro Organisation in org_settings gespeichert. Beim ersten Start befüllt der Server die fehlenden Zeilen der Standard-Org aus der entsprechenden Umgebungsvariablen (oder einem sinnvollen Standard, wenn die Umgebungsvariable nicht gesetzt ist). Danach ist der gespeicherte Wert die maßgebliche Quelle und die Umgebungsvariable wird ignoriert; das Ändern der Umgebungsvariablen bei einem späteren Neustart wirkt sich nicht auf den Wert einer aktiven Org aus, und zusätzliche Orgs starten mit Standardwerten und konfigurieren ihre eigenen. Das bedeutet:

Für ein frisches Deployment setzen Sie die Umgebungsvariablen wie oben gezeigt, und die Standard-Org liest sie beim ersten Start.
Um einen Wert später zu ändern, melden Sie sich im Dashboard an und bearbeiten ihn unter /<org>/settings. Die Änderung gilt innerhalb von Sekunden über alle Server-Replikate; kein Neustart erforderlich.
Eine Start-Log-Zeile zeichnet auf, was gesetzt wurde gegenüber was bereits vorhanden war, sodass Sie bestätigen können, dass der Bootstrap wirksam wurde:
INFO settings bootstrap: seeded default-org row key=allowed_sign_ins env_var=ALLOWED_EMAILS seeded_from_env=true

Anmeldesemantik über Organisationen hinweg

Eine Session und ein OTP sind global für den Benutzer, nicht für eine einzelne Org, sodass zwei Regeln die Pro-Org-Einstellungen bei der Anmeldung abstimmen:

Session- / OTP-Dauer: Die strengste (kürzeste) Dauer unter den Orgs, zu denen der Benutzer gehört, gewinnt.
Erlaubte Anmeldungen: Das Gate verbindet jede Org-Zulassungsliste per ODER mit der Org-Mitgliedschaft: Ein Benutzer darf ein OTP anfordern, wenn die Zulassungsliste einer beliebigen Org seine E-Mail-Adresse zulässt oder er bereits Mitglied einer beliebigen Org ist.

Berechtigungen

Der Zugriff auf eine /<org>/settings-Seite ist durch zwei Berechtigungen geschützt:

settings:read: Seite und aktuelle Werte anzeigen.
settings:write: Änderungen speichern.

Der Bootstrap-Admin-Benutzer (aus ADMIN_EMAIL gesetzt) erhält automatisch beide zusammen mit allen anderen Berechtigungen. Anderen Benutzern können sie bei Bedarf unter /<org>/users gewährt werden.

Organisationen (Multi-Tenancy)

Ein einzelnes Deployment kann mehrere isolierte Organisationen (Tenants) bedienen; jede Datenzeile gehört genau einer Org, und die Isolation wird in der Datenbank-Engine erzwungen. Eine Single-Tenant-Installation benötigt hier nichts; alle Daten leben in einer integrierten default-Org. (Sie können dieser Org einen freundlicheren Namen und URL-Slug geben, sodass sie z. B. unter /acme statt /default erreichbar ist, indem Sie DEFAULT_ORG_NAME / DEFAULT_ORG_SLUG vor dem ersten Start setzen oder sie jederzeit mit agenteye-orgctl org rename umbenennen.) Tenant-Provisionierung ist nur für Betreiber. Organisationen und ihre Mitgliedschaften werden mit dem agenteye-orgctl-CLI erstellt und verwaltet, das innerhalb des Server-Images (neben agenteye-server) ausgeliefert wird und innerhalb des vorhandenen Server-Pods läuft; es gibt keinen separaten Pod/Job, keine HTTP-API und keinen Dashboard-Button. Es nutzt die DATABASE_URL, CLICKHOUSE_URL und ORG_CH_SECRET des Servers.

# Docker Compose - in den laufenden Server-Dienst hineinwechseln:
docker compose exec server agenteye-orgctl org create --slug acme --name "Acme Corp"
docker compose exec server agenteye-orgctl member add --org acme --email alice@acme.example --set admin

# Kubernetes - in das laufende Server-Deployment hineinwechseln:
kubectl -n agenteye exec deploy/server -- agenteye-orgctl org list

Verfügbare Verben: org create | list | rename | delete | purge und member add | list | update | remove, mit integrierten Berechtigungs-Sets admin, standard und read-only. Hinzugefügte Mitglieder erhalten beim ersten Dashboard-Login ein OTP. Bevor Sie eine zweite Org erstellen: Setzen Sie ein starkes, stabiles ORG_CH_SECRET (der org create-Befehl verweigert die Ausführung mit dem integrierten Entwicklungsstandard) und stellen Sie sicher, dass Postgres 15+ ist. Unverändert: Per-Org-API-Schlüssel werden weiterhin im Dashboard/API durch Org-Mitglieder erstellt; nur der Org- und Mitglieds-Lebenszyklus wurde in den CLI verschoben. Vollständige Befehlsreferenz und ein ausgearbeitetes Beispiel: enterprise-docs/tenant-management.md.

Kontextfenster-Füllstand

Jedes model_response-Event zeigt eine Kontextfüllstand-Pille — Eingabe- plus Ausgabe-Token als Prozentsatz des Kontextfensters dieses Modells. Die Bereiche sind healthy (0–24%), watch (25–49%), compacting (50–74%) und reset context (75–100%). AgentEye löst gängige Modell-IDs automatisch auf, sodass keine anfängliche Konfiguration erforderlich ist. Jedes Modell, das eine Organisation sendet, erscheint unter Einstellungen → Modell-Kontextfenster. Benutzer mit settings:write können dessen Fenster überschreiben oder ein privates/Proxy-Modell hinzufügen (0–1.000.000 Token); 0 bedeutet “unbekannt” und unterdrückt die Pille. Änderungen gelten für neu eingehende Events. Benutzer mit settings:read können die Liste einsehen. Neue Events erhalten den Füllstand ab dem Moment des Upgrades. Um auch historische Events (und die Pro-Modell-Liste) für ein bestehendes Deployment zu befüllen, führen Sie das einmalige Backfill aus — es wird innerhalb des Server-Images (wie agenteye-orgctl) ausgeliefert und läuft im vorhandenen Server-Pod:

# Vorschau (gibt die Pro-Org-Mutation aus, ändert nichts):
kubectl -n agenteye exec deploy/server -- agenteye-backfill-context-window --dry-run
# Anwenden:
kubectl -n agenteye exec deploy/server -- agenteye-backfill-context-window
# docker compose:
docker compose exec server agenteye-backfill-context-window

Es ist idempotent (sicher mehrfach ausführbar) und nutzt DATABASE_URL / CLICKHOUSE_URL / REDIS_URL aus dem Pod. Führen Sie es erneut aus, nachdem Sie Modellfenster bearbeitet haben, wenn Sie möchten, dass vorhandene Events neu berechnet werden.

Produktionsüberlegungen

Postgres: Verwenden Sie einen verwalteten Postgres-Dienst oder eine dedizierte Instanz mit regelmäßigen Backups. DATABASE_URL unterstützt alle Standard-libpq-Parameter, einschließlich sslmode=require für verschlüsselte Verbindungen.
TLS: Stellen Sie Server und Dashboard hinter einen Reverse-Proxy (nginx, Caddy, Traefik), der TLS terminiert.
Firewall: Der Server-Port (Standard 8080) sollte nur von Collector-Maschinen und dem Dashboard-Host erreichbar sein, nicht aus dem öffentlichen Internet.
Admin-Schlüssel: Setzen Sie ADMIN_KEY auf ein starkes zufälliges Geheimnis. Nach dem Bootstrapping erstellen Sie dedizierte, eingeschränkte Schlüssel für Collector und Dashboard, anstatt den Admin-Schlüssel überall zu verwenden.
Image-Tags: Fixieren Sie in der Produktion auf die Version in Ihren Release-Manifesten (z. B. server:v0.0.1-beta.48) statt auf einem Floating-Tag, um unbeabsichtigte Upgrades zu vermeiden. Aktuelle Beta-Builds werden unter beta-latest veröffentlicht; latest wird nur stabilen Releases zugewiesen.
Health-Monitoring: Auf Kubernetes verwendet die Readiness-Probe /ready (Postgres + ClickHouse-Erreichbarkeit), während Liveness auf /health bleibt. Für flottenweit Alerting nach Slack bei “Ist AgentEye selbst oben?”, aktivieren Sie das optionale Robusta-Add-on; siehe enterprise-docs/health-monitoring.md.

Verfügbare Image-Tags

Tag	Beschreibung
`latest`	Neuestes stabiles Release
`beta-latest`	Neuestes Pre-Release (Beta)
`v<version>`	Fixierte Version, z. B. `v0.0.1-beta.48` (empfohlen für die Produktion)

​Architekturübersicht

​Server

​Image herunterladen

​Umgebungsvariablen

​Starten

​Health-Check

​E-Mail-Magic-Link-URL

​Dashboard

​Image herunterladen

​Umgebungsvariablen

​Starten

​Telemetrie & Datenschutz

​KI-Assistent (optional)

​ClickHouse (erforderlicher Analyse-Store)

​Schema

​Konfiguration

​Backups

​Redis (optionaler Cache)

​Konfiguration

​Arbeitsspeicher und Persistenz

​Wann Redis NICHT eingesetzt werden sollte

​Docker Compose (empfohlen)

​Betriebseinstellungen

​Wie der Bootstrap funktioniert

​Anmeldesemantik über Organisationen hinweg

​Berechtigungen

​Organisationen (Multi-Tenancy)

​Kontextfenster-Füllstand

​Produktionsüberlegungen

​Verfügbare Image-Tags

Architekturübersicht

Server

Image herunterladen

Umgebungsvariablen

Starten

Health-Check

E-Mail-Magic-Link-URL

Dashboard

Image herunterladen

Umgebungsvariablen

Starten

Telemetrie & Datenschutz

KI-Assistent (optional)

ClickHouse (erforderlicher Analyse-Store)

Schema

Konfiguration

Backups

Redis (optionaler Cache)

Konfiguration

Arbeitsspeicher und Persistenz

Wann Redis NICHT eingesetzt werden sollte

Docker Compose (empfohlen)

Betriebseinstellungen

Wie der Bootstrap funktioniert

Anmeldesemantik über Organisationen hinweg

Berechtigungen

Organisationen (Multi-Tenancy)

Kontextfenster-Füllstand

Produktionsüberlegungen

Verfügbare Image-Tags