Instalação e auto-hospedagem

O Olivares AI e distribuído como um único binário estatico com a consola web embebida. O plano de controlo — a parte que observa, governa e audita os agentes de IA na sua infraestrutura — funciona no seu perímetro e pode ser air-gapped. Esta página cobre a instalação com forma de produção: um host, valores seguros por defeito, sondas de saúde e a escolha de armazém que importa para implantações multi-inquilino.

Se só quer ver primeiro, o inicio rápido arranca um ambiente de demonstração sintético em cerca de cinco minutos. Esta página e a postura real.

Obter o binário

Não há URL de download público para copiar aqui. Obtém o binário olivares de uma de duas formas:

• Um artefacto de versão assinado — verifique-o antes de o executar. Veja verificar uma versão para a cadeia de assinatura e proveniência.
• Compilar a partir do código-fonte — o armazém e SQLite em Go puro, portanto não há toolchain C. Um task build produz ./bin/olivares com a interface web e conectores de primeira parte embebidos; olivares version confirma o que compilou.

De qualquer forma acaba com um único ficheiro. Instale-o e crie um utilizador de serviço dedicado em vez de o executar como root.

Valores seguros por defeito

Os valores predefinidos são escolhidos para que uma instalação nova seja segura antes de tocar em quaisquer flags.

Um primeiro arranque mínimo:

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

O diretório de dados contém o armazém, a chave de assinatura de auditoria e o material TLS. Faca backup e proteja-o com permissões restritivas.

Reclamar o token de configuração único

Uma instalação nova não tem credenciais predefinidas. No primeiro arranque, enquanto não existem utilizadores, o motor cunha um token de configuração de uso único e imprime-o apenas em stdout — nunca nos registos:

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

Apenas o hash do token e armazenado, portanto um token perdido não pode ser recuperado e um reinicio não o reimprime. Numa instalação nova sem utilizadores, remover o token armazenado do diretório de dados e reiniciar cunha um novo. Essa recuperação funciona apenas enquanto não existem utilizadores, portanto nunca pode tomar conta de uma instalação configurada.

Após criar o primeiro administrador, o endpoint de configuração e fechado definitivamente.

Sondas de saúde

O listener HTTP expoe duas sondas com semanticas deliberadamente diferentes. Ligue-as a sonda Kubernetes correspondente — confundir as duas causa ciclos de reinicio ou roteamento obsoleto.

/livez e liveness. Não executa nenhuma verificação de dependência: se o processo consegue responder, esta vivo. Uma dependência em falha nunca deve acionar um reinicio por liveness.

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

/readyz e readiness, e e o sinal de disponibilidade em que um load balancer deve drenar. Retorna 503 em dois casos, distinguidos no corpo para os seus registos:

• Armazém inalcançável — {"status":"unavailable","store":"down"}. O ping do armazém executa com um timeout curto, portanto um backend bloqueado drena a instancia em vez de ficar pendurado.
• Não é o escritor ativo — {"status":"standby","store":"up","leader":false}. Num cluster ativo-passivo, um standby reporta 503 aqui para que o Service pare de rotear para ele, sem reinicia-lo (isso é trabalho do /livez — um hot standby deve permanecer ativo para tomar conta). Quando o lider morre, um standby adquire liderança e isto muda para 200, portanto o trafego segue o novo lider automaticamente.

Quando o motor esta pronto retorna 200:

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

setup_required e reportado para observabilidade mas não falha readiness — um motor recem arrancado esta pronto para ser configurado. Num armazém de no único, o escritor esta sempre ativo, portanto /readyz simplesmente rastreia a acessibilidade do armazém.

Escolher um armazém

O armazém e selecionado com --engine. Escolha por topologia, não por preferencia.

SQLite (predefinido)

O armazém SQLite embebido em Go puro não precisa de nada externo e e a escolha certa para um no único, um laboratorio, um ambiente pequeno ou uma instalação air-gapped. Todo o estado reside no diretório de dados.

Postgres (multi-inquilino)

Para implantações multi-host ou multi-inquilino, use Postgres. Não conecte como superutilizador ou como um papel com BYPASSRLS. O isolamento de inquilinos e aplicado por FORCE ROW LEVEL SECURITY, e o Postgres silenciosamente contorna toda a segurança ao nível de linha para tais papeis — o que deixaria apenas o predicado da camada de aplicação entre inquilinos. O motor recusa-se a arrancar contra um papel privilegiado a menos que passe explicitamente --allow-privileged-db-role (apenas inquilino único ou dev).

Provisione um papel dedicado de menor privilégio — NOSUPERUSER NOBYPASSRLS NOCREATEROLE NOCREATEDB. Possui a sua própria base de dados para poder aplicar migracoes de schema; FORCE ROW LEVEL SECURITY aplica a política de inquilino mesmo ao proprietario da tabela, portanto um papel que possui mas não contorna fica totalmente isolado.

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

Use sslmode=verify-full e uma palavra-passe SCRAM forte. Leituras genuinamente cross-inquilino de Sistema (a lista de organizações, cobertura de pontos de verificação multi-inquilino) precisam de um papel separado: provisione um que seja NOSUPERUSER BYPASSRLS — menor privilégio mas capaz de ler entre inquilinos — e aponte --admin-dsn para ele. Omita-o para implantações de inquilino único e essas leituras ficam simplesmente limitadas por RLS.

Antes de dar como concluido

Duas coisas decidem se a sua evidência sobrevive a um incidente:

• Faca backup da chave de assinatura de auditoria fora do host. Assina o registo de auditoria apenas adicao; se for perdida, o registo já não pode ser re-verificado. O motor avisa no primeiro arranque — não há custódia forçada.
• Mantenha uma copia fora do host da chave pública do registo. Essa copia fora do host e o que torna a verificação de auditoria resistente após um comprometimento do host.

Depois agende backups reais do diretório de dados.

O que funciona onde

Apenas o plano de controlo e seu para colocar — air-gapped se escolher. Os coletores (plano de dados) funcionam sempre na sua infraestrutura. Uma ressalva que vale a pena declarar claramente: o Olivares governa e audita o uso de Claude, mas a inferência Claude em si não e auto-hospedada — alcança a API da Anthropic (diretamente ou via Bedrock, Vertex ou Foundry). Apenas modelos genuinamente auto-hospedados funcionam offline. Veja a página de honestidade e limites para o limite completo.

Proximos passos

• Ligar sinal real: ligar uma fonte e ligar Claude Code.
• Afinar a instalação: a referência de configuração.
• Compreender o modelo: o mapa de acesso leitura/escrita.