n8n w Dockerze na własnym serwerze: co pokazał odczyt konfiguracji

Kategoria: Automatyzacja i autonomia

„Czy n8n w Dockerze wystarczy na stałe, czy to tylko sposób na szybki test?” Wątpliwość pojawia się po pierwszej godzinie, gdy trzeba zdecydować, czy przenosić tam coś, na czym naprawdę zależy.

Opisuję jedną instancję n8n, która stoi na moim serwerze domowym i obsługuje wszystkie moje automatyzacje. Wszystkie wartości poniżej odczytałem 2 listopada 2026 z konfiguracji działającego kontenera i z pliku docker compose, który go uruchamia. Jest to odczyt stanu z tego dnia, nie pomiar wydajności ani zalecenie.

Co właściwie jest uruchomione

Własny obraz, a nie oficjalny

n8n nie chodzi u mnie z oficjalnego obrazu, lecz z obrazu autonomous-living-n8n:latest, zbudowanego w moim repozytorium z pliku infrastructure/scripts/Dockerfile.n8n. W konfiguracji działającego kontenera nie widać, co ten plik dokłada do oficjalnego obrazu.

Widać natomiast coś, co warto wiedzieć przed zbudowaniem własnego obrazu: etykieta latest nie mówi nic o tym, co jest w środku. Wersję, czyli 2.45.7, musiałem odczytać z pliku wewnątrz kontenera, a nie z nazwy obrazu.

Polityka restartu to unless-stopped: kontener wraca sam po restarcie maszyny i nie wraca, jeżeli zatrzymałem go celowo. Ta druga połowa jest ważniejsza, bo przy always zatrzymanie kontenera na czas naprawy kończy się tym, że Docker uruchamia go w środku tej naprawy.

Port, i to, co stoi przed nim

5678 wystawiony na każdy interfejs

Kontener publikuje port 5678 na adresie 0.0.0.0, czyli na każdy interfejs sieciowy maszyny, i nie ma przed nim na tym hoście ani serwera pośredniczącego, ani TLS.

To nie znaczy, że edytor stoi u mnie w internecie bez osłony. Ustawione są N8N_WEBHOOK_URL, N8N_EDITOR_BASE_URL i N8N_TRUST_PROXY, a te trzy razem znaczą, że publiczna nazwa i terminacja TLS są o warstwę dalej, na innej maszynie. Z tego hosta nie widać, która to maszyna.

Kolejność jest tu ważniejsza niż numer portu: 0.0.0.0:5678 bez niczego przed sobą jest bezpieczne dopiero wtedy, gdy wiadomo, co odgradza maszynę od sieci.

Gdzie n8n trzyma to, co w nim zbudowałem

Zero wolumenów nazwanych, same montowania katalogów

Mój kontener nie ma ani jednego wolumenu nazwanego. Wszystko jest podmontowanym katalogiem z dysku hosta: dane samego n8n, czyli workflow i konfiguracja, leżą w katalogu n8n_data w moim repozytorium i wchodzą do kontenera jako /home/node/.n8n. Obok tego wchodzą kopie zapasowe, całe repozytorium, katalog notatek i katalog wymiany plików.

Powód jest konkretny: te dane mają leżeć tam, gdzie je widzę, a nie w miejscu, którym zarządza Docker. Cena jest taka, że ścieżka hosta jest teraz częścią konfiguracji, a przeniesienie tego na inną maszynę jest przeniesieniem katalogów.

Jedno montowanie ma skutki inne niż wygoda i podaję je, bo kto skopiuje układ, skopiuje też tę linię. Do kontenera wchodzi gniazdo Dockera, /var/run/docker.sock, i jest tam dla osobnego mechanizmu uruchamiającego zadania w izolowanych kontenerach, a nie dla samego n8n. Skutek jest taki, że z wnętrza kontenera da się zrobić Dockerowi na hoście to samo, co z wiersza poleceń.

Baza danych: PostgreSQL, ale nie wprost

n8n łączy się z puli połączeń, nie z serwerem bazy

n8n ma u mnie DB_TYPE=postgresdb, więc trzyma workflow i historię w PostgreSQL, a nie w domyślnym pliku SQLite. Adresem bazy nie jest jednak serwer PostgreSQL, lecz pgbouncer na porcie 6432, czyli pula połączeń stojąca przed bazą. n8n ma tam własną bazę i własne konto.

Nie jest to wyjątek zrobiony dla n8n. Reguła jest starsza niż ta instancja i opisałem ją, tłumacząc, dlaczego mam osiem baz danych z jedną drogą dostępu: nic nie łączy się z bazą samo. n8n jest tu jednym klientem z wielu i dlatego nie ma w swojej konfiguracji adresu serwera bazy.

Tryb wykonywania: zwykły, nie kolejkowy

Redis stoi w tym samym projekcie i nie obsługuje kolejki n8n

n8n umie pracować w trybie kolejkowym, w którym przebiegi rozdziela się na osobne procesy wykonawcze. Moja instancja tak nie pracuje: w odczycie nie ma ani EXECUTION_MODE=queue, ani włączonych procesów wykonawczych. Jedyna zmienna z tej rodziny to N8N_RUNNERS_TASK_TIMEOUT=300, a to limit czasu jednego zadania, nie kolejka.

Redis w tym samym projekcie docker compose stoi i działa, tylko z kolejką n8n nie ma nic wspólnego. Czytając czyjś plik compose, łatwo wziąć obecność Redisa obok n8n za dowód trybu kolejkowego. Nie jest nim.

Dlaczego tryb zwykły mi wystarcza, wynika z liczby, którą podałem, czytając błędy w swoich workflow: przez czternaście dni instancja wykonała 5 245 przebiegów, czyli około 375 na dobę. Przy takim ruchu jeden proces nie jest ograniczeniem, które bym odczuwał.

Limity, które zadeklarowałem, i których kontener nie ma

2 rdzenie i 2 GB w pliku, zero w działającym kontenerze

Tu odczyt pokazał coś, czego się nie spodziewałem. Mój plik docker compose deklaruje dla n8n limit 2,0 rdzenia i 2 GB pamięci. Działający kontener nie ma ani jednego z nich: przydział czasu procesora jest w jego konfiguracji zerowy, a limitu pamięci nie ma w ogóle.

Byłem więc przekonany, że ta instancja ma górną granicę pamięci, a nie miała jej. Gdyby workflow pociągnął pamięć w górę, nic nie zatrzymałoby go przed zabraniem tego, co jest na maszynie.

Wniosek nie dotyczy n8n i jest wart więcej niż ta liczba: deklaracja w pliku nie dowodzi, że limit działa. Sprawdza się to na uruchomionym kontenerze, nie w pliku, który go opisuje.

Cały odczyt:

Wszystkie trzynaście wartości to jeden odczyt z tego samego dnia.

To nie jest instrukcja instalacji

Siedem rzeczy, których ten odczyt nie rozstrzyga, zebranych tu, a nie rozsypanych po akapitach.

• Nie jest to instrukcja instalacji. Opisuję stan końcowy, a nie kolejność kroków, które do niego doprowadziły.
• Nie odpowiadam na pytanie o koszt n8n. Nie mam na warunki licencyjne źródła z datą, które mógłbym tu podać, a czytelnik sprawdzić.
• Licznik restartów zero nic nie dowodzi. Kontener był w chwili odczytu uruchomiony od dwóch i pół godziny, bo chwilę wcześniej odtworzyłem go po przebudowie obrazu. To zero jest świadectwem świeżego startu, nie stabilności.
• Nie wiem, ile ta instancja faktycznie zajmuje pamięci. Skoro limitu nie ma, nie ma też liczby, którą ten limit by przycinał. Zużycia nie zmierzyłem i nie będę go szacował.
• Nie opisuję drogi z internetu do tego portu. Publiczna nazwa i TLS są na innej maszynie, której w tym odczycie nie ma.
• Nie wiem, czym mój obraz różni się od oficjalnego. W odczycie jest nazwa pliku budującego, nie treść.
• To nie jest miara oszczędności czasu. Nie mam jej zmierzonej dla żadnej ze swoich dziedzin i konfiguracja hostingu jej nie przybliża.

Co w tej instancji faktycznie działa, to osobny odczyt, i rozbiłem go przy pytaniu o to, co znaczy ponad 150 workflow w n8n. To, co odpowiada po drugiej stronie wywołań modeli, policzyłem osobno przy modelach AI w n8n: chmura czy lokalnie.