Установка та самостійне розгортання

Продакшн установка єдиного бінарного файлу Olivares AI — без облікових даних за замовчуванням, TLS увімкнений за замовчуванням, зонди /readyz та /livez.

Olivares AI поставляється як один статичний бінарний файл із вбудованою веб-консоллю. Площина управління — частина, яка спостерігає, керує та аудитує ШІ-агентів на вашій інфраструктурі — працює у вашому периметрі та може бути ізольованою. Ця сторінка описує установку для продакшн: один хост, безпечні замовчування, зонди стану здоров’я та вибір сховища, що має значення для багатоорендарних розгортань.

Якщо ви хочете лише оглянутися, швидкий старт завантажує синтетичне демонстраційне середовище приблизно за п’ять хвилин. Ця сторінка — реальна позиція.

Отримання бінарного файлу

Тут немає публічного URL для завантаження. Ви отримуєте бінарний файл olivares одним із двох способів:

Підписаний артефакт релізу — перевірте його перед запуском. Див. перевірка релізу для ланцюга підписів та провенансу.
Збірка з вихідного коду — сховище є чистим Go SQLite, тому немає тулчейну C. Команда task build створює ./bin/olivares із вбудованим веб-інтерфейсом та вбудованими конекторами; olivares version підтверджує, що ви зібрали.

У будь-якому випадку ви отримуєте один файл. Встановіть його та створіть виділеного сервісного користувача замість запуску від root.

Безпечні замовчування

Замовчування обрані так, щоб свіжа установка була безпечною до того, як ви торкнетеся будь-яких прапорців.

Замовчування	Поведінка
Облікові дані	Немає. Перше завантаження друкує одноразовий, одноразового використання токен налаштування (префікс `olst_`); ви створюєте першого адміністратора з його допомогою.
TLS	Увімкнений. Без `--tls-cert`/`--tls-key` рушій генерує самопідписаний сертифікат у каталозі даних та журналює його `fingerprint_sha256`. `--insecure` (відкритий текст) лише для локальної розробки.
Прив’язка	Loopback. `--listen` за замовчуванням `127.0.0.1:8443`, а gRPC — `127.0.0.1:8444`; відкривайте їх навмисно, за власним ingress та TLS.

Мінімальне перше завантаження:

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

Каталог даних містить сховище, ключ підпису аудиту та TLS-матеріали. Зробіть резервну копію та захистіть його обмежувальними дозволами.

Отримання одноразового токена налаштування

Свіжа установка не має облікових даних за замовчуванням. При першому завантаженні, поки користувачів не існує, рушій створює одноразовий токен налаштування та друкує його лише в stdout — ніколи в журнали:

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

Зберігається лише хеш токена, тому пропущений токен не може бути відновлений, а перезапуск не передруковує його. На абсолютно новій установці без користувачів видалення збереженого токена з каталогу даних та перезапуск створить новий. Це відновлення працює лише поки користувачів не існує, тому воно ніколи не може захопити налаштовану установку.

Після створення першого адміністратора точка доступу налаштування закривається назавжди.

Зонди стану здоров’я

HTTP-слухач надає два зонди з навмисно різною семантикою. Підключіть їх до відповідного зонду Kubernetes — плутання двох викликає цикли перезапуску або застарілу маршрутизацію.

/livez — це зонд живучості. Він не перевіряє залежності: якщо процес може відповісти, він живий. Відмова залежності ніколи не повинна викликати перезапуск за живучістю.

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

/readyz — це зонд готовності, і це сигнал доступності, за яким балансувальник навантаження повинен дренувати. Він повертає 503 у двох випадках, розрізнених у тілі для ваших журналів:

Сховище недоступне — {"status":"unavailable","store":"down"}. Перевірка сховища виконується з коротким тайм-аутом, тому заклинений бекенд дренує екземпляр замість зависання.
Не є активним записувачем — {"status":"standby","store":"up","leader":false}. У кластері активний-пасивний резервний повідомляє 503 тут, щоб Service припинив маршрутизацію до нього, не перезапускаючи його (це завдання /livez — гарячий резервний повинен залишатися запущеним для перехоплення). Коли лідер помирає, резервний отримує лідерство і це перемикається на 200, тому трафік автоматично слідує за новим лідером.

Коли рушій готовий, він повертає 200:

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

setup_required повідомляється для спостережуваності, але не впливає на готовність — свіжо завантажений рушій готовий бути налаштованим. На сховищі з одним вузлом записувач завжди активний, тому /readyz просто відстежує доступність сховища.

Вибір сховища

Сховище обирається за допомогою --engine. Обирайте за топологією, а не за вподобанням.

SQLite (за замовчуванням)

Вбудоване чисте Go SQLite сховище не потребує нічого зовнішнього і є правильним вибором для одного вузла, лабораторії, малого середовища або ізольованої установки. Весь стан живе у каталозі даних.

Postgres (багатоорендарний)

Для багатохостових або багатоорендарних розгортань використовуйте Postgres. Не підключайтеся як суперкористувач або як роль із BYPASSRLS. Ізоляція орендарів забезпечується через FORCE ROW LEVEL SECURITY, а Postgres мовчки обходить усю безпеку на рівні рядків для таких ролей — що залишить лише предикат на рівні додатку між орендарями. Рушій відмовляється запускатися проти привілейованої ролі, якщо ви явно не передасте --allow-privileged-db-role (лише для одного орендаря або тимчасового використання).

Натомість створіть виділену роль з найменшими привілеями — NOSUPERUSER NOBYPASSRLS NOCREATEROLE NOCREATEDB. Вона володіє власною базою даних, тому може застосовувати міграції схеми; FORCE ROW LEVEL SECURITY застосовує політику орендарів навіть до власника таблиці, тому роль, що володіє, але не обходить, залишається повністю ізольованою.

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

Використовуйте sslmode=verify-full та надійний пароль SCRAM. Справді кросорендарні System читання (список організацій, покриття контрольних точок для багатьох орендарів) потребують окрему роль: створіть таку, яка є NOSUPERUSER BYPASSRLS — з найменшими привілеями, але здатну читати між орендарями — та вкажіть --admin-dsn на неї. Опустіть її для одноорендарних розгортань, і ці читання просто обмежені RLS.

Перед тим, як вважати завершеним

Дві речі визначають, чи виживуть ваші докази після інциденту:

Зробіть резервну копію ключа підпису аудиту поза сервером. Він підписує журнал аудиту тільки для додавання; якщо він втрачений, журнал більше не може бути перевірений. Рушій попереджає при першому завантаженні — немає примусового ескроу.
Зберігайте позасерверну копію публічного ключа журналу. Ця позахостова копія — це те, що робить перевірку аудиту стійкою після компрометації хоста.

Потім заплануйте реальні резервні копії каталогу даних.

Що працює де

Лише площина управління — ваша для розміщення — ізольована, якщо оберете. Колектори (площина даних) завжди працюють на вашій інфраструктурі. Одне застереження, варте чіткого зазначення: Olivares керує та аудитує використання Claude, але сам вивід Claude не є самостійно розгортуваним — він досягає API Anthropic (напряму або через Bedrock, Vertex чи Foundry). Тільки справді самостійно розгорнуті моделі працюють офлайн. Див. сторінку чесність і обмеження для повної межі.

Наступні кроки

Підключіть реальний сигнал: підключення джерела та підключення Claude Code.
Налаштуйте установку: довідник конфігурації.
Зрозумійте модель: карта доступу читання/запису.