n8n בענן מול n8n על שרת שלכם - מה באמת ההבדל
כל כמה שבועות מגיע אלינו עסק שכבר החליט שהוא רוצה n8n על שרת פרטי, כי ככה המידע נשאר אצלו. חלק מהם צודקים. החלק השני מקבל שרת שאף אחד לא מעדכן, ושמונה חודשים אחר כך הוא פחות מאובטח מהענן שממנו ברחו.
ההחלטה בין n8n Cloud לבין התקנה על שרת פרטי נשמעת כמו החלטה טכנית, והיא בעיקר החלטה תפעולית ומשפטית. השאלה האמיתית היא לא איפה הקוד רץ. השאלה היא מי אחראי עליו בשתיים בלילה כשמשהו נופל, ומי חותם מול הלקוח שלכם על התשובה לשאלה איפה המידע שלו שמור.
מה כל אפשרות אומרת בפועל
n8n Cloud
אתם נרשמים, מקבלים סביבה מנוהלת עם כתובת משלכם, ומתחילים לבנות. n8n מחזיקים את התשתית, מעדכנים גרסאות, מגבים ואחראים על הזמינות. אתם משלמים מנוי חודשי או שנתי, והתמחור בנוי סביב מספר ההרצות ולא סביב מספר הצעדים בתוך כל הרצה. זה הבדל מהותי מול Zapier או Make, ששם כל פעולה בתוך התהליך נספרת בנפרד. תהליך עם ארבעים צעדים עולה אותו דבר כמו תהליך עם שלושה, כל עוד הוא רץ אותו מספר פעמים.
המשמעות הפרקטית: בענן משתלם לבנות תהליכים ארוכים ומפורטים עם הרבה בדיקות תקינות באמצע, ולא משתלם להריץ טריגר שבודק כל דקה אם קרה משהו. הרבה עסקים מגלים את זה רק אחרי החשבון השני.
התקנה על שרת שלכם
אתם מרימים שרת, בדרך כלל VPS אצל ספק כמו Hetzner, DigitalOcean, AWS או ספק ישראלי, מתקינים את n8n בקונטיינר, מחברים בסיס נתונים חיצוני, מגדירים דומיין ותעודת SSL, ומסדירים גיבויים וניטור. משם הסביבה שלכם. אתם מחליטים מתי לשדרג, אילו תוספים להתקין, כמה זמן לשמור לוגים, ומי בכלל יכול להיכנס לממשק.
הרישיון של הגרסה הקהילתית מאפשר שימוש פנימי בלי תשלום רישוי, ומכאן מגיעה השורה שאנחנו שומעים הכי הרבה: self-hosted זה בחינם. זה נכון בערך באותה מידה שבה רכב משומש שקיבלתם במתנה הוא בחינם.
self-hosted לא חוסך כסף, הוא מעביר את החשבון מכרטיס האשראי לשעות של מישהו בצוות.
מה שנכנס לסל האחריות הזה, וכדאי להסתכל על הרשימה לפני שמחליטים:
- עדכוני גרסה של n8n עצמו, שיוצאים בקצב גבוה ולעיתים כוללים שינויים שוברים בצמתים קיימים
- עדכוני אבטחה של מערכת ההפעלה, של סביבת הקונטיינרים ושל בסיס הנתונים
- גיבויים שמישהו באמת ניסה לשחזר מהם, ולא רק וידא שהם רצים
- ניטור זמינות, כי תהליך שלא רץ בשלוש לפנות בוקר לא שולח על עצמו התראה
- ניהול מפתחות וסיסמאות של כל המערכות המחוברות, הצפנה ומדיניות גישה לממשק
- תשובה לשאלה מה קורה כשהאדם שהקים את זה עוזב או יוצא לחופשה ארוכה
כמה זה עולה, בסדר גודל
נתחיל בהסתייגות: המספרים כאן הם סדרי גודל מהפרויקטים שלנו ומהמחירונים הפומביים, לא מחקר שוק. מחירים משתנים, ואת המספר המדויק צריך לבדוק ביום שאתם קונים.
מנוי n8n Cloud מתחיל בעשרות בודדות של אירו לחודש במדרגה הנמוכה, שמספיקה בהחלט לעסק עם כמה תהליכים שרצים כמה מאות עד אלפי פעמים בחודש. מדרגות גבוהות יותר, עם יותר הרצות, יותר תהליכים פעילים וסביבות נפרדות, נעות במאות אירו לחודש. התמחור מדורג לפי נפח הרצות, כך שהקפיצה בחשבון מגיעה כשמוסיפים תהליכים תכופים, לא כשמוסיפים מורכבות.
בצד השני, שרת שמספיק לעומס של עסק קטן או בינוני עולה בין כמה עשרות שקלים לכמה מאות שקלים בחודש. זה החלק הזול, וזה החלק היחיד שרוב האנשים מחשבים. החלק היקר הוא שעות אדם. מהניסיון שלנו, תחזוקה שוטפת של סביבת n8n עצמית נעה בין שעה לכמה שעות בחודש בשגרה, וקופצת ליום עבודה שלם או יותר כשעדכון גרסה שובר משהו או כשצריך לשחזר מגיבוי. תכפילו את זה בעלות שעת עבודה של מי שיעשה את זה בפועל, בין אם זה עובד פנימי או ספק חיצוני.
כשעשינו את החשבון הזה מול לקוחות, ברוב המקרים המנוי בענן יצא זול יותר מהעלות הכוללת של שרת עצמי, ולפעמים בפער משמעותי. נקודת ההיפוך הכלכלית מגיעה בדרך כלל בנפחי הרצה גדולים מאוד, או כשמחזיקים הרבה סביבות נפרדות, למשל סוכנות שמריצה תשתית לכמה לקוחות. הנקודה חשובה: self-hosted מתחיל להשתלם בגלל נפח, לא בגלל עיקרון.
איפה יושב המידע, ומה באמת עובר דרך שכבת האוטומציה
ל-n8n Cloud יש אזורי אחסון שנבחרים בהרשמה, ואירופה היא האזור הרלוונטי לרוב הלקוחות שלנו. אילו אזורים זמינים בפועל ובאיזו מדרגת מנוי זה דבר שמשתנה מדי פעם, ולכן שווה לבדוק את זה מול הספק ביום ההרשמה ולא להסתמך על מאמר, כולל המאמר הזה. מה שכן בטוח: אין כרגע אזור ישראלי, ולכן אם הדרישה שלכם היא שהמידע לא יצא מגבולות המדינה, הענן לא עונה עליה.
בהתקנה עצמית אתם בוחרים את המיקום. אפשר להעמיד את השרת בפרנקפורט, אפשר אצל ספק אחסון ישראלי, ואפשר בתוך הרשת הפנימית שלכם אם יש לכם כזו. זו היכולת המרכזית שהאפשרות הזאת קונה, וכל השאר הוא נגזרת.
״המידע עובר דרך המערכת״ - מה זה אומר בפועל
אנשים נוטים לדמיין את שכבת האוטומציה כצינור: משהו נכנס בצד אחד ויוצא בצד השני בלי להישאר. זה לא מדויק, וההבדל חשוב כשעונים על שאלון אבטחה של לקוח.
- גוף ההודעה המלא עובר בזיכרון של השרת בזמן ההרצה, כולל שדות שלא נגעתם בהם בכלל
- לוגים של הרצות שומרים בפועל את הנתונים שעברו, כולל תעודות זהות, כתובות, סכומים ותוכן הודעות, אלא אם הגדרתם אחרת במפורש
- כישלונות והרצות חוזרות משכפלים את אותם נתונים לרשומות נוספות
- המפתחות וההרשאות לכל המערכות המחוברות יושבים באותו מקום, וזה בדרך כלל הנכס הרגיש ביותר בסביבה, יותר מהמידע עצמו
אפשר לצמצם את החשיפה הזאת משמעותית: לכבות שמירת נתונים בהרצות מוצלחות, לקצר את תקופת שמירת ההיסטוריה, להעביר מזהים במקום תוכן מלא כשזה אפשרי, ולהוציא שדות רגישים מה-workflow לפני שהם נכנסים אליו. את כל אלה עושים גם בענן וגם בשרת עצמי, בהגדרות. הניסיון שלנו הוא שרוב האנשים לא עושים את זה באף אחת מהאפשרויות, ואז מתווכחים על מיקום השרת.
הזווית הרגולטורית בישראל
נפתח במשפט שאנחנו אומרים בכל פגישה שבה עולה הנושא: אנחנו לא עורכי דין, וזו לא חוות דעת משפטית. אנחנו יכולים להסביר איך המידע זורם ואיפה הוא נשמר. את השאלה מה מותר ומה נדרש צריך לשאול מי שזה המקצוע שלו.
חוק הגנת הפרטיות ותיקון 13 שלו נכנסו לתוקף באוגוסט 2025, והכיוון הכללי ברור: סמכויות האכיפה והפיקוח של הרשות להגנת הפרטיות התרחבו, והחשיפה של עסקים לעיצומים כספיים גדלה. בפועל זה העלה את חשיבות השאלות הבסיסיות - איזה מידע אישי אתם מחזיקים, איפה הוא יושב, מי עוד נוגע בו, ומה קורה כשמישהו מבקש שתמחקו אותו. אנחנו לא נכנסים כאן לסעיפים ספציפיים או לסכומים, כי זה בדיוק המקום שבו מאמרים באינטרנט טועים.
מה שכן אפשר להגיד בביטחון: השאלה הרגולטורית הרלוונטית היא לא ״ענן או שרת״ אלא ״האם אתם יודעים לתאר במדויק את זרימת המידע שלכם״. עסק שמריץ אוטומציות על שרת בתל אביב בלי מיפוי, בלי מדיניות מחיקה ובלי לדעת מי יכול להיכנס לממשק, לא נמצא במצב טוב יותר מעסק שמשתמש בענן מנוהל עם הגדרות מסודרות.
אם אתם משרתים לקוחות באיחוד האירופי, GDPR רלוונטי בלי קשר לאיפה אתם יושבים, ושם יש כללים ברורים יותר לגבי העברת מידע מחוץ לאיחוד. במקרה הזה אזור אחסון אירופי בענן דווקא מקל, ולא מקשה.
יש סקטורים שבהם הדרישה מגיעה מהלקוח ולא מהמחוקק. עסקים שעובדים מול גופי בריאות, מוסדות פיננסיים, גופים ביטחוניים או קבלנים שלהם, נתקלים בשאלוני אבטחה שמצהירים במפורש שמידע לא יוצא מישראל, או שאסור להעביר אותו לספק SaaS צד שלישי. זו דרישה חוזית, והיא מחייבת בדיוק כמו חוק. גם כאן שווה לבדוק לעומק: לא פעם ראינו שהדרישה מתייחסת למערכת הליבה ולנתוני הלקוח הסופי, ולא לשכבת האוטומציה שמעבירה בעיקר מזהים וסטטוסים.
אם אחרי הבדיקה הזאת הדרישה עדיין עומדת - זו סיבה טובה ל-self-hosted. למען האמת, זו כמעט הסיבה היחידה שראינו שמחזיקה מים לאורך זמן.
הבדלים תפעוליים שמרגישים אחרי חצי שנה
שדרוגי גרסה
בענן זה קורה מעצמו, וזה גם החיסרון: לפעמים משהו בהתנהגות של צומת משתנה ואתם מגלים את זה כשתהליך מתנהג אחרת. בשרת עצמי אתם שולטים בתזמון, ולכן אפשר לבדוק לפני, וגם אפשר לדחות שדרוג לשנה שלמה עד שהוא הופך למבצע מסוכן בפני עצמו. שתי הגישות נכשלות בדרכים שונות. הרוב מגלים את זה בפעם הראשונה שהם מדלגים על שלוש גרסאות.
community nodes ואינטגרציות נישתיות
אחד ההבדלים המעשיים ביותר. בשרת עצמי אפשר להתקין כל תוסף קהילתי, וזה קריטי כשצריך אינטגרציה לכלי ישראלי או נישתי שאין לו צומת רשמי. בענן יש סט מאושר, והוא רחב אבל לא הכל. הפתרון בענן הוא בדרך כלל עבודה מול ה-API ישירות דרך צומת HTTP, מה שדורש קצת יותר עבודה אבל עובד כמעט תמיד. אם התהליך שלכם תלוי בתוסף קהילתי מסוים, בדקו את זה לפני שאתם בוחרים ולא אחרי.
סקייל, queue mode ומקביליות
כשנפח ההרצות עולה, הרצה בתהליך יחיד מפסיקה להספיק. n8n תומך במצב תור שבו עובדים נפרדים מושכים משימות, וזה מה שמאפשר להריץ הרבה תהליכים במקביל בלי שהכל יעמוד. בענן זה חלק מהשירות במדרגות המתאימות. בשרת עצמי זו הגדרה שאתם מקימים בעצמכם, עם Redis ועוד רכיבים, וזה כבר לא פרויקט של שעה. עסקים שמגיעים לשם בלי צוות טכני מגלים שהם קנו מערכת שדורשת מהם להיות אנשי תשתיות.
לוגים, דיבאג ושמירת היסטוריה
כשמשהו נשבר, מה שמעניין זה כמה אחורה אפשר להסתכל. בענן יש מדיניות שמירה לפי המנוי. בשרת עצמי אתם קובעים, אבל אתם גם משלמים על האחסון ונושאים בסיכון שהיסטוריה ארוכה מדי היא בעצמה מאגר מידע רגיש שמישהו צריך לאבטח. הגישה שאנחנו מעדיפים היא שמירה קצרה של נתוני הרצה מלאים, יחד עם רישום ארוך של אירועים מסוכמים במקום נפרד, בלי תוכן רגיש.
השוואה מרוכזת
| פרמטר | n8n Cloud | self-hosted |
|---|---|---|
| עלות | מנוי חודשי קבוע לפי מדרגת הרצות, כולל תשתית ותמיכה. צפוי מראש. | עלות שרת נמוכה יחסית, ומעליה שעות אדם לתחזוקה - שהן החלק היקר והנסתר. |
| זמן הקמה | דקות. נרשמים ומתחילים לבנות. | חצי יום עד כמה ימים להקמה שאפשר להישען עליה, כולל בסיס נתונים, SSL, גיבויים וניטור. |
| שליטה במיקום המידע | בוחרים אזור מתוך מה שהספק מציע. אין אזור ישראלי. | שליטה מלאה, כולל אחסון בישראל, אצל ספק מקומי או ברשת פנימית. |
| תחזוקה שוטפת | באחריות הספק. אתם לא מתעסקים בזה. | באחריותכם במלואה: עדכונים, אבטחה, גיבויים, שחזור, זמינות. |
| התאמה לרגולציה מחמירה | מספיק לרוב המקרים, בכפוף לבדיקה מול הדרישות הספציפיות שלכם. | עונה גם על דרישות חוזיות שאוסרות SaaS חיצוני או יציאת מידע מישראל. |
| מתאים למי | רוב העסקים הקטנים והבינוניים בישראל, כברירת מחדל. | מי שיש לו דרישת לקוח או רגולטור למיקום מידע, נפחי הרצה גדולים מאוד, או צוות IT קיים. |
מסגרת החלטה לפי סוג עסק
אם אתם מחפשים תשובה מהירה, נסו למקם את עצמכם באחת מהשורות הבאות. ברוב המקרים אחת מהן מתארת אתכם כמעט במדויק.
- חנות אונליין, סוכנות, משרד מקצועי, עסק שירות או קליניקה בלי דרישות מיוחדות: ענן. אין סיבה עסקית להחזיק שרת.
- עסק שמעבד מידע רפואי, מידע פיננסי מזוהה, או עובד כקבלן משנה של גוף ביטחוני: קודם תבררו מה בדיוק כתוב בדרישה החוזית, ורק אז תחליטו. הרבה פעמים מתברר שהדרישה צרה יותר ממה שחשבתם.
- עסק עם צוות IT שכבר מתחזק שרתים וקונטיינרים: self-hosted הוא תוספת שולית לעומס קיים, וזה מה שהופך אותו להגיוני אצלכם ולא אצל אחרים.
- סוכנות שמריצה תשתית עבור כמה לקוחות, או מי שמגיע לעשרות אלפי הרצות בחודש: החישוב מתחיל לנטות ל-self-hosted, ושווה לעשות אותו ברצינות עם מספרים אמיתיים.
- מי שלא יודע לענות על השאלה מי יעדכן את השרת בעוד שנה: ענן. זו לא שאלה רטורית, זו השאלה המכריעה.
החלק שפחות משתלם לנו להגיד
פרויקטי self-hosted טובים לנו. הם כוללים הקמה, קשיחות, ניטור, ובדרך כלל גם ריטיינר תחזוקה חודשי. פרויקט ענן הוא בעיקר בניית תהליכים, וזהו. אז שווה שתדעו מאיפה אנחנו מדברים כשאנחנו אומרים את המשפט הבא.
לרוב העסקים הקטנים והבינוניים בישראל, n8n Cloud היא ברירת המחדל הנכונה. בחירה ב-self-hosted מתוך תחושה כללית של ״ככה זה יותר בטוח״, בלי דרישה קונקרטית ובלי מישהו שמחזיק את זה לאורך זמן, מייצרת ברוב המקרים שרת פחות מאובטח מהענן: גרסה ישנה, גיבוי שאף אחד לא ניסה לשחזר, ממשק ניהול חשוף לאינטרנט עם סיסמה אחת, וניטור שקיים בראש של מישהו. ראינו את זה מספיק פעמים כדי להפסיק לנסח את זה בעדינות.
ויש מצבים שבהם לא כדאי להביא אותנו בכלל. אם יש לכם שני תהליכים פשוטים, ההקמה בענן והחיבור הראשוני הם משהו שאפשר לעשות לבד תוך כמה ערבים, והכסף שלכם עדיף שילך לשיווק. אם התהליך שאתם רוצים לאטמט עדיין משתנה כל חודש, אין מה לבנות עליו. ואם אתם עומדים להחליף מערכת ליבה בחצי השנה הקרובה, כל מה שנבנה עכשיו ייבנה שוב אחר כך.
שאלון החלטה של עשר דקות
- 1האם יש לקוח, רגולטור או חוזה שדורש במפורש שהמידע יישאר בישראל או לא יעבור ל-SaaS חיצוני. אם כן - self-hosted, וסיימנו.
- 2האם אתם משרתים לקוחות באיחוד האירופי. אם כן, ודאו שאזור האחסון אירופי, בענן או בשרת.
- 3כמה הרצות בחודש אתם צופים בשנה הראשונה. עד כמה אלפים - ענן, בלי לחשוב יותר מדי.
- 4האם יש בעסק מישהו שמתחזק שרתים היום, כחלק מתפקידו. אם אין, אל תיצרו את התפקיד הזה בשביל אוטומציה.
- 5האם אתם תלויים בתוסף קהילתי או באינטגרציה נישתית שאין לה צומת רשמי. אם כן, בדקו אם אפשר לעבוד מול ה-API ישירות לפני שאתם מקימים שרת בשבילה.
- 6כמה יעלה לכם יום שבו כל האוטומציות עומדות. אם התשובה גבוהה, ההבדל בין ענן לשרת הוא בעיקר שאלה של מי עונה לטלפון.
- 7רשמו את התשובות. אם יותר משתיים מהן מצביעות על ענן, בחרו ענן והפסיקו להתלבט.
מה שאנחנו מבקשים מלקוחות לעשות לפני שהם מחליטים זה לכתוב בשלוש שורות איזה מידע יעבור בתהליכים, ומי הצד השני שמבקש הבטחות לגביו. מי שיודע לכתוב את שלוש השורות האלה כבר יודע מה נכון לו. מי שלא, יחליט לפי תחושה, וישלם על התחושה הזאת בתחזוקה.
שאלות שחוזרות
- האם התקנה על שרת שלנו באמת מאובטחת יותר מהענן?
- לא כברירת מחדל. שרת שמעודכן, מגובה, מנוטר ובעל גישה מוגבלת הוא אכן מאובטח יותר, כי אתם שולטים בכל שכבה. שרת שהוקם פעם אחת ונשכח הוא פחות מאובטח מסביבה מנוהלת, כי הפרצות שנסגרות בענן אוטומטית נשארות פתוחות אצלכם. ההבדל הוא לא הארכיטקטורה אלא מי מתחזק אותה בפועל.
- כמה זמן לוקח להקים n8n על שרת פרטי?
- התקנה בסיסית שרצה אפשר לעשות בשעה. התקנה שאפשר להישען עליה בעסק, עם בסיס נתונים חיצוני, דומיין, תעודת SSL, גיבויים אוטומטיים, ניטור והפרדת סביבות, לוקחת בדרך כלל בין חצי יום לכמה ימים תלוי בכמה סדר יש לכם ממילא בתשתית. הפער בין שתי ההתקנות האלה הוא בדיוק מה שאנשים לא מתמחרים.
- אפשר להעביר workflows מהענן לשרת עצמי ובחזרה?
- ה-workflows עצמם עוברים כקובץ JSON ואפשר לייבא אותם לשני הכיוונים. מה שלא עובר: הרשאות וסיסמאות למערכות המחוברות, שצריך להזין מחדש; community nodes שהתקנתם בשרת ולא קיימים בענן; והבדלי סביבה קטנים כמו אזור זמן, משתני סביבה וגרסת n8n. תכננו מעבר כזה כיום עבודה, לא כפעולה טכנית.
- האם n8n Cloud עומד בדרישות חוק הגנת הפרטיות בישראל?
- זו שאלה שמנוסחת קצת לא נכון, ואנחנו לא עורכי דין. האחריות על עמידה בדרישות היא שלכם כמי שאוספים ומעבדים את המידע, לא של הכלי. מה שספק ענן יכול לתת לכם זה בחירת אזור אחסון, הסכם עיבוד מידע ותיעוד של אמצעי האבטחה שלו. את השאלה אם זה מספיק למאגר הספציפי שלכם צריך לשאול עורך דין שמכיר את התחום.
- אנחנו עסק קטן עם חמישה תהליכים. מה נכון לנו?
- כמעט בוודאות n8n Cloud, ובכנות, כנראה שגם לא צריך אותנו כדי להקים אותו. הרשמה, חיבור החשבונות ובניית שני תהליכים ראשונים זה משהו שאדם סביר בעסק יכול לעשות לבד תוך כמה ערבים. שווה להביא גורם חיצוני כשהתהליכים מסתעפים, כשיש חריגים אמיתיים, או כשהעלות של תקלה שקטה גבוהה.
- מה קורה אם נבחר בענן ואחר כך לקוח גדול ידרוש שהמידע יישאר בישראל?
- אז מעבירים. זו אחת הסיבות שאנחנו ממליצים לבנות workflows בצורה נקייה מלכתחילה, בלי תלות בהתנהגויות ייחודיות של סביבה מסוימת. מעבר כזה הוא פרויקט של ימים, לא של חודשים, והוא זול בהרבה מלהחזיק שרת שנתיים בגלל תרחיש שאולי יקרה.