Wiki de Serviços Bravonix

Documentação dos ambientes e serviços internos da Bravonix, todos em br-sao (São Paulo) — dados processados no Brasil.

Se você chegou aqui para descobrir onde um sistema roda e como o código chega nele, comece pela tabela de ambientes.

Ambientes de produto

Os produtos têm ambientes dev, homolog e prod sob uma instalação própria do Coolify. O Adapter também tem test, compartilhando a máquina de dev. Painéis separados por produto não são preferência: no Coolify, quem entra em um painel enxerga as variáveis de todos os ambientes dele, produção inclusive.

Produto	O que é	Ambientes	Estado da produção
Adapter (LGPDQuest)	Plataforma de conformidade LGPD	dev · test · homolog · prod	⏳ a virada ainda não aconteceu
SmartITBI	Análise de imóveis para ITBI	dev · homolog · prod	✅ em uso, desde 21/08/2026
LBCA (cobrança)	Recuperação de crédito para instituições de ensino	dev · homolog · prod	⏳ no ar e sem a carteira
Bravobot (assistente)	Assistente conversacional com base de conhecimento	dev · homolog · prod	⏳ no ar e vazia

Ambiente de produção no ar não quer dizer sistema em uso

Em três dos quatro produtos, o prod já responde mas ainda não é o que atende cliente — o atendimento segue em instalações anteriores até cada virada ser decidida. Antes de apontar alguém para um endereço de produção, confira a coluna acima.

Serviços compartilhados

Serviço	Para que serve	Onde
Milvus	Armazenamento e busca de vetores	Laboratório, com acesso autenticado
Telemetria e monitoramento	Disponibilidade, recursos dos servidores e investigação de falhas	Central Grafana, Prometheus, Collector e Loki
Build e publicação	Construção das imagens, registry e entrega aos ambientes	Build compartilhado pelos quatro produtos
BravoCore	API de RAG multi-tenant e agentes LGPD	Nos quatro ambientes do Adapter, gerenciados pelo Coolify
Langfuse	Rastro das chamadas de modelo: prompt, tokens, custo e latência	Uma instância compartilhada, com projeto por ambiente — ver a página

Os modelos de linguagem são servidos pela própria Bravonix

Chat, geração de vetores e reordenação passam pelo gateway interno. Isso mantém o conteúdo dentro da infraestrutura e faz o custo ser previsível — mas significa que todos os produtos dependem desse gateway.

O que estes ambientes têm em comum

• A build acontece fora do ambiente, num servidor dedicado — nenhum deploy compete com quem está usando o sistema.
• Uma branch por ambiente, e o merge nela é o que dispara o deploy.
• Backup diário do banco e da configuração do painel, com um vigia que avisa quando um backup falha ou simplesmente não roda — o segundo caso é o perigoso, porque parece silêncio normal.
• Só o frontend é exposto: as APIs e os bancos não têm porta aberta para a internet.

Como esta wiki é publicada

O site é estático e servido pela máquina de build da infra, com certificado renovado automaticamente.

Para adicionar ou alterar uma página:

1. edite ou crie o .md em docs/;
2. registre no nav do mkdocs.yml se for página nova;
3. commite — o que sobe é a árvore local, e o repositório é a única cópia com histórico;
4. rode ./publicar.sh da sua máquina (precisa do tailnet e da chave da infra).

O servidor não puxa do GitHub

A saída SSH da máquina é bloqueada, então o conteúdo vai da máquina de quem edita. Enquanto ninguém rodar ./publicar.sh, o site continua na versão anterior — mesmo com tudo mergeado.