Dział finansów otworzył kolejny rachunek za automatyzację, a zespół bezpieczeństwa w tym samym tygodniu zablokował scenariusz, który miał wysyłać dane klientów na zewnętrzne serwery. Właściciel procesu został z pytaniem, które brzmi prosto, a w praktyce rozbija się o licencję, architekturę i odpowiedzialność za dane: czy Make da się „przenieść na własny serwer”, czy jedyną realną drogą self-hostingu jest n8n. [1]
Chmura kontra własna infrastruktura: zderzenie założeń Make i n8n
Make i n8n rozwiązują podobny problem operacyjny: łączą aplikacje, odbierają webhooki, transformują rekordy i uruchamiają kolejne kroki bez ręcznego przeklejania danych. Różnica zaczyna się w miejscu, w którym te kroki się wykonują. Make jest przede wszystkim usługą SaaS. Scenariusze projektuje się w przeglądarce, a silnik wykonawczy, kolejki i magazyn logów należą do dostawcy. Własny serwer pojawia się w tej rozmowie dopiero na poziomie umowy enterprise, a nie jako standardowa ścieżka instalacji.
Mit o łatwym przeniesieniu Make na infrastrukturę firmy wynika zwykle z pomieszania trzech rzeczy: konta w chmurze, scenariusza wyeksportowanego jako schemat oraz produktu on-premises. Eksport scenariusza nie jest wdrożeniem silnika. Edycja przeznaczona do instalacji u klienta jest ofertą korporacyjną: osobna wycena, procedura weryfikacji, wymagania środowiskowe i wsparcie producenta. Dla małego zespołu, który chce postawić automatyzację obok własnego CRM-u, ta ścieżka bywa droższa i wolniejsza niż sam problem, który miała rozwiązać.
n8n od początku jest projektowane tak, aby dało się je uruchomić jako własną instancję, najczęściej w kontenerze. Edytor, silnik workflow i historia wykonań mogą działać na VPS, w klastrze Kubernetes albo na maszynie w sieci firmowej. To nie znaczy, że self-hosting jest „darmowy i bezobsługowy”. Oznacza, że kontrola nad kodem wykonawczym, bazą, kopiami zapasowymi i ruchem sieciowym zostaje po stronie organizacji, a nie jest dodatkiem sprzedawanym tylko największym klientom.
Realny dylemat nie brzmi więc „które narzędzie ma ładniejszy edytor”. Brzmi: czy zespół chce płacić za bezobsługową chmurę i akceptować, że dane przechodzą przez infrastrukturę dostawcy, czy jest gotów utrzymać własną instancję i w zamian dostać przewidywalny koszt przy dużym wolumenie oraz pełną kontrolę nad tym, dokąd te dane wychodzą. Make zostaje mocnym wyborem tam, gdzie priorytetem jest czas do pierwszego działającego scenariusza. n8n self-hosted wygrywa tam, gdzie priorytetem jest suwerenność danych i architektura, którą da się obronić przed audytem. [3]
Mini-wniosek jest prosty: jeśli „własny serwer” ma być warunkiem projektu, a nie hasłem w prezentacji, porównanie trzeba prowadzić między chmurą Make a self-hosted n8n, a nie między dwoma równie łatwymi instalatorami. [5]
Architektura techniczna i wymagania instalacyjne na własnym serwerze
Własna instancja automatyzacji to nie jest kolejna wtyczka do firmowego dysku. To usługa sieciowa, która przyjmuje webhooki, trzyma poświadczenia, wykonuje kod i zapisuje historię. Zanim ktokolwiek porówna liczbę gotowych integracji, trzeba wiedzieć, co faktycznie stanie na serwerze i kto będzie to podnosił po aktualizacji systemu.
Wdrożenie n8n w środowisku Docker i Docker Compose
Najczęstsza ścieżka produkcyjna dla n8n to oficjalny obraz kontenerowy i plik Docker Compose. Kontener aplikacji dostaje trwały wolumen na dane, zmienne środowiskowe z kluczem szyfrowania poświadczeń oraz publiczny adres webhooków wystawiony przez reverse proxy. TLS kończy się na Caddy, Traefik albo Nginx. Bez poprawnego WEBHOOK_URL część integracji wygląda na „podłączoną”, a w rzeczywistości zewnętrzne systemy wołają zły adres.
Sam Docker nie załatwia izolacji. Instancja powinna mieć osobnego użytkownika bazy, ograniczony egress tam, gdzie polityka sieci na to pozwala, oraz sekret trzymany poza repozytorium. Klucz szyfrowania poświadczeń trzeba zarchiwizować razem z procedurą odtwarzania. Utrata tego klucza przy działającej bazie oznacza, że zapisane tokeny API stają się nie do odczytania, nawet jeśli pliki workflow ocalały.
Aktualizacja obrazu to osobny rytuał, nie kliknięcie w panelu dostawcy. Sensowny układ to środowisko testowe z kopią workflow, okno aktualizacji i szybki rollback do poprzedniego tagu obrazu. n8n rozwija węzły dość szybko. Scenariusz, który działał na starszej wersji, po skoku o kilka wydań może wymagać poprawki mapowania pól. To nie jest wada kontenera. To koszt posiadania silnika, którego nie aktualizuje za was dostawca SaaS.
Parametry VPS: od lekkiego webhooka do stałego ruchu
Lekki start, kilka wewnętrznych scenariuszy i niewielki ruch webhooków, zwykle mieści się na maszynie z 2 vCPU i 2–4 GB RAM oraz dyskiem NVMe. To punkt wyjścia do testów i małego zespołu, nie obietnica wydajności. Gdy w workflow pojawiają się duże pliki, równoległe gałęzie i częste odpytywanie API, pamięć kończy się wcześniej niż procesor. Historia wykonań z pełnymi payloadami potrafi rozepchać dysk szybciej, niż sugeruje „mały” ruch biznesowy.
Dla stałego ruchu produkcyjnego rozsądniej zacząć od 2–4 vCPU i 4–8 GB RAM, z osobnym monitoringiem zużycia i limitem retencji wykonań. Ciężkie transformacje, generowanie PDF-ów albo równoległe pobieranie załączników wymagają już profilu dobranego do pomiaru, nie do tabelki z forum. Dysk ma być szybki i monitorowany. Padająca instancja przez zapełniony wolumen logów jest częstsza niż „za słaby procesor”.
Make w chmurze zdejmuje ten dobór z zespołu. Płacicie za model operacji i limity planu, a skalowanie silnika zostaje po stronie dostawcy. Na własnym serwerze ten komfort znika: musicie wiedzieć, czy wąskim gardłem jest CPU, baza, dysk, czy limit równoległych wykonań ustawiony w samej instancji.
SQLite na start, PostgreSQL tam, gdzie instancja ma przeżyć weekend
Domyślny SQLite upraszcza pierwszy start. Jedna instancja, mały zespół, rzadkie scenariusze, brak trybu kolejkowego: na tym etapie osobny serwer bazy bywa przerostem. Problem zaczyna się w momencie, gdy historia wykonań rośnie, a kilka procesów zapisuje stan jednocześnie. SQLite nie jest narzędziem do wieloprocesowego obciążenia produkcyjnego.
PostgreSQL staje się wyborem domyślnym, gdy instancja ma działać stale, przyjmować webhooki od systemów zewnętrznych albo pracować w trybie z workerami. Backup robi się narzędziem bazy, nie kopiowaniem pliku „w locie”. Przywracanie warto przećwiczyć, zanim pierwszy incydent pokaże, że kopia jest niepełna. n8n trzyma w bazie nie tylko definicje workflow, ale też dane wykonań. To często dane osobowe albo fragmenty dokumentów. Polityka retencji jest tu decyzją bezpieczeństwa, nie tylko kosmetyką panelu.
Tryb kolejkowy i Redis przy gęstych webhookach
Pojedynczy proces n8n obsługuje edytor i wykonania. Przy spokojnym ruchu to wystarcza. Gdy webhooki przychodzą seriami, a część scenariuszy czeka na wolne API, jeden proces staje się kolejką zatorów. Tryb kolejkowy rozdziela rolę główną od workerów i używa Redis jako brokera. Webhook może zostać przyjęty i oddany do kolejki, zamiast blokować cały edytor.
Ten układ ma sens przy większym natężeniu, nie przy trzech integracjach księgowych uruchamianych raz dziennie. Dokłada Redis, osobne kontenery workerów i konieczność zrozumienia, który proces padł. Zysk jest konkretny: awaria jednego workera nie musi zatrzymać przyjmowania nowych wywołań, a skalowanie idzie przez dokładanie workerów, nie przez „większy jeden kontener na wszystko”.
Bariera wejścia dla Make On-Premises
Make On-Premises nie jest lustrzanym odpowiednikiem docker compose up dla n8n Community. To wdrożenie klasy enterprise: rozmowa handlowa, wymagania producenta, architektura uzgodniona z działem IT i koszt, który dla małego oraz średniego zespołu zwykle wypada poza budżet samej automatyzacji. Publiczna dokumentacja społecznościowa nie zastępuje tej ścieżki. Nie da się uczciwie porównać „darmowej instancji Make na VPS” z n8n, bo takiej równoległej, swobodnie stawianej edycji Make po prostu nie ma w modelu self-service. [2]
Dla organizacji, która już ma umowę enterprise, własny Make może być uzasadniony: znajomy edytor, istniejące scenariusze, wsparcie vendora i brak migracji. Dla zespołu, który dopiero wybiera narzędzie pod własny serwer, bariera jest inna niż krzywa uczenia edytora. To bariera zakupu, compliance i utrzymania produktu, którego nie kontrolujecie tak, jak obrazu kontenerowego.
Mini-wniosek: jeśli nie macie procesu na backup bazy, aktualizację obrazu i monitoring dysku, self-hosting n8n będzie tańszy na fakturze i droższy w awariach. Make w chmurze kupuje właśnie ten brakujący proces.
Finanse bez złudzeń: koszt operacji w chmurze a koszt utrzymania serwera
Porównanie „abonament kontra VPS” psuje się w pierwszym miesiącu, jeśli liczy się tylko cenę wejścia. Make sprzedaje wykonane operacje i wygodę. n8n Community nie wystawia rachunku za każdy obrót pętli, ale serwer, kopie, czas człowieka i ryzyko przestoju mają właściciela. Ten właściciel musi być nazwany, zanim ktoś ogłosi oszczędność.
Jak pętla w Make zamienia się w rachunek
W Make operacją bywa nie cały scenariusz, lecz pojedynczy moduł wykonany na pojedynczym elemencie. Pętla po 2 000 rekordów, w której każdy rekord przechodzi przez pobranie, mapowanie, filtr i zapis, potrafi zmultiplikować zużycie planu, nawet jeśli „biznesowo” był to jeden nocny import. Scenariusze z routerami, ponowieniami i webhookami zwrotnymi dokładają kolejne jednostki. Zespół, który projektował przepływ jak diagram, a nie jak licznik, dostaje fakturę zaskakująco odległą od liczby procesów biznesowych.
Da się to ograniczać: agregacja rekordów, rzadsze harmonogramy, filtry przed drogimi modułami, przeniesienie ciężkiej transformacji bliżej źródła danych. To są dobre praktyki także poza Make. Nie zmieniają jednak modelu: przy rosnącym wolumenie koszt rośnie schodkowo albo liniowo, zależnie od cennika planu. Aktualne progi trzeba czytać w ofercie dostawcy, bo zmieniają się niezależnie od architektury waszego procesu.
Co naprawdę kosztuje n8n Community na własnym serwerze
Kod n8n w edycji community można uruchomić bez opłaty licencyjnej za sam silnik. To nie jest klasyczna licencja open source w rozumieniu OSI. Obowiązuje licencja fair-code z ograniczeniami, między innymi co do oferowania n8n jako hostowanej usługi dla osób trzecich. Wewnętrzne użycie w firmie na własnej instancji jest typowym przypadkiem self-hostingu. Funkcje enterprise, SSO w wyższym wariancie, niektóre mechanizmy zarządzania i wsparcie producenta są osobną rozmową handlową, nie dodatkiem do obrazu Docker.
Rachunek infrastruktury jest skromny tylko na papierze startowym. VPS, dysk na kopie, ewentualnie zarządzana baza PostgreSQL, monitoring i adres pod webhooki to pozycje miesięczne. Do tego dochodzi czas: ktoś musi wgrać aktualizację, sprawdzić certyfikat, odtworzyć backup i wyjaśnić, czemu kolejka stoi. Przy jednym zespole i kilku workflow ten czas bywa mniejszy niż różnica między planami Make. Przy krytycznym procesie księgowym ten sam czas staje się dyżurem.
Ukryty koszt administracyjny
Chmura Make w cenie planu zawiera dostępność silnika, łatki platformy i skalowanie, na które nie macie wpływu, ale też nie musicie go pilnować. Własna instancja przenosi ten pakiet na was. Nie potrzeba od razu etatu DevOps, jeśli automatyzacja nie jest ścieżką krytyczną. Potrzebna jest jednak konkretna osoba z uprawnieniami do serwera, procedurą aktualizacji i numerem telefonu, gdy webhook płatności przestanie odpowiadać w piątek wieczorem. [4]
Warto rozdzielić trzy klasy procesów. Pierwsza to powiadomienia i wewnętrzne porządki: krótki przestój jest irytujący, nie jest stratą. Druga to operacje klientów, gdzie godzina ciszy oznacza zaległe zamówienia. Trzecia to dane wrażliwe, gdzie błąd konfiguracji jest incydentem, nie „drobnym bugiem integracji”. Im bliżej drugiej i trzeciej klasy, tym bardziej koszt administracyjny trzeba wpisać do porównania, a nie traktować jako szczegół po zakupie VPS.
Warto przeczytać również powiązany artykuł: Jakie języki programowania są najczęściej wykorzystywane w automatyzacji?.
Gdzie wolumen przechyla szalę
Nie ma jednej liczby rekordów, od której n8n „zawsze się opłaca”. Jest punkt, który da się policzyć na waszym ruchu. Bierzcie rzeczywisty scenariusz: ile elementów wchodzi, ile modułów dotyka każdego elementu, ile razy dziennie to się powtarza, jaki plan Make to pokrywa i jaki zapas zostaje na wzrost. Obok stawiacie roczny koszt VPS, kopii, czasu aktualizacji i akceptowalny przestój. Jeśli licznik operacji rośnie szybciej niż wartość procesu, a dane i tak nie mogą iść do chmury, własna instancja przestaje być ideologią, a staje się rachunkiem.
Odwrotny próg też istnieje. Zespół bez osoby technicznej, z kilkunastoma prostymi scenariuszami i danymi, które wolno przetwarzać u procesora w chmurze, często przepłaci „oszczędność” na n8n w postaci niedokończonej instalacji. Make zostaje wtedy tańszy, mimo że cennik za operacje wygląda drożej na slajdzie.
| Składnik decyzji | Make w chmurze | n8n na własnym serwerze |
|---|---|---|
| Jednostka kosztu | Plan i zużyte operacje, rosnące przy pętlach | Serwer, backup, czas utrzymania, ewentualna licencja enterprise |
| Start bez zespołu IT | Krótki, konto i edytor | Wymaga Docker, proxy, bazy i procedur |
| Dane wrażliwe | Przetwarzanie u dostawcy, umowa i region | Dane zostają w waszej sieci, jeśli integracje też tak zaprojektujecie |
| Skala przy dużym wolumenie | Wyższy plan albo optymalizacja scenariuszy | Większa maszyna, PostgreSQL, kolejka i workerzy |
Możliwości techniczne i elastyczność: praca z kodem, danymi i API
Na własnym serwerze elastyczność nie polega na tym, że „można wszystko”. Polega na tym, że limity da się świadomie ustawić, a nietypowe API nie musi czekać na gotową wtyczkę. Jednocześnie swoboda kodu bez standardu w zespole kończy się scenariuszami, których nikt nie chce dotykać po odejściu autora.
Gotowe węzły kontra swoboda w pisaniu skryptów
Make jest mocne tam, gdzie proces da się złożyć z gotowych modułów, a osoba prowadząca scenariusz myśli diagramem, nie repozytorium. Wizualny edytor, routery, obsługa błędów na poziomie modułu i duży katalog integracji skracają drogę od pomysłu do działania. Dla działu operacji, który ma dostęp do API, ale nie utrzymuje kodu, to często decydująca przewaga. Mniej kodu własnego oznacza mniej miejsc, w których „działa tylko u autora”.
n8n idzie w drugą stronę, gdy gotowy węzeł nie pokrywa kontraktu API albo gdy transformacja danych jest zbyt krzywa na sam mapper. Węzeł Code pozwala napisać krótki fragment w JavaScript albo Pythonie, przejść po elementach, złożyć niestandardowy payload i oddać czysty obiekt do kolejnego kroku. Na własnej instancji ten kod wykonuje się u was, z waszymi limitami pamięci i z waszą wersją środowiska, a nie w piaskownicy planu chmurowego. To wygoda przy nietypowym podpisie żądania, paginacji, którą producent API opisał połowicznie, albo przy składaniu jednego rekordu z trzech źródeł, zanim cokolwiek wyjdzie na zewnątrz.
Swoboda ma cenę czytelności. Scenariusz, w którym połowa logiki siedzi w jednym długim skrypcie, przestaje być diagramem i staje się aplikacją bez recenzji. Sensowny podział jest prosty: węzły gotowe do autoryzacji, pobrania i zapisu, a kod tylko tam, gdzie mapper naprawdę nie daje rady. Krótki komentarz przy węźle, nazwa opisująca wejście i wyjście oraz przykładowy payload w notatce workflow oszczędzają więcej czasu niż „elegancki” skrypt na sto linii.
Dane wykonania, wyrażenia i granica pamięci
Przy self-hostingu łatwo zapomnieć, że każde wykonanie zostawia ślad. n8n domyślnie potrafi trzymać dane wejściowe i wyjściowe węzłów, co przy imporcie faktur albo załączników szybko zapełnia dysk i bazę. Zanim włączycie nocny przebieg po tysiącach rekordów, ustawcie retencję wykonań i zdecydujcie, czy w logu ma zostać cały dokument, czy tylko identyfikator i status. To ta sama decyzja, co backup: dane osobowe w historii wykonań są nadal danymi osobowymi.
Wyrażenia w n8n i mapowanie pól w Make rozwiązują podobny problem, ale inaczej się psują. W Make błąd typu „puste pole w co dziesiątym rekordzie” widać na konkretnym module i da się go złapać routerem błędów. W n8n to samo puste pole potrafi wywrócić wyrażenie w środku długiego łańcucha, a komunikat wskazuje węzeł, nie biznesowy powód. Praktyczny nawyk jest jeden: walidujcie obowiązkowe pola na początku przepływu i odkładajcie braki do osobnej gałęzi, zamiast liczyć, że ostatni zapis „jakoś przyjmie null”.
Na własnym serwerze limity nie znikają, tylko zmieniają właściciela. Zbyt duży plik w pamięci procesu, równoległe wykonania tego samego workflow i brak limitu współbieżności kończą się restartem kontenera, nie komunikatem o wyczerpanym planie. Przy imporcie plików lepiej streamować albo dzielić paczki, niż wczytywać cały zrzut do jednego elementu „bo na VPS jest 8 GB RAM”.
API, webhooki i własne integracje
Oba narzędzia żyją z HTTP. Różnica wychodzi przy integracji, której nie ma w katalogu. W Make sięgacie po moduł HTTP, nagłówki i obsługę paginacji w ramach scenariusza. Działa to dobrze, dopóki autoryzacja jest standardowa, a odpowiedź da się zmapować bez własnego parsera. W n8n ten sam brak wtyczki zamykacie węzłem HTTP Request, a powtarzalny klient API możecie wynieść do węzła społecznościowego albo do małej funkcji w Code. Na własnej instancji da się też dołożyć nagłówki sieciowe po stronie reverse proxy: allowlistę adresów źródłowych webhooka, limit żądań i odcięcie ścieżek, które nie powinny być publiczne.
Webhook to nie jest „darmowy trigger”. W chmurze Make dostajecie adres i nie martwicie się certyfikatem. Na serwerze adres musi wskazywać na działające proxy, a system zewnętrzny nie może czekać w nieskończoność, aż worker wstanie po aktualizacji. Dobrą praktyką jest przyjmować wywołanie, zapisać identyfikator zdarzenia i odesłać szybką odpowiedź, a ciężką pracę oddać do kolejki. Dzięki temu dostawca płatności nie ponawia żądania tylko dlatego, że wasze API księgowe miało pięć sekund zwłoki.
Własne węzły społecznościowe skracają powtarzalne integracje, ale wprowadzają zależność od paczki, której nie utrzymuje zespół n8n w tym samym rytmie co rdzeń. Przed wrzuceniem takiej paczki na instancję produkcyjną warto sprawdzić, kiedy była aktualizowana, jakie uprawnienia dostaje i czy da się ją zastąpić zwykłym HTTP, gdy autor zniknie. Make w modelu chmurowym zdejmuje z was ten wybór: katalog jest vendora, a niestandardowość kończy się na module HTTP i ewentualnym wsparciu w planie.
Mini-wniosek praktyczny: jeśli 80 procent przepływów to znane aplikacje i diagram bez kodu, Make zostaje narzędziem operacji. Jeśli regularnie składacie niestandardowe API, trzymacie dane wykonania u siebie i potrzebujecie kolejkowania webhooków, n8n na serwerze oddaje kontrolę, której chmura z definicji nie sprzeda.
Bezpieczeństwo, RODO i pełna suwerenność nad wrażliwymi procesami
Suwerenność nie zaczyna się od hasła „mamy własny serwer”. Zaczyna się od listy systemów, przez które i tak przechodzi treść: poczta, CRM, model językowy, bramka płatności. n8n na VPS nie cofnie wysłania PESEL-u do zewnętrznego API. Odbiera za to konieczność oddawania całego przebiegu, historii wykonań i poświadczeń platformie automatyzacji, której region i podprocesorzy są poza waszą siecią.
Gdzie naprawdę leżą dane
W Make w chmurze scenariusz, poświadczenia i treść operacji przetwarzane są u dostawcy. Da się to uregulować umową, regionem i oceną podprocesorów, i dla wielu firm to wystarcza. Nie wystarcza tam, gdzie polityka bezpieczeństwa mówi wprost: treść zgłoszeń klientów, dokumentacja medyczna albo dane płacowe nie opuszczają wskazanego środowiska. Wtedy nawet „europejski region” bywa za mało precyzyjny, bo liczy się konkretny procesor i konkretna ścieżka logów.
Self-hosted n8n przenosi silnik do waszej sieci, ale poświadczenia nadal są sekretem o wysokiej wartości. Trzymanie ich w zmiennych środowiskowych kontenera, w menedżerze sekretów albo w zaszyfrowanej bazie to trzy różne poziomy. Wspólne konto „admin” do edytora, bez osobnych ról, oznacza, że każda osoba z dostępem do automatyzacji widzi tokeny do systemów, do których biznesowo nie powinna mieć wstępu. Przy danych osobowych włączcie retencję, ograniczcie logowanie pełnych payloadów i nie zostawiajcie produkcyjnych wykonań na instancji testowej skopiowanej „na szybko”.
RODO bez magicznego skrótu
Własny serwer nie zastępuje podstawy prawnej, informacji dla osób ani umowy powierzenia z tymi dostawcami, których workflow i tak woła. Zastępuje jeden element: procesora w postaci chmurowej platformy automatyzacji. Dla administratora danych to często różnica między jedną oceną dostawcy a projektem, w którym silnik stoi u was, a powierzenie dotyczy tylko systemów źródłowych.
Praktyczny test jest krótki. Wypiszcie pola, które wchodzą do automatyzacji: imię, e-mail, numer sprawy, treść umowy, skan dowodu. Przy każdym polu zaznaczcie, czy musi przejść przez narzędzie, czy wystarczy identyfikator. Potem zaznaczcie, które węzły wysyłają to pole poza waszą sieć. Jeśli skan dowodu idzie do chmurowego OCR „bo tak było szybciej w szablonie”, suwerenność instancji jest pozorna. Lepiej zanonimizować albo obciąć dokument przed wywołaniem, a do n8n wpuszczać tylko wynik, który naprawdę jest potrzebny do decyzji.
Make On-Premises, tam gdzie organizacja już go kupuje, zamyka podobną lukę po stronie znanego edytora: silnik nie jest publiczną chmurą, wsparcie i architektura są uzgodnione z IT. Dla zespołu bez takiej umowy n8n Community pozostaje drogą do trzymania silnika u siebie, pod warunkiem że backup, aktualizacje i dostęp do edytora są opisane tak samo poważnie jak sam przepływ.
Dostęp, aktualizacje i granica zaufania
Edytor automatyzacji to panel administracyjny procesów. Wystawianie go na cały internet „żeby było wygodnie z domu” jest częstszą przyczyną incydentu niż sama licencja narzędzia. Sensowny układ to dostęp przez VPN albo sieć wewnętrzną, konto na osobę, wyłączone współdzielone hasło i osobna instancja testowa. Webhooki mogą być publiczne. Edytor nie musi.
Aktualizacja obrazu n8n to łatka zależności, nie kosmetyka. Odkładanie jej miesiącami dlatego, że „workflow działa”, zostawia znaną powierzchnię ataku na hoście, na którym leżą tokeny do banku i CRM. Z drugiej strony aktualizacja w piątek na produkcji, bez kopii bazy i bez sprawdzenia na kopii przepływu, jest równie złą praktyką. Okno serwisowe, kopia przed wgraniem i krótki scenariusz kontrolny po starcie wystarczają małemu zespołowi, o ile ktoś jest właścicielem tego rytuału.
Make w chmurze oddaje tę granicę vendorowi: łatki platformy nie są waszym kalendarzem, ale też nie kontrolujecie, kiedy i jak zmienia się środowisko wykonania. Dla procesów o niskiej wrażliwości to ulga. Dla procesów, przy których audyt pyta, kto miał dostęp do treści w danym dniu i gdzie stał dziennik, własna instancja daje odpowiedź tylko wtedy, gdy logi i kopie naprawdę istnieją.
Wybór na własny serwer jest więc wąski i konkretny. Jeśli dane nie mogą iść do chmurowej platformy automatyzacji, wolumen albo niestandardowe API uzasadniają utrzymanie, a w zespole jest osoba od backupu i aktualizacji, n8n Community jest narzędziem, które da się postawić i obronić. Jeśli priorytetem jest diagram bez kodu, krótki start i brak dyżuru przy hoście, Make w chmurze kupuje ten spokój w cenie operacji. Make na własnej infrastrukturze zostaje opcją enterprise, nie skrótem do tej samej decyzji.
Najważniejsze wnioski
- Make jest przede wszystkim usługą SaaS, a jego wariant on-premises należy do oferty enterprise, z osobną wyceną i wymaganiami wdrożeniowymi.
- n8n można uruchomić na własnym serwerze, najczęściej przy użyciu Docker Compose, z samodzielnym zarządzaniem bazą, kopiami zapasowymi, bezpieczeństwem i aktualizacjami.
- Self-hosting n8n daje większą kontrolę nad danymi i ruchem sieciowym, ale wymaga monitoringu, retencji danych, procedur odtwarzania oraz odpowiedzialności za awarie.
- SQLite wystarcza na początek przy małej instancji, natomiast PostgreSQL jest rozsądniejszym wyborem dla stałego ruchu, webhooków i pracy z workerami.
- Tryb kolejkowy n8n z Redisem może pomóc przy większej liczbie webhooków i równoległych wykonań, ale zwiększa złożoność infrastruktury.
- Wybór powinien uwzględniać nie tylko cenę planu lub VPS-a, lecz także koszt operacji, czasu administracji, backupu, bezpieczeństwa i ryzyka przestoju.
Pytania od czytelników
Czy do małego wdrożenia n8n potrzebuję od razu PostgreSQL i Redisa?
Co trzeba zabezpieczyć przed uruchomieniem n8n na VPS?
Czy eksport scenariusza z Make pozwala uruchomić go na własnym serwerze?
Jak ocenić, czy VPS ma wystarczające zasoby dla n8n?
