# Production

> Exécuter PentAGI pour une équipe — durcissement, isolation, Podman et plusieurs instances.

## [Liste de contrôle](https://pentagi.com/fr/docs/deployment/production/#checklist)

* Définissez tous les identifiants, y compris `COOKIE_SIGNING_SALT`, avant le premier démarrage — voir [Sécurité](https://pentagi.com/fr/docs/configuration/security/). L’installateur génère le sel et les mots de passe des services, mais pas les mots de passe administrateur Langfuse et Grafana : définissez `LANGFUSE_INIT_USER_PASSWORD`, `password` dans le modèle, avant le premier démarrage de Langfuse, et modifiez l’identifiant / mot de passe par défaut de Grafana `admin` / `admin` après son premier démarrage. Sur une installation en cours d’exécution, modifiez les mots de passe PostgreSQL et Neo4j au sein des bases de données avant de les modifier dans `.env`.
* Fournissez un certificat réel et une valeur `PUBLIC_URL` stable.
* Derrière un reverse proxy, définissez `TRUSTED_PROXIES` sur l’adresse ou le CIDR du proxy. Sinon, tous les utilisateurs partagent l’adresse du proxy, et 30 échecs de connexion en 5 minutes bloquent tout le monde pendant 15 minutes.
* Déplacez l'exécution de [tool](https://pentagi.com/fr/docs/glossary/#tool) vers un [worker node](https://pentagi.com/fr/docs/deployment/worker-node/) dédié.
* Activez l'[observabilité](https://pentagi.com/fr/docs/configuration/observability/) afin de suivre les coûts et les échecs.
* Maintenez le [knowledge graph](https://pentagi.com/fr/docs/glossary/#knowledge-graph) et Langfuse sur un réseau privé.

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

PentAGI fonctionne aussi bien sur Podman que sur Docker. En mode rootless, le service `scraper` nécessite une configuration supplémentaire car les conteneurs rootless ne peuvent pas se lier aux ports privilégiés ; le README du dépôt décrit les configurations rootless et rootful.

## [Plusieurs instances (`TENANT_ID`)](https://pentagi.com/fr/docs/deployment/production/#several-instances-tenant_id)

Laissez `TENANT_ID` vide pour une installation unique, et laissez-le vide sur une installation existante : le définir ultérieurement déplace l'instance vers un nouveau schéma vide qui commence avec le compte `admin@pentagi.com` par défaut, et ses [flows](https://pentagi.com/fr/docs/glossary/#flow), utilisateurs et paramètres n'apparaissent plus. Définissez-le sur les instances que vous ajoutez lorsque plusieurs instances PentAGI partagent des ressources externes telles qu'un serveur PostgreSQL, un [worker node](https://pentagi.com/fr/docs/glossary/#worker-node), une instance Neo4j ou Langfuse :

| Domaine           | Effet de `TENANT_ID=acme`                                                   |
| ----------------- | --------------------------------------------------------------------------- |
| PostgreSQL        | Fonctionne dans le schéma `acme` au lieu de `public`                        |
| Conteneurs worker | Nommés `acme-pentagi-terminal-<flow>`                                       |
| Knowledge graph   | Les identifiants de groupe deviennent `acme-flow-<id>`                      |
| Authentification  | Les clés de cookie et de jeton incluent le [tenant](https://pentagi.com/fr/docs/glossary/#tenant) |
| Télémétrie        | Les données Langfuse et OpenTelemetry sont étiquetées avec le tenant        |

La valeur doit correspondre à `^[a-z][a-z0-9_]{0,31}$`. Les ressources de l'hôte ne sont pas isolées par espace de noms. Les instances sur un même serveur nécessitent leurs propres `DATA_DIR` et ports publiés. Les instances dont les [sandbox](https://pentagi.com/fr/docs/glossary/#sandbox) s'exécutent sur le même hôte Docker, sur un serveur ou un worker node partagé, nécessitent leurs propres `DOCKER_PORTS_BASE` et, s'il est défini, leur propre `DOCKER_WORK_DIR` ; sinon, leurs sandbox revendiquent les mêmes ports et les flow ne parviennent pas à démarrer. Chaque base démarre une plage de 2000 ports, `28000` par défaut, utilisez donc par exemple `28000` et `30000`.