# Produzione

> Eseguire PentAGI per un team: hardening, isolamento, Podman e più istanze.

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

* Imposta tutte le credenziali, `COOKIE_SIGNING_SALT` inclusa, prima del primo avvio — vedi [Sicurezza](https://pentagi.com/it/docs/configuration/security/). L'installer genera il salt e le password dei servizi, ma non le password di amministrazione di Langfuse e Grafana: imposta `LANGFUSE_INIT_USER_PASSWORD`, `password` nel template, prima che Langfuse si avvii per la prima volta, e cambia le credenziali predefinite di Grafana `admin` / `admin` dopo il suo primo avvio. Su un'installazione in esecuzione, cambia le password di PostgreSQL e Neo4j all'interno dei database prima di cambiarle in `.env`.
* Utilizza un certificato reale e un `PUBLIC_URL` stabile.
* Dietro un reverse proxy, imposta `TRUSTED_PROXIES` sull'indirizzo o sul CIDR del proxy. Altrimenti ogni utente condivide l'indirizzo del proxy e 30 accessi falliti entro 5 minuti bloccano tutti per 15 minuti.
* Sposta l'esecuzione dei [tool](https://pentagi.com/it/docs/glossary/#tool) su un [worker node](https://pentagi.com/it/docs/deployment/worker-node/) dedicato.
* Abilita l'[osservabilità](https://pentagi.com/it/docs/configuration/observability/) per monitorare costi ed errori.
* Mantieni il [knowledge graph](https://pentagi.com/it/docs/glossary/#knowledge-graph) e Langfuse su una rete privata.

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

PentAGI funziona sia con Podman che con Docker. In modalità rootless, il servizio `scraper` richiede una configurazione aggiuntiva perché i container rootless non possono associarsi a porte privilegiate; il README del repository descrive le configurazioni rootless e rootful.

## [Più istanze (`TENANT_ID`)](https://pentagi.com/it/docs/deployment/production/#several-instances-tenant_id)

Lascia `TENANT_ID` vuoto per un'installazione singola e mantienilo vuoto su un'installazione esistente: impostarlo in seguito sposta l'istanza in uno schema nuovo e vuoto che inizia con l'account `admin@pentagi.com` predefinito, e i suoi [flow](https://pentagi.com/it/docs/glossary/#flow), utenti e impostazioni non appaiono più. Impostalo sulle istanze che aggiungi quando più istanze di PentAGI condividono risorse esterne come un server PostgreSQL, un [worker node](https://pentagi.com/it/docs/glossary/#worker-node), un'istanza di Neo4j o di Langfuse:

| Area             | Effetto di `TENANT_ID=acme`                                               |
| ---------------- | ------------------------------------------------------------------------- |
| PostgreSQL       | Opera nello schema `acme` invece di `public`                              |
| Container worker | Denominati `acme-pentagi-terminal-<flow>`                                 |
| Knowledge graph  | Gli ID di gruppo diventano `acme-flow-<id>`                               |
| Autenticazione   | Le chiavi di cookie e token includono il [tenant](https://pentagi.com/it/docs/glossary/#tenant) |
| Telemetria       | I dati di Langfuse e OpenTelemetry sono etichettati con il tenant         |

Il valore deve corrispondere a `^[a-z][a-z0-9_]{0,31}$`. Le risorse dell'host non sono isolate in namespace. Le istanze sullo stesso server necessitano del proprio `DATA_DIR` e delle proprie porte pubblicate. Le istanze i cui [sandbox](https://pentagi.com/it/docs/glossary/#sandbox) vengono eseguiti sullo stesso host Docker, su un server o su un worker node condiviso, necessitano del proprio `DOCKER_PORTS_BASE` e, se è impostato, del proprio `DOCKER_WORK_DIR`; altrimenti i loro sandbox reclamano le stesse porte e i flow non riescono ad avviarsi. Ogni base avvia una finestra di 2000 porte, `28000` per impostazione predefinita, quindi usa ad esempio `28000` e `30000`.