SSD Nodes Learn Hosting plans →
מדריכים Matt Connorמאת Matt Connor · עודכן 2026-08-27

התקנת n8n על שרת VPS עם Docker ו-HTTPS

מדריך מלא להקמת n8n ב-Docker Compose עם Postgres ו-reverse proxy. נלמד להגדיר נכון את WEBHOOK_URL ואת ה-encryption-key כדי למנוע שגיאות נפוצות באוטומציה שלכם.

מה אתם בונים

n8n הוא כלי לאוטומציה של תהליכי עבודה: עורך ויזואלי שבו טריגר, webhook, תזמון או טופס שנשלח מפעילים שרשרת של צמתים (nodes) הקוראים ל-APIs, מעבדים נתונים וכותבים למערכות אחרות. הוא הפך לסטנדרט לחיבור תהליכי עבודה של סוכני AI, כיוון שהוא מתממשק לכל ספק מודלים ומסד נתונים ללא צורך בכתיבת שירות ייעודי. docker run אחד מאפשר להפעיל עורך עובד תוך שתי דקות. מדריך זה עוסק ב-90 האחוזים הנותרים: הפיכת המערכת לעמידה באמצעות Postgres במקום קובץ SQLite ברירת המחדל, הנגשתה דרך HTTPS, והחלק שרוב האנשים טועים בו – הגדרת webhooks כך שיפיקו כתובת URL שהעולם החיצון אכן יכול להגיע אליה.

הסטאק הסופי מורכב משתי מכולות על רשת Docker אחת: n8n עצמו, ומסד נתונים Postgres המאחסן את תהליכי העבודה והאישורים שלו. reverse proxy על המארח מבצע TLS termination ומעביר את התעבורה ל-n8n ב-localhost, כך ששום דבר אינו חשוף לאינטרנט מלבד דרך ה-proxy הזה. הוא יושב לצד שירותים אחרים ב-רשימת האירוח העצמי לשנת 2026.

דרישות קדם ומגבלות ריאליות

נדרש VPS עם לפחות 1 GB של RAM. תכננו ל־2 GB כאשר ה־workflows מתחילים לבצע עבודה ממשית, משום שההרצות וסביבת הריצה של Node.js צורכות זיכרון, וה־out-of-memory killer עלול לעצור את המכולה באמצע ההרצה. זו דרך גרועה לגלות שהשרת קטן מדי. vCPU יחיד מספיק בשלב הראשון. אם השרת יפעיל גם שירות כבד יותר, הגדירו את המשאבים לפי דרישות השירות הזה: ספריית תמונות היא בדרך כלל הגורם המגביל, ו־דרישות ה־RAM המעשיות של PhotoPrism ושל Immich גבוהות בהרבה מכל מה ש־n8n דורש. הדבר נכון גם לשרת מדיה: שרת Jellyfin יחד עם ממשק קדמי שניתן לעיין בו, כגון Halcyon, שבונה מחדש את הספרייה כחנות השכרת סרטים משנות ה־90, יתפסו את זיכרון ה־RAM ואת מרווח הביצועים הנדרש ל־transcoding זמן רב לפני ש־n8n יבחין בכך.

עליך להחזיק דומיין או סאב-דומיין, למשל n8n.example.com, עם רשומת A המצביעה לכתובת ה-IP הציבורית של ה-VPS ושמתורגמת (resolves) לפני שתבקש תעודה. פורטים 80 ו-443 חייבים להיות פתוחים ל-proxy; הפורט של n8n עצמו, 5678, אסור שיהיה חשוף לאינטרנט. עליך להתקין את Docker Engine ואת תוסף ה-Compose; אם docker compose version מחזיר שגיאה עם docker: 'compose' is not a docker command, סימן שמותקן אצלך הקובץ הבינארי העצמאי הישן, והתוסף הוא sudo apt install docker-compose-plugin.

SQLite מתאים לבדיקות, Postgres לכל מה שאתם מסתמכים עליו

מסד הנתונים המוגדר כברירת מחדל ב-n8n הוא קובץ SQLite בנתיב /home/node/.n8n/database.sqlite. לצרכי התרשמות ראשונית זה מספיק, אך אם לא תבצעו mount לנפח אחסון (volume), הנתונים יאבדו עם יצירת המכולה מחדש, מה שמהווה שיעור חשוב בפני עצמו. הסיבה למעבר ל-Postgres אינה מהירות גולמית; הסיבה היא ש-SQLite מחזיק מנעול כתיבה יחיד. לכן, מופע שמריץ כמה תהליכי עבודה (workflows) במקביל, או מצב תור (queue mode) שתזדקקו לו בהמשך, יחזיר שגיאת SQLITE_BUSY: database is locked תחת עומס. ל-Postgres אין מגבלות כאלו, הוא מאפשר גיבוי נקי באמצעות pg_dump, והוא מסד הנתונים שתיעוד ה-n8n מניח שבו תשתמשו עבור שרת שאתם מסתמכים עליו. מעבר מאוחר יותר ידרוש העברת נתונים ידנית, לכן אם השרת הזה חשוב לכם, התחילו עם Postgres.

DNS וחומת האש

הגדירו תחילה את רשומת ה-DNS ופתחו את הפורטים, כדי ששלב הנפקת התעודה לא ייכשל עקב שם מתחם שאינו מתרגם לכתובת IP.

dig +short n8n.example.com
curl -s ifconfig.me
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow OpenSSH
sudo ufw enable

אין לפתוח את פורט 5678. קובץ ה-compose מגדיר את n8n ל-127.0.0.1:5678, כך שרק ה-reverse proxy של המארח יוכל לגשת אליו; פתיחת ufw allow 5678 תבטל את הבידוד הזה.

קובץ ה-Compose

צרו ספריית עבודה וקובץ docker-compose.yml. זהו ה-stack המלא, הכולל שני שירותים, רשת פנימית אחת ושני volumes בעלי שם.

services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - n8n_net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
      interval: 10s
      timeout: 5s
      retries: 5

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.29.10
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.example.com/
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_PROXY_HOPS=1
      - GENERIC_TIMEZONE=Europe/London
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    networks:
      - n8n_net
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres_data:
  n8n_data:

networks:
  n8n_net:

כמה החלטות שראוי לציין במפורש. DB_POSTGRESDB_HOST=postgres הוא שם השירות, ש-Docker פותר ברשת המשותפת, בניגוד ל-localhost, שבתוך ה-container של n8n מתייחס ל-n8n עצמו. ה-depends_on עם condition: service_healthy מונע מ-n8n לנסות להתחבר ל-Postgres לפני שהוא מוכן בעת העלייה; בלעדיו n8n מתחיל, לא מוצא מסד נתונים ונסגר. ה-volume בעל השם n8n_data בנתיב /home/node/.n8n מאחסן את מפתח ההצפנה ובמקרה של SQLite, גם את מסד הנתונים – זו הספרייה שאסור לאבד. קבעו את גרסת ה-image לגרסה ספציפית, לעולם אל תשתמשו ב-latest; הסיבות לכך מפורטות בסעיף השדרוגים להלן.

קובץ ה-secrets

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

printf 'POSTGRES_PASSWORD=%s\n'  "$(openssl rand -hex 24)" >  .env
printf 'N8N_ENCRYPTION_KEY=%s\n' "$(openssl rand -hex 32)" >> .env
chmod 600 .env

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

משתני הסביבה הקובעים אם Webhooks יפעלו

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

  • N8N_HOST הוא שם המארח הציבורי, n8n.example.com. השאירו אותו כברירת המחדל localhost כאשר אתם מאחורי proxy, אחרת העורך ינסה לטעון את ה-API של עצמו מ-localhost בתוך הדפדפן שלכם, מה שייכשל.
  • N8N_PROTOCOL=https מורה ל-n8n שהוא מוגש מעל TLS, לכן הוא מסמן את ה-cookie של הסשן כ-Secure ובונה כתובות URL מסוג https://.
  • N8N_PORT=5678 הוא הפורט שבו n8n מאזין בתוך המכולה. זה אינו הפורט הציבורי; ה-proxy הוא זה שמחזיק ב-443.
  • WEBHOOK_URL=https://n8n.example.com/ הוא המשתנה שגורם לבעיות. n8n מדפיס את כתובות ה-webhook שאתם מדביקים ב-Stripe, ב-GitHub או בכל גורם חיצוני אחר על ידי בנייתן מערכים אלו. אם הוא לא מוגדר או שגוי, n8n חוזר ל-N8N_HOST:N8N_PORT ומספק לכם https://n8n.example.com:5678/webhook/... או, במקרה הגרוע, http://localhost:5678/webhook/..., המודפסים ללא שגיאה, נראים תקינים אך אינם נגישים מהאינטרנט, כך שהבקשות של הגורם החיצוני פשוט לא מגיעות. הגדירו אותו לכתובת ה-URL הציבורית המדויקת עם לוכסן (slash) בסוף, ולאחר מכן ודאו שצומת ה-webhook מציג כתובת URL ללא פורט.

N8N_PROXY_HOPS=1 מורה לשרת ה-Express של n8n לבטוח ב-proxy אחד לפניו, כך שהגבלת קצב (rate-limiting) וכל תכונה שקוראת את ה-IP של הלקוח יראו את הכתובת האמיתית ולא את זו של ה-proxy. משתנה אחד שאתם לא צריכים להגדיר כאן הוא N8N_RUNNERS_ENABLED: מריצי משימות (task runners), המריצים את הלוגיקה של ה-Code-node ב-n8n בתהליך מבודד (sandboxed), הם ברירת המחדל מאז גרסה 1.69 והם חובה החל מקו גרסאות 2.x שבו מדריך זה מתמקד, לכן האפשרות הישנה אינה רלוונטית עוד. אם תגדירו אותו כעת, n8n פשוט ירשום הודעה בלוג המורה לכם להסירו.

הפעלה ראשונה

docker compose up -d
docker compose ps
docker compose logs -f n8n

עלייה תקינה בפעם הראשונה מסתיימת בשורת Editor is now accessible via:, כאשר מעליה מופיעה שורת n8n ready on ..., port 5678. הפקודה docker compose ps צריכה להציג את שני הקונטיינרים Up, כאשר postgres מסומן כ-(healthy). אם n8n תקוע בלולאת Restarting, יש לקרוא את הלוגים; ברוב המוחלט של המקרים מדובר בבעיית חיבור למסד הנתונים או בהרשאות על ה-volume, כפי שמתואר בהמשך.

TLS עם reverse proxy

n8n עצמו מתקשר ב-HTTP רגיל בפורט 5678; רכיב כלשהו בחזית מבצע TLS termination. ישנן שתי אפשרויות פשוטות.

אם אתם כבר מריצים כמה מכולות, הציבו את n8n מאחורי reverse proxy מסוג Traefik שמנפיק תעודות TLS באופן אוטומטי. באמצעות מספר תוויות (labels), Traefik יבקש ויחדש עבורכם את התעודה.

אם זהו היישום היחיד על השרת, הגדרת virtual host ב-nginx עם תעודת Let's Encrypt היא פשוטה יותר. השתמשו ב-מדריך הגדרת TLS עם Certbot ו-nginx עבור Ubuntu 24.04 כדי להנפיק את התעודה, ולאחר מכן השתמשו בבלוק ה-server הבא:

server {
    listen 443 ssl;
    server_name n8n.example.com;

    ssl_certificate     /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600;
        client_max_body_size 16m;
    }
}

ה-headers מסוג Upgrade ו-Connection "upgrade" אינם אופציונליים. n8n דוחף עדכוני הרצה בזמן אמת לעורך באמצעות WebSocket, ובלי שתי השורות הללו דף ההתחברות ייטען אך ייתקע עם הודעת שגיאה על אובדן חיבור. proxy_read_timeout 3600 מונע מהרצות ארוכות להיקטע לאחר 60 שניות, שהן ברירת המחדל של nginx. ה-header מסוג X-Forwarded-Proto $scheme הוא המשלים ל-N8N_PROXY_HOPS=1: הוא מדווח ל-n8n שהבקשה המקורית הייתה HTTPS, אף על פי שה-proxy ניגש אליו ב-HTTP רגיל. כך n8n לא יחליט שהחיבור אינו מאובטח ולא ידחה את ה-cookie שלו.

ה-workflow הראשון שלך, כדי להפוך את זה לממשי

פתח את https://n8n.example.com/, צור את חשבון הבעלים (בסעיף הבא), ובנה את ה-workflow הקטן ביותר שמוכיח שהנתיב עובד: webhook נכנס, קריאת HTTP, ותגובה יוצאת.

  1. הוסף צומת Webhook. הגדר את השיטה ל-POST ואת הנתיב ל-hello. הוא מציג שני כתובות URL, Test URL ו-Production URL, שהם המקור למחצית מהדיווחים על "ה-webhook שלי לא עובד". ה-Test URL עונה לקריאה אחת בלבד, ורק בזמן שלחצת על Listen for test event; לאחר מכן הוא פג תוקף. ה-Production URL עונה בכל פעם שה-workflow במצב Active.
  2. הוסף אחריו צומת HTTP Request, המופנה לכל API ציבורי של JSON; קריאת GET ל-https://api.github.com/zen מחזירה מחרוזת בשורה אחת, וזה מספיק.
  3. הוסף צומת Respond to Webhook, והגדר את אפשרות ה-Respond של צומת ה-Webhook ל-"Using Respond to Webhook node" כדי שהקולט יקבל בחזרה את הפלט של צומת ה-HTTP.
  4. העבר את ה-workflow למצב Active (בפינה הימנית העליונה) וקרא לו: curl -X POST https://n8n.example.com/webhook/hello. אתה אמור לקבל בחזרה את שורת ה-zen; POST נכנס, קריאת API, ותגובה יוצאת – זהו המבנה של רוב האוטומציות האמיתיות.

גרסה מתוזמנת מחליפה את צומת ה-Webhook ב-Schedule Trigger וקוראת במקום זאת ל-endpoint של מודל; מודל שמתארח באופן עצמי מתוך Ollama שרץ על אותו VPS הוא דרך מסודרת לבנות מסכם לילי.

ניהול משתמשים, לא basic auth

מדריכים ישנים של n8n מורים להגדיר את N8N_BASIC_AUTH_ACTIVE=true. משתנים אלה הוסרו ב־n8n 1.0 וכיום אינם עושים דבר. מנגנון האימות כיום הוא חשבון הבעלים: בפעם הראשונה שטוענים את עורך n8n, n8n מחייב ליצור חשבון בעלים עם כתובת דוא״ל וסיסמה. שלב זה הוא חובה, ואין מצב אנונימי. צרו את החשבון מיד לאחר האתחול הראשון, לפני שתמסרו למישהו את כתובת ה־URL: בין docker compose up לבין שליחת הטופס הראשונה, כל מי שיגיע למופע יוכל לתבוע עליו בעלות. שכבת basic-auth ב־reverse proxy היא שכבת הגנה נוספת וסבירה, אך היא גורם אימות נוסף ולא מנגנון האימות העיקרי. חשבון הבעלים וכל שאר הרכיבים במדריך זה פועלים במהדורת הקהילה החינמית. אם בהמשך תרצו משתמשים נוספים עם תפקידים מפורטים, או SSO, כדאי לקרוא את אילו תכונות של n8n דורשות רישיון בתשלום לפני שתתכננו את המערכת על סמך תכונות אלה.

גיבויים: תחילה מפתח ההצפנה, לאחר מכן מסד הנתונים

יש לגבות שני רכיבים, ורמת החשיבות שלהם אינה זהה.

ה-N8N_ENCRYPTION_KEY. כל פרט אימות שאתם מאחסנים ב-n8n, אסימוני API, סיסמאות למסדי נתונים וסודות OAuth, מוצפן במנוחה באמצעות מפתח זה. תהליכי העבודה (workflows) ב-Postgres חסרי תועלת בלעדיו: שחזור מסד הנתונים לשרת חדש עם מפתח שונה ימנע מ-n8n לפענח ולו פרט אימות אחד, ללא אפשרות שחזור או איפוס. קובץ ה-.env שלכם מכיל את המפתח; העתיקו אותו למקום מחוץ לשרת, רשומה במנהל סיסמאות היא פתרון אידיאלי, כבר ביום יצירתו. זהו הגיבוי החשוב באמת.

מסד הנתונים Postgres, עבור תהליכי העבודה, היסטוריית ההרצות ופרטי האימות המוצפנים עצמם:

docker compose exec -T postgres pg_dump -U n8n -d n8n \
  | gzip > n8n-db-$(date +%F).sql.gz

הריצו פקודה זו לפי לוח זמנים והעתיקו את ה-dump מחוץ לשרת. כדי לשחזר ב-VPS חדש: העלו את ה-stack פעם אחת כדי שמסד הנתונים ייווצר, עצרו את n8n, טענו את ה-dump בחזרה באמצעות psql, הציבו את אותו ה-N8N_ENCRYPTION_KEY בתוך .env, והפעילו את n8n. מפתח זהה בצירוף ה-dump יניבו מופע תקין; מפתח חדש יניב תהליכי עבודה שלא יוכלו להשתמש באף פרט אימות.

שדרוגים: קיבוע ה־tag

קובץ ה-compose מקבע את n8nio/n8n:2.29.10 במקום את latest בכוונה תחילה. n8n משחררת גרסה מינורית חדשה כמעט מדי שבוע, ולעיתים משנה את מבנה מסד הנתונים או את התנהגות ה-nodes ביניהן. לכן, latest משמעו שפעולת pull אוטומטית עלולה לספק לכם build שמבצע מיגרציה למסד הנתונים ברגע העלייה. קבעו גרסה ספציפית, קראו את הערות השחרור לפני עדכון הגרסה; n8n מציינת שם שינויים שעלולים לשבור תאימות, ובצעו את השדרוג באופן יזום:

docker compose exec -T postgres pg_dump -U n8n -d n8n | gzip > pre-upgrade.sql.gz
# edit the image tag in docker-compose.yml, then:
docker compose pull n8n
docker compose up -d n8n
docker compose logs -f n8n

קפיצות בין גרסאות major הן המקרה שבו הדבר קריטי ביותר. סדרת 2.0, לדוגמה, שינתה את ברירת המחדל של N8N_BLOCK_ENV_ACCESS_IN_NODE ל-true, כך שכל Code node שקרא את process.env מאבד גישה בשקט עד שתגדירו זאת חזרה ל-false; אותו שחרור החל לאכוף הרשאות קשיחות על קובץ ההגדרות. קראו את דף השינויים השוברים בגרסה 2.0 לפני חציית גבול של גרסת major. n8n מריצה כל מיגרציה נדרשת למסד הנתונים באופן אוטומטי בעת העלייה, וזו בדיוק הסיבה לכך שביצוע pg_dump לפני השדרוג אינו אופציונלי. מכיוון שפרטי הגישה נשמרים מוצפנים עם מפתח ב-.env והנתונים נמצאים ב-Postgres, המכולות הן זמניות: אתם משדרגים על ידי החלפתן, ומבצעים rollback על ידי קיבוע ה-tag הקודם ושחזור ה-dump.

מצבי כשל והודעות שגיאה נפוצות

The requested webhook "POST hello" is not registered. שגיאת 404 מתקבלת בעת קריאה ל-webhook שזרימת העבודה (workflow) שלו אינה במצב Active, או בעת קריאה לנתיב הבדיקה כאשר אין מאזין פעיל. נתיבי בדיקה (/webhook-test/...) משיבים רק כאשר לחצת על "Listen for test event"; נתיבי ייצור (/webhook/...) משיבים רק כאשר מתג זרימת העבודה מופעל. השגיאה התאומה This webhook is not registered for GET requests. Did you mean to make a POST request? מציינת שהמתודה שגויה; הצומת מצפה ל-POST ואתה שלחת GET.

כתובת ה-webhook מציגה :5678 או localhost. הצומת מציג https://n8n.example.com:5678/webhook/... או http://localhost:5678/.... המשתנה WEBHOOK_URL אינו מוגדר או שגוי, ולכן n8n בנתה את הכתובת מתוך N8N_HOST:N8N_PORT במקום מכתובת הבסיס הציבורית שלך. הגדר את WEBHOOK_URL=https://n8n.example.com/, צור מחדש את המכולה באמצעות docker compose up -d, והפורט ייעלם.

There was a problem loading init data בדפדפן. העורך נטען אך אינו מצליח להגיע ל-API של ה-backend של עצמו. מאחורי proxy, זו כמעט תמיד בעיה של N8N_HOST או WEBHOOK_URL שגויים, proxy שחסרים בו כותרי (headers) ה-WebSocket מסוג Upgrade, או ש-N8N_PROTOCOL אינו תואם לדרך שבה אתה מתחבר. ודא את ארבעת המשתנים הפונים לציבור וודא שה-proxy מעביר את Upgrade ו-Connection.

password authentication failed for user "n8n" בלוגים, כשהמכולה מבצעת אתחול חוזר. הסיסמה ש-n8n שולחת אינה תואמת לזו ששימשה לאתחול מסד הנתונים. המלכודת: Postgres קורא את POSTGRES_PASSWORD רק כאשר הוא מאתחל ספריית נתונים ריקה. הפעל את ה-stack פעם אחת, לאחר מכן שנה את POSTGRES_PASSWORD ב-.env, וה-volume הקיים של postgres_data עדיין יחזיק בסיסמה הישנה. החזר את הסיסמה המקורית, או, אם אין לך נתונים לשמור, בצע docker compose down ו-docker volume rm ל-volume של postgres, ואז העלה אותו מחדש.

EACCES: permission denied, open '/home/node/.n8n/config' בעת עלייה. n8n רץ כמשתמש node (UID 1000) ואינו יכול לכתוב לספריית התצורה שלו. בעיה זו מתרחשת אצל משתמשים המבצעים bind-mount לתיקייה מארחת (./n8n_data:/home/node/.n8n) שבבעלות root. השתמש ב-named volume המוצג לעיל, או אם אתה מתעקש על bind mount, בצע sudo chown -R 1000:1000 ./n8n_data תחילה.

Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide. Changing permissions to 0600.. החל מגרסה 2.x, n8n אוכפת 0600 על קובץ ההגדרות כברירת מחדל ומתקנת זאת בעצמה בעת העלייה. שורת לוג זו מציינת שהיא כבר תיקנה את ההרשאות, בדרך כלל לאחר bind mount או לאחר שפעולת שחזור העתיקה את הקובץ עם הרשאות רופפות. אין צורך בפעולה; הגדר את N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false רק אם מערכת הקבצים שלך אינה מסוגלת לתמוך בהרשאות.

Mismatching encryption keys, השורה המלאה מציינת שמפתח ההצפנה בקובץ ההגדרות /home/node/.n8n/config אינו תואם ל-N8N_ENCRYPTION_KEY בסביבה שלך. המפתח בסביבה שלך שונה מזה ש-n8n כתבה ל-volume הנתונים שלה בהרצה קודמת, לרוב משום ש-n8n יצרה מפתח אקראי בעלייה מוקדמת יותר כאשר המשתנה לא היה מוגדר, ואז הגדרת מפתח אחר. החזר את המפתח המקורי ל-.env, או, רק אם באמת אין לך אישורים שמורים ששווה לשמור, מחק את הקובץ config בתוך ה-volume של n8n_data ואפשר ל-n8n ליצור אותו מחדש, תוך קבלת העובדה שהאישורים הקיימים יהפכו לבלתי קריאים.

באנר התחברות בנושא עוגיות מאובטחות: Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari. הגדרת N8N_PROTOCOL=https אך הגעת ל-n8n דרך HTTP רגיל, בדרך כלל על ידי פנייה ישירה לכתובת ה-IP והפורט במקום דרך ה-HTTPS proxy. גש לשירות דרך https://n8n.example.com/. רק אם אינך יכול להשתמש ב-HTTPS בשום אופן, עליך להגדיר את N8N_SECURE_COOKIE=false, ולעולם אל תעשה זאת על שרת החשוף לאינטרנט.

כדי להטמיע מודל שפה בתוך זרימות עבודה אלו, ראה בניית זרימות עבודה מבוססות AI עם Claude ו-n8n.

FAQ

האם כדאי להשתמש ב-SQLite או ב-Postgres עבור n8n?

SQLite (ברירת המחדל) מתאים לניסוי ראשוני ב-n8n ולמופע אישי המריץ תהליך עבודה אחד בכל פעם. עברו ל-Postgres עבור כל שירות שאתם מסתמכים עליו: מנגנון הנעילה לכתיבה יחידה של SQLite גורם לשגיאת database is locked בעת עבודה במקביל, בעוד ש-Postgres מאפשר גיבוי נקי באמצעות pg_dump. הגירה בשלב מאוחר יותר דורשת עבודה ידנית, לכן אם השרת חשוב, התחילו מראש עם Postgres.

מדוע ה-webhooks ב-n8n לא מופעלים לעולם?

כמעט תמיד מדובר ב-WEBHOOK_URL. אם המשתנה לא מוגדר או שגוי, n8n מציג כתובות webhook המבוססות על N8N_HOST:N8N_PORT, שלעיתים קרובות כוללות :5678 או localhost; הכתובות נראות תקינות אך אינן נגישות מהאינטרנט, ולכן בקשות השולח אינן מגיעות ליעדן. הגדירו את WEBHOOK_URL=https://n8n.example.com/ וודאו שהצומת מציג כתובת URL ללא פורט. סיבה שנייה היא קריאה ל-webhook שתהליך העבודה שלו אינו מוגדר כ-Active, מה שמחזיר The requested webhook ... is not registered..

מה עלי לגבות ב-n8n?

שני דברים. את ה-N8N_ENCRYPTION_KEY מקובץ ה-.env שלכם, כיוון שכל פרט אימות מאוחסן מוצפן באמצעותו, ואובדנו יהפוך אותם לבלתי ניתנים לפענוח לצמיתות; העתיקו אותו מחוץ לשרת ביום יצירתו. בנוסף, בצעו pg_dump למסד הנתונים Postgres עבור תהליכי העבודה, ההיסטוריה ופרטי האימות. שחזור דורש את שניהם: את אותו המפתח יחד עם הגיבוי.

כיצד אוכל להציב את n8n מאחורי HTTPS?

n8n מגיש HTTP רגיל בפורט 5678; reverse proxy בחזית מבצע את ה-TLS termination. הגדירו את n8n להאזין ל-127.0.0.1:5678 כך שרק ה-proxy יוכל להגיע אליו, ולאחר מכן השתמשו ב-Traefik עם תעודות אוטומטיות או ב-nginx עם תעודת Let's Encrypt. הגדירו את N8N_PROTOCOL=https ו-WEBHOOK_URL=https://your-host/, וודאו שה-proxy מעביר את ה-headers של ה-WebSocket ב-Upgrade, אחרת העורך יקפא.

כיצד לשדרג את n8n בצורה בטוחה?

קבעו גרסת image ספציפית במקום latest, בצעו pg_dump תחילה כיוון ש-n8n מריץ הגירות (migrations) באופן אוטומטי בעת העלייה, קראו את הערות השחרור (release notes) עבור שינויים שעלולים לשבור תאימות, ולאחר מכן עדכנו את התג והריצו docker compose pull n8n && docker compose up -d n8n. המכולה היא זמנית, לכן ניתן לבצע חזרה לגרסה קודמת (rollback) על ידי קיבוע התג הקודם ושחזור הגיבוי שבוצע לפני השדרוג.

#n8n#automation#docker#self-hosting#https