n8n בשרת שלכם: מתחילים ב־Hostinger בלחיצה אחת

מה מקבלים כש־n8n רץ על שרת שלכם

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

מה שכן מקבלים במסלול הזה: ממשק n8n פתוח בכתובת ציבורית, אפשרות לקבל Webhooks ממערכות אחרות, ושמירת האישורים אצלכם. Hostinger מתקין את היישום דרך תבנית מוכנה. הוא אינו מפעיל בשבילכם את האוטומציות, אינו בודק אם תהליך עסקי נכשל, ואינו מחליף בעל תפקיד בעסק.

מה לא מקבלים מהתבנית לבדה: זמינות גבוהה, שחזור שנבדק אצלכם, או צוות תמיכה שיכתוב את התהליכים. אם המטרה היא רק לנסות n8n בלי לנהל שרת, עדיף חשבון n8n בענן או כלי מנוהל אחר. אם המטרה היא מערכת שרצה אצלכם, המדריך הזה מתחיל בלחיצה אחת ב־hPanel ולא במעבדת Linux.

• אתם רוצים שהנתונים והאישורים יישארו על שרת שבשליטתכם
• יש אדם שיראה את ה־VPS גם אחרי שבוע, לא רק ביום ההתקנה
• אתם מוכנים לבדוק גיבוי וכניסה מחדש, לא רק לפתוח את העורך פעם אחת
• אתם מבינים שתבנית Hostinger מתקינה את n8n, ולא מנהלת את התהליכים העסקיים

מתי עדיף לא לארח לבד

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

אל תבחרו במסלול הזה אם אין אדם שמוכן להיכנס ל־hPanel כשהאתר לא נפתח; אם השבתה של כמה שעות אינה נסבלת; אם אין לכם דרך לבדוק שחזור; או אם אתם מצפים שספק האחסון יתקן תהליך שנכשל ב־CRM. גם ארגון שחייב זמינות גבוהה, הפרדת אזורים או התאוששות אוטומטית אינו מקבל זאת מ־VPS יחיד.

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

• יש בעלים לחשבון Hostinger ולחשבון n8n, לא סיסמה משותפת בלי אחריות
• העסק הגדיר כמה זמן השבתה וכמה אובדן מידע הוא יכול לסבול
• אפשר לבדוק שחזור מגיבוי או מצילום מצב, ולא רק לראות שגיבוי קיים
• התהליכים הקריטיים כוללים ניסיון חוזר או השלמה ידנית

n8n מנוהל מול שרת משלכם

בשירות מנוהל, כמו n8n בענן, חלק גדול מהתשתית מוסתר מאחורי המוצר. ב־VPS אתם רואים את השרת בלוח הניהול. הגבול זז: n8n מספקת את התוכנה, Hostinger מספק את התבנית ואת השרת, ואתם נשארים אחראים לחשבון הבעלים, לגיבוי שנבדק, לעדכונים ולתהליכים העסקיים.

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

הגדירו מראש מי מקבל התראה, מי רשאי לשנות את התבנית או לשחזר צילום מצב, ומי בודק תהליך עסקי אחרי שינוי. כניסה מוצלחת לעורך מוכיחה שהיישום עלה. היא אינה מוכיחה שדוא״ל, CRM או סליקה עדיין עובדים.

למה המסלול הראשון הוא Hostinger בלחיצה אחת

למתחילים, הדרך הקצרה והבטוחה יותר היא VPS של Hostinger עם תבנית n8n מוכנה. Hostinger עצמה מציגה את התבנית כמסלול שאינו דורש פקודות התקנה, וממליצה עליו מול התקנת npm או בניית Docker ידנית. המדריך הזה מאמץ את אותה המלצה.

הנתיב בלוח הוא hPanel, אחר כך OS/Applications, אחר כך n8n. אצל Hostinger התפריט מופיע כ־OS & Panel ואז Operating System, עם חיפוש תבניות יישום. אם אתם פותחים VPS חדש, בחרו את תבנית n8n כבר בהקמה. אל תתחילו מ־Ubuntu ריק רק כדי ״ללמוד את השרת״.

יש גם תבניות נוספות, למשל n8n במצב תור או תבנית עם אוסף תהליכים מוכנים. למתחילים מספיקה תבנית n8n הרגילה. מצב תור שייך לעומס שכבר מדדתם. אוסף תהליכים מוכנים אינו תחליף לבדיקה שהמערכת שלכם עונה.

התקנה ידנית עם Docker Compose, Ubuntu, חומת אש ו־Caddy נשארת אפשרות למי שכבר מנהל שרתים. היא אינה מסלול הפתיחה של המדריך. אם הגעתם לכאן כי חיפשתם מעבדת Linux, דלגו לסוף וראו את סעיף המסלול המתקדם.

• המסלול הראשון הוא תבנית n8n ב־Hostinger, לא שרת ריק
• תבנית רגילה מספיקה להתחלה. מצב תור אינו חובה
• Docker Compose נשאר מסלול משני למי שצריך שליטה מלאה
• תיעוד Hostinger הרשמי נבדק ביום ההתקנה, כי שמות התפריטים עשויים להשתנות

מה מכינים לפני שפותחים VPS

לפני התשלום, כתבו מי הבעלים של השרת ושל חשבון n8n. אם שני אנשים חולקים סיסמת root בלי תיעוד, יהיה קשה לדעת מי שינה ומי יכול לשחזר. שמרו את פרטי הכניסה למנהל סיסמאות, לא בצילום מסך ולא בצ׳אט.

Hostinger מציינת של־n8n נדרשים לפחות ליבה אחת ו־1 GB זיכרון, וממליצה על שתי ליבות ו־2 GB למרווח. בדקו את הדרישות העדכניות בעמוד התבנית שלהם. אל תבחרו תוכנית לפי מחיר הפתיחה בלבד אם אתם מתכננים תהליכים כבדים או קבצים גדולים.

הכינו תת־דומיין, למשל n8n אצל הדומיין שלכם, גם אם תתחילו קודם עם כתובת ברירת המחדל של Hostinger. רשומת A תצביע לכתובת ה־IP של ה־VPS. אל תחברו דומיין של אתר קיים בלי לבדוק שאתם לא דורסים אתר פעיל.

קבעו חלון קצר אחרי ההתקנה: ברגע ש־Manage App נפתח, יוצרים חשבון בעלים. מסך ההרשמה הראשונית אינו אמור להישאר פתוח לאינטרנט כפתרון זמני.

• יש בעלים ל־hPanel ולחשבון n8n
• נבדקו דרישות הזיכרון והמעבד בעמוד התבנית העדכני
• מוכן תת־דומיין או החלטה מודעת להתחיל בכתובת Hostinger
• סיסמאות יישמרו מחוץ לשרת, לא בהודעה לעובד אחר

התקנה ב־hPanel: OS/Applications ואז n8n

אם עדיין אין VPS, פתחו תוכנית ב־Hostinger ובחרו תבנית n8n כבר במסך מערכת ההפעלה. חפשו n8n תחת היישומים, לא תחת מערכת הפעלה ריקה. אחרי ההקמה המתינו לסיום ההתקנה. אין צורך להתחבר ב־SSH כדי שהיישום יותקן.

אם כבר יש VPS, היכנסו ל־hPanel, פתחו את אזור ה־VPS, לחצו Manage, ואז OS/Applications. אצל Hostinger זה התפריט OS & Panel ואז Operating System. בשדה החיפוש כתבו n8n ובחרו את תבנית n8n הרגילה.

שינוי מערכת הפעלה מוחק את הקבצים בשרת. Hostinger מציגה אזהרה מפורשת. סמנו אותה רק אם אין בשרת אתר או נתונים שצריך לשמור. הזינו סיסמת root חדשה ושמרו אותה במנהל הסיסמאות. אחרי האישור תופיע התקדמות בלוח.

כשההתקנה מסתיימת, חזרו לסקירת ה־VPS ולחצו Manage App. זה פותח את n8n בדפדפן. אם הכפתור עדיין אינו זמין, המתינו לסיום התבנית ורעננו את הדף. אל תתקינו Docker ידנית ״במקביל״ על אותו שרת כדי לזרז.

1. היכנסו ל־hPanel ופתחו את ה־VPS הרלוונטי.
2. בהקמה חדשה בחרו תבנית n8n. בשרת קיים עברו ל־OS/Applications (Operating System) וחפשו n8n.
3. אשרו שינוי מערכת הפעלה רק אם מובן שהשרת יימחק.
4. שמרו את סיסמת ה־root מחוץ לשרת והמתינו לסיום התבנית.
5. בסקירת ה־VPS לחצו Manage App וודאו שנפתח מסך n8n.

כניסה ראשונה וחשבון הבעלים

בפתיחה הראשונה n8n מבקשת ליצור חשבון בעלים. מלאו שם, דוא״ל וסיסמה חזקה וייחודית. זה החשבון שיכול לשנות תהליכים ולראות אישורים. אל תשתמשו בסיסמה של hPanel ואל תשתפו את החשבון כקישור פתוח לצוות.

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

כתובת ברירת המחדל של Hostinger, לעיתים בסגנון srv ואז מספר אצל hstgr.cloud, מספיקה לבדיקה הראשונה. אם הדפדפן מציג אזהרת עוגייה מאובטחת או חוסם כניסה ב־HTTP, עברו לכתובת HTTPS שמופיעה בלוח. אל תכבו בדיקות אבטחה בדפדפן כפתרון קבוע.

רק אחרי כניסה חוזרת מוצלחת כדאי להזמין משתמשים נוספים, אם בכלל. לכל אדם הרשאה משלו. חשבון משותף מקשה לדעת מי פרסם תהליך ומי ראה נתוני הרצה.

• חשבון הבעלים נוצר עם דוא״ל וסיסמה ייחודיים
• יציאה וכניסה מחדש הצליחו
• הכתובת שנשמרה היא כתובת ה־HTTPS שמופיעה ב־hPanel או בדומיין שלכם
• אין מסך הרשמה פתוח למי שלא אמור ליצור בעלים

דומיין, HTTPS וכתובות Webhook

תהליכים שמקבלים נתונים מבחוץ צריכים כתובת ציבורית ב־HTTPS. כתובת IP גולמית או HTTP ישבור חיבורים רבים, כולל חלק מחיבורי OAuth. לכן אחרי שהעורך נפתח, החליטו אם נשארים עם כתובת Hostinger או מחברים תת־דומיין משלכם.

לחיבור דומיין, צרו רשומת A שמצביעה לכתובת ה־IPv4 של ה־VPS כפי שהיא מופיעה בסקירת hPanel. המתינו להתפשטות ה־DNS לפני הבדיקה. אל תוסיפו רשומת AAAA אלא אם IPv6 מוגדר בפועל לכל המסלול.

אחרי שהדומיין מצביע לשרת, עקבו אחרי מדריך Hostinger הרשמי להחלפת דומיין של n8n ב־VPS. התבנית מנהלת את הגישה דרך שכבת פרוקסי משלה. אין צורך לבנות Caddy או Nginx ידנית במסלול למתחילים. אם המסכים אצלכם שונים, הישארו עם התיעוד של Hostinger ולא עם מדריך כללי לרשת.

בעורך n8n, כתובת ה־Webhook חייבת להתחיל ב־https:// ובשם המארח הציבורי שלכם. אם מופיעים localhost או פורט 5678, הכתובת הציבורית עדיין אינה מוגדרת נכון. זו בעיה של הגדרת מארח, לא של צומת ה־Webhook עצמו.

• רשומת A מצביעה ל־IP העדכני של ה־VPS
• הדפדפן נפתח ב־HTTPS בלי אזהרת תעודה חמורה
• כתובת Webhook בעורך מתחילה בדומיין הציבורי או בכתובת Hostinger
• שינוי הדומיין נעשה לפי תיעוד Hostinger, לא לפי ניחוש בקובצי Docker

בדיקה ראשונה שהמערכת באמת עונה

כניסה לעורך אינה מספיקה. צריך תהליך קטן שמוכיח שכתובת ציבורית מגיעה אל n8n וחוזרת עם תשובה. ייבאו את הקובץ test-workflow.json מההורדות. הוא כולל Webhook בשיטת GET בנתיב guide-fixture, ואחריו צומת Code. הוא אינו קורא למערכת לקוחות ואינו מכיל סודות.

הקוד בקובץ מחזיר אובייקט JSON: {"verified":true,"total":21}. השדה verified הוא סימן בדיקה, לא הוכחת אבטחה. במצב Test לחצו Listen for test event וקראו ל־Test URL. לקבלה אמיתית פרסמו את התהליך וקראו ל־Production URL.

ודאו שהכתובת מתחילה ב־https:// ובשם המארח הציבורי. אחרי הצלחה בטלו שוב את פרסום תהליך הבדיקה, אלא אם החלטתם להשאיר אותו כבדיקת ניטור מאושרת. אל תחברו עדיין CRM, דוא״ל או סליקה. קודם מוכיחים שהשרת עונה.

1. ייבאו את test-workflow.json ובדקו שהוא כולל Webhook ואז Code בלבד.
2. לבדיקה זמנית האזינו ל־Test URL. לבדיקה מתמשכת פרסמו וקראו ל־Production URL.
3. ודאו שהתשובה היא {"verified":true,"total":21} ושהכתובת היא HTTPS ציבורי.
4. בטלו את פרסום תהליך הבדיקה אחרי שהקבלה הושלמה.

curl --fail --silent --show-error "https://YOUR_HOSTNAME/webhook/guide-fixture"

תחזוקה שוטפת ב־hPanel: גיבוי, עדכון וגישה

אחרי שהמערכת עונה, התפעול עובר ללוח Hostinger יותר מאשר לטרמינל. בסקירת ה־VPS בודקים שהשרת דולק, שיש מקום בדיסק, ושצריכת הזיכרון אינה נשארת על הקצה. אם השרת כבוי, אף תהליך לא ירוץ, גם אם העורך נראה תקין בצילום מסך ישן.

Hostinger מציינת שגיבוי שבועי אוטומטי פעיל כברירת מחדל ב־VPS, ושאפשר ליצור גם צילום מצב ידני לפני שינוי גדול. אל תסתפקו בכך שהאפשרות קיימת. היכנסו למסך הגיבויים, רשמו מתי נוצר הגיבוי האחרון, וודאו שאתם יודעים איך לשחזר. שחזור שלא תורגל הוא הנחה, לא יכולת.

לפני עדכון n8n או החלפת תבנית, צרו צילום מצב. עדכון תבנית Hostinger רץ בתוך Docker. עקבו אחרי התיעוד העדכני שלהם, לא אחרי פקודות כלליות מפורום. אחרי העדכון היכנסו שוב, פתחו תהליך אחד ובדקו Webhook. אם משהו נשבר, השחזור הוא מצילום המצב ולא מניחוש.

שמרו רשימה קצרה: מי יכול להיכנס ל־hPanel, מי יכול להיכנס ל־n8n, ומי מקבל התראה אם השרת כבוי. אם אדם עוזב את העסק, מחליפים סיסמאות בשני המקומות.

• יודעים איפה הגיבוי האחרון ומתי נוצר
• צילום מצב נוצר לפני עדכון או החלפת תבנית
• אחרי שינוי נבדקו כניסה ו־Webhook
• רשימת המורשים ל־hPanel ול־n8n מעודכנת

אבטחה בסיסית בלי להיות מנהלי שרתים

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

הגבילו את מי שמקבל קישור ל־n8n. אל תפרסמו את הכתובת במודעת דרושים או בצ׳אט פתוח. ב־hPanel החליפו את סיסמת ה־root אם היא נשלחה במייל או נשמרה אצל ספק הקמה. אם יש גישת SSH, השאירו אותה רק למי שצריך. למתחילים, רוב העבודה אמורה להישאר ב־Manage App ובלוח, לא בטרמינל.

אל תמחקו ותיצרו מחדש את התבנית כדי ״לאפס סיסמה״ אם יש תהליכים פעילים. כך נמחקים נתונים. השתמשו באיפוס סיסמה של המשתמש או בשחזור מצילום מצב. אם אתם מחליפים דומיין, בדקו שוב את כתובות ה־Webhook כדי שמערכות חיצוניות לא ימשיכו לשלוח לכתובת ישנה.

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

• סיסמאות hPanel ו־n8n שונות, חזקות ושמורות מחוץ לשרת
• אין חשבון בעלים משותף לכל העסק
• כתובת n8n אינה מפורסמת לקהל כללי
• לפני מחיקת תבנית או שרת נבדק שיש גיבוי שניתן לשחזר

מסלול מתקדם ב־Docker ופתרון תקלות נפוצות

אם Hostinger אינה מתאימה, או אם אתם כבר מנהלים Ubuntu ורוצים Compose, PostgreSQL ו־Caddy בעצמכם, זה מסלול אחר. הוא דורש SSH, חומת אש, DNS, תעודות, גיבוי ושחזור. ערכת Docker שבסוף העמוד שייכת לשם. היא אינה נדרשת כדי להרים n8n ב־Hostinger.

הערכה נבדקה במעבדה מבודדת: התחלה, HTTPS פנימי, Webhook עם Code, גיבוי ושחזור. לא נבדקו אצלה DNS ציבורי, תעודה ציבורית, חומת אש אצל לקוח או עומס ייצור. אל תורידו אותה כקיצור דרך למתחילים.

אם Manage App אינו נפתח, בדקו ב־hPanel שהתבנית הסתיימה ושה־VPS דולק. אם מופיעה אזהרת עוגייה מאובטחת, עברו ל־HTTPS. אם Webhook מציג localhost, חזרו להגדרת המארח אצל Hostinger. אם שיניתם OS בטעות, הנתונים נמחקו. השחזור הוא מגיבוי שנוצר לפני השינוי.

המערכת מתקבלת למתחילים כאשר אפשר להיכנס כבעלים, לקרוא ל־Webhook ציבורי ב־HTTPS, לראות גיבוי ב־hPanel, ולדעת מי מטפל אם השרת כבוי. בלי אלה יש לכם התקנה, לא מערכת שאפשר לסמוך עליה.

• Manage App נפתח וחשבון הבעלים עובד אחרי יציאה וכניסה
• Production URL ציבורי ב־HTTPS מחזיר את הפלט הסינתטי המדויק
• גיבוי או צילום מצב נראים ב־hPanel ותאריכם ידוע
• יש בעל תפקיד לשרת ול־n8n
• ערכת Docker לא הורדה ולא הורצה כחלק ממסלול המתחילים
• מגבלות התבנית מתועדות: VPS יחיד, בלי הבטחת עומס או זמינות גבוהה