Installeren & zelf hosten

Productie-installatie van de enkele Olivares AI binary — geen standaard credentials, TLS standaard aan, /readyz en /livez probes.

Olivares AI wordt geleverd als één statische binary met de webconsole ingebouwd. Het control plane — het deel dat de AI-agents op je infrastructuur observeert, bestuurt en auditeert — draait in je perimeter en kan air-gapped worden. Deze pagina behandelt de productieachtige installatie: één host, veilige standaarden, healthprobes en de opslagkeuze die ertoe doet voor multi-tenant- deployments.

Als je alleen eerst wilt rondkijken, start de snelstart een synthetisch demo-domein op in ongeveer vijf minuten. Deze pagina is de echte houding.

Verkrijg de binary

Er is geen publieke download-URL om hier te kopiëren. Je krijgt de olivares binary op een van twee manieren:

Een ondertekend release-artefact — verifieer het voordat je het draait. Zie een release verifiëren voor de handtekening- en herkomstketen.
Bouwen vanuit broncode — de opslag is pure-Go SQLite, dus er is geen C-toolchain. Een task build produceert ./bin/olivares met de web-UI en first-party connectors ingebouwd; olivares version bevestigt wat je hebt gebouwd.

Hoe dan ook eindig je met een enkel bestand. Installeer het en maak een toegewijd serviceaccount aan in plaats van het als root te draaien.

Veilige standaarden

De standaarden zijn zo gekozen dat een verse installatie veilig is voordat je vlaggen aanpast.

Standaard	Gedrag
Credentials	Geen. Eerste opstart print een eenmalig, eenmalig-te-gebruiken setuptoken (prefix `olst_`); je maakt de eerste administrator ermee aan.
TLS	Aan. Zonder `--tls-cert`/`--tls-key` genereert de engine een zelfondertekend certificaat in de datadirectory en logt de `fingerprint_sha256`. `--insecure` (plaintext) is alleen voor localhost-ontwikkeling.
Bind	Loopback. `--listen` staat standaard op `127.0.0.1:8443` en gRPC op `127.0.0.1:8444`; stel ze bewust bloot, achter je eigen ingress en TLS.

Een minimale eerste opstart:

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

De datadirectory bevat de opslag, de audit-ondertekeningssleutel en het TLS-materiaal. Maak een back-up en bescherm het met restrictieve rechten.

Claim het eenmalige setuptoken

Een verse installatie heeft geen standaard credentials. Bij eerste opstart, zolang er geen gebruikers bestaan, genereert de engine een eenmalig setuptoken en print het naar alleen stdout — nooit de 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.
========================

Alleen de hash van het token wordt opgeslagen, dus een gemist token kan niet worden hersteld en een herstart print het niet opnieuw. Op een gloednieuwe installatie zonder gebruikers, verwijder het opgeslagen token uit de datadirectory en herstart om een nieuw token te genereren. Dat herstel werkt alleen zolang er geen gebruikers bestaan, dus het kan nooit een geconfigureerde installatie overnemen.

Nadat je de eerste administrator hebt aangemaakt, is het setup-endpoint voorgoed gesloten.

Healthprobes

De HTTP-listener stelt twee probes bloot met bewust verschillende semantiek. Sluit ze aan op de corresponderende Kubernetes-probe — het verwarren van de twee veroorzaakt herstartloops of verouderde routering.

/livez is liveness. Het voert geen afhankelijkheidscontrole uit: als het proces kan antwoorden, is het levend. Een falende afhankelijkheid mag nooit een liveness-herstart triggeren.

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

/readyz is readiness, en het is het beschikbaarheidssignaal waarop een load balancer moet drainen. Het retourneert 503 in twee gevallen, onderscheiden in de body voor je logs:

Opslag onbereikbaar — {"status":"unavailable","store":"down"}. De opslagping draait met een korte timeout, zodat een vastgelopen backend de instantie draint in plaats van te hangen.
Niet de actieve schrijver — {"status":"standby","store":"up","leader":false}. In een actief-passief cluster rapporteert een standby hier 503 zodat de Service stopt met routeren ernaar, zonder het te herstarten (dat is de taak van /livez — een hot standby moet actief blijven om over te nemen). Wanneer de leader uitvalt, verwerft een standby leiderschap en schakelt dit om naar 200, zodat verkeer automatisch de nieuwe leader volgt.

Wanneer de engine gereed is retourneert het 200:

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

setup_required wordt gerapporteerd voor observeerbaarheid maar faalt readiness niet — een vers opgestart engine is gereed om opgezet te worden. Op een single-node opslag is de schrijver altijd actief, dus /readyz volgt simpelweg de bereikbaarheid van de opslag.

Een opslag kiezen

De opslag wordt geselecteerd met --engine. Kies op basis van topologie, niet voorkeur.

SQLite (standaard)

De ingebouwde pure-Go SQLite-opslag heeft niets extern nodig en is de juiste keuze voor een enkele node, een lab, een klein domein of een air-gapped installatie. De hele status leeft in de datadirectory.

Postgres (multi-tenant)

Voor multi-host of multi-tenant deployments, gebruik Postgres. Maak geen verbinding als een superuser of als een rol met BYPASSRLS. Tenantisolatie wordt afgedwongen door FORCE ROW LEVEL SECURITY, en Postgres omzeilt stilzwijgend alle row-level-security voor zulke rollen — wat alleen het applicatieniveau-predikaat tussen tenants zou overlaten. De engine weigert te starten tegen een geprivilegieerde rol tenzij je expliciet --allow-privileged-db-role doorgeeft (single-tenant of alleen dev).

Richt in plaats daarvan een toegewijd least-privilege-rol in — NOSUPERUSER NOBYPASSRLS NOCREATEROLE NOCREATEDB. Het bezit zijn eigen database zodat het schemamigraties kan toepassen; FORCE ROW LEVEL SECURITY past het tenantbeleid zelfs toe op de tabeleigenaar, dus een bezittende-maar-niet-omzeilende rol blijft volledig geïsoleerd.

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

Gebruik sslmode=verify-full en een sterk SCRAM-wachtwoord. Echt cross-tenant systeem- lezingen (de organisatielijst, multi-tenant-checkpointdekking) hebben een aparte rol nodig: richt er een in die NOSUPERUSER BYPASSRLS is — least-privilege maar in staat om cross-tenant te lezen — en wijs --admin-dsn ernaar. Laat het weg voor single-tenant-deployments en die lezingen zijn simpelweg RLS-beperkt.

Voordat je klaar bent

Twee dingen bepalen of je bewijs een incident overleeft:

Maak een back-up van de audit-ondertekeningssleutel off-box. Het ondertekent het append-only auditlogboek; als het verloren gaat, kan het logboek niet meer worden geverifieerd. De engine waarschuwt bij eerste opstart — er is geen afgedwongen escrow.
Bewaar een off-box kopie van de publieke sleutel van het logboek. Die off-host kopie is wat audit- verificatie bestand maakt na een hostcompromis.

Plan daarna echte back-ups van de datadirectory.

Wat draait waar

Alleen het control plane is aan jou om te plaatsen — air-gapped als je wilt. De collectors (data plane) draaien altijd op je infrastructuur. Een kanttekening die het waard is om duidelijk te stellen: Olivares bestuurt en auditeert Claude-gebruik, maar Claude-inferentie zelf is niet zelf gehost — het bereikt Anthropic’s API (direct of via Bedrock, Vertex of Foundry). Alleen echt zelf gehoste modellen draaien offline. Zie de eerlijkheid & beperkingen pagina voor de volledige grens.

Volgende stappen

Sluit echt signaal aan: een bron aansluiten en Claude Code aansluiten.
Stem de installatie af: de configuratiereferentie.
Begrijp het model: de lees/schrijf-toegangskaart.