# Aktualizacja

> Zaktualizuj instalację do nowej wersji i sprawdź, co zmienić podczas przejścia z 2.1.0 na 2.2.0.

Aktualizacja zastępuje obrazy PentAGI, a gdy wydanie je zmieniło, również pliki compose. Twoje `.env` i woluminy danych pozostają, a migracje bazy danych uruchamiają się przy starcie PentAGI.

## [Zanim zaczniesz](https://pentagi.com/pl/docs/deployment/upgrade/#before-you-start)

* Przeczytaj [informacje o wydaniu](https://pentagi.com/changelog/) każdej wersji nowszej niż ta, którą uruchamiasz; od wersji 2.1.0 zawierają one wskazówki dotyczące aktualizacji.
* Wykonaj kopię zapasową bazy danych. Ani instalator, ani PentAGI tego nie robią, a migracji nie można cofnąć bez utraty danych. Przy domyślnym `PENTAGI_POSTGRES_USER` i `PENTAGI_POSTGRES_DB`:

  ```bash
  docker exec pgvector pg_dump -U postgres -Fc pentagidb > pentagi-backup.dump
  ```

  Zachowaj również kopie `.env` i plików compose: instalator zastępuje pliki compose bez tworzenia kopii zapasowej.
* Zakończ [flow](https://pentagi.com/pl/docs/glossary/#flow), których już nie potrzebujesz. [Sandbox](https://pentagi.com/pl/docs/glossary/#sandbox), który nadal działa, jest ponownie wykorzystywany w stanie, w jakim został utworzony, z ustawieniami wydania, które go stworzyło.
* Jeśli aktualizujesz z wersji 2.1.0, wprowadź zmiany opisane w sekcji [From 2.1.0 to 2.2.0](#from-210-to-220) w `.env` oraz w plikach obok niego, zanim rozpocznie się nowe wydanie. Przy włączonym logowaniu przez Google lub GitHub, wyczyść teraz `OAUTH_GOOGLE_CLIENT_ID` i `OAUTH_GITHUB_CLIENT_ID`; sekcja wyjaśnia dlaczego.

## [Docker Compose](https://pentagi.com/pl/docs/deployment/upgrade/#docker-compose)

1. Pobierz pliki compose nowego wydania obok swojego `.env`: `docker-compose.yml` oraz plik każdego opcjonalnego stosu, który uruchamiasz. Kontener PentAGI otrzymuje tylko zmienne wymienione w swoim pliku compose, więc nowe ustawienia w `.env` nie mają skutku za starszym plikiem.

   ```bash
   cd ~/pentagi
   curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/main/docker-compose.yml
   # and the file of each optional stack you run, for example:
   curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/main/docker-compose-langfuse.yml
   ```

2. Pobierz obrazy i uruchom ponownie, używając tych samych plików `-f`, których używasz do uruchamiania stosu. Bez `pull`, `up -d` zachowuje obrazy już znajdujące się na hoście.

   ```bash
   docker compose pull && docker compose up -d
   ```

3. Odśwież obraz sandboxa na hoście Docker, który uruchamia flow, czego `docker compose pull` nie robi. Flow utworzone później będą z niego korzystać.

   ```bash
   docker pull vxcontrol/kali-linux
   ```

Tag obrazu `latest` śledzi główną gałąź. Aby pozostać przy jednym wydaniu, ustaw `PENTAGI_IMAGE=vxcontrol/pentagi:<version>` w `.env`.

## [Instalator](https://pentagi.com/pl/docs/deployment/upgrade/#installer)

1. Pobierz instalator nowego wydania ze strony [Szybki start](https://pentagi.com/pl/docs/getting-started/quickstart/) i uruchom go ze swoim `.env`. Instalator w wersji 2.1.0 nie może zaktualizować samego siebie.
2. Aby zastąpić pliki compose, zmień ustawienie tak, aby w menu pojawiło się **Apply Changes**, wybierz je i odpowiedz `y`, gdy instalator wyświetli listę nieaktualnych plików.
3. W menu konserwacji uruchom **Update PentAGI**, aby pobrać nowe obrazy, oraz **Update Worker Image**, gdy zostanie to zaproponowane. Samo **Update PentAGI** zachowuje stare pliki compose.

## [Od 2.1.0 do 2.2.0](https://pentagi.com/pl/docs/deployment/upgrade/#from-210-to-220)

### [Pliki](https://pentagi.com/pl/docs/deployment/upgrade/#files)

* Plik compose montuje `example.bedrock.provider.yml` obok siebie. Instalator go tworzy; przy ręcznej instalacji utwórz go samodzielnie, pusty plik wystarczy: `touch example.bedrock.provider.yml`.
* Zastąp `docker-compose-langfuse.yml`, jeśli używasz Langfuse: plik z wersji 2.1.0 odnosi się do obrazu `minio/minio`, który nie jest już publikowany, więc `docker compose pull` zakończy się niepowodzeniem z tym plikiem. Jeśli twój `.env` ustawia `MINIO_IMAGE=minio/minio:…`, usuń tę linię.
* Dla [knowledge graph](https://pentagi.com/pl/docs/glossary/#knowledge-graph) umieść `examples/neo4j` z repozytorium w `./neo4j` — Graphiti potrzebuje swojej wtyczki APOC — i zobacz [Pamięć i wiedza](https://pentagi.com/pl/docs/concepts/memory/#knowledge-graph-optional) w sprawie presetów modeli. `GRAPHITI_MODEL_NAME` nie jest już odczytywany.
* Przy pierwszym uruchomieniu zostanie wykonanych osiem migracji bazy danych. `docker compose logs pentagi` wyświetla „Database schema updated successfully”, gdy zostaną one ukończone.

### [Logowanie i dostęp](https://pentagi.com/pl/docs/deployment/upgrade/#sign-in-and-access)

* Każdy musi zalogować się ponownie: sesje z wersji 2.1.0 są odrzucane. Tokeny API nadal działają, a skrypty wylogowują się za pomocą `POST /api/v1/auth/logout`.
* Token API otrzyma kod 403 na trasach REST `/users`, `/roles` i `/tokens`: zarządzaj kontami, rolami i tokenami z poziomu zalogowanej sesji przeglądarki.
* Logowanie przez Google i GitHub podpisuje teraz zweryfikowany przez providera adres e-mail do istniejącego konta z tym adresem, w tym kont lokalnych, z rolą tego konta. Wersja 2.1.0 nie może zmienić adresu e-mail konta, więc jeśli logowanie jest włączone, zaktualizuj system z pustymi `OAUTH_GOOGLE_CLIENT_ID` i `OAUTH_GITHUB_CLIENT_ID`, przenieś `admin@pentagi.com` na adres, który kontrolujesz, w sekcji **Settings → Account**, a następnie włącz logowanie z powrotem. Opcja **Reset Admin Password** instalatora znajduje administratora tylko po `admin@pentagi.com`.
* Za reverse proxy ustaw `TRUSTED_PROXIES`, w przeciwnym razie każdy użytkownik współdzieli adres proxy, a jedna seria nieudanych prób logowania zablokuje wszystkich na 15 minut — zobacz [Udostępnianie sieciowe](https://pentagi.com/pl/docs/configuration/security/#network-exposure).

### [Sandboxes](https://pentagi.com/pl/docs/deployment/upgrade/#sandboxes)

* Przy `DOCKER_INSIDE=true` — domyślnym szablonie `.env` z wersji 2.1.0 i domyśle instalatora — wersja 2.1.0 montowała gniazdo Dockera hosta w każdym sandboxu. Wersja 2.2.0 udostępnia agentom Docker tylko z oddzielnego zestawu daemonów w `DOCKER_INSIDE_HOST`; bez niego nie otrzymują go wcale, a log informuje `sandbox DISABLED`. Przy `DOCKER_INSIDE_HOST` ustaw `DOCKER_SOCKET=` jako puste, w przeciwnym razie `/var/run/docker.sock` szablonu będzie nadal montowany. Zobacz [Węzeł roboczy](https://pentagi.com/pl/docs/deployment/worker-node/).
* Zakończ flow rozpoczęte w wersji 2.1.0: ich sandboxes zachowują stare montowanie gniazda i możliwości aż do zakończenia flow.
* Pozostaw `TENANT_ID` puste: na istniejącej instalacji wskazuje ono PentAGI na nową, pustą schemat.

### [Modele i prompty](https://pentagi.com/pl/docs/deployment/upgrade/#models-and-prompts)

* Niestandardowy [provider](https://pentagi.com/pl/docs/glossary/#provider) wymaga `LLM_SERVER_KEY`: z pustym kluczem jest wyłączony, więc dla serwera bez uwierzytelniania ustaw dowolną niepustą wartość.
* `LLM_SERVER_LEGACY_REASONING` zostało usunięte. Niestandardowy provider wysyła `reasoning_effort` i zamienia budżet `reasoning.max_tokens` na poziom wysiłku; w modelach Kimi K2, GLM przed wersją 5.2 i MiniMax M budżet powoduje teraz niepowodzenie wywołania, więc usuń go z tych agentów.
* W plikach konfiguracyjnych providerów wpis agenta, który pozostawia `max_tokens`, `temperature`, `top_p` lub `n` puste, otrzymuje teraz domyślne wartości typu providera zamiast wysyłania niczego.
* Wbudowane domyślne modele zmieniły się dla każdego providera z wyjątkiem Bedrock; providery zapisane w **Settings → Providers** zachowują swoje modele. Pięć konfiguracji dołączonych do obrazu zmieniło modele — `openrouter`, `deepinfra`, `ollama-cloud`, `moonshot` i `deepseek`. Jeśli `LLM_SERVER_CONFIG_PATH` lub `OLLAMA_SERVER_CONFIG_PATH` wskazuje jeden z nich pod `/opt/pentagi/conf/`, zachowaj plik z wersji 2.1.0 na hoście i zamontuj go jako konfigurację niestandardową lub Ollama.
* Przy `EMBEDDING_URL` na serwerze innym niż OpenAI, ustaw `EMBEDDING_KEY`: `OPEN_AI_KEY` nie jest tam już wysyłane.
* Agenci przeszukują za pomocą jednego narzędzia `web_search`. Niestandardowe prompty z `{{.GoogleToolName}}` i innymi zmiennymi dla każdego silnika są ignorowane z ostrzeżeniem w logu, dopóki nie użyją `{{.WebSearchToolName}}`; oprzyj niestandardowe prompty searchera i pentestera na nowych domyślnych.

### [Inne zmiany](https://pentagi.com/pl/docs/deployment/upgrade/#other-changes)

* W ciągu dwóch minut od uruchomienia, a następnie co trzy godziny, PentAGI raportuje swoją wersję i podsumowanie instalacji do `update.pentagi.com`; [Sprawdzanie aktualizacji](https://pentagi.com/pl/docs/configuration/security/#update-check) wymienia, co wysyła, a `UPDATE_CHECK_INTERVAL=0` wyłącza tę funkcję.
* Profiler nie nasłuchuje już na porcie 7777, chyba że ustawiono `PPROF_ADDR`.
* Nowe opcjonalne ustawienia obejmują [awarię providera](https://pentagi.com/pl/docs/configuration/llm-providers/#failover) z `LLM_FALLBACK_PROVIDER`, `DOCKER_PORTS_BASE` dla [kilku instancji](https://pentagi.com/pl/docs/deployment/production/#several-instances-tenant_id), `DOCKER_IMAGE_SELECTION_MODE` i `DOCKER_ALLOWED_IMAGES`, wewnętrzny [search engine](https://pentagi.com/pl/docs/glossary/#search-engine) `WEB_SEARCH_INTERNAL_ENABLED` oraz klucze Mistral, xAI, MiniMax i Firecrawl.

## [Kopia zapasowa i przywracanie](https://pentagi.com/pl/docs/deployment/upgrade/#back-up-and-roll-back)

PentAGI nigdy nie cofa migracji, a ręczne ich uruchamianie usuwa dane, więc droga powrotu do wersji 2.1.0 prowadzi przez kopię zapasową. Zatrzymaj usługi korzystające z bazy danych, odtwórz ją i przywróć zrzut:

```bash
docker compose stop pentagi pgexporter
docker exec pgvector dropdb -U postgres pentagidb
docker exec pgvector createdb -U postgres pentagidb
docker exec -i pgvector pg_restore -U postgres -d pentagidb < pentagi-backup.dump
```

Następnie przywróć zapisane `.env` i pliki compose, ustaw `PENTAGI_IMAGE=vxcontrol/pentagi:2.1.0` i uruchom stos. Zachowaj nowy `docker-compose-langfuse.yml`: obrazu MinIO z pliku wersji 2.1.0 nie można już pobrać.