SSD Nodes Learn
Mga Gabay Matt ConnorNi Matt Connor · Na-update 2026-07-24

Paano i-host ang n8n sa VPS gamit ang Docker

Matutunan ang tamang setup ng n8n gamit ang Docker Compose at Postgres. Iwasan ang error sa WEBHOOK_URL at encryption-key para sa maayos na HTTPS connection.

Ang iyong bubuuin

Ang n8n ay isang workflow automation tool: isang visual editor kung saan ang isang trigger — gaya ng webhook, schedule, o form submission — ay nagpapatakbo ng chain ng mga node. Ang mga node na ito ay tumatawag sa mga API, nag-aayos ng data, at nagsusulat sa iba pang mga system. Naging standard na ito para sa AI-agent workflows dahil kaya nitong kumonekta sa lahat ng model provider at database nang hindi na kailangang gumawa ng sariling service. Sa loob ng dalawang minuto, magkakaroon ka na ng working editor gamit ang isang docker run. Ang guide na ito ay para sa natitirang ninety percent: ang paggawa nito na durable gamit ang Postgres sa halip na ang default na SQLite file, ang paggawa rito na reachable via HTTPS, at — ang bahaging madalas magkamali ang marami — ang pag-set up ng webhooks para magbigay ng URL na accessible mula sa labas ng network.

Ang tapos na stack ay binubuo ng dalawang container sa iisang Docker network: ang n8n mismo, at isang Postgres database na naglalaman ng mga workflow at credentials nito. Isang reverse proxy sa host ang mag-te-terminate ng TLS at magfo-forward sa n8n sa localhost, kaya walang direktang koneksyon sa internet maliban sa proxy na ito. Kasama ito sa iba pang mga serbisyo sa 2026 self-hosting shortlist.

Mga Prerequisites, at ang mga limitasyon

Kailangan mo ng VPS na may hindi bababa sa 1 GB na RAM; magplano para sa 2 GB kapag nagsimula na ang mabibigat na workflow, dahil kumakain ng memory ang mga execution at ang Node.js runtime. Masakit matutunan ang OOM killer kapag pinatay nito ang container habang tumatakbo ang proseso. Sapat na ang isang vCPU para sa simula.

Kailangan mo ng domain o subdomain — halimbawa ang n8n.example.com — na may A record na nakaturo sa public IP ng VPS na gumagana na bago ka humingi ng certificate. Dapat bukas ang ports 80 at 443 para sa proxy; ang port 5678 ng n8n ay hindi dapat nakalantad sa internet. Kailangan mo ng Docker Engine at ang Compose plugin; kung mag-error ang docker compose version gamit ang docker: 'compose' is not a docker command, ang gamit mo ay ang lumang standalone binary, at ang plugin ay sudo apt install docker-compose-plugin.

Okay ang SQLite para sa testing, pero Postgres para sa production

Ang default database ng n8n ay isang SQLite file sa /home/node/.n8n/database.sqlite. Ayos lang ito para sa testing — huwag mag-mount ng volume at mawawala ang data sa unang container recreate, na isang mahalagang aral. Hindi lang bilis ang dahilan para lumipat sa Postgres; ang SQLite ay may single writer lock, kaya ang instance na tumatakbo ng maraming workflows nang sabay-sabay, o ang queue mode na kakailanganin mo rin, ay nagdudulot ng SQLITE_BUSY: database is locked sa ilalim ng concurrency. Walang ganitong limitasyon ang Postgres, malinis ang backup gamit ang pg_dump, at ito ang standard na ginagamit sa n8n docs para sa mga server na kailangan talaga. Ang paglipat sa huli ay nangangailangan ng manual data migration, kaya kung mahalaga ang server na ito, magsimula na sa Postgres.

DNS at ang firewall

I-point muna ang record at buksan ang mga port. Ginagawa ito para hindi mag-fail ang certificate step dahil sa hindi nag-re-resolve na name.

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

Huwag buksan ang 5678. Ang compose file ay nagba-bind ng n8n sa 127.0.0.1:5678 kaya ang host's reverse proxy lamang ang makaka-reach dito. Ang pagbubukas ng ufw allow 5678 ay makakasira sa isolation na ito.

Ang Compose file

Gumawa ng working directory at isang docker-compose.yml. Ito ang buong stack — dalawang service, isang private network, at dalawang named volume.

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:

May ilang desisyon na dapat linawin. Ang DB_POSTGRESDB_HOST=postgres ang service name na ginagamit ng Docker sa shared network — hindi ang localhost, na ang ibig sabihin sa loob ng n8n container ay ang n8n mismo. Pinipigilan ng depends_on na may condition: service_healthy ang n8n na maunahan ang Postgres sa boot; kung wala ito, magsisimula ang n8n, hindi makakahanap ng database, at mag-eexit. Ang named volume na n8n_data sa /home/node/.n8n ang naglalaman ng encryption key at, para sa SQLite, ang database — ang tanging directory na hindi dapat mawala. I-pin ang image sa isang eksaktong version, huwag gagamit ng latest; ang mga dahilan ay nasa upgrade section sa ibaba.

Ang secrets file

Huwag maglagay ng mga password sa compose file. Maglagay ng .env file sa tabi nito na awtomatikong binabasa ng Compose, at gumamit ng random na values para sa mga ito.

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

Ang N8N_ENCRYPTION_KEY ang pinakaimportanteng string dito — ito ang key na ginagamit para i-encrypt ang bawat stored credential. I-set ito nang manu-mano sa halip na hayaan ang n8n na gumawa nito, dahil ang value na ginawa mo ay maaari mong isulat at i-restore. Kapag na-encrypt na ng n8n ang unang credential gamit ang key na ito, hindi na ma-de-decrypt ang lahat ng credential kapag binago ito — kaya i-set ito nang isang beses, ngayon, at huwag nang galawin ang linyang iyon.

Ang mga env vars na nagtatakda kung gagana ang mga webhook

Apat na variable ang kumokontrol kung paano ipinapakilala ng n8n ang sarili nito sa labas. Ang maling configuration sa mga ito ang pangunahing tanong sa n8n support.

  • Ang N8N_HOST ay ang public hostname, n8n.example.com. Panatilihin ito sa default na localhost kung may proxy; susubukan ng editor na i-load ang sarili nitong API mula sa localhost sa browser mo, na magreresulta sa error.
  • Sinasabi ng N8N_PROTOCOL=https sa n8n na gumagamit ito ng TLS, kaya mamarkahan nito ang session cookie na Secure at bubuoin ang mga https:// URL.
  • Ang N8N_PORT=5678 ay ang port kung saan nakikinig ang n8n sa loob ng container. Hindi ito ang public port; ang proxy ang may hawak sa 443.
  • Ang WEBHOOK_URL=https://n8n.example.com/ ang nagdudulot ng problema. Ipinapakita ng n8n ang mga webhook address na i-pe-paste mo sa Stripe, GitHub, o anumang external caller sa pamamagitan ng pagbuo ng mga ito mula sa mga value na ito. Kung hindi ito naka-set o mali ang laman, gagamitin ng n8n ang N8N_HOST:N8N_PORT at ibibigay sa iyo ang https://n8n.example.com:5678/webhook/... o, mas malala, ang http://localhost:5678/webhook/... — lalabas ito nang walang error at mukhang tama, pero hindi ma-a-access mula sa internet, kaya hindi darating ang mga request ng caller. I-set ito sa eksaktong public base URL na may kasamang trailing slash, pagkatapos ay i-verify kung ang webhook node ay nagpapakita ng URL na walang port.

Sinasabi ng N8N_PROXY_HOPS=1 sa Express server ng n8n na magtiwala sa isang proxy sa harap nito, para ang rate-limiting at anumang feature na nagbabasa ng client IP ay makita ang totoong address sa halip na ang address ng proxy. Isang variable na sadyang hindi dapat i-set dito ang N8N_RUNNERS_ENABLED: ang mga task runner — ang n8n na nagpapatakbo ng Code-node logic sa isang hiwalay na sandboxed process — ay default na simula noong 1.69 at mandatory na simula sa 2.x line na tinutukoy sa guide na ito, kaya deprecated na ang lumang opt-in. I-set ito ngayon at maglalabas lang ang n8n ng notice na nagsasabing tanggalin ito.

Unang pag-boot

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

Ang matagumpay na unang boot ay nagtatapos sa isang Editor is now accessible via: line, na may n8n ready on ..., port 5678 line sa itaas nito. Dapat ipakita ng docker compose ps ang parehong container Up, kung saan ang postgres ay naka-markang (healthy). Kung ang n8n ay nasa loob ng isang Restarting loop, basahin ang mga logs — madalas itong sanhi ng database connection o volume permissions na tatalakayin sa ibaba.

TLS gamit ang reverse proxy

Gumagamit ang n8n ng plain HTTP sa port 5678; kailangan ng nasa harap nito para i-terminate ang HTTPS. May dalawang madaling opsyon.

Kung marami ka nang running containers, ilagay ang n8n sa likod ng isang Traefik reverse proxy na awtomatikong nag-iissue ng TLS certificates gamit ang ilang labels — hihilingin at i-re-renew ng Traefik ang certificate para sa iyo.

Kung ito lang ang tanging app sa server, mas simple ang nginx virtual host na may Let's Encrypt certificate. Gamitin ang Certbot at nginx TLS setup para sa Ubuntu 24.04 para makuha ang certificate, pagkatapos ay gamitin ang server block na ito:

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;
    }
}

Hindi optional ang Upgrade at Connection "upgrade" headers. Nagpapadala ang n8n ng live execution updates sa editor via WebSocket, at kung wala ang dalawang linyang ito, maglo-load ang login page pero mag-ha-hang ito dahil sa "lost-connection" banner. Pinipigilan ng proxy_read_timeout 3600 ang pagkaputol ng mga long-running executions mula sa default na 60 seconds ng nginx. Ang X-Forwarded-Proto $scheme header ang kasama ng N8N_PROXY_HOPS=1: sinasabi nito sa n8n na ang original request ay HTTPS kahit na ang proxy ay gumagamit ng plain HTTP, para hindi isipin ng n8n na insecure ang connection at i-reject ang sarili nitong cookie.

Ang iyong unang workflow, para maging totoo ito

Buksan ang https://n8n.example.com/, gumawa ng owner account (sa susunod na section), at bumuo ng pinakasimpleng workflow para mapatunayan na gumagana ang path: isang webhook in, isang HTTP call, at isang response out.

  1. Magdagdag ng Webhook node. I-set ang method sa POST at ang path sa hello. Magpapakita ito ng dalawang URL, ang Test URL at Production URL — ito ang sanhi ng kalahati ng mga report na "hindi gumagana ang aking webhook". Ang Test URL ay tumutugon sa isang call lamang, at habang naka-click ang Listen for test event; pagkatapos ay mag-eexpire ito. Ang Production URL ay tumutugon tuwing ang workflow ay Active.
  2. Magdagdag ng HTTP Request node pagkatapos nito, na nakaturo sa anumang public JSON API — ang GET sa https://api.github.com/zen ay magbabalik ng isang one-line string, na sapat na.
  3. Magdagdag ng Respond to Webhook node, at i-set ang Respond option ng Webhook node sa "Using Respond to Webhook node" para maibalik sa caller ang output ng HTTP node.
  4. I-toggle ang workflow sa Active (sa itaas na bahagi ng kanan) at i-call ito: curl -X POST https://n8n.example.com/webhook/hello. Dapat mong makuha ang zen line pabalik — POST in, API call, response out, ang pattern ng karamihan sa mga totoong automation.

Ang isang scheduled variant ay pinapalitan ang Webhook node ng Schedule Trigger at tumatawag sa isang model endpoint sa halip — ang isang self-hosted na endpoint mula sa Ollama running on the same VPS ay isang maayos na paraan para bumuo ng isang nightly summariser.

User management, hindi basic auth

Sinasabi sa mga lumang n8n guide na i-set ang N8N_BASIC_AUTH_ACTIVE=true. Tinanggal na ang mga variable na iyon sa n8n 1.0 at wala na itong silbi ngayon. Ang authentication ngayon ay ang owner account: sa unang pagkakataon na i-load ang editor, papipiliin ka ng n8n na gumawa ng email-and-password owner, at mandatory ang gate na ito — walang anonymous mode. Gawin ito agad pagkatapos ng unang boot, bago ibigay ang URL sa kahit sino: sa pagitan ng docker compose up at ng unang form submission na iyon, maaaring ma-claim ang instance ng sinumang unang makakaabot dito. Ang paglalagay ng reverse-proxy basic-auth layer ay isang maayos na extra lock, ngunit ito ay second factor lamang, hindi ang tunay na authentication.

Backups: unahin ang encryption key, pagkatapos ang database

Dalawang bagay ang kailangang i-back up, at hindi sila pareho ng halaga sa pag-recover.

Ang N8N_ENCRYPTION_KEY. Ang bawat credential na naka-store sa n8n — API tokens, database passwords, OAuth secrets — ay naka-encrypt at rest gamit ang key na ito. Walang silbi ang mga workflow sa Postgres kung wala ito: kung i-re-restore ang database sa bagong server na may ibang key, hindi ma-de-decrypt ng n8n ang kahit isang credential. Walang recovery at walang reset. Ang .env file ang may hawak ng key; i-copy ito sa labas ng server — mainam ang paggamit ng password-manager — sa mismong araw na ginawa mo ito. Ito ang backup na pinakaimportante.

Ang Postgres database, para sa mga workflow, execution history, at sa mga encrypted credentials mismo:

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

I-set ito sa isang schedule at i-copy ang dump palabas ng server. Para i-restore sa isang bagong VPS: i-run ang stack nang isang beses para magkaroon ng database, i-stop ang n8n, i-load ang dump gamit ang psql, ilagay ang parehong N8N_ENCRYPTION_KEY sa .env, at i-start ang n8n. Ang parehong key plus ang dump ay isang working instance; ang bagong key ay magreresulta sa mga workflow na hindi makakagamit ng kahit isang credential.

Upgrades: i-pin ang tag

Sadyang naka-pin ang compose file sa n8nio/n8n:2.29.10 sa halip na latest. Naglalabas ang n8n ng bagong minor version halos linggu-linggo at minsan ay binabago ang database schema o node behavior sa pagitan ng mga ito. Dahil dito, ang latest ay nangangahulugang ang isang unattended pull ay maaaring magbigay ng build na magmi-migrate ng iyong database sa oras na mag-start ito. I-pin ang isang version, basahin ang release notes bago mag-bump — inililista ng n8n ang mga breaking changes doon — at mag-upgrade nang may plano:

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

Pinakaimportante ang pag-pin sa mga major-version jumps. Halimbawa, ang 2.0 line ay ginawang true ang N8N_BLOCK_ENV_ACCESS_IN_NODE by default. Dahil dito, anumang Code node na nagbabasa ng process.env ay mawawalan ng access hanggang hindi ito ibinabalik sa false; sinimulan din ng release na ito ang pagpapatupad ng strict permissions sa settings file. Basahin ang 2.0 breaking-changes page bago lumipat sa isang major boundary. Awtomatikong pinapatakbo ng n8n ang anumang kailangang database migrations sa start — ito ang dahilan kung bakit hindi optional ang pre-upgrade pg_dump. Dahil ang mga credentials ay naka-encrypt gamit ang isang key sa .env at ang data ay nasa Postgres, ang mga container ay disposable: mag-upgrade sa pamamagitan ng pag-replace sa mga ito, at mag-rollback sa pamamagitan ng pag-pin sa nakaraang tag at pag-restore ng dump.

Failure modes, kasama ang mga strings na makikita mo

The requested webhook "POST hello" is not registered. Isang 404 error mula sa pagtawag sa isang webhook na ang workflow ay hindi Active, o mula sa pagtawag sa test path habang walang nakikinig. Ang mga test path (/webhook-test/...) ay sasagot lamang kung naka-click ang "Listen for test event"; ang mga production path (/webhook/...) ay sasagot lamang kapag naka-on ang workflow toggle. Ang katumbas na This webhook is not registered for GET requests. Did you mean to make a POST request? ay nangangahulugang mali ang method — inaasahan ng node ang POST pero ang ipinadala mo ay GET.

Ang webhook URL ay nagpapakita ng :5678 o localhost. Ang node ay nagpapakita ng https://n8n.example.com:5678/webhook/... o http://localhost:5678/.... Ang WEBHOOK_URL ay unset o mali, kaya binuo ng n8n ang address mula sa N8N_HOST:N8N_PORT sa halip na sa iyong public base. I-set ang WEBHOOK_URL=https://n8n.example.com/, i-recreate ang container gamit ang docker compose up -d, at mawawala ang port.

There was a problem loading init data sa browser. Na-load ang editor pero hindi maabot ang sarili nitong backend API. Sa likod ng isang proxy, ito ay halos laging dahil sa maling N8N_HOST o WEBHOOK_URL, isang proxy na kulang sa WebSocket Upgrade headers, o hindi tugma ang N8N_PROTOCOL sa paraan ng iyong pag-connect. I-confirm ang apat na public-facing variables at siguraduhing pino-forward ng proxy ang Upgrade at Connection.

password authentication failed for user "n8n" sa logs, kasabay ng pag-restart ng container. Ang password na ipinapadala ng n8n ay hindi tugma sa password na ginamit noong i-initialize ang database. Ang problema: binabasa ng Postgres ang POSTGRES_PASSWORD lamang kapag nag-i-initialize ito ng empty na data directory. I-start ang stack nang isang beses, pagkatapos ay baguhin ang POSTGRES_PASSWORD sa .env, at ang kasalukuyang postgres_data volume ay mayroon pa ring lumang password. Ibalik ito sa orihinal, o kung wala kang data na kailangang i-save, i-docker compose down at i-docker volume rm ang postgres volume, pagkatapos ay i-start ito nang bago.

EACCES: permission denied, open '/home/node/.n8n/config' sa start. Tumatakbo ang n8n bilang node user (UID 1000) at hindi ma-write ang config directory nito. Nangyayari ito sa mga gumagamit ng bind-mount sa isang host folder (./n8n_data:/home/node/.n8n na pagmamay-ari ng root. Gamitin ang named volume na ipinapakita sa itaas, o kung kailangan talaga ng bind mount, i-sudo chown -R 1000:1000 ./n8n_data muna.

Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide. Changing permissions to 0600.. Mula sa 2.x line, ipinapatupad ng n8n ang 0600 sa settings file na iyon sa default at inaayos ito nang kusa sa boot — ang log line na ito ay nangangahulugang naayos na nito ang mode, karaniwan pagkatapos ng bind mount o pagkatapos ma-restore ang file na may maluwag na permissions. Walang kailangang gawin; i-set ang N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false lamang kung ang iyong filesystem ay talagang hindi kayang suportahan ang permissions.

Mismatching encryption keys — ang kumpletong linya ay nagsasabing ang encryption key sa settings file na /home/node/.n8n/config ay hindi tugma sa N8N_ENCRYPTION_KEY sa iyong environment. Ang key sa iyong environment ay iba sa key na isinulat ng n8n sa data volume nito sa nakaraang run — madalas dahil gumawa ang n8n ng random key sa isang naunang boot noong unset ang variable, at nag-set ka pagkatapos ng ibang key. Ibalik ang orihinal na key sa .env, o, kung wala ka talagang mga stored credentials na dapat i-save, i-delete ang config file sa loob ng n8n_data volume at hayaan ang n8n na i-regenerate ito — tanggapin na ang mga existing credentials ay hindi na mababasa.

Isang login banner tungkol sa secure cookies: Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari. Nag-set ka ng N8N_PROTOCOL=https pero naabot ang n8n via plain HTTP — karaniwan sa pamamagitan ng pag-access sa IP at port nang direkta sa halip na sa HTTPS proxy. I-access ito via https://n8n.example.com/. Kung hindi mo talaga kayang gumamit ng HTTPS, i-set lamang ang N8N_SECURE_COOKIE=false, at huwag na huwag ito sa isang internet-facing na machine.

Para maglagay ng language model sa loob ng mga workflow na iyon, tingnan ang building AI workflows with Claude and n8n.

FAQ

SQLite o Postgres ba ang dapat kong gamitin para sa n8n?

Ayos lang ang SQLite (ang default) para sa pagsubok ng n8n o para sa personal na instance na may isang workflow lang na tumatakbo. Lumipat sa Postgres para sa anumang kritikal na gamit: nagdudulot ng database is locked ang single writer lock ng SQLite kapag may concurrency, at malinis ang backup ng Postgres gamit ang pg_dump. Manual ang migration kung gagawin ito sa hinaharap, kaya kung mahalaga ang server, magsimula na sa Postgres.

Bakit hindi gumagana ang mga n8n webhook ko?

Halos laging WEBHOOK_URL ito. Kapag hindi naka-set o mali ang configuration, naglalabas ang n8n ng mga webhook address na binuo mula sa N8N_HOST:N8N_PORT — madalas may kasamang :5678 o localhost — na mukhang valid pero hindi ma-access mula sa internet, kaya hindi nakakarating ang mga request ng caller. I-set ang WEBHOOK_URL=https://n8n.example.com/ at siguraduhing ang URL sa node ay walang port. Ang pangalawang sanhi ay ang pagtawag sa isang webhook na ang workflow ay hindi naka-toggle sa Active, na nagreresulta sa The requested webhook ... is not registered..

Ano ang dapat kong i-back up sa n8n?

Dalawang bagay. Ang N8N_ENCRYPTION_KEY mula sa iyong .env file, dahil ang bawat stored credential ay naka-encrypt gamit ito at hindi na muling ma-de-decrypt kapag nawala ito — i-copy ito palabas ng server sa araw na ginawa mo ito. At ang pg_dump ng Postgres database para sa mga workflow, history, at credentials. Kailangan ang dalawang ito para sa restore: ang parehong key at ang dump.

Paano ko ilalagay ang n8n sa likod ng HTTPS?

Nagse-serve ang n8n ng plain HTTP sa port 5678; gumagamit ng reverse proxy sa harap para sa TLS termination. I-bind ang n8n sa 127.0.0.1:5678 para ang proxy lang ang makaka-access dito, pagkatapos ay gumamit ng Traefik na may automatic certificates o nginx na may Let's Encrypt certificate. I-set ang N8N_PROTOCOL=https at WEBHOOK_URL=https://your-host/, at siguraduhing pino-forward ng proxy ang WebSocket Upgrade headers para hindi mag-hang ang editor.

Paano ang ligtas na pag-upgrade ng n8n?

Gumamit ng specific na image tag sa halip na latest, mag-take muna ng pg_dump dahil awtomatikong nagpapatakbo ang n8n ng mga migration sa start, basahin ang release notes para sa mga breaking changes, pagkatapos ay i-update ang tag at i-run ang docker compose pull n8n && docker compose up -d n8n. Ang container ay disposable, kaya mag-roll back sa pamamagitan ng pag-pin sa dating tag at pag-restore ng pre-upgrade dump.

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