n8n, nebo Make: levnější běh může znamenat vlastní server

U dlouhého a často spouštěného workflow může n8n snížit přímé náklady: podle ceníku n8n se v cloudu platí za celé spuštění bez ohledu na počet kroků a Community Edition lze provozovat na vlastním serveru. Právě vlastní instalace může vyjít levněji při vysokém objemu, jenže tým pak platí infrastrukturu a přebírá odpovědnost za její provoz.

Make je vhodná volba, pokud chce tým provoz přenechat poskytovateli a umí odhadnout počet provedených akcí. Ceník Make váže spotřebu kreditů na akce modulů scénáře, takže délka automatizace může měsíční účet změnit stejně výrazně jako počet jejích spuštění. Rozhodnutí proto stojí na ceně celého provozu, nikoli jen na nejnižším tarifu.

Jedno spuštění není stejná účtovací jednotka

V n8n Cloud znamená jedno spuštění jeden průchod celým workflow, i když obsahuje mnoho kroků. V Make se sčítají zpoplatněné akce provedené při běhu scénáře. Podle pravidel kreditů Make odpovídá u běžných aplikací jedna operace jednomu kreditu; některé funkce AI však počítají spotřebu také podle tokenů nebo jiných veličin.

Samotný počet modulů na plátně tedy není spolehlivou měsíční spotřebou. Rozhoduje, které moduly se skutečně provedou a kolikrát: při zpracování více položek se mohou navazující akce opakovat. Záleží také na tom, zda scénář při běhu projde všemi větvemi a zda obsahuje funkci se zvláštním způsobem účtování. Dva stejně dlouhé scénáře tak mohou spotřebovat různý počet kreditů.

Krátký a dlouhý scénář při čtyřech objemech

Následující podmíněný přepočet používá záměrně jednoduché zadání: krátký scénář provede při každém běhu tři zpoplatněné akce, dlouhý dvacet. Každá stojí jeden kredit a žádná se neopakuje pro další položky. Předpoklad ukazuje rozdíl mezi účtovacími jednotkami; neurčuje cenu tarifu ani výkon serveru potřebný pro konkrétní automatizaci.

• Při 1 000 bězích za měsíc spotřebuje krátký scénář v Make 3 000 kreditů a dlouhý 20 000 kreditů. V n8n Cloud jde v obou případech o 1 000 spuštění.
• Při 5 000 bězích vychází Make na 15 000, respektive 100 000 kreditů. n8n Cloud počítá v obou variantách 5 000 spuštění.
• Při 20 000 bězích představuje krátký scénář 60 000 kreditů a dlouhý 400 000 kreditů. Počet spuštění v n8n Cloud zůstává 20 000.
• Při 100 000 bězích je to v Make 300 000 nebo 2 000 000 kreditů podle délky scénáře. n8n Cloud eviduje 100 000 spuštění.

Dlouhý scénář spotřebuje v tomto modelu přibližně 6,7krát více kreditů než krátký, ačkoli počet jeho běhů je stejný. Jakmile jedna akce pracuje s více položkami nebo nastoupí účtování podle spotřeby AI, přepočet už neplatí beze změny. Počty v seznamu navíc vyjadřují spotřebu, nikoli výslednou fakturu: tu určí dostupný tarif, sjednaný objem a případné další náklady.

Levná infrastruktura ještě není levný provoz

U vlastní instalace n8n je potřeba oddělit software od serveru a práce správce. Community Edition nevyžaduje cloudový tarif n8n, ale její provoz potřebuje výpočetní kapacitu, úložiště a podle nasazení také databázi. Zátěž se přitom neřídí jen počtem spuštění: roli hraje délka běhu, velikost zpracovaných dat a souběh úloh. Nízká cena malého serveru proto sama neurčuje cenu spolehlivé instalace.

Cenový model WizardCost s cenami ověřenými v červenci 2026 uvádí při 100 000 měsíčních bězích 45 dolarů za infrastrukturu lehce zatíženého self-hostovaného n8n a 214,31 dolaru za Make. Počítá se třemi workflow a měsíční platbou; práci na provozu serveru výslovně vynechává. Částku za Make spojuje s tarifem pro 300 000 kreditů, takže ji nelze převzít jako cenu dvacetimodulového příkladu výše.

Rozdíl mezi uvedenými částkami činí 169,31 dolaru měsíčně. Pokud si tým podmíněně vyhradí čtyři hodiny měsíčně na dohled, aktualizace, zálohy a řešení potíží, rozdíl se vyčerpá při interní ceně práce přibližně 42,33 dolaru za hodinu. Při delší údržbě se tato hranice snižuje. Jde o rozpočet času pro rozhodnutí, nikoli o tvrzení, že každá instalace právě tolik práce vyžaduje.

Zálohy rozhodují o ceně výpadku

Vlastní server přenáší na provozovatele také obnovu po chybě a údržbu aplikace. Dokumentace n8n k obnově uvádí, že export workflow a přihlašovacích údajů sám nestačí k obnovení celé instance. Úplná záloha zahrnuje uživatelskou složku s šifrovacím klíčem, při použití externí databáze také její obsah a podle konfigurace další úložiště.

Bez původního šifrovacího klíče nelze z obnovené databáze přečíst uložené přihlašovací údaje. Pro rozpočet je proto podstatné, kdo zálohy pořizuje, kdo umí instanci obnovit a jak rychle musí automatizace po výpadku znovu běžet. Požadavek na vysokou dostupnost může znamenat více práce i dražší infrastrukturu, než předpokládá jednoduchý model lehce zatíženého serveru.

Kontrola dat mění odpovědnost

Self-hostované n8n umožňuje organizaci vybrat umístění vlastní instance a její databáze. To může rozhodovat tam, kde má tým pravidla pro uložení provozních dat nebo už spravuje vlastní systémy. Umístění instance ovšem neřídí služby, k nimž se workflow připojuje: pokud automatizace odesílá údaje do externí aplikace, je potřeba posuzovat i tok dat do této aplikace.

Pro krátký scénář s menším objemem může být cena správy vlastního serveru vyšší než úspora na účtovaných jednotkách. U dlouhého scénáře s častým spouštěním získává větší váhu počet akcí v Make a rozdíl mezi jeho kredity a celými běhy n8n Cloud. Vlastní n8n je finančně přesvědčivé tehdy, když úspora na službě pokryje infrastrukturu, pravidelnou péči i požadovanou dostupnost.

Přečtěte si také:

• Toggl, nebo Clockify: levnější tarif může zpoplatnit klíčový výkaz
• Lokální LLM, nebo cloud: levnější volbu mění vytížení
• Chatbot, nebo AI agent: autonomie znamená i nové riziko