Zapier, Make czy n8n? Jedna pętla potrafi zwielokrotnić rachunek

Przy wyborze między Zapier, Make i n8n dla procesu z pętlą najpierw trzeba policzyć jednostki zużycia. Cennik Zapier nalicza zadania za skutecznie wykonane działania; część działań może zużyć więcej niż jedno zadanie. Cennik Make opiera się na kredytach za działania modułów, z których większość zużywa po jednym kredycie. Cennik n8n rozlicza w planach Cloud całe uruchomienia przepływu niezależnie od liczby kroków i przetworzonych danych.

Jeśli jeden przebieg przetwarza wiele elementów, każde płatne działanie powtarzane dla elementu może zwiększać zużycie w Zapier i Make. W n8n Cloud taka praca nadal mieści się w jednym uruchomieniu, choć kolejne uruchomienie po błędzie powiększa licznik. Samodzielnie hostowana wersja Community wymaga natomiast opłacenia infrastruktury i czasu osoby, która ją utrzymuje. Najtańszy abonament i najtańszy ukończony proces to zatem dwa różne rachunki.

Za co płaci każda platforma

W Zapier wyzwalacz rozpoczynający przepływ nie zużywa zadania, podobnie jak część wbudowanych narzędzi, między innymi Filter, Formatter i Looping. Liczą się skuteczne działania wykonywane później, także te powtarzane dla kolejnych elementów. Nieudane działanie nie obciąża limitu zadań, lecz skuteczne działania wykonane przed błędem już mogły go obciążyć. Przy kalkulacji trzeba więc odróżnić liczbę widocznych kroków od liczby zadań, którą te kroki rzeczywiście zużyją.

Make liczy wykonanie modułów, w tym operacje odczytu, zapisu, przekształcania i iteracji danych. Router oraz wymienione w cenniku moduły obsługi błędów nie zużywają kredytów. Zwykły moduł uruchomiony na ścieżce obsługi błędu może jednak zużyć kredyty, a niektóre zaawansowane działania mają wyższy koszt. Dla obu usług ważna jest więc liczba działań w pętli, a nie tylko liczba uruchomień scenariusza.

W n8n Cloud jednostką jest egzekucja całego przepływu. Ten sposób liczenia ogranicza wpływ liczby węzłów na rachunek za plan, lecz plan nadal ma limit egzekucji. Dostępna do samodzielnego hostingu wersja Community przenosi na firmę koszty serwera i obsługi; płatne, samodzielnie hostowane plany n8n mają własne limity egzekucji. Tych wariantów nie należy wpisywać do kalkulatora jako jednej pozycji.

Co pokazuje wycena tego samego przepływu

W porównaniu Appycodes synchronizacja zamówień z dziewięcioma modułami, w tym ośmioma płatnymi działaniami Zapier, została wyceniona dla 10 tys. uruchomień miesięcznie na 433 USD w Zapier, 81 USD w Make i około 10 USD infrastruktury dla n8n Community na własnym serwerze. Autorzy użyli cen katalogowych z lipca 2026 r. i określonej konfiguracji procesu. Są to kwoty dla tego przepływu i przyjętego sposobu płatności, a nie ceny każdego procesu firmy w Polsce.

Różnica staje się mniejsza, gdy do opłat za platformę doda się pracę i wdrożenie. Przy stawce 90 USD za godzinę, założonym czasie obsługi oraz koszcie budowy rozłożonym na 24 miesiące całkowity miesięczny koszt tego przykładu wyniósł 507 USD dla Zapier, 221 USD dla Make i 253 USD dla własnego n8n. W takim ujęciu Make kosztował mniej niż samodzielnie hostowane n8n. Kwota 10 USD opisuje więc samą infrastrukturę, podczas gdy 253 USD obejmuje także przyjęty przez autorów nakład pracy.

Kalkulator dla własnej pętli i ponowień

Do oszacowania zużycia wpisz wartości dla miesiąca i osobno opisz płatne działania w każdej platformie. To ważne, ponieważ zadanie Zapier i kredyt Make nie zawsze odpowiadają pojedynczemu krokowi o takim samym koszcie:

• R — liczba pierwotnych uruchomień procesu.
• A — liczba płatnych jednostek poza pętlą podczas typowego przebiegu.
• E — średnia liczba elementów w pętli.
• B — liczba płatnych jednostek potrzebnych do obsłużenia jednego elementu.
• Q — średnia liczba ponowień przypadających na pierwotne uruchomienie.
• D — średnia liczba płatnych jednostek wykonanych podczas jednego ponowienia.
• H — liczba godzin miesięcznej administracji własnego n8n, a P — koszt godziny tej pracy.

Przy stałej liczbie elementów szacowane miesięczne zużycie Zapier albo Make wynosi R × (A + E × B) + R × Q × D. Wartości A, B i D policz oddzielnie dla każdej usługi, uwzględniając jej wyjątki oraz działania zużywające więcej niż jedną jednostkę. Jeśli ponawiany jest cały przebieg, D równa się A + E × B. Jeśli ponawiany jest tylko fragment, D obejmuje wyłącznie jednostki zużyte na tej ścieżce; nieudanej akcji Zapier nie dolicza się jako skutecznego zadania.

W warunkowym przykładzie R wynosi 1000, A wynosi 2, E wynosi 20, B wynosi 2, a Q wynosi 0,05. Przy pełnym ponowieniu D wynosi 42, więc wzór daje 44 100 jednostek. Gdyby pętla obsługiwała jeden element przy pozostałych założeniach bez zmian, wynik wyniósłby 4200 jednostek. To ponad dziesięciokrotna różnica w zużyciu; różnica na fakturze zależy jeszcze od progów planu i zasad dopłat.

Dla n8n Cloud punktem wyjścia jest R egzekucji. Dodaj R × Q tylko wtedy, gdy ponowienie oznacza nowe uruchomienie całego przepływu; ponawianie działania wewnątrz trwającej egzekucji nie jest tym samym. W warunkowym przykładzie pełne ponowienia dałyby 1050 egzekucji. Dla n8n Community miesięczny koszt można zapisać jako serwer + H × P + część kosztu wdrożenia przypisana do miesiąca. Jeśli większa pętla wymaga mocniejszej infrastruktury, podnieś również pozycję „serwer”.

Opóźnienia i obsługa błędów

Opublikowany test przepływu webhook–HTTP wykazał medianę dostarczenia 0,8 s dla n8n na własnym serwerze, 1,0 s dla płatnego Make i 4,4 s dla płatnego Zapier. Autor nie odnotował cichych awarii odpowiednio w 3714, 228 i 231 przebiegach tych trzech konfiguracji. Liczby dotyczą prostego przepływu, a próby płatnych usług były znacznie mniejsze od próby n8n. Mediany nie pozwalają więc przewidzieć czasu wieloetapowej integracji z innymi aplikacjami.

Opóźnienie i awaria mają też wymiar kosztowy. Jeżeli po błędzie system ponownie wykona wcześniej skuteczne działania, zużycie Zapier lub Make wzrośnie zgodnie z rzeczywistą ścieżką ponowienia. Jeśli błąd zatrzyma proces przed pętlą, koszt odzyskania będzie inny niż przy błędzie na jej końcu. Własny serwer n8n nie nalicza opłaty za każde powtórzone działanie w Community, ale ponowienia zajmują jego zasoby i mogą wydłużać kolejkę następnych uruchomień.

Kiedy własny serwer obniża całkowity koszt

Samodzielne n8n ma przewagę kosztową wtedy, gdy firma potrafi utrzymać instalację taniej niż wynosi różnica w opłatach za płatne jednostki. Do H należy wliczyć aktualizacje, kopie zapasowe, monitorowanie i czas potrzebny na przywrócenie działania po awarii. Koszt budowy przepływu warto rozłożyć na planowany okres jego używania. Ta praca może być niewielkim dodatkiem dla zespołu, który już obsługuje podobne systemy, albo istotną nową pozycją dla firmy bez takiej obsługi.

Przy krótkim, rzadko uruchamianym procesie przewaga innej jednostki rozliczeniowej może nie pokryć kosztu przeniesienia i utrzymania. Przy wielu elementach w pętli porównanie zmienia się szybciej: Zapier i Make mogą zużywać kolejne jednostki dla każdego elementu, podczas gdy n8n Cloud liczy egzekucje, a n8n Community wymaga odpowiedniej pojemności serwera. Do decyzji zakupowej najlepiej zestawić koszt ukończonego procesu przy zwykłym obciążeniu i przy spodziewanym wzroście liczby elementów oraz ponowień.

Przeczytaj także:

• ChatGPT czy Claude do kodowania? Wynik zależy od rodzaju zadania