> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # Self-host Failproof AI Cloud > Implante o plano de controle do Failproof AI em um cluster Kubernetes gerenciado pelo cliente. O self-hosting é uma implantação Enterprise. [Entre em contato com o Failproof AI](mailto:support@befailproof.ai) para obter uma licença empresarial. ## Pré-requisitos * Kubernetes 1.27 ou mais recente com acesso cluster-admin * `kubectl` com suporte a Kustomize * Helm 3 * Acesso às imagens privadas `ghcr.io/agenteye-enterprise` * Dois nomes DNS: um para o dashboard e outro para ingest * Armazenamento persistente para PostgreSQL e ClickHouse * cert-manager e Traefik, ou infraestrutura equivalente de ingress e certificados adaptada ao seu overlay * SMTP para login OTP em produção e notificações A árvore de fontes fornece um overlay orientado para AWS/EKS e um overlay separado para GCP/GKE. Não combine as instruções de certificado, balanceador de carga ou backup entre eles: o GKE utiliza sua própria configuração de DNS-01, GCS e autoescalonamento. ## Sequência de implantação Instale o cert-manager e os controladores de ingress público/dashboard, verifique seus balanceadores de carga e, em seguida, crie o namespace, as credenciais de pull de imagem, as credenciais do banco de dados, a chave de bootstrap do administrador e os secrets de autenticação/SMTP. Defina `INGEST_DOMAIN` e `DASHBOARD_DOMAIN` no arquivo de ambiente de domínio gerado pelo overlay e crie registros DNS apontando para os balanceadores de carga correspondentes. Use o overlay customer/EKS ou GCP. Inspecione a saída renderizada do Kustomize, aplique-a e confirme que todas as cargas de trabalho e certificados atingiram o estado desejado antes de registrar máquinas. Faça login como administrador protegido, crie uma chave de máquina com escopo de organização e envie uma pequena sessão de teste pelo endpoint de ingest público. ## Serviços obrigatórios e opcionais | Componente | Requisito | | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | ClickHouse | Obrigatório. O servidor recusa a inicialização sem seu armazenamento de eventos canônico. | | PostgreSQL | Obrigatório para usuários, organizações, objetos salvos e estado do plano de controle. | | Redis | Opcional. O servidor e o dashboard degradam para comportamento baseado em banco de dados quando indisponível. | | SMTP | Opcional para desenvolvimento, obrigatório para OTP por e-mail e entrega de notificações em produção. | | Evaluator | Opcional. A avaliação automática permanece desabilitada sem `EVALUATOR_ENDPOINT`. | | LLM de assistente/auditoria | Opcional. Os recursos de assistente e auditoria baseados em LLM permanecem inativos até que uma conexão LLM seja configurada. | | Backup de armazenamento de objetos | Fortemente recomendado para arquivos de backup do PostgreSQL e ClickHouse. | ### Capacidade de auditoria e entrega em caso de falha Execute auditorias no deployment dedicado de audit-agent quando disponível. Cada pod de audit-agent aceita uma investigação por padrão; escalone o throughput com réplicas em vez de aumentar a concorrência por pod sem também aumentar a memória. O servidor pode despachar `réplicas do servidor × AUDIT_WORKERS` auditorias concorrentemente, portanto, a capacidade do dispatcher deve ser grande o suficiente para preencher a frota de audit-agents. Quando todos os slots do audit-agent estão ocupados, uma auditoria aguarda e tenta novamente por até um quarto de sua cadência, limitado a seis horas. Se nenhum slot ficar disponível, a execução é concluída sem resultados e envia um e-mail de falha. Falhas recorrentes do tipo "ocupado" indicam a necessidade de mais réplicas de audit-agent ou âncoras de agendamento mais espaçadas. Falhas recorrentes do tipo "encerrando" indicam pods instáveis ou um rollout em loop, e não capacidade insuficiente. As notificações de falha exigem um canal de e-mail habilitado e SMTP. Elas usam os destinatários da auditoria e, na ausência de um canal de e-mail configurado na auditoria, recorrem a `alerts.email_default_recipients`. ## Verificar a implantação 1. Abra o domínio do dashboard configurado, conclua o fluxo OTP do administrador e confirme o nome e o slug da organização. 2. Acesse **Administração → Chaves** e crie uma chave de máquina com escopo restrito. 3. Envie uma sessão de teste e confirme-a em **Observar → Eventos** e **Observar → Sessões**. 4. Teste um canal de alerta e, quando configurado, uma avaliação manual e uma auditoria. ```bash theme={null} kubectl get pods -n agenteye kubectl get certificates -n agenteye kubectl logs -n agenteye deploy/server --tail=100 fp --base-url https://failproof.example.com login fp --base-url https://failproof.example.com whoami fp --base-url https://failproof.example.com usage ``` Verifique o endpoint de saúde público e uma requisição autenticada `/v1` antes de registrar máquinas em produção. ## Autenticação e e-mail O dashboard utiliza e-mail e códigos de uso único. Sem SMTP, implantações de desenvolvimento registram os códigos OTP na saída do servidor. Quando `SMTP_HOST` está definido, nome de usuário, senha e remetente são obrigatórios em conjunto; caso contrário, o servidor recusa a inicialização. `SMTP_TLS` é um booleano. O transporte criptografado suportado é STARTTLS, normalmente na porta 587; SMTPS implícito na porta 465 não é suportado pelo transporte atual do servidor. Configure corretamente a URL pública do dashboard, pois os e-mails de OTP, alerta, incidente e auditoria utilizam-na para deep links. A associação à organização controla quem pode solicitar um código; cada organização pode restringir ainda mais os logins de seus próprios membros em **Administração → Configurações**. ## Requisitos para multi-tenant Antes de criar uma segunda organização, configure um secret de derivação ClickHouse forte e estável para a organização e mantenha-o idêntico em todas as réplicas do servidor. Rotacioná-lo sem uma migração coordenada pode tornar os usuários ClickHouse específicos da organização inacessíveis. Mantenha o listener do administrador de instância interno. O console do operador fornecido é opcional e foi projetado para `kubectl port-forward`, não para ingress público. Habilitá-lo requer sua própria chave de API forte, uma caixa de correio de super-admin e entrega funcional do segundo fator via SMTP. ### CLI de organização para acesso de emergência `agenteye-orgctl` é incluído na imagem do servidor e se comunica diretamente com o PostgreSQL e o ClickHouse. Permanece disponível quando o servidor público ou o console do operador está indisponível. ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl org create --slug acme --name "Acme Corp" kubectl -n agenteye exec deploy/server -- agenteye-orgctl org list kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member add --org acme --email ops@acme.com --set admin --protected ``` As operações de organização suportadas incluem: criar, listar, renomear, exclusão lógica, restaurar, reprovisionamento de usuário ClickHouse, gerenciamento de data de faturamento, feature flags e exclusão irreversível. As operações de membros incluem: adicionar, listar, atualizar, remover, substituições de permissão e estado de administrador protegido. Use a exclusão lógica antes da exclusão definitiva. `org purge` é irreversível e exige que a organização seja excluída primeiro. Membros protegidos não podem ser removidos ou rebaixados pela página comum de Usuários da organização até que um operador os desproteja explicitamente. ## Checklist de prontidão para produção * DNS de ingest e dashboard resolve para os caminhos de ingress pretendidos diferentes. * O TLS é válido; use TLS mútuo no ingest onde sua implantação exigir. * Os volumes do PostgreSQL e ClickHouse possuem alertas de capacidade. * Os backups incluem ambos os datastores e possuem um procedimento de restauração testado. * Os health checks alertam sobre silêncio no ingest, cargas de trabalho com falha, expiração de certificados, pressão de armazenamento e backups desatualizados. * Os logs estruturados são coletados sem duplicar um pipeline de logs existente no cluster. * A concorrência do Evaluator, auditoria e workers de alerta não foi alterada sem evidências mensuradas de fila. * Uma release de aplicação fixada e um procedimento de rollback estão registrados antes das atualizações. Os manifestos de implantação contêm suposições de segurança e disponibilidade específicas da plataforma. Revise os recursos renderizados, as políticas de rede, a exposição do ingress, as referências a secrets, as classes de armazenamento, os orçamentos de interrupção e os destinos de backup com sua equipe de plataforma antes de aplicá-los.