מאת Matt Connor 2026-07-15 · עודכן 2026-07-24

איך להתקין n8n ב-VPS עם Docker ו-HTTPS

Q: מדוע ה-webhooks של n8n לא עובדים?

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

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

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

Q: איך משדרגים n8n בצורה בטוחה?

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

מדריך להרצת n8n ב-Docker Compose עם Postgres. נלמד איך להימנע משגיאות ב-WEBHOOK_URL וב-encryption-key כדי להבטיח עבודה תקינה עם HTTPS ו-Reverse Proxy.

מה אתם בונים

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

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

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

עליך להשתמש ב-VPS עם לפחות 1 GB של RAM; מומלץ לתכנן ל-2 GB כאשר תהליכי העבודה הופכים למורכבים יותר. הרצת תהליכים יחד עם סביבת ה-Node.js צורכות זיכרון רב, וסוגר ה-out-of-memory שמפסיק את ה-container באמצע הריצה הוא דרך קשה ללמוד זאת. vCPU אחד מספיק להתחלה.

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

SQLite מתאים לבדיקות, Postgres מתאים לכל דבר קריטי

מסד הנתונים الافتراضي של n8n הוא קובץ SQLite בנתיב /home/node/.n8n/database.sqlite. הוא מתאים לבדיקות ראשוניות — אם לא תגדירו volume, הנתונים יימחקו עם יצירה מחדש של ה-container, וזהו שיעור חשוב בפני עצמו. הסיבה לעבור ל-Postgres אינה מהירות גרידא; SQLite משתמש בנעילת כתיבה יחידה (single writer lock), ולכן מופע שמריץ מספר workflows במקביל, או במצב queue mode שיידרש לכם בהמשך, יגרום לשגיאות SQLITE_BUSY: database is locked תחת עומס concurrency. ל-Postgres אין מגבלות כאלו, הוא תומך בגיבוי נקי באמצעות pg_dump, והוא מסד הנתונים שתיעוד ה-official של n8n מניח שיעמוד בשרת קריטי. מעבר מאוחר יותר ידרוש הגירה (migration) של הנתונים באופן ידני, לכן אם השרת חשוב לכם, התחילו עם Postgres.

DNS וה-firewall

יש להגדיר תחילה את הרשומה ולפתוח את הפורטים. פעולה זו תמנע שגיאה בשלב הוצאת התעודה (certificate) עקב שם שאינו נפתר (resolve).

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 — שני שירותים, רשת פרטית אחת ו-two named 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 הוא ה-service name, ש-Docker פותר ברשת המשותפת — לא localhost, שמשמעותו בתוך ה-container של n8n הוא n8n עצמו. ה-depends_on עם condition: service_healthy מונע מ-n8n לרוץ לפני Postgres בזמן ה-boot; ללא זה, n8n יתחיל, לא ימצא מסד נתונים ויצא. ה-named volume בשם n8n_data בנתיב /home/node/.n8n מכיל את מפתח ההצפנה, ובמקרה של SQLite, את מסד הנתונים — זו הספרייה היחידה שאסור לאבד. קבעו את ה-image לגרסה מדויקת, לעולם לא latest; הסיבות לכך מופיעות בסעיף השדרוג להלן.

קובץ ה-secrets

לעולם אל תכניס סיסמאות בתוך ה-compose file. יש להניח אותן בקובץ .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 הוא ה-hostname הציבורי, n8n.example.com. אם תשאיר אותו בברירת המחדל localhost מאחורי Proxy, העורך ינסה לטעון את ה-API שלו מ-localhost בדפדפן שלך, מה שיגרום לשגיאה.
N8N_PROTOCOL=https מודיע ל-n8n שהוא מוגש באמצעות TLS, ולכן הוא מסמן את ה-session cookie שלו כ-Secure ובונה URL-ים מסוג https://.
N8N_PORT=5678 הוא ה-port שבו n8n מאזין בתוך ה-container. זהו לא ה-port הציבורי; ה-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/... — כתובות שנראות הגיוניות אך אינן ניתנות להגעה מהאינטרנט, ולכן הבקשות מהקורא החיצוני לא יגיעו לעולם. הגדר אותו כ-base URL הציבורי המדויק עם לוכסן (/) בסוף, ולאחר מכן ודא שצומת ה-webhook מציג URL ללא port.

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

First start

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 אמור להציג את שני ה-containers ב-Up, כאשר postgres מסומן כ-(healthy). אם n8n נמצא בתוך Restarting loop, יש לקרוא את ה-logs — הסיבה היא כמעט תמיד חיבור ה-database או הרשאות ה-volume המפורטות להלן.

TLS עם reverse proxy

n8n עצמו משתמש ב-HTTP רגיל בפורט 5678; רכיב מקדים (front) אמור לנהל את ה-HTTPS. ישנן שתי אפשרויות פשוטות.

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

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

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, וללא שתי השורות הללו, דף ההתחברות ייטען ואז ייתקע עם הודעת "lost-connection". proxy_read_timeout 3600 מונע מביצועים ארוכים להיקטע בגלל מגבלת ה-60 שניות الافتراضית של nginx. ה-header של X-Forwarded-Proto $scheme הוא המשלים ל-N8N_PROXY_HOPS=1: הוא מודיע ל-n8n שהבקשה המקורית הייתה ב-HTTPS למרות שה-proxy מתקשר איתו ב-HTTP רגיל, וכך n8n לא יזהה את החיבור כלא מאובטח וידחה את ה-cookie שלו.

תזרים העבודה הראשון שלך, כדי להפוך אותו למציאות

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

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

גרסה מתוזמנת מחליפה את צומת ה-Webhook ב-Schedule Trigger וקוראת לנקודת קצה (endpoint) של מודל במקומו — שימוש במודל המארח את עצמו מתוך Ollama running on the same VPS הוא דרך יעילה לבנות מסכם נתונים יומי.

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

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

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

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

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

מסד הנתונים Postgres, עבור ה-workflows, היסטוריית ההרצות (execution history) ופרטי האימות המוצפנים עצמם:

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 יוצר מופע (instance) עובד; מפתח חדש יצור workflows שלא יוכלו להשתמש באף פרט אימות.

Upgrades: pin the tag

קובץ ה-compose משתמש ב-n8nio/n8n:2.29.10 במקום ב-latest בכוונה. n8n מוציאה גרסה minor חדשה כמעט בכל שבוע, ולעיתים משנה את סכימת מסד הנתונים או את התנהגות ה-node בין גרסאות. לכן, שימוש ב-latest עלול לגרום לכך ש-pull אוטומטי יוריד גרסה שתבצע migration למסד הנתונים ברגע ההפעלה. יש לקבע גרסה (pin), לקרוא את release notes לפני שדרוג — n8n מציינת שם שינויים שוברים (breaking changes) — ולבצע שדרוג באופן מבוקר:

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; אותה גרסה החלה גם לאכוף הרשאות מחמירות על קובץ ה-settings. יש לקרוא את 2.0 breaking-changes page לפני מעבר בין גרסאות major. n8n מריצה כל migration נדרש למסד הנתונים באופן אוטומטי בעת ההפעלה — זו הסיבה המדויקת לכך ש-pg_dump לפני השדרוג אינו אופציונלי. מכיוון שה-credentials נשמרים מוצפנים עם מפתח ב-.env והנתונים נשמרים ב-Postgres, ה-containers הם disposable: השדרוג מתבצע על ידי החלפתם, והחזרה לאחור (roll back) מתבצעת על ידי קיבוע ה-tag הקודם ושחזור ה-dump.

Failure modes, with the strings you will see

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

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

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

password authentication failed for user "n8n" בלוגים, עם הפעלה מחדש של ה-container. הסיסמה ש-n8n שולח אינה תואמת לזו שבה ה-database הוגדר בתחילה. המלכוד: 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) ולא יכול לכתוב לספריית ה-config שלו. זה קורה לאנשים שמבצעים bind-mount לתיקייה ב-host (./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 על קובץ ההגדרות כברירת מחדל ומתקן זאת בעצמו בזמן העלייה — שורת לוג זו אומרת שהוא כבר תיקן את ה-mode, בדרך כלל לאחר bind mount או לאחר ששחזור העתיק את הקובץ מחדש עם הרשאות רחבות. אין צורך בפעולה; הגדר את N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false רק אם מערכת הקבצים שלך באמת אינה יכולה לתמוך בהרשאות.

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

באנר התראה על cookies מאובטחים: 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 ול-port במקום דרך ה-HTTPS proxy. התחבר דרך https://n8n.example.com/. רק אם אינך יכול להשתמש ב-HTTPS, עליך להגדיר את N8N_SECURE_COOKIE=false, ואסור לעשות זאת על מכשיר הפונה לאינטרנט.

כדי להוסיף מודל שפה לתוך ה-workflows הללו, ראה את building AI workflows with Claude and n8n.

FAQ

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

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

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

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

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

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

איך אני מעביר את n8n תחת HTTPS?

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

איך משדרגים n8n בצורה בטוחה?

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

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