Jak samodzielnie hostować LiveContext na własnym VPS

Czym jest LiveContext i jakie są koszty jego uruchomienia

Do samodzielnego hostowania LiveContext wymagany jest VPS z około 8 GB pamięci RAM. LiveContext CE to otwartoźródłowa platforma automatyzacji, która uruchamia agentów AI wewnątrz samej automatyzacji. Oprogramowanie jest dostarczane jako stos Docker Compose składający się z sześciu kontenerów opartych na backendzie Java. Dokumentacja upstream zaleca minimum 4 GB pamięci RAM, przy czym 8 GB jest wartością rekomendowaną; plik compose wskazuje, w jaki sposób pamięć ta jest wykorzystywana.

Projekt znajduje się pod adresem livecontext-ai/livecontext-ce w serwisie GitHub i jest udostępniony na licencji AGPL-3.0. Aktualna wersja na sierpień 2026 to v0.2.11, opublikowana 3 sierpnia 2026 roku. Każdy obraz jest budowany wyłącznie dla architektury linux/amd64, co wyklucza korzystanie z tanich planów opartych na procesorach Arm. Niniejszy przewodnik blokuje tę wersję, umieszcza stos za odwrotnym proxy oraz opisuje procedurę tworzenia kopii zapasowych, której nie uwzględnia dokumentacja upstream.

Dobór rozmiaru VPS przed samodzielnym hostowaniem LiveContext

Każda usługa w dostarczonym pliku compose posiada jawny limit pamięci, co pozwala dobrać rozmiar serwera przed jego wynajęciem. Są to limity zapisane w pliku v0.2.11 compose, a nie zmierzone zużycie.

[
  {
    "label": "livecontext (backend)",
    "memory_limit_mb": 1536
  },
  {
    "label": "bridge",
    "memory_limit_mb": 512
  },
  {
    "label": "redis",
    "memory_limit_mb": 384
  },
  {
    "label": "postgres",
    "memory_limit_mb": 256
  },
  {
    "label": "minio",
    "memory_limit_mb": 256
  },
  {
    "label": "websearch (optional)",
    "memory_limit_mb": 2048
  },
  {
    "label": "searxng (optional)",
    "memory_limit_mb": 512
  },
  {
    "label": "renderer (optional)",
    "memory_limit_mb": 1024
  }
]

Sam backend ma limit ustawiony na 1536 MB. Limit ten dotyczy procesu Java 21, więc JVM zajmie większość tej pamięci i będzie ją utrzymywać. Pięć podstawowych usług zajmuje łącznie nieco poniżej 3 GB, a frontend nie posiada żadnego limitu, więc zużywa tyle, ile zażąda Node. Na serwerze VPS z 4 GB pamięci RAM nie pozostaje prawie nic dla jądra systemu i pamięci podręcznej stron, dlatego 4 GB podano jako wartość minimalną, a nie zalecaną.

Opcjonalne profile zwiększają zapotrzebowanie serwera do 8 GB. Profil agenta przeglądarki dodaje kontener Chromium z limitem 2048 MB obok instancji wyszukiwarki SearXNG, a profil renderowania dodaje kolejne 1024 MB na potrzeby zrzutów ekranu i plików PDF. Żaden z nich nie uruchomi się, dopóki nie włączysz odpowiedniego profilu, więc pozostaw oba wyłączone, dopóki nie będą potrzebne. Kontener SearXNG istnieje, aby pełnić rolę backendu wyszukiwania dla agenta, więc zwracane przez niego strony trafiają do promptów jako niezaufany tekst. Jest to granica zaufania, którą szczegółowo omawia artykuł udostępnianie wyszukiwania internetowego SearXNG agentowi AI.

Jeśli korzystasz już z n8n, zaplanuj zastąpienie go, zamiast dodawania kolejnych usług. Stos opisany w naszym przewodniku uruchamiania n8n na VPS z Docker i HTTPS to jeden proces Node obok Postgres, który działa stabilnie na małym serwerze. LiveContext rezerwuje dla samego backendu więcej pamięci, niż zużywa cały wspomniany stos. Dwie platformy automatyzacji na jednym serwerze VPS z 8 GB RAM będą działać poprawnie, dopóki obie nie uruchomią zadań w tej samej minucie. Jeśli współdzielisz hosta, nałóż jawne limity na wszystkie pozostałe usługi, korzystając z metody opisanej w naszym wpisie o ustawianiu limitów pamięci w Docker Compose, aby jeden niekontrolowany proces nie spowodował awarii całego systemu.

Instalacja LiveContext przy użyciu Docker Compose z przypiętą wersją

Rozpocznij od czystej instalacji Ubuntu 24.04 na serwerze VPS z zainstalowanym Docker Engine w wersji 24 lub nowszej oraz Compose v2. Jeśli Docker nie jest jeszcze zainstalowany, wykonaj najpierw kroki opisane w naszym poradniku podstaw Docker Compose na VPS, a następnie wróć do tego miejsca.

Plik README sugeruje npx livecontext jako metodę uruchomienia w jednej linii. Jest to dopuszczalne na komputerze lokalnym. Na serwerze plik compose powinien znajdować się w kontrolowanym katalogu, ponieważ aktualizacja sprowadza się wtedy do git checkout, co pozwala na weryfikację wprowadzonych zmian.

sudo apt update && sudo apt install -y git
git clone https://github.com/livecontext-ai/livecontext-ce.git
cd livecontext-ce
git tag --list 'v*' | tail -5
git checkout v0.2.11
cp docker/.env.ce.example docker/.env.ce
chmod 600 docker/.env.ce

Plik compose ma już przypisane wszystkie obrazy do konkretnych tagów wydań, na przykład ghcr.io/livecontext-ai/livecontext-ce:v0.2.11. Sprawdzenie odpowiedniego tagu git pozwala zachować spójność między plikiem compose a obrazami, ponieważ plik compose dla v0.2.11 został przygotowany pod konkretne wersje tych obrazów. Nie należy zmieniać tagów na latest. Tag latest jest zmienny, a backend wykonuje migracje bazy danych przy każdym starcie, więc przypadkowe pobranie nowej wersji może nieoczekiwanie zaktualizować schemat bazy w nocy, co uniemożliwi powrót do poprzedniej wersji bez przywracania kopii zapasowej.

Przed pierwszym uruchomieniem należy edytować docker/.env.ce (kolejna sekcja zawiera listę wymaganych zmian), a następnie uruchomić stos.

docker compose --env-file docker/.env.ce up -d
docker compose --env-file docker/.env.ce ps

Używaj tej samej flagi --env-file przy każdym poleceniu compose w tym poradniku. Compose odczytuje plik przy każdym wywołaniu, więc polecenie bez tej flagi przywróci domyślne ustawienia zapisane w pliku compose i może opublikować inne porty niż te, które zostały skonfigurowane.

Healthcheck backendu ma ustawiony start_period na 120s i odpytuje /actuator/health, dlatego docker compose ps będzie raportować usługę livecontext jako health: starting przez około dwie pierwsze minuty, podczas których trwają migracje schematu i rejestracja narzędzi. Jest to zachowanie poprawne. Szybka weryfikacja z poziomu serwera:

curl -s localhost:8080/actuator/health

Polecenie powinno zwrócić {"status":"UP"}. Gdy to nastąpi, otwórz interfejs webowy na porcie 3000. Pierwsze utworzone konto staje się kontem administratora, dlatego należy je utworzyć, zanim port stanie się dostępny dla osób trzecich. Jest to najważniejszy powód, dla którego nie należy udostępniać portu 3000 w Internecie od razu po instalacji.

Wartości env wymagające zmiany

Przykładowy plik zawiera domyślne ustawienia, dzięki którym stos uruchamia się na laptopie. Kilka z nich jest niebezpiecznych w przypadku serwera publicznego.

POSTGRES_PASSWORD=<random>
MINIO_ROOT_USER=<not minioadmin>
MINIO_ROOT_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_PASSWORD=<random>
CREDENTIAL_ENCRYPTION_SALT=<random>
ANTHROPIC_API_KEY=sk-ant-...
FRONTEND_PORT=3000
BACKEND_PORT=8080
GATEWAY_PUBLIC_URL=https://lc-api.example.com

Wygeneruj każdą losową wartość za pomocą openssl rand -base64 32. Uwagi dotyczące kluczowych parametrów:

• POSTGRES_PASSWORD oraz MINIO_ROOT_PASSWORD są dostarczane jako postgres i minioadmin. Żaden z portów bazy danych nie jest publikowany na hoście, więc nie są one wystawione bezpośrednio, jednak każdy kontener podłączony później do tej samej sieci może uzyskać do nich dostęp przy użyciu udokumentowanych wartości domyślnych.
• CREDENTIAL_ENCRYPTION_PASSWORD oraz CREDENTIAL_ENCRYPTION_SALT są generowane automatycznie, jeśli pozostaną puste. Należy ustawić je samodzielnie. Poświadczenia przechowywane przez workflowy są szyfrowane za pomocą tej pary, więc zrzut bazy danych przywrócony na nowej maszynie bez tego samego hasła i soli spowoduje, że wiersze z poświadczeniami staną się niemożliwe do odczytania. Ustaw je raz, a następnie traktuj docker/.env.ce jako część kopii zapasowej.
• FRONTEND_PORT oraz BACKEND_PORT są podstawiane w mapowaniach portów jako ${FRONTEND_PORT:-3000}:3000 i ${BACKEND_PORT:-8080}:8080. Przykładowy plik env ustawia oba jawnie, a dostarczone w nim wartości nie zawsze wynoszą 3000 i 8080. Przeczytaj własną kopię pliku, zamiast zakładać wartości domyślne.
• GATEWAY_PUBLIC_URL to adres origin backendu widoczny dla przeglądarki. Ma on znaczenie, gdy używany jest reverse proxy. Zobacz następną sekcję.
• Klucze modeli (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY oraz opcjonalnie MISTRAL_API_KEY lub DEEPSEEK_API_KEY) znajdują się tutaj w postaci jawnego tekstu. Wypełnij tylko dane dostawcy, z którego faktycznie korzystasz.

Zadania sześciu kontenerów

• postgres uruchamia pgvector/pgvector:pg16 jako kontener livecontext-db, przechowujący bazę danych o nazwie livecontext. Rozszerzenie pgvector jest wymagane do wyszukiwania wektorowego, dlatego standardowy obraz postgres:16 nie będzie odpowiedni.
• redis uruchamia redis:7-alpine z parametrami appendonly yes oraz --maxmemory-policy noeviction. Taka polityka jest celowa: Redis pełni tu rolę kolejki i przechowuje stan uruchomienia, więc po osiągnięciu limitu pamięci zwraca błąd do zapisującego zamiast cicho usuwać klucze. Błąd, który można zaobserwować, jest lepszy niż praca, która znika bez śladu.
• minio to kompatybilny z S3 magazyn obiektowy na pliki przetwarzane w ramach workflowów. Jednorazowy kontener minio-init uruchamia mc mb myminio/workflow-files --ignore-existing podczas startu, tworzy bucket i kończy działanie. Stan, w którym minio-init widnieje jako exited (0) w docker compose ps, oznacza poprawne działanie.
• bridge zawiera adaptery CLI oraz narzędzia MCP (model context protocol). Nasłuchuje na porcie 8093 wewnątrz sieci Docker i nie jest publikowany na hoście.
• livecontext to backend, monolityczna aplikacja Java 21 działająca na porcie 8080. Obsługuje silnik workflowów, harmonogramy oraz agentów.
• frontend to interfejs webowy Next.js działający na porcie 3000. Tylko te dwa ostatnie komponenty są publikowane na hoście.

Stan aplikacji przechowywany jest w pięciu nazwanych wolumenach: livecontext_data dla Postgres, livecontext_redis, livecontext_minio, livecontext_keys oraz livecontext_logs. Compose dodaje do nich prefiks z nazwą projektu, która domyślnie odpowiada nazwie katalogu, więc rzeczywista nazwa wolumenu na dysku wygląda jak livecontext-ce_livecontext_minio. Uruchom docker volume ls i skopiuj dokładne nazwy przed przygotowaniem jakiegokolwiek skryptu kopii zapasowej.

docker compose down -v usuwa wszystkie pięć wolumenów. Jest to udokumentowany sposób na rozpoczęcie pracy od zera, ale jednocześnie najszybsza metoda na utratę wszystkich stworzonych workflowów. Flaga -v stanowi tu kluczową różnicę.

Umieszczenie usługi za Traefik zamiast publikowania portu 3000

Publikowanie portów 3000 oraz 8080 na publicznym VPS wystawia aplikację bez TLS (transport layer security) oraz bez bramy zabezpieczającej rejestrację administratora. Reguła ufw sama w sobie nie wystarcza, ponieważ Docker wstawia własne reguły iptables dla opublikowanych portów przed łańcuch zarządzany przez ufw. W rezultacie port opublikowany na 0.0.0.0 pozostaje dostępny, nawet jeśli ufw zgłasza odmowę dostępu.

Poprawnym rozwiązaniem jest niepublikowanie żadnych portów i umożliwienie proxy komunikacji z kontenerami poprzez współdzieloną sieć Docker. Utwórz docker-compose.override.yml w katalogu głównym repozytorium:

services:
  frontend:
    ports: !override []
    networks:
      - default
      - proxy
  livecontext:
    ports: !override []
    networks:
      - default
      - proxy

networks:
  proxy:
    external: true

O powodzeniu decydują dwa szczegóły. !override zastępuje listę portów zamiast ją scalać, co wymaga Compose w wersji 2.24 lub nowszej: sprawdź wersję za pomocą docker compose version, ponieważ w starszych wersjach Compose listy są scalane i porty pozostają opublikowane. Ponadto default musi pozostać na każdej liście networks, ponieważ zdefiniowanie dowolnej sieci zastępuje sieć domyślną, więc pominięcie tego wpisu odetnie frontend od Postgres oraz Redis. Przed uruchomieniem czegokolwiek zweryfikuj scaloną konfigurację:

docker compose --env-file docker/.env.ce config

Routery, resolver certyfikatów oraz przekierowanie z HTTP na HTTPS są identyczne jak w przypadku każdej innej aplikacji, dlatego należy postępować zgodnie z naszym przewodnikiem po reverse proxy Traefik dla wielu aplikacji na jednym VPS zamiast tworzyć nową konfigurację TLS. Skieruj jedną nazwę hosta na frontend na porcie 3000, a drugą na livecontext na porcie 8080.

Druga nazwa hosta nie jest opcjonalna. Interfejs webowy wywołuje backend z poziomu przeglądarki, więc backend musi posiadać własne źródło (origin), do którego przeglądarka ma dostęp. Ustaw GATEWAY_PUBLIC_URL w docker/.env.ce na ten adres URL backendu, na przykład https://lc-api.example.com. Pominięcie tego kroku spowoduje, że strona załaduje się poprawnie, ale każda akcja zakończy się błędem, ponieważ UI rozpozna źródło backendu na podstawie adresu, pod którym otwarto stronę, i będzie próbować wywołać port, którego proxy nie udostępniło.

Ponieważ strona rejestracji jest dostępna dla każdego, kto uzyska do niej dostęp, warto dodać uwierzytelnianie na routerze frontendu, aby nikt nie widział tej strony bez przejścia przez proxy. Można to osiągnąć, stosując uruchomienie Authentik jako własnej warstwy SSO w ramach tej samej konfiguracji Traefik.

Gdzie umieścić klucz modelu i dlaczego bezczynna instancja generuje koszty

Agenci działają wewnątrz automatyzacji, co zmienia model ekonomiczny w porównaniu ze zwykłymi narzędziami do obsługi przepływów pracy. Klucz dostawcy znajduje się w docker/.env.ce jako ANTHROPIC_API_KEY lub OPENAI_API_KEY, jest odczytywany przez backend oraz mostek podczas uruchamiania i dotyczy całej instancji. Nie jest on ograniczony do poszczególnych użytkowników. Każda osoba posiadająca konto w instancji i mogąca tworzyć agentów korzysta z tego klucza, a pierwsza zarejestrowana osoba staje się administratorem.

Trzy nawyki pozwalają utrzymać przewidywalne koszty. Należy utworzyć osobny klucz dostawcy dla tego VPS, aby móc go unieważnić bez wpływu na inne elementy. W konsoli dostawcy trzeba ustawić twardy limit wydatków, ponieważ jest to jedyne ograniczenie zewnętrzne względem zabezpieczanej maszyny. Następnie należy korzystać z budżetów kredytowych i metryk dla poszczególnych agentów, które udostępnia LiveContext, aby pojedyncza pętla nie wyczerpała klucza, zanim zostanie to zauważone.

Koszt bezczynności nie jest zerowy, gdy agent działa zgodnie z harmonogramem. Wyzwalacz harmonogramu uruchamia się niezależnie od tego, czy ktoś monitoruje jego działanie, a każde uruchomienie wiąże się z zużyciem tokenów. Harmonogram pięciominutowy oznacza 288 uruchomień dziennie, a agent, który odczytuje stronę i decyduje się nie podejmować żadnych działań, nadal płaci za odczyt tej strony. Pierwszych agentów warto uruchamiać za pomocą webhooka lub wyzwalacza czatu, monitorować rzeczywiste wydatki przez tydzień i przejść na harmonogram dopiero po poznaniu kosztu pojedynczego uruchomienia.

Tworzenie kopii zapasowej Postgres i magazynu obiektów

Istnieją dwa magazyny danych oraz jeden sekret; utrata któregokolwiek z nich powoduje utratę instancji. Wykonaj kopię bazy danych oraz zasobnika (bucket) w tym samym oknie czasowym, przy zatrzymanym backendzie, aby uniknąć zapisu pliku po wykonaniu zrzutu wiersza bazy danych.

cd ~/livecontext-ce
mkdir -p ~/backups
docker compose --env-file docker/.env.ce stop livecontext frontend
docker compose --env-file docker/.env.ce exec -T postgres \
  pg_dump -U postgres -d livecontext --clean --if-exists \
  | gzip > ~/backups/livecontext-db-$(date +%F).sql.gz

Użyj wartości ustawionej jako DB_USERNAME w miejsce postgres, jeśli została ona zmieniona. Następnie skopiuj wolumen magazynu obiektów, używając nazwy z prefiksem, którą wyświetliło docker volume ls:

docker run --rm \
  -v livecontext-ce_livecontext_minio:/data \
  -v ~/backups:/backup \
  alpine tar czf /backup/livecontext-minio-$(date +%F).tgz -C /data .
docker compose --env-file docker/.env.ce start livecontext frontend
cp docker/.env.ce ~/backups/env.ce.$(date +%F)

Przed uznaniem zrzutu za wiarygodny sprawdź, czy nie jest on pusty: gunzip -c ~/backups/livecontext-db-*.sql.gz | head -20 powinno wyświetlić instrukcje CREATE TABLE oraz DROP TABLE, a nie jednowierszowy komunikat o błędzie. Następnie skopiuj wszystkie trzy pliki poza serwer. Kopia zapasowa, która znajduje się wyłącznie na zabezpieczanej maszynie, nie jest kopią zapasową.

Aby przywrócić dane na nowym serwerze, zainstaluj tę samą wersję (tag), przywróć zapisany plik docker/.env.ce, aby hasło szyfrowania poświadczeń oraz sól były zgodne, uruchom stos raz, aby wolumeny zostały utworzone, zatrzymaj backend, a następnie wczytaj zrzut:

gunzip -c livecontext-db-2026-08-10.sql.gz \
  | docker compose --env-file docker/.env.ce exec -T postgres psql -U postgres -d livecontext

Aktualizacje i przywracanie stanu po awarii

Zawsze należy najpierw wykonać zrzut bazy danych. Backend stosuje migracje schematu przy starcie, a migracje działają tylko w jednym kierunku. Powrót do starszej wersji tagu po nieudanej aktualizacji spowoduje uruchomienie starego kodu na nowszym schemacie. Wycofanie zmian wymaga przywrócenia zrzutu, dlatego zrzut jest pierwszym krokiem.

cd ~/livecontext-ce
git fetch --tags
git tag --list 'v*' | tail -5
TAG=v0.2.11
git checkout "$TAG"
docker compose --env-file docker/.env.ce pull
docker compose --env-file docker/.env.ce up -d
docker compose --env-file docker/.env.ce logs -f livecontext

Ustaw TAG na tag wybrany z listy wyświetlonej przez trzecie polecenie. Monitoruj log backendu, aż endpoint sprawdzający stan (health endpoint) ponownie zacznie odpowiadać. Twój plik docker-compose.override.yml nie jest śledzony, więc polecenie git checkout pozostawi go na miejscu. Należy jednak sprawdzić różnice w docker-compose.yml między tagami, ponieważ dodanie nowej usługi lub zmiana nazwy istniejącej może sprawić, że nadpisanie konfiguracji stanie się nieaktualne bez wyświetlenia komunikatu o błędzie.

Tryby awarii i odpowiadające im komunikaty

Kontener ciągle się restartuje, a docker compose ps wskazuje exited (137). Jest to mechanizm kernel out-of-memory killer, co potwierdza docker inspect livecontext-app poprzez wartość "OOMKilled": true w bloku stanu. Backend osiągnął limit 1536M lub hostowi wyczerpała się pamięć operacyjna. Przed zwiększeniem jakiegokolwiek limitu należy sprawdzić free -m, ponieważ podniesienie limitu dla kontenera na hoście bez wolnych zasobów jedynie przeniesie problem na inny kontener.

Pobieranie obrazu kończy się błędem no matching manifest for linux/arm64/v8 in the manifest list entries. Obrazy są publikowane wyłącznie dla architektury linux/amd64. VPS z procesorem Arm nie uruchomi tego stosu z opublikowanych obrazów, a emulacja przez QEMU jest zbyt wolna dla środowiska JVM oraz Chromium. Należy zmienić plan na x86.

Bind for 0.0.0.0:3000 failed: port is already allocated. Inny proces na hoście zajmuje już ten port. Należy zmienić FRONTEND_PORT w pliku docker/.env.ce lub zastosować powyższe nadpisanie i nie publikować portu w ogóle.

Interfejs działa, ale żądanie logowania kończy się błędem po dodaniu proxy. Przeglądarka wywołuje backend w domenie, której proxy nie obsługuje. Należy otworzyć kartę sieciową w narzędziach deweloperskich przeglądarki i sprawdzić hosta nieudanego żądania. Należy ustawić GATEWAY_PUBLIC_URL na publiczny adres URL backendu i zrestartować kontener frontendowy, ponieważ wartość ta jest odczytywana podczas uruchamiania.

Wszystkie usługi działają poprawnie, ale pliki przesłane w ramach workflow znikają. Należy sprawdzić, czy minio-init zwraca exited (0), a nie kod różny od zera. Jeśli bucket workflow-files nie został utworzony, backend nie ma miejsca na zapisanie obiektów.

Wybór między LiveContext a n8n

Wybierz LiveContext, jeśli priorytetem jest agent: oczekujesz, że model samodzielnie zbuduje i uruchomi automatyzację, a akceptujesz wymóg 8 GB pamięci RAM oraz działanie usługi w środowisku Java. Wybierz n8n, jeśli potrzebujesz deterministycznych przepływów pracy, obszernej biblioteki węzłów oraz niewielkiego zużycia zasobów, które pozwala współdzielić VPS z innymi usługami. Wersje oprogramowania są wczesne, v0.2.11 według stanu na sierpień 2026, dlatego należy przypinać tagi wersji i czytać informacje o wydaniu przed każdą aktualizacją. Aby zapoznać się z szerszym spektrum rozwiązań, w tym narzędziami plasującymi się pomiędzy tymi dwiema opcjami, sprawdź nasze zestawienie alternatyw dla n8n z własnym hostingiem, zamiast ograniczać się do porównania tylko tych dwóch produktów.

FAQ

Ile pamięci RAM wymaga samodzielnie hostowany LiveContext?

Należy zaplanować 8 GB. Dokumentacja upstream podaje 4 GB jako wartość minimalną i 8 GB jako zalecaną, co znajduje odzwierciedlenie w dostarczonym pliku compose: sam backend ma limit ustawiony na 1536 MB, a pięć podstawowych usług zajmuje łącznie nieco poniżej 3 GB przed uruchomieniem nielimitowanego kontenera frontendowego. Włączenie profilu agenta przeglądarki dodaje kolejne 2048 MB dla Chromium oraz kontenera SearXNG, więc przy tej konfiguracji 8 GB przestaje być opcjonalne.

Czy mogę uruchomić LiveContext na VPS z architekturą Arm?

Nie. Każdy opublikowany obraz jest budowany dla linux/amd64, więc docker compose up na planie Arm kończy się niepowodzeniem podczas pobierania z błędem no matching manifest for linux/arm64/v8 in the manifest list entries. Uruchomienie go w emulacji QEMU jest teoretycznie możliwe, lecz w praktyce nieużywalne dla obciążeń JVM. Należy wybrać plan x86.

Gdzie umieścić klucz API modelu?

W pliku docker/.env.ce, jako ANTHROPIC_API_KEY, OPENAI_API_KEY lub GOOGLE_API_KEY, przed pierwszym uruchomieniem. Backend i bridge odczytują go podczas startu, a ustawienie dotyczy całej instancji, a nie pojedynczego użytkownika. Plik powinien mieć uprawnienia 600. Należy użyć klucza utworzonego wyłącznie dla tego serwera, aby móc go samodzielnie unieważnić, oraz ustawić limit wydatków w konsoli dostawcy, ponieważ jest to jedyny limit działający poza maszyną.

Jak wykonać kopię zapasową LiveContext?

Należy zabezpieczyć trzy elementy: pg_dump bazy danych livecontext, kopię wolumenu MinIO oraz plik docker/.env.ce. Przed wykonaniem kopii pierwszych dwóch elementów należy zatrzymać usługi livecontext oraz frontend, aby zapewnić spójność bazy danych i magazynu obiektów. Plik env jest kluczowy, ponieważ poświadczenia przechowywane w workflow są szyfrowane za pomocą CREDENTIAL_ENCRYPTION_PASSWORD i CREDENTIAL_ENCRYPTION_SALT; przywrócenie danych bez tych wartości spowoduje, że wiersze z poświadczeniami staną się nieczytelne na nowej maszynie.

Dlaczego backend pozostaje w stanie health: starting przez kilka minut po uruchomieniu?

Healthcheck w compose ustawia start_period: 120s i odpytuje /actuator/health, więc Docker zgłasza usługę jako uruchamiającą się w czasie, gdy wykonywane są migracje schematu i rejestracja narzędzi. Przy pierwszym uruchomieniu czas od dwóch do trzech minut jest oczekiwany. Jeśli usługa nie przejdzie w stan gotowości, należy sprawdzić docker compose logs -f livecontext. Stos, który zatrzymuje się na etapie migracji, zazwyczaj wskazuje na wolumen bazy danych pochodzący z nowszej wersji.