חלופות ל-n8n באירוח עצמי: השוואה מקיפה

במה להשתמש במקום n8n

החלופות ל-n8n שניתן לארח באופן עצמי (self-hosted) ושראויות לבדיקה על גבי VPS (שרת וירטואלי פרטי) הן Activepieces, Windmill, Node-RED, Automatisch ו-Huginn. ‏Activepieces היא התחליף הקרוב ביותר לאופן שבו רוב המשתמשים מנצלים את n8n, והליבה שלה מופצת תחת רישיון MIT. ‏Windmill מתאימה לצוות שמעדיף לכתוב קוד ב-Python או ב-TypeScript על פני גרירת תיבות על גבי קנבס. ‏Node-RED היא האופציה הקלה, והיא אינה זקוקה למסד נתונים כלל.

קוראים רבים צריכים להישאר היכן שהם נמצאים. הרישיון של n8n מתיר שימוש עסקי פנימי, כך שאם אתם מריצים תהליכי עבודה (flows) עבור החברה שלכם, הרישיון אינו מהווה בעיה. הגירה אינה בחינם. אף כלי ברשימה זו אינו יודע לקרוא ייצוא (export) של n8n, לכן תצטרכו לבנות מחדש כל תהליך עבודה באופן ידני ולהזין מחדש את כל פרטי ההתחברות. התקנת n8n עצמה היא משימה נפרדת, המכוסה ב-התקנת n8n על גבי VPS עם Docker ו-HTTPS, והמאמר n8n מול Zapier ו-Make סוקר כיצד כל הקטגוריה הזו משתווה לשירותים מנוהלים.

מדוע אנשים מחפשים חלופות ל-n8n באירוח עצמי

שתי סיבות עולות שוב ושוב.

הראשונה היא הרישיון. n8n מופץ תחת Sustainable Use License v1.0, שהפרויקט מגדיר כ-fair-code ולא כקוד פתוח. הרישיון מעניק את הזכות "להשתמש או לשנות את התוכנה רק למטרות עסקיות פנימיות או לשימוש לא מסחרי או אישי", והוא אוסר על אספקת התוכנה לאחרים באופן מסחרי. קבצים ותיקיות עם .ee בשמם כפופים לרישיון n8n Enterprise נפרד. אם ברצונכם להריץ אוטומציות עבור לקוחות משלמים, מדובר במחסום מוחלט. אם אתם צוות תפעול פנימי, הדבר אינו משנה דבר בשגרת העבודה שלכם.

הסיבה השנייה היא זיכרון. n8n הוא תהליך Node.js, ונתוני ה-workflow נשמרים בזיכרון בזמן ההרצה. התיעוד של n8n מציין את הגורמים לכך: כמות נתוני ה-JSON, גודל הנתונים הבינאריים, מספר ה-nodes ב-workflow, ה-Code node, הרצות ידניות (שמעתיקות את הנתונים שוב עבור העורך), ו-workflows אחרים שרצים במקביל. הפתרון המתועד אינו מוצר אחר. מדובר ב-queue mode עם תהליכי worker נפרדים, בתוספת Postgres במקום קובץ ה-SQLite המוגדר כברירת מחדל ב-~/.n8n/database.sqlite. משימות גדולות דורשות גם batching, כיוון ש-node מסוג Loop Over Items שמזין sub-workflow שומר בזיכרון רק חלק אחד מהנתונים בכל פעם. נסו זאת לפני שתבנו מחדש שישים תהליכי עבודה במקום אחר.

אילו חלופות n8n לאירוח עצמי עדיין מתוחזקות

קל לקרוא את טקסט הרישיון, לכן כולם משווים רישיונות. קל לדלג על בריאות הפרויקט. אלו הם 6 הפרויקטים בהשוואה זו, עם התיוג האחרון של גרסה (release) שהיה לכל אחד מהם ב-4 באוגוסט 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
  }
]

שתי שורות משנות את הרשימה הקצרה. Automatisch תויג לאחרונה ב-v0.15.0, כלומר הוא בן 361 ימים, והענף (branch) המוגדר כברירת מחדל שלו לא קיבל commit מאז 15 בינואר 2026. Huginn תייג גרסה לאחרונה לפני 1447 ימים, אך יומן ה-commit שלו פעיל החודש. זהו דפוס הפוך: הקוד מתקדם אך הגרסאות לא, לכן הרצתו משמעותה הרצת image ללא תיוג.

בדקו זאת בעצמכם לפני שאתם סומכים על השוואה כלשהי, כולל זו. פתחו את דף ה-releases של הפרויקט ב-GitHub, ולאחר מכן את רשימת ה-commits של ענף ברירת המחדל שלו. פרויקט עם גרסה טרייה ויומן commits שקט נמצא במצב של דעיכה. פרויקט עם commits טריים וללא גרסה מזה שנים מבקש מכם להריץ קוד שאף אחד לא הוציא עבורו גרסה רשמית.

Activepieces: החלופה הקרובה ביותר, עם ליבת MIT

Activepieces הוא הבחירה המקבילה ביותר. זהו בונה ויזואלי עם טריגרים ושלבים, המכונים pieces, וה-README מצהיר על יותר מ-280 כאלו. כל piece חשוף גם כשרת MCP (פרוטוקול הקשר מודל), כך שלקוח LLM (מודל שפה גדול) יכול לקרוא לאותם מחברים ככלים. הליבה מופצת תחת רישיון MIT. שתי ספריות, packages/ee/ ו-packages/server/api/src/app/ee, נושאות רישיון מסחרי, ושימוש בתוכנן על שרת עצמאי מחייב הסכם בתשלום.

קראו על הפיצול הזה לפני שתבצעו הגירה, שכן הוא רחב יותר מאשר ברוב פרויקטי ה-MIT. דף התמחור של Activepieces מתאר את ה-Community Edition כ"קוד פתוח, חינמי לנצח, ללא הגבלה על הרצות, משתמשים או תהליכי עבודה", ומציב מחוץ לו את ה-Agents וה-Chat, פרויקטים, גישת API, וכל שכבת הניהול (Single Sign-On, תפקידי משתמשים, לוגים של ביקורת, מנהלי סודות, מיתוג, וסנכרון Git). לכן, ה-Community Edition הוא מנוע אוטומציה מלא עם תהליכי עבודה ומשתמשים ללא הגבלה, אך הוא אינו פלטפורמה שניתן להפעיל מתוך API. אם התוכנית שלכם הייתה ליצור תהליכי עבודה באופן תכנותי, תוכנית זו מחייבת רישיון.

מבנה זמן הריצה מורכב ממכולת אפליקציה אחת, מכולת worker אחת או יותר, Postgres ו-Redis. AP_DB_TYPE=POSTGRES ו-AP_REDIS_TYPE=STANDALONE הם ברירות המחדל. קיים מצב של מכולה בודדת עם מסד נתונים מוטמע ותור בתוך התהליך (AP_DB_TYPE=PGLITE עם AP_REDIS_TYPE=MEMORY), והתיעוד מציין שהוא "מיועד לשימוש אישי או לבדיקות בלבד". התייחסו לכך כפשוטו. מצבים אלו אינם יכולים להריץ יותר ממופע אחד, כך שצמיחה מעבר להם דורשת הגירה, ולא רק שינוי flag.

Windmill: קוד תחילה, וכבד מכפי שהוא נראה

Windmill מריצה סקריפטים ב-Python, TypeScript, Go, Bash ו-SQL, ואז מאגדת אותם לתוך תהליכי עבודה (flows). אם האוטומציות שלכם מבוססות בעיקר על קוד עם כמות קטנה של "דבק" מסביב, היא מתאימה יותר מכל ממשק מבוסס צמתים (node canvas).

יש להקדיש תשומת לב לרישיון. קוד המקור הוא תחת AGPLv3 כאשר הוא מקומפל ללא דגל ה-enterprise. האימג'ים שמתפרסמים ב-ghcr.io/windmill-labs/windmill הם גרסת ה-Community Edition, הכוללת קוד שאינו קוד פתוח וניתן לשימוש חינמי במסגרת מכסות. דף התמחור של Windmill מגדיר מכסות אלו כ-50 משתמשים, 3 סביבות עבודה (workspaces) ו-10 GiB של אחסון אובייקטים לסביבת עבודה, עם מספר בלתי מוגבל של הרצות. עבור אדם אחד או צוות קטן, התקרה הזו רחוקה מאוד, לכן השאלה המעשית אינה המכסה. השאלה היא שהקובץ הבינארי שאתם מריצים אינו גרסת ה-AGPL.

משקל הוא שיקול נוסף. ה-docker-compose.yml של Windmill כולל מסד נתונים Postgres 16, שרת אחד, שלושה workers כברירת מחדל עם מגבלת זיכרון של 2048M לכל אחד, worker מקורי ו-proxy מסוג Caddy. כלל האצבע המתועד הוא "worker אחד לכל 1vCPU ו-1-2 GB RAM". ניתן לצמצם את מספר ה-replicas בשרת קטן. עליכם להיות מודעים לכך שאתם מצמצמים אותם, כיוון שה-workers הם אלו שמריצים בפועל את המשימות שלכם.

תכונות ה-AI של Windmill מתועדות כעזרה בזמן הפיתוח: יצירת קוד, בניית תהליכי עבודה, צ'אט ומילוי טפסים. הן דורשות מכם להוסיף תחילה משאב של ספק מודלים (model provider) בהגדרות סביבת העבודה. אם מה שאתם מחפשים הוא שלב של סוכן (agent) שרץ לפי לוח זמנים ומפעיל כלים, ה-AI Agent node של n8n הוא עדיין הדרך הישירה יותר, והמדריך בניית סוכן AI ב-n8n מכסה את המבנה הזה.

Node-RED: האפשרות הקטנה, ללא מסד נתונים כלל

Node-RED מופץ תחת רישיון Apache 2.0, הרישיון המתירני ביותר בהשוואה זו. מדובר בתהליך Node.js יחיד עם volume מסוג /data. ללא Postgres. ללא Redis. יש להצמיד אותו לגרסה nodered/node-red:5.0.4, שהיא הגרסה העדכנית ביותר.

הכלי צמח מתוך עולם ה-IoT (האינטרנט של הדברים), ולכן הוא מבוסס על אירועים (event-shaped) ולא על מחברים (connector-shaped). צמתים (nodes) עבור שירותי צד-שלישי מגיעים מספריית הקהילה ואיכותם משתנה, וזהו הפשרה הנדרשת עבור טביעת הרגל הקטנה. אין בו שלב מובנה של סוכן AI. עבור שרת VPS קטן המטפל ב-webhooks ובתעבורת message-queue, זהו הפתרון הקל ביותר כאן שעובד, והוא עולה תוך שניות.

Huginn ו-Automatisch: בדקו תחילה את יומן ה-commit

Huginn מופץ תחת רישיון MIT, כתוב ב-Ruby on Rails, ודורש MySQL או PostgreSQL. הוא פועל לפי מודל של סוכנים (agents) הצופים במקור ופולטים אירועים; זהו מודל שונה מזה של קנבס זרימת עבודה (flow canvas), ואין לו תמיכה מובנית ב-LLM. הקוד עדיין מקבל commits, אך ה-release המתויג האחרון הוא מאוגוסט 2022, לכן הרצה שלו משמעותה שימוש ב-image מסוג ghcr.io/huginn/huginn שנבנה מה-branch המוגדר כברירת מחדל. בחרו בו כאשר מודל הסוכנים מתאים לבעיה שלכם, ולא כתחליף כללי ל-n8n.

Automatisch מופץ תחת רישיון AGPL-3.0, למעט קובצי ה-.ee שלו, והוא נראה כמו גרסה פשוטה יותר של n8n: הוא דורש Postgres, Redis, וכולל קטלוג מצומצם של יישומים. זהו הכלי שמדריכי פריסה עצמית (single-deploy) ממשיכים להמליץ עליו. היסטוריית ה-release מורה להמתין. שנה ללא release וחצי שנה ללא commit אינן סיבה להיכנס לפאניקה אם אתם כבר מריצים אותו, אך הן סיבה מספקת שלא להתחיל פריסת production חדשה המבוססת עליו.

מהו העלות האמיתית של Activepieces במונחי RAM

צריכת זיכרון במצב המתנה או בעבודה אינה נתון שניתן לפרסם עבורך, כיוון שהיא תלויה ב־flows הספציפיים שלך ובכמות הנתונים שהם מעבדים. מה שכן ניתן לבדוק הוא התקציב שכל ספק ממליץ עליו. Activepieces מתעדת את המבנה להלן, והמשפט שלצידו חשוב יותר מהמספרים עצמם: "worker עם concurrency-1 תפוס למשך כל זמן הריצה של ה־flow (עד 10 דקות), לכן יש לבצע תכנון לפי מספר ה־flows המקבילים, ולא לפי קצב ה־trigger."

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

worker אחד דורש 0.5 vCPU ו-1 GB, והוא מריץ בדיוק flow אחד בכל פעם. עבור Postgres יש להקצות 4 GB. קובץ ה-compose של הפרויקט מגיע עם חמישה replicas של worker, כך שלפי תכנון זה, ה-stack במאגר דורש כ-11 GB עוד לפני שה-flows מבצעים פעולה כלשהי. מדריכים המוקדשים לכלי בודד מעתיקים את הקובץ הזה ומכנים אותו פריסה קטנה (small deployment).

על גבי VPS עם 4 GB, הריצו שני workers, שמרו את Postgres באותו פרויקט compose, ובצעו מדידה. הפקודה docker stats --no-stream מדפיסה שורה אחת לכל container עם הזיכרון הפיזי (resident memory) האמיתי שלו, וזה עדיף על כל נתון שמפורסם על ידי ספק או בבלוג. אם container גדל ללא הגבלה, הגבילו אותו, והקישור מגבלות זיכרון ב-Docker Compose מציג את התחביר הנדרש.

קובץ compose עבור Activepieces על שרת VPS יחיד

קבעו את גרסת ה-tag. שימוש ב-latest משמעו שה-docker compose pull הבא עלול לשנות את מבנה מסד הנתונים ללא התראה מוקדמת. גרסה 0.86.3 היא הגרסה שהפרויקט מקבע בקובץ ה-compose שלו נכון ל-4 באוגוסט 2026.

צרו תחילה את שני ה-secrets, תוך שימוש באורכים המצוינים בתיעוד.

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

כתבו את .env לצד קובץ ה-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 חייב להיות כתובת ה-HTTPS הציבורית, שכן אחרת Activepieces ינסה להשתמש בכתובת ה-IP הציבורית שלכם בעת בניית כתובות ה-URL של ה-webhooks. כל webhook שתעבירו לצד שלישי נבנה על בסיס ערך זה; אם הוא עדיין מצביע על localhost, ה-URL שתדביקו בשירות אחר לעולם לא יגיע לשרת שלכם.

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:

קובץ זה הוא ה-compose המקורי של הפרויקט עם ארבעה שינויים: מספר ה-workers יורד מחמישה לשניים, הפורט המפורסם נקשר ל-127.0.0.1 במקום לכל הממשקים, שמות המכולות הקבועים הוסרו מכיוון ששירות עם replicas אינו יכול להשתמש בהם, ובלוק ה-network המפורש הוסר כיוון ש-compose יוצר אחד כזה בכל מקרה.

docker compose up -d
docker compose ps

כל שירות אמור להציג Up, כולל שתי מכולות worker. מכולה שנמצאת בלולאת אתחול מציגה את סיבת הכשל ב-docker compose logs worker, לכן קראו זאת לפני ביצוע שינויים. קישור הפורט אומר ששום דבר לא יגיע ליישום מבחוץ עד שתציבו reverse proxy עם TLS (אבטחת שכבת תעבורה) בחזית, נושא המכוסה ב-הרצת Traefik לפני מספר יישומי compose. שמרו על .env במצב 600 ומחוץ ל-git, כפי שמוסבר ב-טיפול ב-secrets בקובצי env של compose.

הגיבוי שכל מדריך משמיט

כל הכלים הללו מצפינים את פרטי הגישה המאוחסנים, לכן dump של מסד הנתונים כשלעצמו אינו מהווה גיבוי. עליכם לגבות גם את ה-dump וגם את המפתח שמפענח אותו. המלכוד הוא שרוב הכלים הללו מייצרים את המפתח עבורכם, בשקט, ושומרים אותו במיקום שאינכם מגבים.

n8n הוא הדוגמה המובהקת ביותר. אם לא הגדרתם את N8N_ENCRYPTION_KEY, n8n "יוצר מפתח הצפנה אקראי באופן אוטומטי בהפעלה הראשונה ושומר אותו בתיקייה ~/.n8n", ולאחר מכן משתמש במפתח זה כדי להצפין את פרטי הגישה לפני שהם מגיעים למסד הנתונים. אם תבצעו dump ל-Postgres ותשחזרו אותו לתוך מכולה חדשה עם volume חדש, תהליכי העבודה (workflows) יחזרו, אך כל פרטי הגישה יהיו טקסט מוצפן שאף אחד לא יכול לקרוא. הגדירו את המשתנה במפורש, והגדירו את אותו הערך בכל ה-workers כאשר אתם מריצים את המערכת במצב queue.

ל-Node-RED יש מבנה דומה. פרטי הגישה נמצאים בקובץ מוצפן משלהם, והמפתח הוא credentialSecret בתוך settings.js. כאשר אינכם מגדירים מפתח, סביבת ההרצה מייצרת מפתח אקראי ושומרת אותו תחת _credentialSecret בתוך הגדרות המערכת ב-/data. קובץ ההגדרות המקורי מבהיר את ההשלכות: "ברגע שהגדרת מאפיין זה, אל תשנה אותו - פעולה כזו תמנע מ-node-red לפענח את פרטי הגישה הקיימים שלך והם יאבדו". גבו את כל ה-volume של /data, לא רק את קובץ ה-flows.

Activepieces שומרת את AP_ENCRYPTION_KEY בתוך ה-.env שלכם, ומתעדת אותו כ-"מפתח הקסדצימלי בן 32 תווים (16 בתים) המשמש להצפנת חיבורים". Huginn שומרת את APP_SECRET_TOKEN בסביבת ההרצה שלה. ל-Automatisch יש שלושה כאלו: ENCRYPTION_KEY, WEBHOOK_SECRET_KEY ו-APP_SECRET_KEY. בכל מקרה, הסוד נמצא בקובץ סביבה, מה שאומר שקובץ הסביבה הוא חלק מהגיבוי.

Windmill היא היוצאת מן הכלל שכדאי להכיר. המשתנים והסודות שלה מוצפנים באמצעות מפתח סימטרי ספציפי ל-workspace ש-Windmill שומרת בתוך מסד הנתונים שלה, כך ש-dump בודד של Postgres נושא את שני החלקים. זה נוח לשחזורים, ומשמעות הדבר היא שה-dump לבדו מספיק כדי לקרוא כל סוד, לכן הגנו על הקובץ כאילו היה הסודות עצמם.

עבור ה-stack של Activepieces שהוזכר לעיל, הגיבוי מורכב משני קבצים:

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

לאחר מכן, הוכיחו שהגיבוי עובד, שכן גיבוי שלא נבדק הוא רק ניחוש. שחזרו את ה-dump לתוך פרויקט compose זמני שמשתמש ב-AP_ENCRYPTION_KEY שונה במכוון, ואז הריצו תהליך שמשתמש בחיבור שמור. הוא ייכשל, מכיוון שהטקסט המוצפן במסד הנתונים נוצר עם המפתח האחר. חזרו על השחזור עם המפתח האמיתי מתוך .env, ואותו תהליך ירוץ בהצלחה. שתי הרצות אלו הן ההוכחה היחידה לכך שהגיבוי שלכם הוא אכן גיבוי. הוציאו את שני הקבצים מהשרת לפי לוח זמנים באמצעות גיבויי restic מ-VPS, מכיוון שגיבוי שנמצא על אותו דיסק יאבד יחד עם הדיסק במקרה של כשל.

מתי להישאר עם n8n

הישארו עם n8n אם העבודה היא פנימית בתוך החברה שלכם, שכן זה בדיוק מה שרישיון ה-Sustainable Use License מתיר. הישארו אם אתם מסתמכים על מגוון רחב של אפשרויות, שכן n8n מציעה יותר מ-1500 אינטגרציות, או אם אתם משתמשים ב-node של סוכני AI המבוסס על LangChain, שאין לו מתחרים בתחום של שלבי סוכן מוכנים לשימוש. המאמר הפעלת תהליכי עבודה ב-n8n עם Claude מציג כיצד זה נראה בפועל.

עברו ל-Activepieces אם אתם מעוניינים ברישיון מתירני עבור ליבת האוטומציה ובמחסנית טכנולוגית שניתן לקרוא מקצה לקצה. עברו ל-Windmill אם התהליכים שלכם הם למעשה קוד שעטוף בממשק משתמש. עברו ל-Node-RED אם החומרה שלכם מוגבלת והעבודה מבוססת על אירועים (event-shaped). אל תעברו רק בגלל שמדד ביצועים (benchmark) טוען ש-n8n כבדה. מדדו קודם את המופע (instance) שלכם, לאחר מכן קראו את מה כדאי לארח באופן עצמי בשנת 2026 ובצעו בחירה מושכלת פעם אחת, שכן עלות ההגירה השנייה שווה לעלות הראשונה.

FAQ

איזו חלופה ל-n8n היא הקרובה ביותר ל-n8n?

Activepieces. מדובר באותו רעיון: בונה ויזואלי שבו טריגר מפעיל תהליך (flow), וכל שלב קורא לשירות חיצוני, עם קטלוג גדול של מחברים (connectors). הליבה של המערכת מופצת תחת רישיון MIT, היא רצה על Postgres ו-Redis בתוך Docker, והרכיבים שלה משמשים גם כשרתי MCP עבור לקוחות LLM. הפער שחשוב לשים לב אליו הוא שגישה ל-API ותכונות ה-Agent נמצאות בספריות של הגרסה הארגונית (Enterprise), כך שמופע של Community Edition מנוהל דרך ממשק האינטרנט ולא באופן תכנותי.

האם Activepieces היא באמת קוד פתוח?

הליבה היא קוד פתוח תחת רישיון MIT. שתי ספריות, packages/ee/ ו-packages/server/api/src/app/ee, מופצות ברישיון מסחרי, ושימוש בתכונות אלו על השרת שלך דורש רישיון בתשלום. דף התמחור של הספק מציב את ה-Agents וה-Chat, פרויקטים, גישת API, הזדהות אחודה (SSO), תפקידי משתמשים, לוגים של ביקורת, מנהלי סודות, מיתוג וסנכרון מול Git מחוץ ל-Community Edition, בעוד שהרצות, משתמשים ותהליכים נשארים ללא הגבלה. לכן, המערכת היא אכן קוד פתוח לבנייה והרצה של אוטומציות, אך אינה קוד פתוח עבור שכבת הניהול והצוותים.

כמה זיכרון RAM דורשת Activepieces על גבי VPS?

Activepieces מתעדת דרישה של 0.5 vCPU ו-1 GB RAM עבור כל worker, 1 vCPU ו-1 GB RAM עבור מכולת היישום, 4 GB עבור Postgres ו-1 GB עבור Redis. כל worker מטפל בתהליך אחד בכל פעם למשך כל זמן הריצה שלו, לכן יש לתכנן את המשאבים לפי שיא התהליכים המקבילים ולא לפי תדירות הפעלת הטריגרים. קובץ ה-compose במאגר מגיע עם חמישה workers, מה שמסתכם בכ-11 GB של דרישות מערכת מוצהרות. שני workers על שרת VPS עם 4 GB הם התחלה סבירה, ו-docker stats --no-stream יאשר את המספר האמיתי עבור התהליכים שלך בזמן שהם רצים.

מה עלי לגבות כדי שהשחזור אכן יעבוד?

את ה-dump של מסד הנתונים ואת מפתח ההצפנה, יחד. עבור Activepieces מדובר ב-pg_dump של מסד הנתונים activepieces בצירוף הקובץ .env שמכיל את AP_ENCRYPTION_KEY. עבור n8n מדובר במסד הנתונים וב-N8N_ENCRYPTION_KEY, ש-n8n יצר עבורך בתוך התיקייה ~/.n8n אם לא הגדרת אותו בעצמך. עבור Node-RED, יש לגבות את כל ה-volume של /data, כיוון שקובץ האישורים והמפתח שמפענח אותו נמצאים שניהם שם. Windmill היא היוצאת מן הכלל: מפתח סביבת העבודה שלה יושב בתוך מסד הנתונים Postgres שלה, כך שה-dump מכיל את הכל ויש לשמור עליו כאילו היה הסודות עצמם.

האם ניתן לייבא את תהליכי ה-n8n שלי לכלי אחר?

לא. פרויקטים אלו מייבאים ומייצאים פורמטים של תהליכים משלהם, לא את אלו של n8n. הגירה משמעותה בנייה מחדש של כל תהליך בבונה החדש ויצירה מחדש של כל אישור (credential) מול השירות המקורי. עבודה זו היא העלות האמיתית של המעבר, לכן ספור את התהליכים שלך לפני שתחליט. שנים-עשר תהליכים הם עבודה של אחר צהריים. מאתיים תהליכים הם פרויקט, ובדרך כלל זול יותר לפתור את צריכת הזיכרון של n8n באמצעות מצב תור (queue mode) ו-Postgres מאשר לבנות את כולם מחדש.