# Produção

> Executando o PentAGI para uma equipe — hardening, isolamento, Podman e várias instâncias.

## [Checklist](https://pentagi.com/pt-br/docs/deployment/production/#checklist)

* Defina todas as credenciais, incluindo `COOKIE_SIGNING_SALT`, antes da primeira inicialização — veja [Segurança](https://pentagi.com/pt-br/docs/configuration/security/). O instalador gera o salt e as senhas dos serviços, mas não as senhas de administrador do Langfuse e do Grafana: defina `LANGFUSE_INIT_USER_PASSWORD` e `password` no template, antes que o Langfuse seja iniciado pela primeira vez, e altere o `admin` / `admin` padrão do Grafana após sua primeira inicialização. Em uma instalação em execução, altere as senhas do PostgreSQL e do Neo4j dentro dos bancos de dados antes de alterá-las em `.env`.
* Use um certificado real e um `PUBLIC_URL` estável.
* Atrás de um proxy reverso, defina `TRUSTED_PROXIES` como o endereço ou CIDR do proxy. Caso contrário, todos os usuários compartilham o endereço do proxy, e 30 tentativas de login com falha em 5 minutos bloqueiam todos por 15 minutos.
* Mova a execução de [tool](https://pentagi.com/pt-br/docs/glossary/#tool) para um [worker node](https://pentagi.com/pt-br/docs/deployment/worker-node/) dedicado.
* Habilite a [observabilidade](https://pentagi.com/pt-br/docs/configuration/observability/) para acompanhar custos e falhas.
* Mantenha o [knowledge graph](https://pentagi.com/pt-br/docs/glossary/#knowledge-graph) e o Langfuse em uma rede privada.

## [Podman](https://pentagi.com/pt-br/docs/deployment/production/#podman)

O PentAGI roda tanto no Podman quanto no Docker. No modo rootless, o serviço `scraper` precisa de configuração extra porque containers rootless não podem vincular portas privilegiadas; o README do repositório descreve as configurações rootless e rootful.

## [Várias instâncias (`TENANT_ID`)](https://pentagi.com/pt-br/docs/deployment/production/#several-instances-tenant_id)

Deixe `TENANT_ID` vazio para uma instalação única e mantenha-o vazio em uma existente: defini-lo posteriormente move a instância para um novo esquema vazio, que começa com a conta padrão `admin@pentagi.com`, e seus [flows](https://pentagi.com/pt-br/docs/glossary/#flow), usuários e configurações deixam de aparecer. Defina-o nas instâncias que você adicionar quando várias instâncias do PentAGI compartilharem recursos externos, como um servidor PostgreSQL, um [worker node](https://pentagi.com/pt-br/docs/glossary/#worker-node), um Neo4j ou um Langfuse:

| Área                       | Efeito de `TENANT_ID=acme`                                          |
| -------------------------- | ------------------------------------------------------------------- |
| PostgreSQL                 | Opera dentro do schema `acme` em vez de `public`                    |
| Contêineres do worker node | Nomeados como `acme-pentagi-terminal-<flow>`                        |
| Knowledge graph            | IDs de grupo tornam-se `acme-flow-<id>`                             |
| Autenticação               | Chaves de cookie e token incluem o [tenant](https://pentagi.com/pt-br/docs/glossary/#tenant) |
| Telemetria                 | Dados do Langfuse e OpenTelemetry são marcados com o tenant         |

O valor deve corresponder a `^[a-z][a-z0-9_]{0,31}$`. Recursos do host não são namespaced. Instâncias em um servidor precisam de seus próprios `DATA_DIR` e portas publicadas. Instâncias cujos [sandboxes](https://pentagi.com/pt-br/docs/glossary/#sandbox) rodam no mesmo host Docker, em um servidor ou em um worker node compartilhado, precisam de seus próprios `DOCKER_PORTS_BASE` e, se estiver definido, de seus próprios `DOCKER_WORK_DIR`; caso contrário, seus sandboxes reivindicam as mesmas portas e os flows falham ao iniciar. Cada base inicia uma janela de 2000 portas, `28000` por padrão, então use por exemplo `28000` e `30000`.