Self-host n8n sa VPS gamit ang Docker at HTTPS

Ano ang binubuo mo

Ang n8n ay isang workflow automation tool: isang visual editor kung saan ang isang trigger, webhook, schedule, o form submission ay nagpapasimula ng chain ng mga node na tumatawag sa mga API, nag-aayos muli ng data, at nagsusulat sa ibang system. Naging default na glue ito para sa AI-agent workflows dahil nakakausap nito ang bawat model provider at database nang hindi mo kailangang magsulat ng service. Sa loob ng dalawang minuto, makakakuha ang isang docker run ng gumaganang editor. Ang gabay na ito ay tungkol sa natitirang siyamnapung porsiyento: gawing durable ito gamit ang Postgres sa halip na default na SQLite file, gawin itong maabot sa HTTPS, at—ang bahaging madalas magkamali ang halos lahat—tulungan ang mga webhook na magbigay ng URL na aktuwal na maaabot ng external world.

Ang natapos na stack ay binubuo ng dalawang container sa iisang Docker network: ang n8n mismo at isang Postgres database na naglalaman ng mga workflow at credential nito. Sa host, may reverse proxy na nagte-terminate ng TLS at nagpapasa ng traffic sa n8n sa localhost, kaya walang direktang nakaharap sa internet maliban sa proxy na iyon. Kasama ito ng iba pang service sa shortlist ng self-hosting para sa 2026.

Mga prerequisite at ang totoong mga limitasyon

Kailangan mo ng VPS na may hindi bababa sa 1 GB na RAM. Maglaan ng 2 GB kapag aktuwal nang gumagawa ng mabibigat na gawain ang mga workflow, dahil kumokonsumo ng memory ang mga execution kasama ng Node.js runtime. Hindi magandang paraan para matuklasan ito kapag pinahinto ng out-of-memory killer ang container habang tumatakbo ito. Sapat na ang isang vCPU para magsimula. Kung magpapatakbo rin ang server na ito ng mas mabigat na serbisyo, iyon ang unang isaalang-alang sa pag-size nito: karaniwang salarin ang photo library, at mas mataas nang malaki ang aktuwal na minimum na RAM para sa PhotoPrism at Immich kaysa sa hinihingi ng n8n. Ganoon din sa media box: kukunin ng Jellyfin server at ng browsable front end para rito, gaya ng Halcyon, na muling inaayos ang library na parang rental shop noong 90s, ang RAM at transcoding headroom bago pa ito mapansin ng n8n.

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

Maayos ang SQLite para sa test, pero Postgres para sa anumang inaasahan mong gagana

Ang default na database ng n8n ay isang SQLite file sa /home/node/.n8n/database.sqlite. Para sa paunang pagsubok, sapat na ito. Ngunit kung walang naka-mount na volume, mawawala ang data sa unang pag-recreate ng container, na isa ring mahalagang aral. Hindi raw speed ang dahilan para lumipat sa Postgres. Ang dahilan ay iisang writer lock lamang ang hinahawakan ng SQLite. Kaya kapag sabay-sabay na nagpapatakbo ng maraming workflow ang isang instance, o kapag ginamit mo ang queue mode na kakailanganin mo kalaunan, lumalabas ang SQLITE_BUSY: database is locked kapag mataas ang concurrency. Walang ganitong limitasyon ang Postgres. Madali rin itong i-back up gamit ang pg_dump. Ito rin ang database na ipinapalagay ng sariling documentation ng n8n para sa server na inaasahan mong gagana. Ang paglipat sa ibang pagkakataon ay nangangailangan ng manual na pag-migrate ng data. Kaya kung mahalaga ang server na ito, magsimula sa Postgres.

DNS at firewall

Ituro muna ang record at buksan ang mga port upang hindi mabigo ang certificate step sa bandang huli dahil hindi nagre-resolve ang pangalan.

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. Ibinabind ng compose file ang n8n sa 127.0.0.1:5678 kaya ang reverse proxy lang ng host ang makakaabot dito, at mawawala ang isolation na iyon kapag gumamit ng ufw allow 5678.

Ang Compose file

Gumawa ng working directory at isang docker-compose.yml. Ito ang buong stack: dalawang serbisyo, 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 desisyong kailangang linawin. Ang DB_POSTGRESDB_HOST=postgres ang service name na nireresolve ng Docker sa shared network, hindi ang localhost. Sa loob ng n8n container, ang localhost ay tumutukoy sa n8n mismo. Pinipigilan ng depends_on na may condition: service_healthy ang pag-unahan ng n8n at Postgres sa pag-boot. Kung wala ito, nagsisimula ang n8n, walang nakikitang database, at nag-e-exit. Ang named volume na n8n_data sa /home/node/.n8n ang naglalaman ng encryption key at, kapag SQLite ang gamit, ng database. Ito ang nag-iisang directory na hindi mo dapat mawala. I-pin ang image sa eksaktong version. Huwag kailanman gumamit ng latest. Nakasaad sa upgrade section sa ibaba ang mga dahilan.

The secrets file

Huwag kailanman maglagay ng mga password sa compose file. Ilagay ang mga ito sa isang .env file na nasa tabi nito at awtomatikong binabasa ng Compose. I-generate ang mga ito upang tunay na random ang mga value.

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 pinakamahalagang string dito. Ito ang key na ginagamit upang i-encrypt ang bawat naka-store na credential. Itakda ito nang tahasan sa halip na hayaang i-generate ito ng n8n, dahil ang value na ikaw ang nag-generate ay maaaring isulat at i-restore. Kapag na-encrypt na ng n8n ang unang credential gamit ang key na ito, kapag binago ito, hindi na made-decrypt ang lahat ng credential. Kaya itakda ito ngayon at huwag nang baguhin ang linyang iyon.

Ang mga env var na nagtatakda kung gagana ang webhooks

Apat na variable ang kumokontrol sa paraan ng pagpapakilala ng n8n sa external network. Kapag mali ang mga ito, ito ang pinakakaraniwang tanong sa n8n support.

• Ang N8N_HOST ay ang public hostname, n8n.example.com. Kapag iniwan ito sa default na localhost habang nasa likod ng proxy, susubukan ng editor na i-load ang sarili nitong API mula sa localhost sa browser mo. Mabibigo ito.
• Sinasabi ng N8N_PROTOCOL=https sa n8n na TLS ang ginagamit nito. Dahil dito, itinatakda nito ang session cookie bilang Secure at bumubuo ng mga URL na https://.
• Ang N8N_PORT=5678 ay ang port na pinakikinggan ng n8n sa loob ng container. Hindi ito ang public port. Ang proxy ang may kontrol sa 443.
• Ang WEBHOOK_URL=https://n8n.example.com/ ang madalas magdulot ng problema. Binubuo ng n8n ang mga webhook address na ipinapasa mo sa Stripe, GitHub, o anumang external caller gamit ang mga value na ito. Kapag hindi ito naka-set o mali ang value, nagfa-fallback ang n8n sa N8N_HOST:N8N_PORT at ibinibigay sa iyo ang https://n8n.example.com:5678/webhook/... o, mas masama, http://localhost:5678/webhook/.... Ipinapakita ito nang walang error, mukhang makatwiran, pero hindi naaabot mula sa internet. Dahil dito, tahimik na hindi nakararating ang mga request ng caller. Itakda ito sa eksaktong public base URL na may trailing slash. Pagkatapos, kumpirmahing URL na walang port ang ipinapakita ng webhook node.

Sinasabi ng N8N_PROXY_HOPS=1 sa Express server ng n8n na magtiwala sa isang proxy na nasa unahan nito. Dahil dito, nakikita ng rate limiting at ng anumang feature na bumabasa sa client IP ang totoong address, hindi ang address ng proxy. Ang isang variable na sadyang hindi mo dapat itakda rito ay N8N_RUNNERS_ENABLED. Ang task runners, kung saan nagpapatakbo ang n8n ng Code-node logic sa hiwalay na sandboxed process, ay default na mula pa noong 1.69 at mandatory na sa 2.x line na ginagamit ng guide na ito. Deprecated na ang dating opt-in. Kapag itinakda mo ito ngayon, notice lang ang ila-log ng n8n na nagsasabing alisin ito.

Unang pagsisimula

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

Nagtatapos ang matagumpay na unang boot sa isang linyang Editor is now accessible via:, na may linyang n8n ready on ..., port 5678 sa itaas nito. Dapat ipakita ng docker compose ps ang parehong container na Up, at ang postgres ay dapat mamarkahang (healthy). Kung nasa Restarting loop ang n8n, basahin ang logs. Halos palaging database connection o volume permissions ang sanhi nito, na tinalakay sa ibaba.

TLS reverse proxy gamit ang

Ang n8n mismo ay gumagamit ng plain HTTP sa 5678; may component sa unahan nito na nagte-terminate ng HTTPS. May dalawang maayos na opsyon.

Kung nagpapatakbo ka na ng ilang container, ilagay ang n8n sa likod ng Traefik reverse proxy na awtomatikong nag-iisyu ng TLS certificate gamit ang ilang label. Si Traefik ang hihiling at magre-renew ng certificate para sa iyo.

Kung ito lang ang 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 upang kunin 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 gamit ang WebSocket. Kung wala ang dalawang linyang iyon, naglo-load ang login page at pagkatapos ay nagha-hang na may lost-connection banner. Pinipigilan ng proxy_read_timeout 3600 na maputol ang matagal na execution pagkalipas ng default na 60 segundo ng nginx. Ang X-Forwarded-Proto $scheme header ang katambal ng N8N_PROXY_HOPS=1: sinasabi nito sa n8n na HTTPS ang orihinal na request kahit plain HTTP ang ginagamit ng proxy para maabot ito. Dahil dito, hindi ipagpapalagay ng n8n na insecure ang connection at hindi nito ire-reject ang sarili nitong cookie.

Ang iyong unang workflow, para maging aktuwal

Buksan ang https://n8n.example.com/, gawin ang owner account (sa susunod na seksyon), at buuin ang pinakamaliit na workflow na magpapatunay na gumagana ang daloy: papasok ang webhook, gagawa ng HTTP call, at lalabas ang response.

1. Magdagdag ng Webhook node. Itakda ang method sa POST at ang path sa gaya ng hello. Magpapakita ito ng dalawang URL: Test URL at Production URL. Dito nagmumula ang kalahati ng mga ulat na “hindi gumagana ang webhook.” Sumasagot ang Test URL sa isang call lamang, at gumagana lang habang na-click mo ang Listen for test event; pagkatapos nito, mag-e-expire ito. Sumasagot ang Production URL kapag Active ang workflow.
2. Magdagdag ng HTTP Request node pagkatapos nito at ituro ito sa anumang public JSON API. Ang GET sa https://api.github.com/zen ay nagbabalik ng isang linyang string, at sapat na iyon.
3. Magdagdag ng Respond to Webhook node. Itakda ang Respond option ng Webhook node sa "Using Respond to Webhook node" upang matanggap ng caller ang output ng HTTP node.
4. I-toggle ang workflow sa Active (sa upper right) at tawagin ito: curl -X POST https://n8n.example.com/webhook/hello. Dapat mong matanggap ang zen line. POST ang papasok, API call ang isasagawa, at response ang lalabas. Ito ang karaniwang anyo ng maraming aktuwal na automation.

Sa scheduled na variant, pinapalitan ang Webhook node ng Schedule Trigger at tinatawag ang isang model endpoint. Maayos na paraan ang self-hosted na Ollama na tumatakbo sa parehong VPS para gumawa ng nightly summariser.

User management, hindi basic auth

Sinasabi ng mga lumang n8n guide na itakda ang N8N_BASIC_AUTH_ACTIVE=true. Inalis ang mga variable na iyon sa n8n 1.0 at wala na itong ginagawa ngayon. Ang authentication ngayon ay gumagamit ng owner account: sa unang pag-load mo ng editor, kailangan kang gumawa ng owner account na may email at password. Mandatory ang gate na ito at walang anonymous mode. Gawin ito kaagad pagkatapos ng first boot, bago mo ibigay sa iba ang URL: sa pagitan ng docker compose up at ng unang pagsusumite ng form, maaaring ma-claim ang instance ng unang makaka-access dito. Makatuwirang magdagdag ng basic-auth layer sa reverse proxy bilang dagdag na lock, pero pangalawang layer lang ito at hindi ang aktuwal na authentication. Gumagana ang owner account at lahat ng iba pa sa guide na ito sa libreng community edition. Kung kailangan mo sa ibang pagkakataon ng karagdagang user na may granular roles o SSO, sulit basahin ang kung aling n8n feature ang nangangailangan ng bayad na license bago mo ibatay rito ang iyong plano.

Mga backup: unahin ang encryption key, saka ang database

Dalawang bagay ang kailangang i-back up, at hindi pareho ang dali nilang palitan.

Ang N8N_ENCRYPTION_KEY. Lahat ng credential na sine-save mo sa n8n—API token, database password, at OAuth secret—ay naka-encrypt habang naka-store gamit ang key na ito. Walang silbi ang mga workflow sa Postgres kung wala ito: kapag ni-restore mo ang database sa bagong server gamit ang ibang key, hindi made-decrypt ng n8n ang kahit isang credential. Walang recovery at walang reset. Nasa .env file ang key; kopyahin ito sa labas ng server sa araw na gawin mo ito. Mainam ang isang entry sa password manager. Ito ang backup na talagang mahalaga.

Ang Postgres database, para sa mga workflow, execution history, at mismong mga naka-encrypt na credential:

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

Patakbuhin ito ayon sa schedule at kopyahin ang dump sa labas ng server. Para mag-restore sa bagong VPS: paandarin muna nang isang beses ang stack para malikha ang database, ihinto ang n8n, i-load muli ang dump gamit ang psql, ilagay ang parehong N8N_ENCRYPTION_KEY sa .env, at simulan ang n8n. Ang parehong key kasama ang dump ay magbibigay ng gumaganang instance; ang bagong key ay mag-iiwan ng mga workflow na hindi makagamit ng kahit isang credential.

Mga Upgrade: i-pin ang tag

Sinasadyang naka-pin ang compose file sa n8nio/n8n:2.29.10 sa halip na latest. Nagre-release ang n8n ng bagong minor version halos bawat linggo, at kung minsan ay nagbabago ang database schema o node behavior sa pagitan ng mga ito. Kaya ang latest ay nangangahulugang maaaring awtomatikong mag-pull ng build na magmi-migrate ng database sa mismong oras na magsimula ito. Mag-pin ng version, basahin ang release notes bago mag-bump; tinutukoy ng n8n doon ang mga breaking change. Isagawa ang upgrade nang planado:

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

Pinakamahalaga ito kapag may pagtalon sa major version. Halimbawa, binago ng 2.0 line ang default mula N8N_BLOCK_ENV_ACCESS_IN_NODE tungo sa true. Dahil dito, tahimik na mawawalan ng access ang anumang Code node na bumabasa sa process.env hanggang ibalik mo ito sa false. Nagsimula rin ang release na iyon na magpatupad ng mahigpit na permission sa settings file. Basahin ang page tungkol sa breaking changes sa 2.0 bago tumawid sa major-version boundary. Awtomatikong isinasagawa ng n8n ang mga kinakailangang database migration sa pagsisimula. Iyan mismo ang dahilan kung bakit hindi optional ang pre-upgrade pg_dump. Dahil naka-encrypt ang credentials gamit ang key sa .env at nasa Postgres ang data, disposable ang mga container. Isinasagawa ang upgrade sa pamamagitan ng pagpapalit sa mga ito, at isinasagawa ang rollback sa pamamagitan ng pag-pin sa dating tag at pag-restore sa dump.

Mga failure mode at mga string na makikita mo

The requested webhook "POST hello" is not registered. Isang 404 ang lumalabas kapag tumawag ka sa webhook na hindi Active ang workflow, o kapag tinawag mo ang test path habang walang nakikinig. Sumasagot lamang ang mga test path (/webhook-test/...) habang na-click mo ang “Listen for test event”; sumasagot lamang ang mga production path (/webhook/...) kapag naka-on ang workflow toggle. Ibig sabihin ng katabing This webhook is not registered for GET requests. Did you mean to make a POST request? ay mali ang method: POST ang inaasahan ng node pero GET ang ipinadala mo.

May :5678 o localhost sa webhook URL. Ipinapakita ng node ang https://n8n.example.com:5678/webhook/... o http://localhost:5678/.... Hindi naka-set o mali ang WEBHOOK_URL, kaya binuo ng n8n ang address mula sa N8N_HOST:N8N_PORT sa halip na mula sa iyong public base. I-set ang WEBHOOK_URL=https://n8n.example.com/, gawin muli ang container gamit ang docker compose up -d, at mawawala ang port.

There was a problem loading init data sa browser. Nag-load ang editor pero hindi nito maabot ang sarili nitong backend API. Kapag nasa likod ito ng proxy, halos palaging mali ang N8N_HOST o WEBHOOK_URL, walang WebSocket Upgrade headers ang proxy, o hindi tugma ang N8N_PROTOCOL sa paraan ng pagkonekta mo. Kumpirmahin ang apat na public-facing variable at tiyaking ipinapasa ng proxy ang Upgrade at Connection.

password authentication failed for user "n8n" sa logs at patuloy na nagre-restart ang container. Hindi tugma ang password na ipinapadala ng n8n sa password na ginamit noong in-initialize ang database. Ang dapat bantayan: binabasa lamang ng Postgres ang POSTGRES_PASSWORD kapag nag-i-initialize ito ng empty na data directory. Simulan ang stack nang isang beses, pagkatapos ay baguhin ang POSTGRES_PASSWORD sa .env, at mananatili sa kasalukuyang postgres_data volume ang lumang password. Ibalik ang orihinal na password, o kung wala kang kailangang panatilihing data, docker compose down at docker volume rm ang postgres volume, pagkatapos ay simulan itong muli bilang bagong setup.

EACCES: permission denied, open '/home/node/.n8n/config' sa pagsisimula. Tumatakbo ang n8n bilang user na node (UID 1000) at hindi nito maisulat ang config directory nito. Karaniwan itong nangyayari kapag nag-bind-mount ng host folder (./n8n_data:/home/node/.n8n) na pagmamay-ari ng root. Gamitin ang named volume na ipinakita sa itaas, o kung kailangan mong gumamit ng bind mount, 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 bilang default ang 0600 sa settings file na iyon at awtomatikong inaayos ito sa boot. Ibig sabihin ng log line na ito ay naitama na nito ang mode, karaniwan pagkatapos ng bind mount o restore na nagbalik ng file na may maluwag na permissions. Walang kailangang gawin; i-set lamang ang N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false kung talagang hindi kayang suportahan ng filesystem mo ang permissions.

Mismatching encryption keys, at sinasabi sa mas kumpletong line na hindi tugma ang encryption key sa settings file /home/node/.n8n/config sa N8N_ENCRYPTION_KEY sa iyong environment. Naiiba ang key sa iyong environment sa key na isinulat ng n8n sa data volume nito noong nakaraang run. Madalas itong nangyayari kapag bumuo ang n8n ng random key sa naunang boot habang hindi naka-set ang variable, at pagkatapos ay nagtakda ka ng ibang key. Ibalik ang orihinal na key sa .env, o, kung wala ka talagang stored credentials na kailangang panatilihin, burahin ang config file sa loob ng n8n_data volume at hayaang buuin itong muli ng n8n, ngunit tandaan na hindi na mababasa ang mga kasalukuyang credential.

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.. Naka-set ang N8N_PROTOCOL=https pero plain HTTP ang ginamit mo sa pag-access sa n8n, karaniwan dahil direktang ginamit ang IP at port sa halip na ang HTTPS proxy. I-access ito gamit ang https://n8n.example.com/. Kung talagang hindi ka makagamit ng HTTPS, saka lamang i-set ang N8N_SECURE_COOKIE=false, at huwag kailanman gawin ito sa server na direktang exposed sa internet.

Para maglagay ng language model sa mga workflow na iyon, tingnan ang pagbuo ng AI workflow gamit ang Claude at n8n.

FAQ

Dapat ba akong gumamit ng SQLite o Postgres para sa n8n?

Sapat ang SQLite (ang default) para subukan ang n8n at para sa personal na instance na isang workflow lang ang tumatakbo sa bawat pagkakataon. Lumipat sa Postgres para sa anumang mahalaga o maaasahan mo: ang single writer lock ng SQLite ay nagdudulot ng database is locked kapag may concurrency, at malinis i-back up ang Postgres gamit ang pg_dump. Mano-mano ang migration sa susunod, kaya kung mahalaga ang server, magsimula sa Postgres.

Bakit hindi kailanman nagti-trigger ang mga webhook ng n8n?

Halos palaging WEBHOOK_URL. Kapag unset o mali ito, nagpi-print ang n8n ng mga webhook address na binuo mula sa N8N_HOST:N8N_PORT, na madalas may :5678 o localhost, kaya mukhang valid ang mga ito pero hindi maaabot mula sa internet at hindi nakararating ang mga request ng caller. I-set ang WEBHOOK_URL=https://n8n.example.com/ at kumpirmahing URL na walang port ang ipinapakita ng node. Ang ikalawang sanhi ay pagtawag sa webhook ng workflow na hindi naka-toggle sa Active, na nagbabalik ng The requested webhook ... is not registered.

Ano ang kailangan kong i-back up sa n8n?

Dalawang bagay. Una, ang N8N_ENCRYPTION_KEY mula sa iyong .env file, dahil ine-encrypt ang bawat naka-store na credential gamit ito at magiging permanenteng hindi made-decrypt ang mga credential kapag nawala ito; kopyahin ito sa labas ng server sa araw na gawin mo ito. Ikalawa, isang pg_dump ng Postgres database para sa mga workflow, history, at credential. Kailangan ang dalawa para sa restore: ang parehong key at ang dump.

Paano ko ilalagay ang n8n sa likod ng HTTPS?

Nagsisilbi ang n8n ng plain HTTP sa port 5678; ang reverse proxy sa unahan nito ang nagte-terminate ng TLS. I-bind ang n8n sa 127.0.0.1:5678 para proxy lamang ang makaka-access dito, pagkatapos ay gamitin ang 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 tiyaking ipinapasa ng proxy ang mga WebSocket Upgrade header para hindi mag-hang ang editor.

Paano ko ligtas na ia-upgrade ang n8n?

Mag-pin ng partikular na image tag sa halip na latest, gumawa muna ng pg_dump dahil awtomatikong nagpapatakbo ng migrations ang n8n sa pagsisimula, basahin ang release notes para sa mga breaking change, pagkatapos ay i-bump ang tag at patakbuhin ang docker compose pull n8n && docker compose up -d n8n. Disposable ang container, kaya mag-roll back sa pamamagitan ng pag-pin sa dating tag at pag-restore ng dump bago ang upgrade.