Instalacja i self-hosting

Olivares AI dostarczany jest jako jeden statyczny plik binarny z wbudowaną konsolą webową. Płaszczyzna kontrolna — część, która obserwuje, zarządza i audytuje agentów AI na twojej infrastrukturze — działa w twoim perymietrze i może być izolowana sieciowo. Ta strona obejmuje instalację o kształcie produkcyjnym: jeden host, bezpieczne domyślne ustawienia, sondy zdrowia i wybór magazynu, który ma znaczenie dla wdrożeń wielodzierżawczych.

Jeśli chcesz tylko najpierw się rozejrzeć, szybki start uruchamia syntetyczną demostracyjną infrastrukturę w około pięć minut. Ta strona to prawdziwa postawa.

Pobierz plik binarny

Nie ma publicznego URL do pobrania do skopiowania tutaj. Plik binarny olivares otrzymujesz na jeden z dwóch sposobów:

• Podpisany artefakt wydania — zweryfikuj go zanim uruchomisz. Zobacz weryfikacja wydania dla łańcucha podpisów i provenance.
• Budowa ze źródeł — magazyn to czysty Go SQLite, więc nie ma toolchaina C. task build produkuje ./bin/olivares z wbudowanym interfejsem webowym i konektorami pierwszej strony; olivares version potwierdza co zbudowałeś.

Tak czy inaczej kończysz z jednym plikiem. Zainstaluj go i utwórz dedykowanego użytkownika serwisowego zamiast uruchamiać jako root.

Bezpieczne domyślne ustawienia

Domyślne są dobrane tak, by świeża instalacja była bezpieczna zanim dotkniesz jakichkolwiek flag.

Minimalne pierwsze uruchomienie:

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

Katalog danych zawiera magazyn, klucz podpisu audytu i materiały TLS. Zrób jego kopię zapasową i chroń restrykcyjnymi uprawnieniami.

Odbierz jednorazowy token konfiguracji

Świeża instalacja nie ma domyślnych poświadczeń. Przy pierwszym uruchomieniu, gdy nie istnieją jeszcze użytkownicy, silnik tworzy jednorazowy token konfiguracji i drukuje go tylko na stdout — nigdy do logów:

=== 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.
========================

Przechowywany jest tylko hash tokenu, więc przegapiony token nie może być odzyskany, a restart nie wydrukuje go ponownie. Na zupełnie nowej instalacji bez użytkowników, usunięcie przechowywanego tokenu z katalogu danych i restart tworzy nowy. To odzyskiwanie działa tylko gdy nie ma jeszcze użytkowników, więc nigdy nie może przejąć skonfigurowanej instalacji.

Po utworzeniu pierwszego administratora punkt końcowy konfiguracji jest zamknięty na zawsze.

Sondy zdrowia

Listener HTTP udostępnia dwie sondy z celowo różnymi semantykami. Podłącz je do odpowiedniej sondy Kubernetes — pomylenie dwóch powoduje pętle restartów lub przestarzały routing.

/livez to żywotność. Nie uruchamia żadnego sprawdzania zależności: jeśli proces może odpowiedzieć, jest żywy. Niedziałająca zależność nigdy nie powinna wyzwalać restartu żywotności.

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

/readyz to gotowość i jest sygnałem dostępności, na którym load balancer powinien drenować. Zwraca 503 w dwóch przypadkach, rozróżnianych w ciele dla twoich logów:

• Magazyn nieosiągalny — {"status":"unavailable","store":"down"}. Ping magazynu działa z krótkim timeoutem, więc zakleszczony backend drenuje instancję zamiast wisieć.
• Nie jest aktywnym pisarzem — {"status":"standby","store":"up","leader":false}. W klastrze aktywno-pasywnym standby raportuje 503 tutaj, aby Service przestał trasować do niego, bez restartowania go (to zadanie /livez — gorący standby musi pozostać aktywny, by przejąć). Gdy lider umiera, standby przejmuje przywództwo i to przeskakuje na 200, więc ruch podąża za nowym liderem automatycznie.

Gdy silnik jest gotowy, zwraca 200:

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

setup_required jest raportowane dla obserwowalności, ale nie powoduje błędu gotowości — świeżo uruchomiony silnik jest gotowy do bycia skonfigurowanym. Na magazynie jednowęzłowym pisarz jest zawsze aktywny, więc /readyz po prostu śledzi osiągalność magazynu.

Wybór magazynu

Magazyn jest wybierany przez --engine. Wybieraj według topologii, nie preferencji.

SQLite (domyślny)

Wbudowany magazyn SQLite w czystym Go nie wymaga nic zewnętrznego i jest właściwym wyborem dla pojedynczego węzła, laboratorium, małej infrastruktury lub instalacji izolowanej sieciowo. Cały stan żyje w katalogu danych.

Postgres (wielodzierżawczy)

Dla wdrożeń wielohostowych lub wielodzierżawczych użyj Postgres. Nie łącz się jako superuser ani jako rola z BYPASSRLS. Izolacja dzierżawców jest wymuszana przez FORCE ROW LEVEL SECURITY, a Postgres cicho pomija wszystkie polityki na poziomie wierszy dla takich ról — co pozostawiłoby tylko predykat warstwy aplikacji między dzierżawcami. Silnik odmawia uruchomienia z uprzywilejowaną rolą, chyba że wyraźnie przekażesz --allow-privileged-db-role (tylko jednoedzierżawczy lub tymczasowy).

Zamiast tego udostępnij dedykowaną rolę z minimalnym uprawnieniem — NOSUPERUSER NOBYPASSRLS NOCREATEROLE NOCREATEDB. Posiada ona własną bazę danych, więc może stosować migracje schematu; FORCE ROW LEVEL SECURITY stosuje politykę dzierżawcy nawet do właściciela tabeli, więc posiadająca-ale-nie-pomijająca rola pozostaje w pełni izolowana.

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

Użyj sslmode=verify-full i silnego hasła SCRAM. Prawdziwie międzydzierżawcze odczyty System (lista organizacji, pokrycie checkpoint wielodzierżawczy) wymagają oddzielnej roli: udostępnij jedną, która jest NOSUPERUSER BYPASSRLS — minimalne uprawnienie, ale zdolna czytać między dzierżawcami — i skieruj --admin-dsn na nią. Pomiń ją dla jednoedzierżawczych wdrożeń, a te odczyty są po prostu ograniczone przez RLS.

Zanim uznasz, że skończyłeś

Dwie rzeczy decydują, czy twoje dowody przetrwają incydent:

• Zrób kopię zapasową klucza podpisu audytu poza maszyną. Podpisuje on rejestr audytu tylko-do-dopisywania; jeśli zostanie utracony, rejestru nie można już ponownie zweryfikować. Silnik ostrzega przy pierwszym uruchomieniu — nie ma wymuszonego depozytu.
• Trzymaj kopię klucza publicznego rejestru poza maszyną. Ta kopia poza hostem sprawia, że weryfikacja audytu jest odporna po kompromitacji hosta.

Następnie zaplanuj prawdziwe kopie zapasowe katalogu danych.

Co gdzie działa

Tylko płaszczyzna kontrolna jest twoja do umieszczenia — izolowana sieciowo jeśli chcesz. Kolektory (płaszczyzna danych) zawsze działają na twojej infrastrukturze. Jedno zastrzeżenie warte wyraźnego stwierdzenia: Olivares zarządza i audytuje użycie Claude, ale inferencja Claude sama nie jest self-hostowana — dociera do API Anthropic (bezpośrednio lub przez Bedrock, Vertex lub Foundry). Tylko prawdziwie self-hostowane modele działają offline. Zobacz stronę uczciwości i ograniczenia dla pełnej granicy.

Następne kroki

• Podłącz prawdziwy sygnał: podłącz źródło i podłącz Claude Code.
• Dostosuj instalację: referencja konfiguracji.
• Zrozum model: mapa dostępu odczyt/zapis.