# Producción

> Ejecutar PentAGI para un equipo: hardening, aislamiento, Podman y varias instancias.

## [Lista de verificación](https://pentagi.com/es/docs/deployment/production/#checklist)

* Configura todas las credenciales, incluida `COOKIE_SIGNING_SALT`, antes del primer inicio — consulta [Seguridad](https://pentagi.com/es/docs/configuration/security/). El instalador genera la sal y las contraseñas de los servicios, pero no las contraseñas de administrador de Langfuse y Grafana: configura `LANGFUSE_INIT_USER_PASSWORD` y `password` en la plantilla, antes de que Langfuse se inicie por primera vez, y cambia el `admin` / `admin` predeterminado de Grafana después de su primer inicio. En una instalación en ejecución, cambia las contraseñas de PostgreSQL y Neo4j dentro de las bases de datos antes de cambiarlas en `.env`.
* Sirve un certificado real y un `PUBLIC_URL` estable.
* Detrás de un proxy inverso, establece `TRUSTED_PROXIES` con la dirección o CIDR del proxy. De lo contrario, todos los usuarios comparten la dirección del proxy y 30 intentos de inicio de sesión fallidos en 5 minutos bloquean a todos durante 15 minutos.
* Mueve la ejecución de [tool](https://pentagi.com/es/docs/glossary/#tool) a un [worker node](https://pentagi.com/es/docs/deployment/worker-node/) dedicado.
* Habilita la [observabilidad](https://pentagi.com/es/docs/configuration/observability/) para que puedas seguir los costos y los fallos.
* Mantén el [knowledge graph](https://pentagi.com/es/docs/glossary/#knowledge-graph) y Langfuse en una red privada.

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

PentAGI se ejecuta tanto en Podman como en Docker. En modo rootless, el servicio `scraper` necesita configuración adicional porque los contenedores rootless no pueden enlazar puertos privilegiados; el README del repositorio describe las configuraciones rootless y rootful.

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

Deja `TENANT_ID` vacío para una instalación única y manténlo vacío en una existente: configurarlo más tarde mueve la instancia a un esquema nuevo y vacío que comienza con la cuenta `admin@pentagi.com` por defecto, y sus [flows](https://pentagi.com/es/docs/glossary/#flow), usuarios y configuraciones ya no aparecen. Configúralo en las instancias que añadas cuando varias instancias de PentAGI compartan recursos externos como un servidor PostgreSQL, un [worker node](https://pentagi.com/es/docs/glossary/#worker-node), un Neo4j o un Langfuse:

| Área                | Efecto de `TENANT_ID=acme`                                                  |
| ------------------- | --------------------------------------------------------------------------- |
| PostgreSQL          | Funciona dentro del esquema `acme` en lugar de `public`                     |
| Contenedores worker | Con nombre `acme-pentagi-terminal-<flow>`                                   |
| Knowledge graph     | Los IDs de grupo se convierten en `acme-flow-<id>`                          |
| Autenticación       | Las claves de cookies y tokens incluyen el [tenant](https://pentagi.com/es/docs/glossary/#tenant) |
| Telemetría          | Los datos de Langfuse y OpenTelemetry se etiquetan con el tenant            |

El valor debe coincidir con `^[a-z][a-z0-9_]{0,31}$`. Los recursos del host no tienen espacios de nombres aislados. Las instancias en un mismo servidor necesitan su propio `DATA_DIR` y puertos publicados. Las instancias cuyos [sandboxes](https://pentagi.com/es/docs/glossary/#sandbox) se ejecutan en el mismo host de Docker, ya sea en un servidor o en un worker node compartido, necesitan su propio `DOCKER_PORTS_BASE` y, si está configurado, su propio `DOCKER_WORK_DIR`; de lo contrario, sus sandboxes reclaman los mismos puertos y los flows no pueden iniciarse. Cada base inicia un rango de 2000 puertos, `28000` por defecto, así que usa por ejemplo `28000` y `30000`.