Jak samodzielnie hostować Superlog na własnym serwerze

Co faktycznie instaluje samodzielnie hostowany Superlog

Aby samodzielnie hostować Superlog, należy sklonować repozytorium, uruchomić Postgres, ClickHouse oraz kolektor OpenTelemetry za pomocą Docker Compose, wykonać jedną migrację bazy danych, a następnie uruchomić cztery usługi Node z kodu źródłowego. Aplikacje wysyłają ślady (traces), logi i metryki w protokole OTLP (OpenTelemetry protocol) na port wejściowy, Superlog tworzy ich odciski palców (fingerprints), grupuje powtarzające się zdarzenia w jeden incydent, a agent przygotowuje wstępną triażę. Instalacja zajmuje jedno popołudnie. Przed rozpoczęciem warto zapoznać się z wymaganiami sprzętowymi oraz rzeczywistymi ograniczeniami systemu.

Superlog jest udostępniany na licencji Apache 2.0 i znajduje się pod adresem github.com/superloglabs/superlog. Według stanu na sierpień 2026 r. projekt posiada około 1,2 tys. gwiazdek, mniej więcej 460 commitów w main i brak jakichkolwiek tagów wersji. Ten ostatni punkt wpływa na proces instalacji: git checkout v1.0.0 nie oferuje niczego do pobrania, więc należy samodzielnie przypiąć konkretny commit lub uruchomić to, co akurat znajdowało się w main w momencie klonowania repozytorium.

Na jakie pytania odpowiada Superlog, na które nie odpowiadają Uptime Kuma i Langfuse

Narzędzia do monitoringu typu self-hosted z zewnątrz wydają się zamienne. W rzeczywistości takie nie są, a uruchomienie niewłaściwego rozwiązania prowadzi do niepotrzebnego obciążenia serwera.

• Uptime Kuma sonduje punkty końcowe z zewnątrz i odpowiada na jedno pytanie: czy usługa działa.
• Zabbix monitoruje hosty i usługi na Ubuntu 24.04, sprawdzając użycie CPU, pamięci, dysku oraz stan usług względem zdefiniowanych progów.
• Langfuse śledzi wywołania LLM, rejestrując prompt, model, tokeny, opóźnienia oraz koszt każdego zapytania.
• Superlog pobiera telemetrię, którą standardowe usługi już emitują, i przekształca powtarzające się awarie w incydenty.

Superlog odpowiada na inne pytanie: co uległo awarii i dlaczego. Narzędzie nie analizuje wywołań LLM i nie sonduje usług z zewnątrz. Pobiera dane OTLP z kodu aplikacji i umieszcza agenta na etapie segregacji zgłoszeń, czyli wykonuje pierwszą czynność, którą i tak musiałby wykonać administrator pełniący dyżur.

Kluczową różnicą z punktu widzenia budżetu VPS jest sposób przechowywania danych. Uptime Kuma działa stabilnie na 1 GB RAM, ponieważ przechowuje jedynie kilka tysięcy wyników testów. Superlog wykorzystuje bazę kolumnową, ponieważ telemetria jest zapisywana jednokrotnie, a następnie odpytywana w określonych przedziałach czasowych dla milionów wierszy. Do tego służy ClickHouse, a nie Postgres. Postgres pozostaje w stosie technologicznym jako baza dla niewielkich danych relacyjnych: projektów, użytkowników, incydentów oraz kluczy dostępowych.

Co faktycznie uruchamia polecenie docker compose up -d?

Trzy kontenery, z których żaden nie jest Superlog. Jest to zaskakujące dla osób oczekujących instalacji za pomocą jednego polecenia.

• postgres:16, opublikowany na porcie hosta 5434
• clickhouse/clickhouse-server:26.1, na porcie 8123 dla HTTP oraz 9000 dla protokołu natywnego
• otel/opentelemetry-collector-contrib:0.150.1, na porcie 4317 dla gRPC oraz 4318 dla OTLP przez HTTP

Aplikacje Superlog działają na hoście, uruchamiane ze źródeł za pomocą pnpm dev. Na stan z sierpnia 2026 roku w repozytorium nie ma produkcyjnego pliku compose, więc instalacja długoterminowa wymaga utworzenia własnych jednostek systemd dla skryptu start każdej aplikacji lub użycia plików Dockerfile dostarczonych w drzewie katalogów.

Należy zapamiętać ścieżkę, jaką pokonuje sygnał, ponieważ każda awaria opisana poniżej wynika z przerwania jednego z jej etapów. Aplikacja wysyła OTLP do proxy wejściowego Superlog. Proxy uwierzytelnia żądanie za pomocą klucza ingest key, nadaje mu identyfikator projektu i przekazuje do kolektora. Kolektor usuwa wszelkie atrybuty superlog.*, które klient próbował ustawić, dodaje superlog.project_id z nagłówka dostarczonego przez proxy, grupuje dane i zapisuje je w ClickHouse. Następnie aplikacja webowa oraz API odczytują dane telemetryczne z ClickHouse, a pozostałe informacje z Postgres.

Usuwanie atrybutów jest realnym mechanizmem kontroli multi-tenancy, a nie tylko dekoracją. Bez tego zabezpieczenia każdy posiadacz ważnego klucza ingest key mógłby samodzielnie ustawić superlog.project_id i zapisywać dane wewnątrz innego projektu.

Jakie wymagania sprzętowe musi spełniać VPS?

Należy zaplanować 4 vCPU, 8 GB pamięci RAM oraz 40 GB przestrzeni SSD dla instalacji jednowęzłowej przy niskim wolumenie danych wejściowych. Jest to wartość minimalna, a nie wynik pomiarów, dlatego należy traktować ją jako punkt wyjścia i zweryfikować pod kątem rzeczywistego ruchu.

Pamięć RAM jest wykorzystywana w czterech obszarach. ClickHouse jest zaprojektowany z myślą o maszynach z dużą ilością pamięci RAM i takie też przyjmuje wartości domyślne. Postgres 16 ma skromniejsze wymagania, ponieważ przechowuje metadane, a nie telemetrię. Kolektor również nie jest zasobożerny. Cztery procesy Node stanowią wyjątek: serwer deweloperski Vite oraz trzy procesy tsx watch zajmują łącznie setki megabajtów, dlatego uruchomienie pnpm dev na maszynie z 2 GB RAM jest nieefektywne.

Przestrzeń dyskowa jest problemem mniej oczywistym. pnpm install w tym monorepo pobiera AWS SDK, klienta ClickHouse, OpenTelemetry SDK oraz łańcuch narzędzi React, zanim jeszcze zostanie przetworzony pierwszy span. Następnie ClickHouse rozrasta się wraz ze wzrostem ruchu. Należy monitorować oba parametry:

df -h /
free -m
docker stats --no-stream
docker compose exec clickhouse clickhouse-client --database superlog --query "SELECT table, formatReadableSize(sum(bytes_on_disk)) AS size FROM system.parts WHERE active AND database = 'superlog' GROUP BY table ORDER BY sum(bytes_on_disk) DESC"

Przy niskim obciążeniu, gdy kilka usług wysyła kilkaset spanów na minutę, serwer pozostaje w stanie spoczynku, a ClickHouse przez większość czasu jest bezczynny. Obciążenie, które powoduje problemy, to nagłe skoki ruchu: nieudane wdrożenie generujące tysiące identycznych błędów na minutę. Mechanizm fingerprintingu grupuje je w jeden incydent dla użytkownika, jednak ClickHouse nadal zapisuje każdy wiersz w bazie danych.

Polityka retencji zależy od administratora. Eksporter ClickHouse w kolektorze tworzy tabele otel_traces, otel_logs oraz po jednej tabeli dla każdego typu metryki. Czas przechowywania (TTL) jest stosowany tylko wtedy, gdy konfiguracja w infra/collector/config.yaml go określa. Dane nie są usuwane automatycznie, więc przy dużym natężeniu ruchu miesiąc pracy może zapełnić dysk, jeśli nie zostanie to odpowiednio zaplanowane.

Instalacja z przypiętego commita

git clone https://github.com/superloglabs/superlog.git
cd superlog
git tag -l
git log -1 --format='%H %cs %s'

git tag -l brak danych wyjściowych jest oczekiwanym rezultatem na sierpień 2026. Należy wybrać przetestowany commit i pozostać przy nim:

git checkout 0d3a6c8bb63eda3493e6ba0003e7c2a70750bc1e

Następnie łańcuch narzędzi:

node -v
corepack enable
corepack prepare pnpm@9.12.0 --activate
pnpm -v

package.json deklaruje engines.node jako >=20.0.0 oraz packageManager jako pnpm@9.12.0. Uruchomienie instalacji na starszej wersji Node powoduje zatrzymanie pnpm z błędem ERR_PNPM_UNSUPPORTED_ENGINE, wskazującym na wymaganą wersję. Pakiet nodejs w archiwum Ubuntu 24.04 jest starszy niż 20, dlatego należy zainstalować Node 20 lub nowszy z NodeSource albo za pomocą nvm. Repozytorium dostarcza .nvmrc, więc nvm use automatycznie wybierze właściwą wersję, jeśli używasz nvm.

pnpm install
docker compose up -d
docker compose ps

Należy poczekać na zakończenie testów stanu (health checks), zamiast zakładać, że up -d oznacza gotowość. Zarówno Postgres, jak i ClickHouse mają zdefiniowane testy w pliku compose:

curl -sS http://127.0.0.1:8123/ping
pg_isready -h 127.0.0.1 -p 5434 -U postgres

ClickHouse odpowiada Ok., a pg_isready odpowiada accepting connections. Błąd connection refused na porcie 8123 oznacza, że kontener nadal się uruchamia lub uległ awarii. docker compose logs clickhouse pozwala sprawdzić stan, a docker inspect $(docker compose ps -q clickhouse) | grep -i oomkilled zgłasza true, gdy jądro systemu przerwało proces z powodu braku pamięci. Wskazuje to na zbyt małe zasoby serwera, a nie na błąd w konfiguracji.

Następnie migracja i aplikacje:

pnpm --filter @superlog/db db:migrate
pnpm dev

Należy zwrócić uwagę na port: 5434, a nie 5432. Plik compose publikuje Postgres na porcie 5434, aby uniknąć konfliktu z instancją Postgres zainstalowaną bezpośrednio na hoście. Pliki konfiguracyjne aplikacji .env.example są zgodne z tym ustawieniem dzięki DATABASE_URL=postgres://postgres:postgres@localhost:5434/superlog. Skierowanie migracji na port 5432 na serwerze, na którym już działa Postgres, spowoduje odmowę połączenia lub, co gorsza, wykonanie migracji na niewłaściwej bazie danych.

pnpm dev uruchamia cztery procesy wymienione w pliku Procfile repozytorium: api, web, worker oraz proxy. Każdy z nich przekierowuje wyjście do tmp/logs/, więc tail -f tmp/logs/proxy.log jest miejscem, w którym należy monitorować procesy. Plik README umieszcza aplikację web na http://localhost:5173, API na http://localhost:4100, a punkt odbioru OTLP na http://localhost:4101.

Przed skierowaniem ruchu należy potwierdzić, na których portach nasłuchują usługi:

ss -lntp | grep -E '4100|4101|5173'
curl -sS http://127.0.0.1:4101/health

Jest to istotne w dalszej części konfiguracji. Proxy odczytuje własny port ze zmiennej środowiskowej PORT i używa wartości domyślnej 4000, gdy PORT nie jest ustawiona. Środowisko programistyczne ustawia tę zmienną automatycznie. Własna jednostka systemd tego nie robi, więc eksporter skierowany na port 4101, podczas gdy proxy nasłuchuje na 4000, zakończy się błędem connection refused bez dodatkowych informacji diagnostycznych.

Wysłanie śladu, wygenerowanie błędu, zaobserwowanie incydentu

Utwórz projekt w aplikacji internetowej i skopiuj jego klucz ingest. Moduł intake uwierzytelnia każde żądanie za pomocą tego klucza, więc telemetria wysłana bez niego nigdy nie dotrze do ClickHouse.

Skieruj dowolny OpenTelemetry SDK na moduł intake, używając standardowych zmiennych środowiskowych:

export OTEL_SERVICE_NAME=checkout-api
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4101
export OTEL_EXPORTER_OTLP_HEADERS='x-api-key=YOUR_INGEST_KEY'

Moduł intake odczytuje klucz z nagłówka x-api-key, akceptuje również authorization: bearer YOUR_INGEST_KEY, jeśli konfiguracja eksportera jest w ten sposób łatwiejsza. Obsługuje trzy standardowe ścieżki OTLP: /v1/traces, /v1/logs oraz /v1/metrics, a także /health.

Warto zwrócić uwagę na jedną pułapkę. OTEL_EXPORTER_OTLP_ENDPOINT to bazowy adres URL, do którego SDK automatycznie dołącza ścieżkę sygnału. Zmienne specyficzne dla sygnału, takie jak OTEL_EXPORTER_OTLP_TRACES_ENDPOINT, są używane dokładnie w podanej formie, bez dołączania ścieżki. Ustawienie zmiennej specyficznej dla sygnału na http://127.0.0.1:4101 spowoduje wysyłanie danych do /, co nie jest poprawną trasą. W rezultacie dane nie dotrą do celu, a SDK zarejestruje błąd eksportu, podczas gdy aplikacja będzie wydawać się poprawnie działającą.

W przypadku usługi Node wystarczy podejście zero-code, aby zweryfikować potok:

npm install @opentelemetry/api @opentelemetry/auto-instrumentations-node
node --require @opentelemetry/auto-instrumentations-node/register server.js

Teraz wywołaj celowy błąd. Wystarczy dowolna trasa, która zgłasza wyjątek:

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/boom

Sprawdź kolejne etapy, ponieważ pierwsza luka wskaże miejsce awarii:

tail -n 50 tmp/logs/proxy.log
docker compose exec clickhouse clickhouse-client --database superlog --query 'SELECT count() FROM otel_traces'

Wzrost liczby w otel_traces przy pustej aplikacji internetowej oznacza niedopasowanie projektu, więc sprawdź, do którego projektu przypisany jest klucz ingest. Stała liczba przy jednoczesnej aktywności w logach proxy wskazuje na problem z kolektorem lub zapisem do ClickHouse, więc przejrzyj docker compose logs collector. Brak aktywności w logach proxy oznacza, że eksporter nie dotarł do modułu intake: przyczyną może być błędny port, błędna ścieżka lub odrzucony klucz.

W aplikacji internetowej powtarzające się awarie są rejestrowane jako jeden incydent, a nie jako osobny wiersz dla każdego żądania. Superlog tworzy odciski palców przychodzących sygnałów i grupuje pasujące do siebie, co pozwala uniknąć sytuacji, w której skrzynka odbiorcza zawiera 4000 identycznych błędów zamiast jednego wpisu. Następnie agent dołącza wyniki analizy do tej grupy.

Krok analizy wywołuje model, więc worker wymaga skonfigurowanego dostawcy modelu. Nazwy zmiennych należy pobrać z pliku .env.example znajdującego się w każdym katalogu aplikacji w przypiętym commicie, zamiast polegać na zewnętrznych dokumentacjach, ponieważ nazwy te zmieniają się wraz z main. To samo dotyczy integracji z GitHub i Sentry, które posiadają własne dokumenty konfiguracyjne pod adresami docs/github-app-setup.md oraz docs/sentry-app-setup.md, a formaty ładunków webhook opisano w docs/webhooks.md.

Zapewnienie prywatności danych wejściowych i ograniczenie uprawnień agenta

Domyślnie Docker publikuje porty kontenerów na adresie 0.0.0.0. Tak opublikowane porty omijają ufw, ponieważ Docker zapisuje własne reguły w łańcuchu DOCKER-USER, które są przetwarzane, zanim ufw otrzyma pakiet. Na serwerze VPS z publicznym adresem IP, dostarczony plik compose wystawia interfejs HTTP ClickHouse na porcie 8123 oraz Postgres na 5434, co czyni je dostępnymi z Internetu. Poświadczenia w tym pliku to domyślne ustawienia programistyczne: użytkownik ClickHouse default z pustym hasłem oraz Postgres z postgres jako użytkownikiem i hasłem.

Powiąż te porty z interfejsem loopback. Każdy opublikowany port w pliku compose pobiera wartość hosta ze zmiennej środowiskowej, więc wystarczy plik .env w głównym katalogu repozytorium:

POSTGRES_HOST_PORT=127.0.0.1:5434
CLICKHOUSE_HTTP_HOST_PORT=127.0.0.1:8123
CLICKHOUSE_TCP_HOST_PORT=127.0.0.1:9000
COLLECTOR_GRPC_HOST_PORT=127.0.0.1:4317
COLLECTOR_HTTP_HOST_PORT=127.0.0.1:4318

Zweryfikuj wynik przed jego użyciem, a następnie zrestartuj kontenery:

docker compose config
docker compose up -d
ss -lntp | grep -E '5434|8123|9000|4317|4318'

docker compose config wyświetla przetworzony plik, dzięki czemu można odczytać 127.0.0.1:5434:5432 zamiast zgadywać. ss powinno wtedy wskazywać 127.0.0.1:5434, a nigdy 0.0.0.0:5434. Nie próbuj naprawiać tego za pomocą pliku override compose, który ponownie deklaruje ports, ponieważ Compose łączy listy portów z różnych plików zamiast je zastępować. W rezultacie oba powiązania pozostaną aktywne, w tym to publiczne.

Dane wejściowe wymagają takiej samej ochrony. Klucz ingest przesyłany jest w nagłówku, dlatego wymaga zabezpieczenia TLS (transport layer security): zakończ TLS w nginx lub Caddy przed proxy albo utrzymuj ingest wewnątrz sieci prywatnej lub tunelu WireGuard. Aplikacja webowa na porcie 5173 to serwer deweloperski Vite i nie powinna być w ogóle wystawiona na Internet.

Następnie sam agent. Założeniem Superlog jest to, że agent analizuje problem i proponuje poprawkę, a kluczowym słowem jest tutaj proponuje. Utrzymuj dostęp tylko do odczytu w środowisku produkcyjnym, dopóki nie zaobserwujesz jego działania podczas kilku rzeczywistych incydentów. Nadaj aplikacji GitHub App uprawnienia do odczytu i pozwól jej otwierać pull requesty, które samodzielnie zweryfikujesz. Agent, który odczytuje telemetrię i przygotowuje poprawkę, jest użyteczny. Agent, który może restartować usługi, wiąże się z innym poziomem ryzyka – powinna to być świadoma decyzja, a nie domyślne ustawienie. Kwestia kosztów wymaga takiej samej uwagi, ponieważ każda analiza to wywołanie modelu: zaplanuj budżet na działanie agenta na VPS przed skierowaniem go na system produkcyjny generujący duży ruch oraz prowadź rejestr działań wykonanych przez agenta, aby każdy nieoczekiwany pull request posiadał ścieżkę audytu.

Błędy, które wystąpią, oraz ciągi znaków je identyfikujące

• ERR_PNPM_UNSUPPORTED_ENGINE podczas pnpm install oznacza, że wersja Node jest starsza niż 20. node -v potwierdza to w jednej linii.
• ECONNREFUSED 127.0.0.1:5434 podczas migracji oznacza, że stos compose nie jest uruchomiony lub DATABASE_URL wskazuje błędny port.
• Zapętlenie restartów ClickHouse zazwyczaj wynika z braku pamięci. Należy przeczytać docker compose logs clickhouse, a następnie sprawdzić w kontenerze, czy OOMKilled ma wartość true.
• Eksporter zgłaszający sukces, podczas gdy aplikacja webowa pozostaje pusta, zazwyczaj oznacza, że dane trafiły bezpośrednio do kolektora na port 4318, co pomija proces oznaczania projektu wykonywany przez proxy.
• Błąd Connection refused na porcie 4101 w instalacji produkcyjnej oznacza, że proxy powróciło do PORT=4000. Należy jawnie ustawić PORT w pliku jednostki.
• docker compose ps wyświetlające 0.0.0.0:8123 oznacza, że powiązania z interfejsem loopback nie działają. Należy uruchomić docker compose config i odczytać rozpoznane porty.

Flawless, HyperProbe oraz miejsce Superlog

Ta kategoria jest nowa, a narzędzia różnią się zakresem uprawnień agenta. Flawless to narzędzie typu open source AI SRE (site reliability engineering) przeznaczone dla Kubernetes, które odczytuje dane z istniejącego stosu Prometheus, Loki i Grafana, zamiast przejmować kontrolę nad potokiem danych. HyperProbe działa w odwrotny sposób: jest to produkt hostowany, o zamkniętym kodzie źródłowym według stanu na sierpień 2026, który umieszcza sondy typu read-only wewnątrz uruchomionego procesu w celu przechwycenia stanu zmiennych i udostępnia ten stan asystentowi za pośrednictwem MCP (model context protocol).

Superlog znajduje się pomiędzy tymi dwoma rozwiązaniami. Przejmuje on pełną kontrolę nad potokiem danych, od odbioru OTLP aż po przechowywanie w ClickHouse, a agenta umieszcza na etapie triażu, a nie na etapie naprawy. Taka konstrukcja sprawia, że samodzielne hostowanie tego rozwiązania jest decyzją infrastrukturalną, a nie tylko uruchomieniem kontenera, o którym można zapomnieć. Po uruchomieniu Superlog obsługuje się kolumnową bazę danych, która wymaga takiej samej dbałości, jak każda inna posiadana baza danych.

FAQ

Ile pamięci RAM wymaga samodzielnie hostowany Superlog?

Dla pojedynczego węzła przy niskim wolumenie danych wejściowych należy zaplanować 8 GB pamięci RAM, 4 vCPU oraz 40 GB miejsca na dysku. Stos technologiczny obejmuje Postgres, ClickHouse, kolektor OpenTelemetry oraz cztery procesy Node, a ClickHouse wymaga zapasu pamięci. Serwer VPS z 1 GB lub 2 GB RAM jest niewystarczający: pnpm install sam w sobie jest zasobożerny, a ClickHouse pod obciążeniem jest zamykany przez mechanizm OOM (Out of Memory) jądra systemu. Należy samodzielnie zmierzyć zużycie zasobów za pomocą docker stats --no-stream oraz free -m, zamiast polegać na jakichkolwiek opublikowanych danych, w tym na niniejszych.

Na który port skierować eksporter OTLP?

Na proxy wejściowe Superlog, które zgodnie z plikiem README działa na http://localhost:4101. Obsługuje ono /v1/traces, /v1/logs oraz /v1/metrics i uwierzytelnia się za pomocą klucza ingest projektu pobieranego z nagłówka x-api-key lub authorization: bearer. Port 4318 obsługuje bezpośrednio kolektor OpenTelemetry, a wysyłanie danych bezpośrednio tam pomija proxy, czyli komponent przypisujący identyfikator projektu do danych. Proxy korzysta z portu 4000, gdy zmienna PORT nie jest ustawiona, dlatego przed założeniem, że jest to 4101, należy wykonać ss -lntp i sprawdzić, na którym porcie nasłuchuje proces.

Czy Superlog zastępuje Uptime Kuma lub Zabbix?

Nie. Uptime Kuma sprawdza, czy punkt końcowy odpowiada spoza sieci, a Zabbix monitoruje metryki hosta i usług względem zdefiniowanych progów. Superlog przetwarza ślady (traces), logi i metryki generowane przez aplikacje oraz grupuje powtarzające się awarie w incydenty. Należy zachować zewnętrzną sondę monitorującą dostępność, ponieważ sonda działająca w innym miejscu zgłosi awarię, gdy serwer obsługujący potok telemetryczny przestanie działać.

Czy agent Superlog może zmieniać moje systemy produkcyjne?

Tylko w zakresie przyznanych uprawnień. Wynikiem jego działania jest analiza oraz propozycja zmiany, którą weryfikuje człowiek. Na początku należy ograniczyć uprawnienia aplikacji GitHub do odczytu i zgłaszania pull requestów, a poświadczenia posiadane przez proces roboczy ograniczyć do uprawnień do odczytu. Przyznanie uprawnień do zapisu w środowisku produkcyjnym powinno być świadomą decyzją, ponieważ agent mogący restartować usługi stanowi znacznie większe ryzyko niż agent jedynie odczytujący telemetrię i przygotowujący poprawki do przeglądu.

Czy przypiąć konkretny commit, czy śledzić gałąź main?

Należy przypiąć konkretny commit. Na sierpień 2026 w repozytorium nie ma tagów wydań, więc main jest jedynym dostępnym celem, który zmienia się o kilka commitów tygodniowo. Należy zapisać przetestowany skrót SHA, wdrożyć tę wersję i przeanalizować różnice (diff) przed aktualizacją. git log --oneline <old-sha>..main zawiera przegląd zmian, a pliki .env.example dla poszczególnych aplikacji są pierwszym miejscem, w którym należy szukać informacji o nowo wymaganych zmiennych po każdej aktualizacji.