n8n, automatyzacja workflow i agenci AI

n8n, automatyzacja procesów z własnym serwerem i agentami AI

n8n łączy usługi w wizualne przepływy: węzeł pobiera dane, kolejny je przekształca, następny wysyła dalej. Od konkurencji odróżniają go dwie rzeczy. Można go uruchomić na własnym serwerze bez opłat licencyjnych, a rozliczenie w chmurze liczy uruchomienia całego przepływu, nie pojedyncze kroki.

Dla kogo to narzędzie

n8n siedzi pomiędzy klikanymi automatyzacjami a pisaniem własnego backendu. Zbudujesz w nim przepływ bez kodu, ale w dowolnym miejscu wstawisz węzeł z JavaScriptem albo Pythonem, gdy klikanie przestaje wystarczać.

Ta granica decyduje o dopasowaniu. Zespół marketingu, który potrzebuje przenosić leady z formularza do CRM-u, poradzi sobie równie dobrze w prostszym narzędziu. Zespół techniczny, który chce podpiąć własne API, przetworzyć odpowiedź i wysłać ją do trzech systemów zależnie od warunku, zyskuje w n8n miejsce na tę logikę bez stawiania osobnej usługi.

Drugi typowy powód wyboru to dane wrażliwe. Instancja na własnym serwerze nie wysyła treści przetwarzanych dokumentów do zewnętrznego dostawcy, co przy danych osobowych albo medycznych bywa warunkiem, a nie preferencją.

Licencja, czyli co dokładnie znaczy darmowy

n8n nie jest oprogramowaniem open source w rozumieniu licencji zatwierdzonych przez OSI. Używa modelu fair-code i Sustainable Use License, co w praktyce oznacza trzy rzeczy.

Kod jest jawny i możesz go modyfikować. Wolno uruchomić instancję na własnym serwerze i używać jej wewnątrz firmy bez opłat, niezależnie od liczby użytkowników i przepływów. Nie wolno natomiast sprzedawać n8n jako usługi hostowanej dla klientów zewnętrznych ani budować na nim konkurencyjnego produktu.

Dla większości zespołów ograniczenie jest teoretyczne, bo dotyczy odsprzedaży, a nie użytku własnego. Warto je jednak znać przed wpisaniem n8n do oferty jako element sprzedawany klientowi, bo wtedy potrzebna jest licencja komercyjna. To częste nieporozumienie w agencjach, które konfigurują automatyzacje dla klientów i chcą hostować je u siebie.

Chmura czy własny serwer

Od kwietnia 2026 roku zniknął limit aktywnych przepływów we wszystkich planach, więc rozliczenie opiera się wyłącznie na liczbie uruchomień. Wcześniej trzeba było pilnować, ile automatyzacji jest włączonych naraz, co wymuszało sztuczne łączenie procesów w jeden przepływ.

Przy każdej kwocie zwróć uwagę na sposób płatności, bo cennik pokazuje domyślnie stawkę roczną, a przy płatności miesięcznej ta sama pula kosztuje mniej więcej o jedną piątą więcej. Plany Pro i Business mają dodatkowo wyższe progi uruchomień w tej samej rodzinie, na przykład Pro w wariancie na pięćdziesiąt tysięcy przebiegów, więc przeskok nie musi od razu oznaczać zmiany rodziny planu.

Drugą rzeczą, która rzadko trafia do porównań, jest to, co się dzieje po wyczerpaniu puli. Przepływy nie zatrzymują się: działają dalej, a nadwyżka trafia na fakturę, o ile nie przejdziesz na wyższy próg. Na planie Business nadwyżkę rozlicza się pakietami po trzysta tysięcy uruchomień, a faktura wystawiana jest z opóźnieniem liczonym w tygodniach, więc rachunek za przekroczenie zobaczysz później, niż się ono wydarzyło. Osobno działa limit równoległości: przebiegi ponad limit nie giną, tylko czekają w kolejce i wykonują się w kolejności zgłoszenia.

Rachunek za własny serwer jest niższy tylko pozornie. Do kosztu maszyny dolicz aktualizacje, kopie zapasowe bazy z historią wykonań, monitoring i czas kogoś, kto zareaguje, gdy instancja przestanie odbierać webhooki. Przy dwóch procesach chmura wychodzi taniej, przy dwudziestu proporcje się odwracają.

Rozliczenie za uruchomienie, nie za krok

To najczęściej pomijana różnica przy porównywaniu narzędzi. W Zapierze płacisz za każdy wykonany krok, więc przepływ z dziesięcioma węzłami zużywa dziesięć jednostek. W n8n cały przebieg liczy się jako jedno uruchomienie, niezależnie od liczby węzłów.

Konsekwencja jest praktyczna: przepływy w n8n opłaca się budować szczegółowo. Rozbicie logiki na piętnaście czytelnych węzłów zamiast trzech przeładowanych nic nie kosztuje, a znacząco ułatwia późniejsze poprawki. W narzędziach rozliczanych za krok ta sama decyzja podnosi rachunek pięciokrotnie.

Warto policzyć próg opłacalności przed wyborem planu. Proces uruchamiany co pięć minut przez całą dobę to około ośmiu tysięcy sześciuset przebiegów miesięcznie, czyli więcej niż limit planu Starter przy jednym tylko procesie. Automatyzacja reagująca na zdarzenia zamiast odpytywania co kilka minut potrafi zbić tę liczbę dziesięciokrotnie, więc zanim dołożysz plan, sprawdź, czy da się zamienić harmonogram na webhook.

Uwaga na pętle. Węzeł przetwarzający listę stu elementów nadal jest jednym uruchomieniem, ale przepływ wywołujący sam siebie sto razy to sto uruchomień. Przy dużych zbiorach danych sprawdzaj, czy węzeł działa w trybie wsadowym, czy tworzy osobny przebieg dla każdego elementu.

Pierwszy przepływ

Instalacja lokalna zajmuje jedno polecenie.

docker run -it --rm -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Typowy przepływ zaczyna się od wyzwalacza. Węzeł Webhook nadaje adres, pod który wysyłasz żądanie, a reszta przepływu przetwarza jego zawartość.

Załóżmy proces obsługi zgłoszeń: formularz wysyła dane na webhook, przepływ klasyfikuje treść modelem językowym, zapisuje wynik w bazie i powiadamia zespół tylko przy wysokim priorytecie. Cztery węzły, jedno rozgałęzienie.

Warunek ustawia się w węźle If, gdzie porównujesz wartość pola z progiem. Odwołania do danych z poprzednich węzłów mają postać wyrażeń.

{{ $json.priorytet }}
{{ $('Klasyfikacja').item.json.kategoria }}
{{ $now.minus({ days: 7 }).toISO() }}

Pierwsza forma sięga do bieżącego elementu, druga do wyniku konkretnego węzła po nazwie, trzecia korzysta z wbudowanej biblioteki dat. Nazwy węzłów wchodzą do wyrażeń, więc zmiana nazwy po zbudowaniu przepływu psuje odwołania. Nazwij węzły sensownie od razu.

Węzeł Code i granica klikania

Gdy przekształcenie danych robi się zawiłe, wygodniej napisać je wprost niż układać z pięciu węzłów.

const wynik = []

for (const element of $input.all()) {
  const pozycje = element.json.zamowienie.pozycje ?? []
  wynik.push({
    json: {
      numer: element.json.zamowienie.numer,
      wartosc: pozycje.reduce((suma, p) => suma + p.cena * p.ilosc, 0),
      liczbaPozycji: pozycje.length
    }
  })
}

return wynik

Węzeł Code działa w dwóch trybach: raz dla całej partii danych albo osobno dla każdego elementu. Pierwszy jest szybszy i pozwala agregować, drugi czytelniejszy przy prostych przekształceniach.

Reguła, która oszczędza kłopotów: kod w n8n powinien przekształcać dane, a nie zawierać logiki biznesowej wartej testów. Wszystko, co wymaga testów jednostkowych, lepiej trzymać we własnym API i wywołać z przepływu, bo w węźle Code nie ma ani wersjonowania, ani testów.

Agenci AI w przepływach

n8n ma węzły do modeli językowych, pamięci rozmowy i narzędzi, więc agent staje się elementem przepływu, a nie osobną aplikacją. Rozliczenie jest to samo co dla zwykłych węzłów, bez dodatkowej taryfy za AI.

Praktyczny układ wygląda tak: węzeł agenta dostaje model z OpenAI albo Claude, listę narzędzi zdefiniowanych jako inne węzły oraz pamięć trzymaną w bazie. Agent sam decyduje, które narzędzie wywołać, a n8n wykonuje je i oddaje wynik.

Ten model sprawdza się przy zadaniach na kilka kroków, gdzie kolejność zależy od danych. Do procesów o stałej kolejności lepiej użyć zwykłych węzłów, bo są tańsze, szybsze i przewidywalne. Jeśli zadanie wymaga rozgałęzień, pamięci między sesjami i akceptacji człowieka, rozważ zbudowanie go w LangChain i wywołanie z n8n jako pojedynczego kroku.

Osobna sprawa to koszt tokenów. Agent w przepływie uruchamianym tysiąc razy dziennie wygeneruje rachunek u dostawcy modelu znacznie wyższy niż subskrypcja n8n. Zanim włączysz taki przepływ na stałe, policz koszt jednego przebiegu i pomnóż przez realny wolumen.

n8n kontra alternatywy

Wybór sprowadza się zwykle do dwóch pytań. Czy dane mogą opuścić firmę, oraz czy w zespole jest ktoś, kto zaktualizuje kontener i przywróci bazę z kopii. Odpowiedź przecząca na drugie pytanie przy twierdzącej na pierwsze prowadzi wprost do chmury.

Utrzymanie własnej instancji

Domyślna konfiguracja zapisuje dane w SQLite, co wystarcza do prób, ale nie do produkcji. Przy realnym ruchu przełącz bazę na Postgresa, na przykład z Supabase, i włącz tryb kolejkowy, w którym osobne procesy robocze wykonują zadania.

Trzy rzeczy warto ustawić od pierwszego dnia. Automatyczne czyszczenie historii wykonań, bo tabela z pełnymi danymi każdego przebiegu rośnie szybciej, niż się wydaje, i potrafi zapełnić dysk w kilka tygodni. Kopię zapasową bazy, ponieważ razem z nią giną wszystkie przepływy i klucze. Klucz szyfrowania danych logowania zapisany poza serwerem, bo bez niego przywrócona kopia nie odszyfruje żadnego połączenia.

Przepływy trzymaj w repozytorium jako pliki JSON, nawet jeśli edytujesz je w przeglądarce. Eksport pozwala przeglądać zmiany, cofać nieudane poprawki i przenosić konfigurację między środowiskiem testowym a produkcyjnym.

Monitorowanie i diagnostyka

Historia wykonań jest pierwszym miejscem, do którego zaglądasz po zgłoszeniu, że coś nie zadziałało. Każdy przebieg pokazuje dane wejściowe i wyjściowe każdego węzła, więc znalezienie momentu, w którym pole zniknęło albo zmieniło typ, zajmuje chwilę.

Domyślnie n8n zapisuje wszystkie przebiegi, także udane, co po miesiącu daje bazę większą niż same przepływy. Rozsądny układ to pełna historia błędów przez trzydzieści dni i skrócona historia sukcesów przez kilka dni.

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=336
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_SAVE_ON_ERROR=all

Powiadomienia o awariach warto wyprowadzić poza n8n. Przepływ obsługi błędów, który wysyła alert innym przepływem n8n, przestaje działać dokładnie wtedy, kiedy instancja ma problem. Alert o niedostępności całej instancji ustaw w zewnętrznym monitoringu, odpytującym adres zdrowia co minutę.

Przy trybie kolejkowym obserwuj długość kolejki, a nie tylko obciążenie procesora. Rosnąca kolejka przy niskim zużyciu zasobów zwykle oznacza, że procesy robocze czekają na wolną odpowiedź zewnętrznego API, i wtedy dokładanie mocy nic nie da. Rozwiązaniem jest limit współbieżności po stronie tego węzła albo przeniesienie wolnego wywołania do osobnego przepływu.

Typowe błędy

Pierwszy to brak obsługi błędów. Przepływ bez osobnej ścieżki na wypadek awarii przerywa się po cichu, a zgłoszenie klienta ginie. Ustaw przepływ obsługi błędów i podepnij go do każdego procesu, który dotyka danych klienta.

Drugi to przechowywanie kluczy w węzłach zamiast w danych logowania. Klucz wpisany w pole URL trafia do eksportu przepływu i do historii wykonań.

Trzeci to jeden przepływ na wszystko. Proces z czterdziestoma węzłami i sześcioma rozgałęzieniami jest nieczytelny i nie da się go testować fragmentami. Rozbij go na kilka mniejszych, wywoływanych jeden z drugiego.

Czwarty to testowanie na produkcji. n8n rozróżnia adresy webhooków testowe i produkcyjne, więc korzystaj z tego rozdziału zamiast wyłączać przepływ na czas prób.

Piąty to ślepe zaufanie do struktury odpowiedzi zewnętrznego API. Węzeł skonfigurowany na polach, które akurat przyszły podczas budowania, przestanie działać, gdy dostawca doda opakowanie albo zmieni nazwę pola. Sprawdzaj obecność pól warunkiem, zamiast zakładać ich istnienie.

FAQ

Czy n8n jest darmowy?

Wersja Community uruchomiona na własnym serwerze nie ma opłat licencyjnych ani limitów uruchomień, płacisz tylko za maszynę. Licencja fair-code zabrania jednak odsprzedaży n8n jako usługi hostowanej dla klientów, do czego potrzebna jest umowa komercyjna. Plany chmurowe zaczynają się od 20 EUR miesięcznie przy płatności rocznej albo 24 EUR przy miesięcznej.

Czym n8n różni się od Zapiera?

Trzema rzeczami: rozliczeniem za całe uruchomienie zamiast za krok, możliwością uruchomienia na własnym serwerze oraz węzłem Code, w którym piszesz JavaScript lub Pythona. Zapier ma za to więcej gotowych integracji i prostszy start dla osób nietechnicznych.

Ile zasobów potrzebuje własna instancja?

Do kilkunastu procesów o niewielkim wolumenie wystarczy serwer z dwoma rdzeniami i czterema gigabajtami pamięci. Przy większym ruchu przejdź na tryb kolejkowy z osobnymi procesami roboczymi i bazą Postgres, bo domyślny układ jednoprocesowy staje się wąskim gardłem.

Czy da się wersjonować przepływy w gicie?

Tak, przez eksport do JSON-a i trzymanie plików w repozytorium. Plany biznesowe mają wbudowaną synchronizację z gitem, w wersji darmowej robi się to skryptem korzystającym z API n8n.

Czy n8n nadaje się do przetwarzania dużych zbiorów danych?

Do partii rzędu tysięcy rekordów tak, przy założeniu przetwarzania wsadowego i odpowiednich zasobów. Przy milionach rekordów lepszym narzędziem jest potok danych zbudowany do tego celu, na przykład oparty o Airflow, bo n8n optymalizuje wygodę budowania procesu, a nie przepustowość.

Aktualny cennik stoi na n8n.io, a dokumentacja w docs.n8n.io.