# Produkcja

> Uruchamianie PentAGI dla zespołu — hardening, izolacja, Podman i wiele instancji.

## [Lista kontrolna](https://pentagi.com/pl/docs/deployment/production/#checklist)

* Ustaw wszystkie dane uwierzytelniające, w tym `COOKIE_SIGNING_SALT`, przed pierwszym uruchomieniem — zobacz [Bezpieczeństwo](https://pentagi.com/pl/docs/configuration/security/). Instalator generuje sól i hasła usług, ale nie hasła administratora Langfuse i Grafana: ustaw `LANGFUSE_INIT_USER_PASSWORD`, `password` w szablonie, zanim Langfuse zostanie uruchomiony po raz pierwszy, a domyślne `admin` / `admin` Grafany zmień po jej pierwszym uruchomieniu. Na działającej instalacji zmień hasła PostgreSQL i Neo4j wewnątrz baz danych, zanim zmienisz je w `.env`.
* Użyj prawdziwego certyfikatu i stabilnego `PUBLIC_URL`.
* Za reverse proxy ustaw `TRUSTED_PROXIES` na adres lub CIDR proxy. W przeciwnym razie wszyscy użytkownicy współdzielą adres proxy, a 30 nieudanych prób logowania w ciągu 5 minut zablokuje dostęp wszystkim na 15 minut.
* Przenieś wykonywanie [tool](https://pentagi.com/pl/docs/glossary/#tool) na dedykowany [worker node](https://pentagi.com/pl/docs/deployment/worker-node/).
* Włącz [obserwowalność](https://pentagi.com/pl/docs/configuration/observability/), aby móc śledzić koszty i błędy.
* Trzymaj [knowledge graph](https://pentagi.com/pl/docs/glossary/#knowledge-graph) i Langfuse w sieci prywatnej.

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

PentAGI działa zarówno na Podman, jak i na Docker. W trybie rootless usługa `scraper` wymaga dodatkowej konfiguracji, ponieważ kontenery rootless nie mogą wiązać portów uprzywilejowanych; README repozytorium opisuje konfiguracje rootless i rootful.

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

Pozostaw `TENANT_ID` puste dla pojedynczej instalacji i nie zmieniaj tej wartości w istniejącej: późniejsze ustawienie przenosi instancję do nowego, pustego schematu, który zaczyna się od domyślnego konta `admin@pentagi.com`, a jej [flow](https://pentagi.com/pl/docs/glossary/#flow), użytkownicy i ustawienia przestają być widoczne. Ustaw tę wartość w dodawanych instancjach, gdy kilka instancji PentAGI współdzieli zasoby zewnętrzne, takie jak jeden serwer PostgreSQL, jeden [worker node](https://pentagi.com/pl/docs/glossary/#worker-node), jedna instancja Neo4j lub jedno Langfuse:

| Obszar            | Wpływ `TENANT_ID=acme`                                                               |
| ----------------- | ------------------------------------------------------------------------------------ |
| PostgreSQL        | Działa w schemacie `acme` zamiast `public`                                           |
| Kontenery robocze | Nazwane `acme-pentagi-terminal-<flow>`                                               |
| Knowledge graph   | Identyfikatory grup stają się `acme-flow-<id>`                                       |
| Uwierzytelnianie  | Klucze ciasteczek i tokenów zawierają identyfikator [tenant](https://pentagi.com/pl/docs/glossary/#tenant) |
| Telemetria        | Dane Langfuse i OpenTelemetry są oznaczone identyfikatorem tenant                    |

Wartość musi być zgodna z `^[a-z][a-z0-9_]{0,31}$`. Zasoby hosta nie są odizolowane przestrzennie. Instancje na jednym serwerze potrzebują własnych `DATA_DIR` i publikowanych portów. Instancje, których [sandboxes](https://pentagi.com/pl/docs/glossary/#sandbox) działają na tym samym hoście Docker, na jednym serwerze lub współdzielonym worker node, potrzebują własnego `DOCKER_PORTS_BASE` oraz, jeśli jest ustawiony, własnego `DOCKER_WORK_DIR`; w przeciwnym razie ich sandboxes zajmą te same porty i flow nie uruchomią się. Każda baza rozpoczyna zakres 2000 portów, domyślnie `28000`, więc użyj na przykład `28000` i `30000`.