EQVPS

אחסנו-בעצמכם את n8n על VPS עם Docker

15 ביוני 2026 · 2 דק' קריאה · EQVPS Team

n8n הוא סוג הכלי שאתם מתחילים להשתמש בו קלות ואז בשקט מנתבים דרכו חצי מהתפעול שלכם. בנקודה הזו "זה רץ על מושב בענן של מישהו, נמדד לפי הרצה, עם מפתחות ה-API שלי חיים על השרתים שלהם" מתחיל להרגיש פחות נהדר. אחסון-עצמי מתקן את כל השלושה — עלות קבועה, ללא תקרת הרצה, והמפתחות שלכם נשארים על ארגז שאתם הבעלים שלו. עם Docker זו עבודה של חמש-עשרה דקות.

כמה שרת הוא באמת צריך

מספרים כנים קודם, כך שלא תקנו יותר או פחות מדי:

n8n אינו רעב-CPU במנוחה; הוא מתפרץ במהלך ריצות. ארגז 2-ליבות בסדר לרוב ההגדרות. (עוד על התאמת מפרטים ל-workload במדריך המדידה.)

הגדרת ה-Docker

על ארגז Ubuntu/Debian טרי, התקינו Docker:

curl -fsSL https://get.docker.com | sudo sh

צרו תיקייה ו-docker-compose.yml — n8n עם volume מתמשך ו-Postgres:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=db
      - DB_POSTGRESDB_PASSWORD=change-me
    volumes:
      - ./n8n-data:/home/node/.n8n
    depends_on: [db]
  db:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_PASSWORD=change-me
      - POSTGRES_DB=n8n
    volumes:
      - ./db-data:/var/lib/postgresql/data
sudo docker compose up -d

שני דברים ששווה להצביע עליהם: ה-volumes (n8n-data, db-data) הם מה ששומר את ה-workflows שלכם חיים על פני restarts ושדרוגים — אל תדלגו עליהם. ו-n8n קשור ל-127.0.0.1, לא ל-0.0.0.0 — הוא לא חשוף לאינטרנט ישירות. זה מכוון; הצעד הבא מטפל בגישה בבטחה.

גישה: HTTPS או מנהרה

נעלו את זה ושמרו אותו למעלה

n8n מחזיק את מפתחות ה-API והאישורים שלכם, אז הארגז חייב להיות הדוק: עשו את רשימת התיוג לאבטחה (מפתחות SSH, חומת אש, ללא התחברות סיסמה) לפני שאתם שמים אישורים אמיתיים. restart: always בקובץ ה-compose כבר אומר ש-Docker מחזיר את n8n אחרי קריסה או אתחול — זה זמן הפעילות שלכם מטופל.

האם זה שווה את זה?

היו כנים עם עצמכם לגבי נפח. אם אתם מריצים אוטומציות כל הזמן, אחסון-עצמי מנצח בעלות (קבוע מול לפי-הרצה) ומסיר כל מגבלת workflow/הרצה. אם אתם מפעילים כמה flows בחודש, מושב מאוחסן פחות טרחה. אבל טיעון השליטה עומד ללא קשר: ה-workflows שלכם, הנתונים שלכם, המפתחות שלכם — על השרת שלכם, לא מושכר. לרוב האנשים שהתחילו להיות רציניים לגבי n8n, זה הגורם המכריע.

ארגז 2 GB, קובץ compose, דומיין (או מנהרה), ואתם מריצים את מרכז האוטומציה שלכם — משולם בקריפטו ללא KYC, חי תוך דקות.


הגדרה מוכנה-מראש: ראו VPS ל-n8n — התוכנית המומלצת ופריסת קריפטו של דקה.

שאלות נפוצות

כמה RAM n8n באחסון-עצמי צריך?

בערך 2 GB הן הנקודה המתוקה הנוחה ל-n8n בתוספת מסד הנתונים Postgres שלו ו-workflows רגילים. הוא רץ ב-1 GB אם ה-workflows קלים, אבל תרגישו את זה בריצות גדולות יותר. הרצות מקביליות כבדות או payloads גדולים — לכו ל-4 GB.

האם אני צריך Docker כדי לאחסן-בעצמי את n8n?

זו בהרבה הדרך הקלה ביותר — קובץ compose אחד נותן לכם n8n, מסד נתונים ואחסון מתמשך, ושדרוגים הם משיכה בודדת. אתם יכולים להתקין דרך npm במקום, אבל Docker חוסך לכם את כאבי הראש של תלויות ושדרוגים.

האם אחסון-עצמי של n8n זול יותר מ-n8n cloud?

אם אתם מריצים זרם קבוע של אוטומציות, כן — VPS חודשי קבוע מנצח תמחור לפי-הרצה, ואין תקרת workflow או הרצה. לקומץ הרצות בחודש, מושב מאוחסן עשוי להיות פשוט יותר. הסיבה האחרת שאנשים מאחסנים-בעצמם היא שליטה: הנתונים ומפתחות ה-API שלכם לעולם לא עוזבים את השרת שלכם.

האם אני צריך דומיין ל-n8n?

ל-nodes מבוססי-OAuth (Google וכו') ו-HTTPS נקי, כן — כוונו דומיין לשרת ושימו את n8n מאחורי reverse proxy עם תעודה. לשימוש פנימי בלבד אתם יכולים להגיע אליו דרך מנהרת SSH ללא דומיין.

האם n8n יכול לרוץ על NAT VPS או שאני צריך IP ייעודי?

שימוש פנימי/מנהרת-SSH עובד על ארגז NAT. אם אתם רוצים URL ציבורי עם דומיין ו-HTTPS משלכם (נדרש לחלק מ-callbacks של OAuth ו-webhooks), תוכנית עם IP ייעודי היא ההתאמה הנקייה יותר מכיוון שאתם שולטים בכל הפורטים.

← חזרה לבלוגראו תוכניות ומחירים →

תגובות

אין עדיין תגובות. היו הראשונים.

השאירו תגובה

התגובות עוברות מודרציה לפני שהן מופיעות.