Installation und Self-Hosting

Olivares AI wird als ein statisches Binary mit eingebetteter Webkonsole ausgeliefert. Die Steuerungsebene — der Teil, der die KI-Agenten auf Ihrer Infrastruktur beobachtet, steuert und auditiert — läuft in Ihrem Perimeter und kann air-gapped werden. Diese Seite behandelt die produktionsgerechte Installation: Ein Host, sichere Standardwerte, Health-Probes und die Speicherwahl, die für Multi-Tenant-Deployments wichtig ist.

Wenn Sie nur erst einmal schauen wollen, startet der Schnellstart eine synthetische Demo-Umgebung in etwa fünf Minuten. Diese Seite ist die echte Haltung.

Das Binary erhalten

Es gibt keine öffentliche Download-URL zum Kopieren. Sie erhalten das olivares-Binary auf einem von zwei Wegen:

• Ein signiertes Release-Artefakt — verifizieren Sie es, bevor Sie es ausführen. Siehe Einen Release verifizieren für die Signatur- und Provenienzkette.
• Aus dem Quellcode kompilieren — der Speicher ist reines Go mit SQLite, es gibt also keine C-Toolchain. Ein task build erzeugt ./bin/olivares mit eingebetteter Web-UI und First-Party-Konnektoren; olivares version bestätigt, was Sie gebaut haben.

In jedem Fall erhalten Sie eine einzelne Datei. Installieren Sie sie und erstellen Sie einen dedizierten Dienstbenutzer, anstatt sie als Root auszuführen.

Sichere Standardwerte

Die Standardwerte sind so gewählt, dass eine frische Installation sicher ist, bevor Sie irgendwelche Flags ändern.

Ein minimaler erster Start:

olivares serve \
  --listen 127.0.0.1:8443 \
  --grpc-listen 127.0.0.1:8444 \
  --data-dir /var/lib/olivares

Das Datenverzeichnis hält den Speicher, den Audit-Signaturschlüssel und das TLS-Material. Sichern Sie es und schützen Sie es mit restriktiven Berechtigungen.

Den einmaligen Setup-Token einlösen

Eine frische Installation hat keine Standard-Credentials. Beim ersten Start, solange keine Benutzer existieren, prägt die Engine einen einmaligen Setup-Token und gibt ihn ausschließlich auf stdout aus — nie in die Logs:

=== FIRST-BOOT SETUP ===
No users exist yet. Create the first administrator:
  POST /v1/setup  {"token":"olst_…","email":"you@example.com","password":"..."}
This token is shown ONCE and is single-use.
========================

Nur der Hash des Tokens wird gespeichert, sodass ein verpasster Token nicht wiederhergestellt werden kann und ein Neustart ihn nicht erneut ausgibt. Bei einer brandneuen Installation ohne Benutzer können Sie den gespeicherten Token aus dem Datenverzeichnis entfernen und neu starten, um einen neuen zu prägen. Diese Wiederherstellung funktioniert nur, solange keine Benutzer existieren, sodass sie nie eine konfigurierte Installation übernehmen kann.

Nachdem Sie den ersten Administrator erstellt haben, ist der Setup-Endpunkt endgültig geschlossen.

Health-Probes

Der HTTP-Listener exponiert zwei Probes mit bewusst unterschiedlicher Semantik. Verdrahten Sie sie mit der passenden Kubernetes-Probe — eine Verwechslung verursacht Neustart-Schleifen oder veraltetes Routing.

/livez ist Liveness. Es führt keine Abhängigkeitsprüfung durch: Wenn der Prozess antworten kann, lebt er. Eine fehlschlagende Abhängigkeit darf nie einen Liveness-Neustart auslösen.

curl -ks https://127.0.0.1:8443/livez
# {"status":"ok"}

/readyz ist Readiness, und es ist das Verfügbarkeitssignal, auf das ein Load Balancer drain sollte. Es gibt 503 in zwei Fällen zurück, unterschieden im Body für Ihre Logs:

• Speicher nicht erreichbar — {"status":"unavailable","store":"down"}. Der Speicher-Ping läuft mit kurzem Timeout, sodass ein feststeckendes Backend die Instanz draint, anstatt zu hängen.
• Nicht der aktive Writer — {"status":"standby","store":"up","leader":false}. In einem aktiv-passiven Cluster meldet ein Standby hier 503, damit der Service das Routing zu ihm stoppt, ohne es neu zu starten (das ist die Aufgabe von /livez — ein Hot-Standby muss laufen bleiben, um zu übernehmen). Wenn der Leader stirbt, übernimmt ein Standby die Führung und dies wechselt zu 200, sodass der Verkehr automatisch dem neuen Leader folgt.

Wenn die Engine bereit ist, gibt sie 200 zurück:

{"status":"ok","store":"up","leader":true,"setup_required":false}

setup_required wird für Observability gemeldet, lässt aber die Readiness nicht fehlschlagen — eine frisch gestartete Engine ist bereit, eingerichtet zu werden. Bei einem Single-Node-Speicher ist der Writer immer aktiv, sodass /readyz einfach die Speichererreichbarkeit verfolgt.

Einen Speicher wählen

Der Speicher wird mit --engine ausgewählt. Wählen Sie nach Topologie, nicht nach Vorliebe.

SQLite (Standard)

Der eingebettete Pure-Go-SQLite-Speicher braucht nichts Externes und ist die richtige Wahl für einen einzelnen Knoten, ein Labor, eine kleine Umgebung oder eine Air-Gap- Installation. Der gesamte Zustand lebt im Datenverzeichnis.

Postgres (Multi-Tenant)

Für Multi-Host- oder Multi-Tenant-Deployments verwenden Sie Postgres. Verbinden Sie sich nicht als Superuser oder mit einer Rolle, die BYPASSRLS hat. Die Mandantenisolierung wird durch FORCE ROW LEVEL SECURITY durchgesetzt, und Postgres umgeht stillschweigend alle Row-Level-Security für solche Rollen — was nur das Anwendungsschicht-Prädikat zwischen den Mandanten lässt. Die Engine weigert sich, gegen eine privilegierte Rolle zu starten, es sei denn, Sie übergeben explizit --allow-privileged-db-role (nur Single-Tenant oder Dev).

Stellen Sie stattdessen eine dedizierte Least-Privilege-Rolle bereit — NOSUPERUSER NOBYPASSRLS NOCREATEROLE NOCREATEDB. Sie besitzt ihre eigene Datenbank, damit sie Schema-Migrationen anwenden kann; FORCE ROW LEVEL SECURITY wendet die Mandantenrichtlinie selbst auf den Tabellenbesitzer an, sodass eine besitzende-aber-nicht- umgehende Rolle vollständig isoliert bleibt.

olivares serve --engine postgres \
  --dsn "postgres://olivares_app:$DB_PASSWORD@db:5432/olivares?sslmode=verify-full" \
  --data-dir /var/lib/olivares

Verwenden Sie sslmode=verify-full und ein starkes SCRAM-Passwort. Echt cross-tenant System-Lesevorgänge (die Org-Liste, Multi-Tenant-Checkpoint-Abdeckung) brauchen eine separate Rolle: Stellen Sie eine bereit, die NOSUPERUSER BYPASSRLS ist — Least-Privilege, aber in der Lage, über Mandanten hinweg zu lesen — und richten Sie --admin-dsn darauf. Lassen Sie es für Single-Tenant-Deployments weg, und diese Lesevorgänge sind einfach RLS-eingeschränkt.

Bevor Sie es als erledigt betrachten

Zwei Dinge entscheiden, ob Ihre Nachweise einen Vorfall überleben:

• Sichern Sie den Audit-Signaturschlüssel off-box. Er signiert das nur-anhängende Audit-Ledger; wenn er verloren geht, kann das Ledger nicht mehr re-verifiziert werden. Die Engine warnt beim ersten Start — es gibt kein erzwungenes Escrow.
• Behalten Sie eine Off-Box-Kopie des Ledger-Public-Key. Diese Off-Host-Kopie macht die Audit-Verifizierung nach einer Host-Kompromittierung widerstandsfähig.

Planen Sie dann echte Backups des Datenverzeichnisses.

Was wo läuft

Nur die Steuerungsebene liegt bei Ihnen — air-gapped, wenn Sie wollen. Die Kollektoren (Datenebene) laufen immer auf Ihrer Infrastruktur. Ein Hinweis, der klar ausgesprochen werden sollte: Olivares steuert und auditiert die Claude-Nutzung, aber die Claude-Inferenz selbst ist nicht selbst gehostet — sie erreicht die Anthropic-API (direkt oder über Bedrock, Vertex oder Foundry). Nur wirklich selbst gehostete Modelle laufen offline. Siehe die Seite Ehrlichkeit und Grenzen für die vollständige Grenze.

Nächste Schritte

• Echtes Signal verdrahten: Eine Quelle verbinden und Claude Code verbinden.
• Die Installation tunen: Die Konfigurationsreferenz.
• Das Modell verstehen: Die Lese-/Schreib-Zugriffskarte.