Mga Alternatibo sa n8n: Paghahambing sa Self-Hosting

Ano ang gagamitin kapalit ng n8n

Ang mga self-hosted na alternatibo sa n8n na sulit gamitin sa isang VPS (virtual private server) ay Activepieces, Windmill, Node-RED, Automatisch, at Huginn. Ang Activepieces ang pinakamalapit na kapalit para sa paraan ng paggamit ng karamihan sa n8n, at MIT licensed ang core nito. Ang Windmill ay angkop sa team na mas gustong magsulat ng Python o TypeScript kaysa mag-drag ng mga box sa isang canvas. Ang Node-RED ang pinakamagaan sa mga ito, at hindi ito nangangailangan ng database.

Maraming reader ang dapat manatili sa kasalukuyang setup nila. Pinapahintulutan ng n8n licence ang internal business use, kaya kung nagpapatakbo ka ng flows para sa sarili mong kumpanya, hindi problema ang licence. Hindi rin libre ang migration. Wala sa listahang ito ang makakabasa ng n8n export, kaya kailangan mong buuin muli nang mano-mano ang bawat flow at muling ilagay ang bawat credential. Hiwalay na gawain ang pag-install mismo ng n8n. Saklaw ito ng pag-install ng n8n sa isang VPS gamit ang Docker at HTTPS, habang ipinapaliwanag naman ng paghahambing ng n8n sa Zapier at Make kung paano inihahambing ang buong kategoryang ito sa mga hosted service.

Bakit naghahanap ang mga tao ng self-hosted na alternatibo sa n8n

Dalawang dahilan ang paulit-ulit na lumilitaw.

Una ang license. Ang n8n ay inilalabas sa ilalim ng Sustainable Use License v1.0, na tinatawag ng project na fair-code sa halip na open source. Binibigyan ng license ang user ng karapatang “gamitin o baguhin ang software para lamang sa sarili mong internal business purposes o para sa non-commercial o personal na paggamit,” at ipinagbabawal nitong ibigay ang software sa ibang tao bilang commercial service. Ang mga file at folder na may .ee sa pangalan ay saklaw ng hiwalay na n8n Enterprise License. Kung gusto mong magpatakbo ng automations para sa mga client na nagbabayad, hindi ito puwede sa ilalim ng license na ito. Kung internal operations team ka, wala itong binabago sa pang-araw-araw mong paggamit.

Pangalawa ang memory. Node.js process ang n8n, at nasa memory ang workflow data habang tumatakbo ang execution. Tinutukoy ng n8n documentation ang mga sanhi: dami ng JSON data, laki ng binary data, bilang ng nodes sa isang workflow, Code node, manual executions (na muling kumokopya ng data para sa editor), at iba pang workflow na sabay na tumatakbo. Ang dokumentadong solusyon ay hindi ang paggamit ng ibang product. Gumamit ng queue mode na may magkakahiwalay na worker process, kasama ang Postgres sa halip na default na SQLite file sa ~/.n8n/database.sqlite. Nangangailangan din ng batching ang malalaking job, dahil kapag ang Loop Over Items node ay nagpapasa ng data sa sub-workflow, isang bahagi lang ng data ang nasa memory sa bawat pagkakataon. Subukan muna ito bago mo muling buuin ang animnapung flow sa ibang platform.

Aling self-hosted na alternatibo sa n8n ang patuloy na minamantini

Madaling basahin ang licence text, kaya ikinukumpara ito ng lahat. Madaling malaktawan ang kalagayan ng proyekto. Ito ang 6 proyekto sa paghahambing na ito, kasama ang pinakabagong tagged release ng bawat isa hanggang 4 August 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
  }
]

Dalawang row ang nagbabago sa shortlist. Ang pinakahuling tagged release ng Automatisch ay v0.15.0, na 361 araw na ang nakalipas, at walang commit ang default branch nito mula 15 January 2026. Ang pinakahuling release ng Huginn ay 1447 araw na ang nakalipas, ngunit aktibo ang commit log nito ngayong buwan. Kabaligtaran ito: gumagalaw ang code ngunit hindi ang mga release, kaya ang pagpapatakbo nito ay nangangahulugang pagpapatakbo ng untagged image.

Suriin mo mismo ito bago ka magtiwala sa anumang paghahambing, kabilang na ito. Buksan ang releases page ng proyekto sa GitHub, saka ang commit list ng default branch nito. Ang proyektong may bagong release ngunit tahimik ang commit log ay halos hindi na nagbabago. Ang proyektong may mga bagong commit ngunit ilang taon nang walang release ay nagtutulak sa iyong magpatakbo ng code na wala pang inilabas na bersyon.

Activepieces: pinakamalapit na katumbas, at MIT ang core

Ang Activepieces ang pinakatapat na kapalit. Isa itong visual builder na may mga trigger at step, na tinatawag nitong pieces, at ayon sa README, mahigit 280 ang mga ito. Ang bawat piece ay inilalantad din bilang MCP (model context protocol) server, kaya maaaring tawagin ng isang LLM (large language model) client ang parehong connector bilang mga tool. MIT-licensed ang core. Ang dalawang directory na packages/ee/ at packages/server/api/src/app/ee ay saklaw ng commercial licence, at kailangan ng paid agreement para magamit sa sarili mong server ang mga laman ng mga ito.

Basahin ang paghahating ito bago mag-migrate, dahil mas malawak ito kaysa sa karamihan ng MIT projects. Inilalarawan ng Activepieces pricing page ang Community Edition bilang “open source, free forever, with no cap on runs, users, or flows,” at hindi nito kasama ang Agents and Chat, Projects, API access, at ang buong administration layer (single sign-on, user roles, audit logs, secret managers, branding, Git sync). Kaya ang Community Edition ay kumpletong automation engine na may unlimited flows at users, pero hindi ito platform na maaari mong kontrolin gamit ang API. Kung plano mong mag-generate ng flows nang programmatically, kailangan ng licence para sa planong iyon.

Ang runtime ay binubuo ng isang app container, isa o higit pang worker container, Postgres, at Redis. Ang AP_DB_TYPE=POSTGRES at AP_REDIS_TYPE=STANDALONE ang mga default. May single-container mode na gumagamit ng embedded database at in-process queue (AP_DB_TYPE=PGLITE gamit ang AP_REDIS_TYPE=MEMORY), at sinasabi ng documentation na “is only meant for personal use or testing.” Tanggapin ito nang literal. Hindi maaaring magpatakbo ang mga mode na ito ng higit sa isang instance, kaya ang pag-scale lampas sa mga ito ay migration, hindi flag.

Windmill: code muna, at mas mabigat kaysa sa inaakala

Nagpapatakbo ang Windmill ng mga script sa Python, TypeScript, Go, Bash, at SQL, at pagkatapos ay pinagsasama ang mga ito sa mga flow. Kung karamihan sa iyong automation ay code na may kaunting glue lamang, mas angkop ito kaysa sa anumang node canvas.

Kailangang maingat sa lisensya. AGPLv3 ang source kapag kino-compile nang walang enterprise feature flag. Ang mga image na inilalathala sa ghcr.io/windmill-labs/windmill ay Community Edition. Kasama rito ang code na hindi open source, at maaari itong gamitin nang libre sa loob ng mga quota. Itinatakda ng pricing page ng Windmill ang mga quota na ito sa 50 users, 3 workspaces, at 10 GiB ng workspace object storage, na may unlimited executions. Para sa isang tao o maliit na team, malayo pa ang limitasyong iyon. Kaya hindi quota ang praktikal na tanong. Ang mahalaga ay hindi AGPL build ang binary na pinapatakbo mo.

Ang bigat ng system ang isa pang dapat isaalang-alang. Ang sariling docker-compose.yml ng Windmill ay may kasamang Postgres 16 database, isang server, 3 default worker na may 2048M memory limit bawat isa, isang native worker, at Caddy proxy. Ang dokumentadong gabay ay “1 worker per 1vCPU and 1-2 GB RAM”. Maaari mong bawasan ang replica count sa maliit na server. Dapat alam mong binabawasan mo ito, dahil ang workers ang aktuwal na nagpapatakbo ng iyong mga job.

Ang AI features ng Windmill ay inilalarawan bilang tulong habang nagbu-build: code generation, flow building, chat, at form filling. Kailangan mo munang magdagdag ng model provider resource sa workspace settings. Kung ang kailangan mo ay isang agent step na tumatakbo ayon sa schedule at tumatawag ng mga tool, mas direktang opsyon pa rin ang AI Agent node ng n8n, at ipinapaliwanag ng pagbuo ng AI agent sa n8n ang ganitong setup.

Node-RED: ang maliit na opsyon, walang database

Ang Node-RED ay Apache 2.0, ang pinaka-permissive na lisensiya sa paghahambing na ito. Isa itong Node.js process na may /data volume. Walang Postgres. Walang Redis. I-pin ito sa nodered/node-red:5.0.4, na siyang kasalukuyang release.

Nagmula ito sa IoT (internet of things) wiring, kaya event-shaped ito sa halip na connector-shaped. Ang mga node para sa third-party service ay mula sa community library at magkakaiba ang kalidad. Ito ang kapalit ng maliit nitong footprint. Walang first-class AI agent step. Para sa maliit na VPS na humahawak ng webhook at message-queue traffic, ito ang pinakamagaan na opsyon dito na gumagana, at nagsisimula ito sa loob ng ilang segundo.

Huginn at Automatisch: unahin ang pagsuri sa commit log

Ang Huginn ay may MIT license, nakasulat sa Ruby on Rails, at nangangailangan ng MySQL o PostgreSQL. Gumagamit ito ng mga agent na nagmo-monitor ng source at naglalabas ng mga event. Iba itong modelo kumpara sa flow canvas, at wala itong LLM story. May mga commit pa rin ang code, pero ang pinakahuling tagged release ay mula Agosto 2022. Kaya kapag pinatakbo ito, ang ginagamit ay ang ghcr.io/huginn/huginn image na binuo mula sa default branch. Piliin ito kapag angkop sa problema mo ang agent model, hindi bilang pangkalahatang kapalit ng n8n.

Ang Automatisch ay may AGPL-3.0 license, maliban sa mga .ee file nito. Mukha itong mas simpleng n8n: Postgres, Redis, at maliit na catalogue ng mga app. Ito ang tool na paulit-ulit na inirerekomenda ng mga tutorial para sa single deployment. Sinasabi ng release history na maghintay muna. Ang isang taong walang release at kalahating taong walang commit ay hindi dahilan para mag-panic kung ginagamit mo na ito. Dahilan naman ito para huwag magsimula ng bagong production deployment gamit ito.

Ang tunay na RAM cost ng Activepieces stack

Walang makakapagbigay sa iyo ng tiyak na idle at working memory measurement, dahil nakadepende ito sa sarili mong flows at sa dami ng data na dala ng mga ito. Ang mababasa mo ay ang budget na inirerekomenda ng bawat vendor. Ipinapakita sa ibaba ng Activepieces ang ganitong sizing, at mas mahalaga kaysa sa mga numero ang katabing pahayag: "Busy ang isang concurrency-1 worker sa buong duration ng flow (hanggang 10 min), kaya mag-size batay sa concurrent flows, hindi sa trigger rate."

[
  {
    "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
  }
]

Ang isang worker ay 0.5 vCPU at 1 GB, at eksaktong isang flow lang ang pinapatakbo nito sa bawat pagkakataon. Ang Postgres ay sine-size sa 4 GB. Ang sariling compose file ng project ay naglalabas ng limang worker replica, kaya batay sa sizing na iyon, humihingi ang stack sa repository ng humigit-kumulang 11 GB bago pa gumawa ng anumang kapansin-pansing gawain ang iyong mga flow. Kinokopya ng mga tutorial para sa single-tool ang file na iyon at tinatawag itong maliit na deployment.

Sa isang 4 GB VPS, magpatakbo ng dalawang worker, panatilihin ang Postgres sa parehong compose project, at magsukat. Nagpi-print ang docker stats --no-stream ng isang linya para sa bawat container na naglalaman ng aktuwal nitong resident memory, na mas mapagkakatiwalaan kaysa sa anumang figure na inilathala ng vendor o blog. Kung patuloy na lumalaki ang memory ng isang container nang walang limitasyon, lagyan ito ng cap, at ipinapakita ng mga memory limit sa Docker Compose ang syntax.

Isang compose file para sa Activepieces sa isang VPS

I-pin ang tag. Ibig sabihin ng latest, maaaring baguhin ng susunod na docker compose pull ang database schema nang walang abiso. Ang version na 0.86.3 ang naka-pin sa sariling compose file ng project noong 4 August 2026.

Bumuo muna ng dalawang secret gamit ang mga haba na tinutukoy sa documentation.

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

Isulat ang .env sa tabi ng compose file:

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

Ang AP_FRONTEND_URL ay dapat ang public HTTPS address, dahil kung hindi, susubukan ng Activepieces na gamitin ang public IP address mo kapag bumubuo ito ng mga webhook URL. Ang bawat webhook na ibinibigay mo sa third party ay binubuo mula sa value na iyon. Kaya kung localhost pa rin ang nakalagay, hindi makakarating sa server mo ang URL na ipinapasa mo sa ibang service.

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:

Ang file na iyon ay sariling compose file ng project na may apat na pagbabago: ibinaba ang bilang ng worker mula lima sa dalawa, itinali ang published port sa 127.0.0.1 sa halip na sa lahat ng interface, inalis ang fixed container names dahil hindi ito maaaring gamitin ng service na may replicas, at inalis ang explicit network block dahil awtomatiko nang gumagawa nito ang compose.

docker compose up -d
docker compose ps

Dapat ipakita ng bawat service ang Up, kabilang ang dalawang worker container. Kapag paulit-ulit na nagre-restart ang isang container, ipinapakita nito ang dahilan sa docker compose logs worker, kaya basahin muna iyon bago magbago ng anuman. Dahil sa port binding, walang makakaabot sa app mula sa labas hanggang hindi ka naglalagay ng reverse proxy na may TLS (transport layer security) sa harap nito. Saklaw ito ng pagpapatakbo ng Traefik sa harap ng ilang compose app. Panatilihin ang .env sa mode 600 at huwag itong isama sa git, gaya ng inilalarawan sa pamamahala ng mga secret sa compose env files.

Ang backup na madalas hindi isinasaalang-alang ng mga guide

Ini-encrypt ng lahat ng tool na ito ang mga nakaimbak na credential, kaya hindi backup ang database dump lang. Kailangan mo ang dump at ang key na nagde-decrypt nito. Ang problema, karamihan sa mga tool na ito ay tahimik na awtomatikong gumagawa ng key at ini-save ito sa lugar na hindi mo bina-back up.

Pinakamalinaw itong halimbawa ang n8n. Kung hindi mo kailanman itinakda ang N8N_ENCRYPTION_KEY, “awtomatikong gumagawa ang n8n ng random encryption key sa unang pag-launch at ini-save ito sa folder na ~/.n8n,” pagkatapos ay ginagamit nito ang key na iyon upang i-encrypt ang mga credential bago mapunta ang mga ito sa database. I-dump ang Postgres, i-restore ito sa bagong container na may bagong volume, at babalik ang mga workflow habang ang bawat credential ay ciphertext na hindi mabasa ninuman. Itakda nang tahasan ang variable, at gamitin ang parehong value sa bawat worker kapag gumagamit ka ng queue mode.

Pareho ang pattern sa Node-RED. Nasa sarili nilang encrypted file ang mga credential, at ang key ay credentialSecret sa settings.js. Kapag hindi ka nagtakda ng key, gumagawa ang runtime ng random key at ini-save ito sa _credentialSecret sa sarili nitong settings store sa loob ng /data. Malinaw ang consequence sa stock settings file: “kapag itinakda mo na ang property na ito, huwag mo itong baguhin—kapag ginawa mo iyon, hindi na made-decrypt ng node-red ang mga dati mong credential at mawawala ang mga ito.” I-back up ang buong /data volume, hindi lang ang flows file.

Iniingatan ng Activepieces ang AP_ENCRYPTION_KEY sa iyong .env, at dokumentado ito bilang “32-character (16-byte) hexadecimal key na ginagamit upang i-encrypt ang mga connection.” Iniingatan naman ng Huginn ang APP_SECRET_TOKEN sa environment nito. Tatlo ang key ng Automatisch: ENCRYPTION_KEY, WEBHOOK_SECRET_KEY, at APP_SECRET_KEY. Sa bawat kaso, nasa environment file ang secret, kaya bahagi ng backup ang environment file.

Ang Windmill ang exception na mahalagang malaman. Ini-encrypt ang mga variable at secret nito gamit ang workspace-specific symmetric key na iniimbak ng Windmill sa sarili nitong database, kaya kasama sa isang Postgres dump ang parehong bahagi. Maginhawa ito para sa mga restore, pero nangangahulugan din itong sapat na ang dump para mabasa ang bawat secret. Protektahan ang file na iyon na para bang mga secret mismo ito.

Para sa Activepieces stack sa itaas, dalawang file ang backup:

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

Pagkatapos, patunayang gumagana ang backup, dahil palagay lang ang backup na hindi nasubukan. I-restore ang dump sa isang scratch compose project na sadyang gumagamit ng ibang AP_ENCRYPTION_KEY, pagkatapos ay magpatakbo ng flow na gumagamit ng naka-save na connection. Mabibigo ito dahil ginawa ang ciphertext sa database gamit ang ibang key. Ulitin ang restore gamit ang totoong key mula sa .env at gagana ang parehong flow. Ang dalawang test na iyon lamang ang patunay na backup ang iyong backup. Regular na ipadala ang dalawang file sa labas ng server gamit ang mga restic backup mula sa VPS, dahil mamamatay kasama ng disk ang backup na nasa parehong disk.

Kailan manatili sa n8n

Manatili kung panloob sa sarili ninyong kumpanya ang gawain, dahil ito mismo ang pinapahintulutan ng Sustainable Use License. Manatili kung mahalaga sa inyo ang lawak ng integrations, dahil sinasabi ng n8n na mayroon itong mahigit 1500 integration, o kung ginagamit ninyo ang AI Agent node nito na nakabatay sa LangChain. Walang ibang opsyon dito ang may kapantay na handa nang agent steps. Ipinapakita ng Pagpapatakbo ng mga n8n workflow gamit ang Claude kung ano ang hitsura nito sa aktuwal na paggamit.

Lumipat sa Activepieces kung gusto ninyo ng permissive licence para sa automation core at stack na maaari ninyong basahin mula simula hanggang dulo. Lumipat sa Windmill kung ang mga flow ninyo ay talagang code na may user interface lamang. Lumipat sa Node-RED kung maliit ang box at nakabatay sa mga event ang gawain. Huwag lumipat dahil sinabi ng isang benchmark na mabigat ang n8n. Sukatin muna ang sarili ninyong instance, pagkatapos ay basahin ang kung ano ang sulit i-self-host sa 2026 at pumili nang isang beses, dahil kasinglaki ng unang migration ang gastos sa ikalawa.

FAQ

Aling self-hosted n8n alternative ang pinakamalapit sa n8n?

Ang Activepieces. Pareho ang konsepto: isang visual builder kung saan nagsisimula ang isang trigger ng flow at tumatawag ang bawat step sa isang service, na may malaking catalog ng mga connector. MIT-licensed ang core nito, tumatakbo ito sa Postgres at Redis gamit ang Docker, at nagsisilbi ring MCP servers ang mga piece nito para sa mga LLM client. Ang dapat bantayan ay nasa commercial enterprise directories ang API access at mga agent feature, kaya ginagamit ang Community Edition instance sa web interface nito sa halip na programmatically.

Talaga bang open source ang Activepieces?

Oo, ang core nito ay nasa ilalim ng MIT license. Commercially licensed ang dalawang directory, packages/ee/ at packages/server/api/src/app/ee, at kailangan ng paid license para magamit ang mga feature na ito sa sarili mong server. Ayon sa pricing page ng vendor, wala sa Community Edition ang Agents and Chat, Projects, API access, single sign-on, user roles, audit logs, secret managers, branding, at Git sync, habang walang limitasyon ang runs, users, at flows. Kaya tunay itong open source para sa pagbuo at pagpapatakbo ng mga automation, pero hindi ito open source para sa team at governance layer.

Gaano karaming RAM ang kailangan ng Activepieces sa isang VPS?

Ayon sa documentation ng Activepieces, kailangan ng bawat worker ng 0.5 vCPU at 1 GB, ng app container ng 1 vCPU at 1 GB, ng Postgres ng 4 GB, at ng Redis ng 1 GB. Isang flow lang ang hinahawakan ng worker sa bawat pagkakataon, mula simula hanggang matapos ang flow, kaya ibatay ang sizing sa peak concurrent flows at hindi sa dalas ng pag-fire ng mga trigger. May limang worker ang compose file sa repository, na katumbas ng humigit-kumulang 11 GB ayon sa published sizing. Makatuwirang magsimula sa dalawang worker sa isang 4 GB VPS, at kinukumpirma ng docker stats --no-stream ang aktuwal na bilang para sa mga flow mo habang tumatakbo ang mga ito.

Ano ang kailangan kong i-back up para talagang gumana ang restore?

Magkasama ang database dump at encryption key. Para sa Activepieces, ito ay pg_dump ng activepieces database kasama ang .env file na naglalaman ng AP_ENCRYPTION_KEY. Para sa n8n, ito ay ang database kasama ang N8N_ENCRYPTION_KEY, na awtomatikong ginawa ng n8n sa loob ng ~/.n8n folder kung hindi mo ito itinakda. Para sa Node-RED, i-back up ang buong /data volume, dahil naroon ang credentials file at ang key na nagde-decrypt dito. Exception ang Windmill: nasa sarili nitong Postgres database ang workspace key nito, kaya dala ng dump ang lahat at dapat itong protektahan na parang mismong secrets.

Maaari ko bang i-import ang mga n8n workflow ko sa ibang tool?

Hindi. Nag-i-import at nag-e-export ang mga project na ito ng sarili nilang flow format, hindi ng format ng n8n. Ang migration ay nangangahulugan ng muling pagbuo ng bawat flow sa bagong builder at muling paglikha ng bawat credential mula sa orihinal na service. Iyan ang tunay na gastos ng paglipat, kaya bilangin muna ang mga flow bago magpasya. Labindalawang flow ay matatapos sa isang hapon. Dalawang daang flow ay isang proyekto, at karaniwang mas mura na ayusin ang memory use ng n8n gamit ang queue mode at Postgres kaysa buuing muli ang lahat.