Alternatywy dla n8n: porównanie narzędzi self-hosted

Co wybrać zamiast n8n

Alternatywy dla n8n z możliwością hostowania we własnym zakresie, które warto rozważyć na VPS (virtual private server), to Activepieces, Windmill, Node-RED, Automatisch oraz Huginn. Activepieces jest rozwiązaniem najbardziej zbliżonym do sposobu, w jaki większość użytkowników korzysta z n8n, a jego rdzeń jest udostępniony na licencji MIT. Windmill sprawdzi się w zespołach, które preferują pisanie kodu w Python lub TypeScript zamiast łączenia bloków na kanwie. Node-RED jest rozwiązaniem lekkim i nie wymaga żadnej bazy danych.

Wielu użytkowników powinno pozostać przy obecnym rozwiązaniu. Licencja n8n zezwala na wewnętrzne wykorzystanie biznesowe, więc jeśli automatyzacje obsługują własną firmę, licencja nie stanowi problemu. Migracja również nie jest darmowa. Żadne z wymienionych narzędzi nie obsługuje importu eksportów z n8n, co oznacza konieczność ręcznego odtworzenia każdego przepływu i ponownego wprowadzenia wszystkich danych uwierzytelniających. Instalacja samego n8n to odrębne zadanie, opisane w instalacji n8n na VPS z Docker i HTTPS, natomiast n8n w porównaniu z Zapier i Make omawia zestawienie tej kategorii narzędzi z usługami typu hosted.

Dlaczego użytkownicy szukają alternatyw dla self-hosted n8n

Często pojawiają się dwa główne powody.

Pierwszym jest licencja. n8n jest wydawany na podstawie Sustainable Use License v1.0, którą projekt określa mianem fair-code, a nie open source. Licencja przyznaje prawo do „używania lub modyfikowania oprogramowania wyłącznie na własne wewnętrzne potrzeby biznesowe lub do użytku niekomercyjnego bądź osobistego” i zabrania komercyjnego udostępniania oprogramowania innym osobom. Pliki i foldery z .ee w nazwie podlegają odrębnej licencji n8n Enterprise License. Jeśli planowane jest uruchamianie automatyzacji w imieniu płacących klientów, stanowi to istotną przeszkodę. W przypadku wewnętrznych zespołów operacyjnych sytuacja ta nie zmienia codziennej pracy.

Drugim powodem jest zużycie pamięci. n8n to proces Node.js, a dane przepływu pracy znajdują się w pamięci operacyjnej podczas jego wykonywania. Dokumentacja n8n wskazuje przyczyny: ilość danych JSON, rozmiar danych binarnych, liczbę węzłów w przepływie, węzeł Code, ręczne uruchomienia (które ponownie kopiują dane dla edytora) oraz inne przepływy działające w tym samym czasie. Udokumentowanym rozwiązaniem nie jest zmiana produktu. Jest nim tryb kolejkowy (queue mode) z oddzielnymi procesami roboczymi (worker processes) oraz wykorzystanie Postgres zamiast domyślnego pliku SQLite w ~/.n8n/database.sqlite. W przypadku dużych zadań zaleca się również przetwarzanie wsadowe, ponieważ węzeł Loop Over Items przekazujący dane do podprocesu utrzymuje w pamięci tylko jeden fragment danych jednocześnie. Warto wypróbować to rozwiązanie przed przebudową sześćdziesięciu przepływów w innym systemie.

Które alternatywy n8n z własnym hostingiem są nadal utrzymywane

Tekst licencji jest czytelny, dlatego każdy porównuje licencje. Łatwo pominąć stan zdrowia projektu. Oto 6 projektów w tym zestawieniu, wraz z datą najnowszego wydania oznaczonego tagiem na dzień 4 sierpnia 2026.

[
  {
    "tool": "n8n",
    "licence": "Sustainable Use License",
    "latest_release": "2.33.3",
    "released": "2026-07-31",
    "days_since_release": 4
  },
  {
    "tool": "Activepieces",
    "licence": "MIT core, commercial ee",
    "latest_release": "0.86.3",
    "released": "2026-07-17",
    "days_since_release": 18
  },
  {
    "tool": "Windmill",
    "licence": "AGPLv3 source, CE image",
    "latest_release": "v1.778.0",
    "released": "2026-08-04",
    "days_since_release": 0
  },
  {
    "tool": "Node-RED",
    "licence": "Apache 2.0",
    "latest_release": "5.0.4",
    "released": "2026-07-30",
    "days_since_release": 5
  },
  {
    "tool": "Automatisch",
    "licence": "AGPL-3.0, commercial ee",
    "latest_release": "v0.15.0",
    "released": "2025-08-08",
    "days_since_release": 361
  },
  {
    "tool": "Huginn",
    "licence": "MIT",
    "latest_release": "v2022.08.18",
    "released": "2022-08-18",
    "days_since_release": 1447
  }
]

Dwa wiersze zmieniają krótką listę. Automatisch ostatnio oznaczyło tagiem v0.15.0, co oznacza, że wydanie ma 361 dni, a jego domyślna gałąź nie otrzymała żadnego commita od 15 stycznia 2026. Huginn ostatnio oznaczył wydanie 1447 dni temu, jednak jego dziennik commitów jest aktywny w tym miesiącu. To odwrotny wzorzec: kod się zmienia, a wydania nie, więc uruchomienie go oznacza korzystanie z obrazu bez tagu.

Sprawdź to samodzielnie, zanim zaufasz jakiemukolwiek porównaniu, w tym temu. Otwórz stronę wydań projektu w serwisie GitHub, a następnie listę commitów dla jego domyślnej gałęzi. Projekt ze świeżym wydaniem i cichym dziennikiem commitów wyhamowuje. Projekt ze świeżymi commitami i brakiem wydań od lat wymaga uruchomienia kodu, dla którego nikt nie przygotował wersji.

Activepieces: najbliższy odpowiednik z rdzeniem na licencji MIT

Activepieces stanowi bezpośredni odpowiednik. Jest to wizualny kreator wykorzystujący wyzwalacze i kroki, określane jako pieces, których według pliku README jest ponad 280. Każdy element jest również udostępniany jako serwer MCP (model context protocol), dzięki czemu klient LLM (large language model) może wywoływać te same konektory jako narzędzia. Rdzeń oprogramowania jest objęty licencją MIT. Dwa katalogi, packages/ee/ oraz packages/server/api/src/app/ee, podlegają licencji komercyjnej, a korzystanie z ich zawartości na własnym serwerze wymaga płatnej umowy.

Przed migracją należy zapoznać się z tym podziałem, ponieważ jest on szerszy niż w większości projektów na licencji MIT. Strona z cennikiem Activepieces opisuje Community Edition jako „open source, darmową na zawsze, bez limitów uruchomień, użytkowników czy przepływów” (flows), wyłączając z niej funkcje Agents and Chat, Projects, dostęp do API oraz całą warstwę administracyjną (single sign-on, role użytkowników, dzienniki audytu, menedżery sekretów, branding, synchronizacja z Git). W rezultacie Community Edition to kompletny silnik automatyzacji z nieograniczoną liczbą przepływów i użytkowników, który nie jest platformą sterowalną przez API. Jeśli plan zakładał programowe generowanie przepływów, wymaga to posiadania licencji.

Struktura środowiska uruchomieniowego składa się z jednego kontenera aplikacji, jednego lub większej liczby kontenerów roboczych (worker), bazy Postgres oraz Redis. AP_DB_TYPE=POSTGRES i AP_REDIS_TYPE=STANDALONE są wartościami domyślnymi. Dostępny jest tryb jednokontenerowy z wbudowaną bazą danych i kolejką wewnątrzprocesową (AP_DB_TYPE=PGLITE z AP_REDIS_TYPE=MEMORY), jednak dokumentacja wskazuje, że „jest on przeznaczony wyłącznie do użytku osobistego lub testów”. Należy traktować to zastrzeżenie dosłownie. Tryby te nie pozwalają na uruchomienie więcej niż jednej instancji, więc przejście na wyższy poziom wymaga migracji, a nie tylko zmiany flagi.

Windmill: podejście "code first" i większe wymagania zasobowe

Windmill uruchamia skrypty w językach Python, TypeScript, Go, Bash oraz SQL, a następnie łączy je w przepływy pracy. Jeśli automatyzacje opierają się głównie na kodzie, a nie na wizualnym łączeniu węzłów, rozwiązanie to sprawdza się lepiej niż jakikolwiek edytor graficzny.

Kwestia licencji wymaga uwagi. Kod źródłowy jest objęty licencją AGPLv3, o ile kompilacja odbywa się bez flagi funkcji enterprise. Obrazy publikowane pod ghcr.io/windmill-labs/windmill to wersja Community Edition, która zawiera kod niebędący oprogramowaniem open source, dostępny bezpłatnie w ramach określonych limitów. Strona z cennikiem Windmill określa te limity na 50 użytkowników, 3 obszary robocze (workspaces) oraz 10 GiB pamięci na obiekty w obszarze roboczym, przy nieograniczonej liczbie wykonań. Dla jednej osoby lub małego zespołu te limity są bardzo wysokie, więc kwestia kwot nie jest problemem praktycznym. Istotne jest natomiast to, że uruchamiany plik binarny nie jest kompilacją AGPL.

Kolejnym czynnikiem jest waga rozwiązania. Domyślny plik docker-compose.yml Windmill zawiera bazę danych Postgres 16, jeden serwer, trzy domyślne procesy robocze (workers) z limitem pamięci 2048M każdy, proces roboczy typu native oraz proxy Caddy. Dokumentowana zasada mówi o "1 procesie roboczym na 1 vCPU oraz 1-2 GB pamięci RAM". Na małym serwerze można ograniczyć liczbę replik. Należy jednak pamiętać, że to procesy robocze odpowiadają za faktyczne wykonywanie zadań.

Funkcje AI w Windmill są udokumentowane jako pomoc przy tworzeniu kodu: generowanie kodu, budowanie przepływów, czat oraz wypełnianie formularzy. Wymagają one wcześniejszego dodania zasobu dostawcy modelu w ustawieniach obszaru roboczego. Jeśli celem jest stworzenie agenta działającego według harmonogramu i wywołującego narzędzia, węzeł AI Agent w n8n pozostaje bardziej bezpośrednim rozwiązaniem, a budowanie agenta AI w n8n opisuje ten proces.

Node-RED: wariant lekki, bez bazy danych

Node-RED jest udostępniany na licencji Apache 2.0, najbardziej liberalnej w tym zestawieniu. Jest to pojedynczy proces Node.js z wolumenem /data. Brak Postgres. Brak Redis. Należy przypiąć wersję nodered/node-red:5.0.4, która jest aktualnym wydaniem.

Narzędzie wywodzi się z łączenia urządzeń IoT (Internet of Things), dlatego jego struktura opiera się na zdarzeniach, a nie na konektorach. Węzły dla usług zewnętrznych pochodzą z biblioteki społecznościowej i charakteryzują się zróżnicowaną jakością, co jest kompromisem za niewielkie zapotrzebowanie na zasoby. Brak tu natywnego kroku dla agenta AI. W przypadku małego serwera VPS obsługującego webhooki i ruch z kolejek komunikatów, jest to najlżejsze działające rozwiązanie, które uruchamia się w kilka sekund.

Huginn i Automatisch: najpierw sprawdź logi commitów

Huginn jest udostępniany na licencji MIT, napisany w Ruby on Rails i wymaga bazy danych MySQL lub PostgreSQL. Opiera się na modelu agentów, którzy monitorują źródło i generują zdarzenia, co różni się od modelu opartego na kanwie przepływów (flow canvas) i nie posiada wbudowanej obsługi LLM. Kod projektu jest nadal rozwijany, jednak ostatnie wydanie z tagiem pochodzi z sierpnia 2022 roku, więc uruchomienie go oznacza korzystanie z obrazu ghcr.io/huginn/huginn zbudowanego z domyślnej gałęzi. Wybierz to rozwiązanie, gdy model agentów pasuje do Twojego problemu, a nie jako ogólny zamiennik n8n.

Automatisch jest udostępniany na licencji AGPL-3.0, z wyłączeniem plików .ee, i wygląda na prostszą wersję n8n: wymaga PostgreSQL, Redis oraz posiada niewielki katalog aplikacji. Jest to narzędzie często polecane w poradnikach dotyczących pojedynczych wdrożeń. Historia wydań sugeruje wstrzemięźliwość. Rok bez wydania i pół roku bez commitu nie jest powodem do paniki, jeśli już korzystasz z tego narzędzia, ale stanowi powód, by nie rozpoczynać na nim nowego wdrożenia produkcyjnego.

Rzeczywiste zapotrzebowanie stosu Activepieces na pamięć RAM

Pomiar zużycia pamięci w stanie spoczynku i podczas pracy nie jest wartością, którą można jednoznacznie określić, ponieważ zależy ona od własnych przepływów (flows) oraz ilości przetwarzanych przez nie danych. Można natomiast przyjąć założenia budżetowe sugerowane przez dostawcę. Activepieces dokumentuje poniższą strukturę, przy czym zdanie obok niej jest ważniejsze niż same liczby: „Worker z obsługą jednego zadania jednocześnie (concurrency-1) jest zajęty przez cały czas trwania przepływu (do 10 minut), dlatego należy planować zasoby w oparciu o liczbę równoległych przepływów, a nie częstotliwość wyzwalania”.

[
  {
    "label": "App container",
    "vcpu": 1,
    "ram_gb": 1
  },
  {
    "label": "Worker (each)",
    "vcpu": 0.5,
    "ram_gb": 1
  },
  {
    "label": "Postgres",
    "vcpu": 2,
    "ram_gb": 4
  },
  {
    "label": "Redis",
    "vcpu": 1,
    "ram_gb": 1
  }
]

Jeden worker wymaga 0.5 vCPU oraz 1 GB pamięci RAM i obsługuje dokładnie jeden przepływ w danym momencie. Dla bazy Postgres należy zarezerwować 4 GB. Plik compose dostarczony w projekcie zawiera pięć replik workerów, co oznacza, że zgodnie z tą specyfikacją stos w repozytorium wymaga około 11 GB pamięci, zanim uruchomione zostaną jakiekolwiek przepływy. Poradniki dotyczące pojedynczych narzędzi często kopiują ten plik, nazywając taką konfigurację małym wdrożeniem.

Na serwerze VPS z 4 GB pamięci RAM należy uruchomić dwa workery, pozostawić Postgres w tym samym projekcie compose i przeprowadzić pomiary. Polecenie docker stats --no-stream wyświetla po jednej linii dla każdego kontenera z informacją o rzeczywistej pamięci rezydentnej, co jest bardziej wiarygodne niż jakakolwiek wartość podana przez dostawcę czy w blogu. Jeśli kontener wykazuje niekontrolowany wzrost zużycia pamięci, należy nałożyć na niego limity, a limity pamięci w Docker Compose przedstawiają odpowiednią składnię.

Plik compose dla Activepieces na jednym VPS

Przypnij tag. latest oznacza, że następna wersja docker compose pull może bez ostrzeżenia zmienić schemat bazy danych. Wersja 0.86.3 jest tą, którą projekt przypina we własnym pliku compose na dzień 4 sierpnia 2026.

Najpierw wygeneruj dwa sekrety, używając długości określonych w dokumentacji.

openssl rand -hex 16    # AP_ENCRYPTION_KEY, encrypts stored connections
openssl rand -hex 32    # AP_JWT_SECRET, signs session tokens

Zapisz .env obok pliku compose:

AP_ENGINE_EXECUTABLE_PATH=dist/packages/engine/main.js
AP_ENVIRONMENT=prod
AP_FRONTEND_URL=https://automation.example.com
AP_ENCRYPTION_KEY=REPLACE_WITH_HEX_16
AP_JWT_SECRET=REPLACE_WITH_HEX_32
AP_DB_TYPE=POSTGRES
AP_POSTGRES_DATABASE=activepieces
AP_POSTGRES_HOST=postgres
AP_POSTGRES_PORT=5432
AP_POSTGRES_USERNAME=postgres
AP_POSTGRES_PASSWORD=REPLACE_WITH_A_LONG_RANDOM_PASSWORD
AP_REDIS_TYPE=STANDALONE
AP_REDIS_HOST=redis
AP_REDIS_PORT=6379
AP_EXECUTION_MODE=UNSANDBOXED
AP_TELEMETRY_ENABLED=false

AP_FRONTEND_URL musi być publicznym adresem HTTPS, ponieważ w przeciwnym razie Activepieces podczas budowania adresów URL webhooków próbuje użyć publicznego adresu IP. Każdy webhook przekazywany stronie trzeciej jest budowany na podstawie tej wartości, więc jeśli nadal wskazuje ona na localhost, adres URL wklejony do innej usługi nigdy nie dotrze do serwera.

services:
  app:
    image: ghcr.io/activepieces/activepieces:0.86.3
    restart: unless-stopped
    ports:
      - '127.0.0.1:8080:80'
    depends_on:
      - postgres
      - redis
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=APP
    volumes:
      - ./cache:/usr/src/app/cache
  worker:
    image: ghcr.io/activepieces/activepieces:0.86.3
    restart: unless-stopped
    depends_on:
      - app
    env_file: .env
    environment:
      - AP_CONTAINER_TYPE=WORKER
    deploy:
      replicas: 2
    volumes:
      - ./cache:/usr/src/app/cache
  postgres:
    image: pgvector/pgvector:0.8.0-pg14
    restart: unless-stopped
    env_file: .env
    environment:
      - POSTGRES_DB=${AP_POSTGRES_DATABASE}
      - POSTGRES_USER=${AP_POSTGRES_USERNAME}
      - POSTGRES_PASSWORD=${AP_POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
  redis:
    image: redis:7.0.7
    restart: unless-stopped
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

Ten plik to oryginalny plik compose projektu z czterema zmianami: liczba workerów została zmniejszona z pięciu do dwóch, opublikowany port jest powiązany z 127.0.0.1 zamiast ze wszystkimi interfejsami, usunięto sztywne nazwy kontenerów, ponieważ usługa z replikami nie może ich używać, oraz usunięto jawny blok sieci, ponieważ compose tworzy go automatycznie.

docker compose up -d
docker compose ps

Każda usługa powinna wykazywać stan Up, w tym dwa kontenery worker. Kontener, który restartuje się w pętli, wypisuje przyczynę w docker compose logs worker, więc przeczytaj ją przed wprowadzeniem jakichkolwiek zmian. Powiązanie portu oznacza, że nic nie dotrze do aplikacji z zewnątrz, dopóki nie umieścisz przed nią reverse proxy z TLS (transport layer security), co opisano w uruchamianie Traefik przed kilkoma aplikacjami compose. Utrzymuj .env w trybie 600 i poza systemem git, zgodnie z obsługa sekretów w plikach env dla compose.

Kopia zapasowa, o której zapominają wszystkie poradniki

Wszystkie te narzędzia szyfrują przechowywane dane uwierzytelniające, więc sam zrzut bazy danych nie stanowi kopii zapasowej. Potrzebny jest zarówno zrzut, jak i klucz służący do jego odszyfrowania. Pułapka polega na tym, że większość tych narzędzi generuje klucz automatycznie w tle i przechowuje go w miejscu, które nie jest objęte kopią zapasową.

n8n jest najbardziej wyrazistym przykładem. Jeśli nie ustawisz N8N_ENCRYPTION_KEY, n8n „automatycznie tworzy losowy klucz szyfrujący przy pierwszym uruchomieniu i zapisuje go w folderze ~/.n8n”, a następnie używa tego klucza do szyfrowania danych uwierzytelniających przed ich zapisaniem w bazie danych. Jeśli wykonasz zrzut Postgres i przywrócisz go w nowym kontenerze z nowym wolumenem, przepływy pracy powrócą, ale wszystkie dane uwierzytelniające pozostaną nieczytelnym szyfrogramem. Ustaw zmienną jawnie i użyj tej samej wartości na każdym workerze w trybie queue mode.

Node-RED działa w ten sam sposób. Dane uwierzytelniające znajdują się w oddzielnym zaszyfrowanym pliku, a klucz to credentialSecret w settings.js. Jeśli go nie ustawisz, środowisko uruchomieniowe wygeneruje losowy klucz i zapisze go pod _credentialSecret wewnątrz własnego magazynu ustawień w /data. Standardowy plik ustawień ostrzega przed konsekwencjami: „po ustawieniu tej właściwości nie zmieniaj jej – zmiana uniemożliwi Node-RED odszyfrowanie istniejących danych uwierzytelniających, co doprowadzi do ich utraty”. Wykonuj kopię zapasową całego wolumenu /data, a nie tylko pliku z przepływami.

Activepieces przechowuje AP_ENCRYPTION_KEY w .env, co w dokumentacji opisano jako „32-znakowy (16-bajtowy) klucz szesnastkowy używany do szyfrowania połączeń”. Huginn przechowuje APP_SECRET_TOKEN w swoim środowisku. Automatisch posiada trzy takie klucze: ENCRYPTION_KEY, WEBHOOK_SECRET_KEY oraz APP_SECRET_KEY. W każdym przypadku sekret znajduje się w pliku środowiskowym, co oznacza, że plik ten musi być częścią kopii zapasowej.

Windmill jest wyjątkiem, o którym warto wiedzieć. Jego zmienne i sekrety są szyfrowane symetrycznym kluczem specyficznym dla obszaru roboczego, który Windmill przechowuje we własnej bazie danych, więc pojedynczy zrzut Postgres zawiera obie części. Jest to wygodne przy przywracaniu, ale oznacza również, że sam zrzut wystarczy do odczytania każdego sekretu, więc chroń ten plik tak, jakby był samymi sekretami.

Dla powyższego stosu Activepieces kopia zapasowa składa się z dwóch plików:

cd /srv/activepieces
docker compose exec -T postgres pg_dump -U postgres -Fc activepieces > "ap-$(date +%F).dump"
cp .env "ap-env-$(date +%F).bak"
chmod 600 ap-*.dump ap-env-*.bak

Następnie sprawdź, czy kopia działa, ponieważ nieprzetestowana kopia zapasowa to tylko przypuszczenie. Przywróć zrzut do tymczasowego projektu compose, który używa celowo innego AP_ENCRYPTION_KEY, a następnie uruchom przepływ korzystający z zapisanego połączenia. Operacja zakończy się niepowodzeniem, ponieważ szyfrogram w bazie danych został utworzony przy użyciu innego klucza. Powtórz przywracanie z właściwym kluczem z .env, a ten sam przepływ zadziała. Te dwie próby są jedynym dowodem na to, że Twoja kopia zapasowa jest faktycznie kopią. Wysyłaj oba pliki poza serwer zgodnie z harmonogramem, korzystając z kopii zapasowych restic z VPS, ponieważ kopia zapasowa na tym samym dysku zginie wraz z awarią dysku.

Kiedy pozostać przy n8n

Pozostań przy tym rozwiązaniu, jeśli praca ma charakter wewnętrzny w ramach Twojej firmy, ponieważ dokładnie na to pozwala licencja Sustainable Use License. Pozostań, jeśli polegasz na szerokim zakresie możliwości, gdyż n8n oferuje ponad 1500 integracji, lub jeśli korzystasz z węzła AI Agent opartego na LangChain, dla którego nie ma obecnie odpowiednika w postaci gotowych kroków agenta. Obsługa workflow w n8n za pomocą Claude pokazuje, jak wygląda to w praktyce.

Przejdź na Activepieces, jeśli wymagasz liberalnej licencji dla rdzenia automatyzacji oraz stosu technologicznego, który można w całości przeanalizować. Przejdź na Windmill, jeśli Twoje przepływy to w rzeczywistości kod ubrany w interfejs użytkownika. Przejdź na Node-RED, jeśli dysponujesz ograniczonymi zasobami sprzętowymi, a praca ma charakter zdarzeniowy. Nie zmieniaj narzędzia tylko dlatego, że benchmarki wskazują na duże zużycie zasobów przez n8n. Najpierw zmierz wydajność własnej instancji, następnie przeczytaj co warto hostować samodzielnie w 2026 roku i podejmij decyzję raz, ponieważ koszt drugiej migracji jest równy kosztowi pierwszej.

FAQ

Która alternatywa dla n8n z własnym hostingiem jest najbardziej zbliżona do n8n?

Activepieces. Opiera się na tej samej koncepcji: wizualnym kreatorze, w którym wyzwalacz uruchamia przepływ, a każdy kolejny krok wywołuje usługę, korzystając z obszernego katalogu konektorów. Rdzeń oprogramowania jest dostępny na licencji MIT, działa w oparciu o Postgres i Redis w środowisku Docker, a jego komponenty (pieces) pełnią również rolę serwerów MCP dla klientów LLM. Należy pamiętać, że dostęp do API oraz funkcje agentów znajdują się w komercyjnych katalogach enterprise, dlatego instancja Community Edition jest obsługiwana głównie przez interfejs WWW, a nie programowo.

Czy Activepieces jest rzeczywiście oprogramowaniem open source?

Rdzeń systemu jest dostępny na licencji MIT. Dwa katalogi, packages/ee/ oraz packages/server/api/src/app/ee, są objęte licencją komercyjną, a korzystanie z tych funkcji na własnym serwerze wymaga płatnej licencji. Strona z cennikiem producenta wskazuje, że agenci i czat, projekty, dostęp do API, logowanie jednokrotne (SSO), role użytkowników, dzienniki audytu, menedżery sekretów, branding oraz synchronizacja z Git znajdują się poza wersją Community Edition, podczas gdy liczba uruchomień, użytkowników i przepływów pozostaje nielimitowana. Jest to zatem rozwiązanie open source w zakresie tworzenia i uruchamiania automatyzacji, ale nie w warstwie zarządzania zespołem i administracji.

Ile pamięci RAM wymaga Activepieces na serwerze VPS?

Dokumentacja Activepieces wskazuje na zapotrzebowanie 0,5 vCPU i 1 GB RAM dla każdego procesu worker, 1 vCPU i 1 GB RAM dla kontenera aplikacji, 4 GB dla Postgres oraz 1 GB dla Redis. Jeden worker obsługuje jeden przepływ w danym czasie przez cały okres jego trwania, dlatego zasoby należy planować w oparciu o szczytową liczbę jednoczesnych przepływów, a nie częstotliwość wyzwalania. Plik compose w repozytorium zawiera konfigurację dla pięciu workerów, co łącznie wymaga około 11 GB RAM. Uruchomienie dwóch workerów na serwerze VPS z 4 GB RAM jest rozsądnym początkiem, a docker stats --no-stream pozwala zweryfikować rzeczywiste zużycie zasobów przez przepływy w trakcie ich działania.

Co należy zabezpieczyć, aby przywracanie danych było skuteczne?

Zrzut bazy danych oraz klucz szyfrujący jednocześnie. W przypadku Activepieces jest to pg_dump bazy danych activepieces oraz plik .env zawierający AP_ENCRYPTION_KEY. Dla n8n jest to baza danych oraz N8N_ENCRYPTION_KEY, który n8n wygenerował wewnątrz folderu ~/.n8n, jeśli nie został on zdefiniowany ręcznie. W przypadku Node-RED należy wykonać kopię zapasową całego wolumenu /data, ponieważ plik z poświadczeniami oraz klucz służący do ich odszyfrowania znajdują się w tym samym miejscu. Wyjątkiem jest Windmill: klucz obszaru roboczego znajduje się wewnątrz bazy danych Postgres, więc zrzut bazy zawiera wszystkie niezbędne dane i musi być chroniony tak samo rygorystycznie, jak same sekrety.

Czy mogę zaimportować przepływy z n8n do innego narzędzia?

Nie. Projekty te importują i eksportują własne formaty przepływów, a nie format n8n. Migracja wymaga przebudowania każdego przepływu w nowym kreatorze i ponownego utworzenia wszystkich poświadczeń dla każdej usługi. Ten nakład pracy stanowi rzeczywisty koszt zmiany, dlatego przed podjęciem decyzji należy policzyć liczbę przepływów. Dwanaście przepływów to praca na jedno popołudnie. Dwieście przepływów to osobny projekt i zazwyczaj taniej jest zoptymalizować zużycie pamięci w n8n poprzez tryb kolejkowy (queue mode) i Postgres, niż przebudowywać wszystko od podstaw.