n8n czy Make? Porównanie z perspektywy kogoś, kto pracuje w obu

Pytanie „n8n czy Make?” słyszę zwykle na samym początku rozmowy o automatyzacji, zanim ktokolwiek wie, co właściwie ma być zautomatyzowane. Rozumiem to. Wybór narzędzia wydaje się pierwszą decyzją, bo od niego zależy, gdzie zbudujemy scenariusz i ile będziemy płacić co miesiąc.

Pracuję w obu. Dzisiaj większość moich automatyzacji działa na własnej instancji n8n, ale scenariusze w Make też buduję i utrzymuję. Poniżej porównuję je tak, jak porównuję je przy projektach: po sposobie liczenia kosztów, po tym, gdzie leżą dane, po obsłudze błędów i po tym, kto będzie to potem utrzymywał.

Najkrócej: czym różnią się n8n i Make

Oba narzędzia robią to samo: łączą aplikacje i przenoszą dane według ustalonych kroków. Formularz wysyła zgłoszenie, automat zapisuje je w CRM, wysyła maila i dodaje zadanie. W Make taki ciąg kroków nazywa się scenariuszem, a pojedynczy krok modułem. W n8n mówimy o workflowie i węzłach (nodes).

	n8n	Make
Za co płacisz	za uruchomienie całego workflowu, bez względu na liczbę kroków	za kredyty, czyli w praktyce za akcje modułów
Gdzie działa	w chmurze n8n albo na Twoim serwerze	w chmurze Make
Próg wejścia	wyższy, bliżej programowania	niższy, bardzo wizualny
Własny kod	węzeł Code (JavaScript, Python)	głównie funkcje w polach modułów
Obsługa błędów	osobny workflow błędów, czerwone wyjścia węzłów	trasy obsługi błędów przy modułach
Agenci AI	węzeł AI Agent z narzędziami i pamięcią	agenci AI w ramach platformy

Tabela niczego jeszcze nie rozstrzyga. Większość różnic wychodzi dopiero przy konkretnym procesie, a najmocniej przy rachunku.

Ile kosztuje n8n, a ile Make

Najważniejsza różnica dotyczy tego, co się liczy.

n8n pisze w cenniku wprost: płacisz za miesięczną liczbę uruchomień workflowu, „bez względu na złożoność”. Jedno uruchomienie (execution) to jedno przejście całego workflowu i według n8n nie ma znaczenia, ile ma kroków ani ile danych przetwarza. W chmurze n8n najtańszy plan Starter kosztuje 20 euro miesięcznie przy płatności rocznej i daje 2500 uruchomień, plan Pro 50 euro i 10 000 uruchomień.

Make rozlicza się w kredytach. Według cennika większość akcji zużywa jeden kredyt, a liczy się każda akcja modułu: odczyt, wyszukanie, utworzenie rekordu, aktualizacja, przekształcenie danych, iteracja. Routery i moduły obsługi błędów kredytów nie zużywają, za to niektóre funkcje AI mogą zużywać więcej. Darmowy plan ma 1000 kredytów miesięcznie, dwa aktywne scenariusze i uruchomienie najczęściej co 15 minut.

Na przykładzie wygląda to tak. Raz dziennie automat pobiera ze sklepu 100 nowych zamówień i dla każdego robi pięć rzeczy: sprawdza klienta w CRM, zapisuje zamówienie, aktualizuje arkusz, wysyła powiadomienie i oznacza zamówienie jako przetworzone. W n8n to jedno uruchomienie dziennie, około 30 w miesiącu. W Make każdy z pięciu modułów wykona się sto razy, więc w przybliżeniu 500 kredytów dziennie i około 15 000 w miesiącu. To przybliżenie, bo dokładny wynik zależy od budowy scenariusza, ale skala różnicy jest prawdziwa.

Odwrotnie bywa przy prostych, rzadkich automatach. Scenariusz z trzema modułami, który rusza kilka razy dziennie, zmieści się w darmowym albo najtańszym planie Make i nie trzeba nic stawiać ani utrzymywać.

n8n na własnym serwerze

n8n można zainstalować na własnym serwerze. Licencja (Sustainable Use License) pozwala używać go i modyfikować „wyłącznie na potrzeby własnej działalności”, do celów niekomercyjnych albo prywatnych. Nie możesz więc sprzedawać n8n jako usługi innym, ale własne procesy firmy możesz na nim automatyzować.

Wersja na własnym serwerze nie ma limitu uruchomień w cenniku. Płacisz za serwer i za czas kogoś, kto go utrzymuje: aktualizacje, kopie zapasowe, certyfikat, pilnowanie miejsca na dysku. Ten czas łatwo pominąć w rachunku, a to on najczęściej przesądza, czy własna instancja się opłaca. Jak policzyć taki koszt razem z czasem ludzi, pokazałem w tekście czy automatyzacja się opłaca.

Gdzie leżą dane klientów

Przy n8n na własnym serwerze dane z formularzy, maili i zamówień przechodzą przez maszynę, którą kontrolujesz. Historia uruchomień (executions) z pełnymi danymi wejściowymi i wyjściowymi każdego węzła też leży u Ciebie. Domyślnie n8n kasuje ją po 14 dniach i tę wartość możesz zmienić.

W Make dane przechodzą przez chmurę dostawcy. To nie musi być problem, bo tak samo działa każdy CRM i każda skrzynka pocztowa w chmurze. Trzeba to jednak wiedzieć, wpisać Make na listę podmiotów przetwarzających dane i sprawdzić umowę powierzenia, jeśli automat przenosi dane osobowe. To samo dotyczy n8n w chmurze.

Przy danych wrażliwych, na przykład medycznych albo finansowych, własny serwer daje więcej kontroli. Daje też więcej odpowiedzialności: kopie, aktualizacje bezpieczeństwa i dostęp do serwera są wtedy po Twojej stronie.

Który łatwiej zbudować i utrzymać

Make jest przyjaźniejszy na start. Scenariusz układa się z kółek, dane z poprzednich modułów wybiera się z listy, a wiele popularnych aplikacji ma gotowe moduły z polami do kliknięcia. Osoba bez technicznego zaplecza zbuduje w Make pierwszy działający automat szybciej niż w n8n.

n8n jest bliżej programowania. Dane płyną między węzłami jako JSON, wyrażenia piszesz w składni JavaScript, a tam, gdzie brakuje gotowego węzła, sięgasz po węzeł HTTP Request i dokumentację API. Dla kogoś, kto zna API i lubi mieć kontrolę, to zaleta. Dla kogoś, kto chce tylko połączyć formularz z arkuszem, przeszkoda.

Przy wyborze pytam więc też, kto będzie poprawiał automat za pół roku. Jeśli po wdrożeniu scenariusze ma przejąć osoba z działu marketingu, Make bywa rozsądniejszy, nawet gdy n8n wychodzi taniej.

Obsługa błędów

Oba narzędzia pozwalają zareagować na błąd, ale robią to inaczej.

W Make przy module dodajesz trasę obsługi błędu z jedną z dyrektyw: Rollback, Break, Resume, Commit albo Ignore. Ignore działa podobnie do opcji Continue w n8n i ma tę samą wadę: błąd znika, a scenariusz wygląda na udany.

W n8n każdy workflow może wskazywać osobny workflow błędów, a każdy węzeł może mieć czerwone wyjście, którym idzie błąd. Opisałem to dokładnie we wpisie o obsłudze błędów w n8n, razem z pułapką, w którą sam wpadłem: workflow błędów był ustawiony, tylko nic nie wysyłał.

Zasada jest w obu narzędziach ta sama. Zanim automat trafi na produkcję, sprawdź, co się stanie, gdy padnie jego najważniejszy krok, i czy ktoś się o tym dowie.

Agenci AI: n8n czy Make

Oba narzędzia mają dziś agentów AI, czyli kroki, w których model językowy sam wybiera, z jakiego narzędzia skorzystać. W n8n jest to węzeł AI Agent, do którego podpinasz model, narzędzia i pamięć. Do tego dochodzą akceptacje człowieka przy wybranych narzędziach, o czym piszę w poradniku o agencie AI w n8n.

Przy agentach model rozliczeń ma jeszcze większe znaczenie. Agent może w jednym zadaniu wykonać kilka albo kilkanaście kroków. W n8n to nadal jedno uruchomienie workflowu, a w Make każdy krok zużywa kredyty. Do tego w obu przypadkach płacisz dostawcy modelu za każde jego wywołanie.

Zanim jednak wybierzesz narzędzie pod agenta, sprawdź, czy agent jest w ogóle potrzebny. Często wystarcza zwykła reguła, o czym piszę w tekście agent AI czy zwykła automatyzacja.

Jak wybrać: test na jednym procesie

Zamiast porównywać listy funkcji, weź jeden proces, który chcesz zautomatyzować, i odpowiedz na pięć pytań:

1. Ile razy w miesiącu automat się uruchomi i ile kroków wykona przy jednym uruchomieniu? Pomnóż jedno przez drugie, a zobaczysz, czy kredyty w Make będą problemem.
2. Czy automat przenosi dane osobowe albo wrażliwe? Jeśli tak, ustal, gdzie mogą być przetwarzane.
3. Kto będzie budował, a kto poprawiał automat za pół roku?
4. Czy wszystkie aplikacje mają gotowe moduły, czy część trzeba podłączyć przez API?
5. Czy w procesie jest krok z modelem AI albo agentem?

Wysoka liczba kroków, dane wrażliwe, osoba techniczna w zespole i dużo integracji przez API przemawiają za n8n. Małe scenariusze, brak kogoś technicznego i gotowe moduły do wszystkich aplikacji przemawiają za Make.

Mieszanie też jest w porządku. Nic nie stoi na przeszkodzie, żeby prosty scenariusz marketingowy działał w Make, a obsługa zamówień i automaty z AI w n8n. Ważniejsze od narzędzia jest to, żeby każdy automat miał właściciela i opis, co robi. Taki opis przydaje się też przy przenosinach, bo nie ma przycisku, który przeniesie scenariusz z Make do n8n albo odwrotnie.

Kiedy zmiana narzędzia nie ma sensu

Jeśli masz w Make kilkadziesiąt działających scenariuszy i rachunek Ci odpowiada, przenosiny do n8n tylko po to, żeby było taniej, rzadko się opłacają. Każdy scenariusz trzeba zbudować od nowa i przetestować, a przez ten czas dwa systemy działają równolegle. Policz najpierw, ile realnie zaoszczędzisz w roku, i porównaj to z czasem przenosin.

Odwrotnie też. Jeśli ktoś w firmie dobrze zna n8n, a scenariusze są złożone, przejście na Make dla wygody interfejsu oznacza zwykle wyższy rachunek i mniej kontroli.

Zastanawiasz się, czy Twoje automaty powinny działać w n8n, Make czy w obu? Napisz do mnie. Zaczniemy od jednego procesu i rachunku dla obu narzędzi.