Bravobot — ambientes

O Bravobot é o assistente conversacional da Bravonix: responde perguntas usando uma base de conhecimento própria, pesquisa na web quando a resposta não está nela, e mostra o caminho que percorreu em cada resposta. É o motor por trás dos chatbots entregues a clientes — cada um com a própria identidade visual, base e regras de tom.

Desde setembro de 2026 ele tem três ambientes padronizados — dev, homolog e prod —, gerenciados por uma instalação própria do Coolify, em br-sao (São Paulo).

Esta página descreve esses ambientes: o que cada um serve, como o código chega neles e o que muda de um para o outro.

Como ele decide o que responder

Antes de responder, o Bravobot escolhe entre três caminhos: procurar na base de conhecimento, pesquisar na web ou responder com o conhecimento do próprio modelo. Essa escolha é feita por um orquestrador, e cada etapa fica registrada — dá para abrir uma resposta e ver qual caminho foi tomado, quais trechos foram recuperados e quanto tempo cada parte levou.

A base de conhecimento é construída a partir de documentos enviados: o texto é dividido em trechos, cada trecho vira um vetor, e a busca acontece por proximidade de significado — não por palavra exata. Quem guarda esses vetores é o próprio PostgreSQL, com a extensão pgvector.

White-label

Cores, logotipo, fontes e textos do aplicativo são configuráveis pela administração, sem tocar em código. É o que permite entregar o mesmo produto com a cara de cada cliente.

Os três ambientes

Ambiente	Endereço	Serve para
Dev	dev.bravobot.bravonix.ia.br	Integração contínua do time
Homologação	homolog.bravobot.bravonix.ia.br	Validação antes de produção
Produção	prod.bravobot.bravonix.ia.br	Ambiente-alvo, no ar e ainda vazio

Produção está no ar, mas ainda não é a produção que atende

O ambiente responde normalmente e não tem dados. O atendimento continua em uma instalação anterior, fora deste Coolify, até a virada ser decidida. Não trate este endereço como o sistema em uso.

O que compõe um ambiente

Os três têm o mesmo desenho: quatro aplicações e dois bancos (recursos do Coolify, sem porta publicada na internet).

flowchart TB
    U["Usuário"]

    subgraph AMB["Um ambiente (dev / homolog / prod)"]
        FE["Frontend<br>nginx — serve as telas e encaminha"]
        API["Backend<br>Django + gunicorn"]
        W["Worker<br>tarefas demoradas"]
        B["Agendador<br>tarefas periódicas"]
        DB[("PostgreSQL + pgvector<br>dados e vetores da base")]
        RD[("Redis<br>fila e cache")]
    end

    EXT["Modelos de linguagem<br>conversa · vetores · reordenação"]

    U --> FE
    FE --> API
    API --> DB
    API --> RD
    W --> DB
    W --> RD
    B --> RD
    API --> EXT
    W --> EXT

Peça	Papel
Frontend (nginx)	Serve as telas e encaminha /api/, /django-admin/, /static/ e /media/ — o navegador fala só com ele
Backend (Django + gunicorn)	Conversas, base de conhecimento, orquestração das respostas e administração
Worker	Processa o que demora: leitura de documentos, geração de vetores, coleta em sites autorizados
Agendador	Dispara as tarefas periódicas
PostgreSQL + pgvector	Dados da aplicação e os vetores da base de conhecimento, no mesmo banco
Redis	Fila das tarefas e cache da aplicação

O banco precisa ser a imagem com pgvector

A busca por significado depende de uma extensão do PostgreSQL. Um banco comum sobe normalmente e só falha quando a aplicação tenta criar as tabelas de vetores — e falha de um jeito que parece erro de aplicação. Vale para restauração de backup também: o destino precisa da extensão antes.

Branches — uma por ambiente

Ambiente	Branch
Dev	develop
Homologação	homolog
Produção	main

Como o código chega no ambiente

1. O merge na branch do ambiente dispara um aviso ao Coolify.
2. O Coolify constrói a imagem em um servidor de build separado — nenhum ambiente gasta CPU compilando.
3. A imagem vai para o registro de imagens interno e o ambiente a baixa de lá.
4. Os containers são trocados; o antigo só sai depois de o novo responder.

Por que a build acontece fora

Construir imagem consome muito processador. Em uma máquina que também atende usuários, um deploy competiria com quem está usando o sistema.

Dados — o que cada ambiente contém

Ambiente	Conteúdo
Dev	Dados de teste, criados na subida
Homologação	Dados de teste
Produção	Vazio

A chave de criptografia é diferente em cada ambiente, de propósito

Conversas e documentos são gravados cifrados. Cada ambiente tem a própria chave, e isso é intencional: com chaves iguais, restaurar um backup de produção em homologação funcionaria, e o conteúdo real passaria a viver onde mais gente tem acesso. Com chaves diferentes, essa restauração falha na hora.

A chave não pode ser trocada depois: com outra chave, o que já está gravado vira texto ilegível. A cópia dela é guardada separada do backup do banco — juntas, uma cópia perdida entregaria as duas coisas.

Backup

O que	Quando
Os três bancos	Diário, de madrugada
Configuração do painel	Diário, logo depois
Vigia	Diário, ao meio-dia — avisa por e-mail quando um backup falha ou simplesmente não roda

O caso que o vigia cobre e a notificação comum não

Backup que falha costuma gerar alarme. Backup que deixa de ser executado não gera nada — e é o mais perigoso, porque parece silêncio normal. Por isso o vigia checa a existência de arquivo novo, não só o resultado da última execução.

Troubleshooting

A página abre, mas o login e a administração falham. Provável endereço não autorizado na aplicação: o backend recusa host que não esteja na lista dele e responde com erro genérico. Quando um ambiente ganha endereço novo, ele precisa ser cadastrado na aplicação, não só no DNS.

A página abre e responde, mas nada de inteligência funciona. As credenciais dos modelos de linguagem provavelmente estão vazias. O sistema sobe sem elas — só não responde nada que dependa de modelo.

O ambiente parece no ar, mas parte das telas dá erro. Vale conferir se o banco tem todas as tabelas. Um endereço respondendo não prova que a estrutura do banco está completa: as telas iniciais podem funcionar enquanto as que dependem das tabelas faltantes falham. A conferência é comparar a contagem de tabelas com a de um ambiente sabidamente bom.

Alguém pediu acesso administrativo. Em produção não existe usuário administrativo padrão: ele é criado sob demanda, com senha própria. Em dev e homologação existe um usuário de teste, que não deve ser usado como modelo para produção.