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.

Mga environment variable na nagtatakda kung gagana ang mga webhook

Apat na variable ang kumokontrol kung paano inilalarawan ng n8n ang sarili nito sa labas ng server. Kapag mali ang mga ito, ito ang pinakakaraniwang tanong sa suporta para sa n8n.

• Ang N8N_HOST ang public hostname, n8n.example.com. Kapag iniwan ito sa default na localhost habang nasa likod ng proxy, sinusubukan ng editor na i-load ang sarili nitong API mula sa localhost sa browser mo, kaya nabibigo ito.
• Sinasabi ng N8N_PROTOCOL=https sa n8n na TLS ang ginagamit sa pag-serve, kaya minamarkahan nito ang session cookie nito bilang Secure at bumubuo ng mga URL na https://.
• Ang N8N_PORT=5678 ang port na pinakikinggan ng n8n sa loob ng container. Hindi ito ang public port; ang proxy ang namamahala sa 443.
• Ang WEBHOOK_URL=https://n8n.example.com/ ang pinakamadalas magdulot ng problema. Iniimprenta ng n8n ang mga webhook address na inilalagay mo sa Stripe, GitHub, o anumang external caller sa pamamagitan ng pagbuo ng mga ito mula sa mga value na ito. Kapag hindi ito naka-set o mali ang value, bumabalik ang n8n sa N8N_HOST:N8N_PORT at ibinibigay sa iyo ang https://n8n.example.com:5678/webhook/... o, mas masahol pa, http://localhost:5678/webhook/.... Iniimprenta ang mga ito nang walang error, mukhang wasto, ngunit hindi maaabot 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 harap nito. Dahil dito, nakikita ng rate limiting at ng anumang feature na nagbabasa ng client IP ang tunay na address sa halip na address ng proxy. Ang isang variable na sadyang hindi mo ise-set dito ay N8N_RUNNERS_ENABLED. Ang task runner, na nagpapatakbo ng logic ng n8n Code node sa hiwalay na process na nakahiwalay sa main process, ay opt-in sa buong 1.x line. Sa panahong iyon, default na false ang variable at kailangan mo itong itakda sa true. Awtomatikong naka-enable ang mga ito sa n8n 2.0. Kaya sa 2.x line, sinasabi ng guide na deprecated na ang variable at hindi na ito kailangang i-set ayon sa documentation ng n8n.

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 unang workflow mo, para gumana talaga

Buksan ang https://n8n.example.com/, gumawa ng owner account (susunod na seksyon), at bumuo ng pinakamaliit na workflow na magpapatunay na gumagana ang buong path: papasok ang webhook, may HTTP call, at may response na lalabas.

1. Magdagdag ng Webhook node. Itakda ang method sa POST at ang path sa gaya ng hello. Magpapakita ito ng dalawang URL, isang Test URL at isang Production URL. Dito nagmumula ang kalahati ng mga report na “hindi gumagana ang webhook ko.” Sumasagot ang Test URL sa isang call lamang, at gagana lang habang na-click mo ang Listen for test event; pagkatapos ay mag-e-expire ito. Nire-register ang Production URL kapag publish mo ang workflow, at sasagot na ito mula noon.
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, at itakda ang Respond option ng Webhook node sa "Using Respond to Webhook node" upang maibalik sa caller ang output ng HTTP node.
4. I-click ang Publish (nasa kanang itaas) at tawagin ito gamit ang curl -X POST https://n8n.example.com/webhook/hello. Dapat bumalik sa iyo ang zen line: POST na pumapasok, API call, at response na lumalabas. Ito ang pangunahing anyo ng karamihan sa mga tunay na automation. Sa mga lumang guide, sinasabing i-toggle ang Active dito; pinalitan ng n8n 2.0 ang toggle na iyon ng Publish at Unpublish.

Sa scheduled na variant, pinapalitan ang Webhook node ng Schedule Trigger at model endpoint naman ang tinatawagan. 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

Sinasadya ng compose file na i-pin ang n8nio/n8n:2.29.10 sa halip na latest. Halos bawat linggo ay naglalabas ang n8n ng bagong minor version, at paminsan-minsan ay binabago nito ang database schema o node behavior sa pagitan ng mga ito. Kaya kapag latest ang ginamit, maaaring awtomatikong mag-pull ng build ang system nang walang pagsusuri, at ma-migrate nito ang database sa mismong pagsisimula. Mag-pin ng version, basahin ang mga release note bago mag-upgrade, at tinutukoy ng n8n doon ang mga breaking change. Mag-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

Sa pagtalon sa major version pinakamahalaga ang prosesong ito. 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 nagbabasa ng process.env hanggang ibalik mo ito sa false. Sa release ding iyon, nagsimulang magpatupad ng mahigpit na permission sa settings file, ginawang default ang task runners, at pinalitan ang Activate toggle ng workflow ng Publish. Basahin ang page tungkol sa breaking change sa 2.0 bago tumawid sa major version boundary. Awtomatikong pinapatakbo ng n8n ang anumang kailangang database migration sa pagsisimula. Iyan mismo ang dahilan kung bakit hindi optional ang pg_dump bago mag-upgrade. Dahil encrypted ang credentials gamit ang key sa .env at nasa Postgres ang data, disposable ang mga container. Mag-upgrade sa pamamagitan ng pagpapalit sa mga ito, at mag-rollback sa pamamagitan ng pag-pin sa dating tag at pag-restore ng dump.

Mga failure mode at mga string na makikita mo

The requested webhook "POST hello" is not registered. Isang 404 ang lumalabas kapag tumatawag sa webhook na hindi pa published ang workflow, o kapag tinatawag ang test path habang walang nakikinig. Sumasagot lamang ang test paths (/webhook-test/...) habang na-click mo ang "Listen for test event"; sumasagot lamang ang production paths (/webhook/...) kapag published na ang workflow. Ibig sabihin ng sibling na 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 ang 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 public base mo. I-set ang WEBHOOK_URL=https://n8n.example.com/, pagkatapos ay i-recreate 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 ng proxy, halos palaging mali ang N8N_HOST o WEBHOOK_URL, walang WebSocket Upgrade headers ang proxy, o hindi tumutugma 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 tumutugma ang password na ipinapadala ng n8n sa password na ginamit noong in-initialize ang database. Ang karaniwang problema: binabasa ng Postgres ang POSTGRES_PASSWORD isang beses lamang kapag nag-initialize ito ng empty data directory. Simulan ang stack nang isang beses, saka baguhin ang POSTGRES_PASSWORD sa .env, at mananatili sa umiiral na postgres_data volume ang lumang password. Ibalik ito sa orihinal na value, o kung wala kang kailangang panatilihing data, gamitin ang docker compose down at docker volume rm sa postgres volume, saka itong i-start muli mula sa simula.

EACCES: permission denied, open '/home/node/.n8n/config' kapag nag-start. Tumatakbo ang n8n bilang user na node (UID 1000) at hindi nito maisulat ang config directory nito. Nangyayari ito 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, gamitin muna ang sudo chown -R 1000:1000 ./n8n_data.

Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide. Changing permissions to 0600.. Simula sa 2.x line, ipinapatupad ng n8n bilang default ang 0600 sa settings file na iyon at awtomatiko nitong inaayos ito kapag nag-boot. Ibig sabihin ng log line na ito ay naitama na nito ang mode, karaniwang matapos ang bind mount o matapos ibalik ang file mula sa restore na may masyadong 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 buong line na hindi tumutugma ang encryption key sa settings file na /home/node/.n8n/config sa N8N_ENCRYPTION_KEY sa environment mo. Naiiba ang key sa environment mo sa key na isinulat ng n8n sa data volume nito noong nakaraang run. Kadalasan itong nangyayari dahil awtomatikong gumawa ang n8n ng random key sa naunang boot habang hindi naka-set ang variable, at pagkatapos ay nag-set ka ng ibang key. Ibalik ang orihinal na key sa .env, o, kung talagang wala kang kailangang panatilihing stored credentials, i-delete ang config file sa loob ng n8n_data volume at hayaan ang n8n na gumawa nito muli. Tandaan na magiging hindi 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.. Na-set mo ang N8N_PROTOCOL=https pero naabot mo ang n8n gamit ang plain HTTP, karaniwang sa direktang pag-access sa IP at port sa halip na sa 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 nakaharap sa internet.

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

FAQ

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

Ayos ang SQLite (ang default) para subukan ang n8n at para sa personal na instance na tig-iisang workflow lang ang pinapatakbo. Gumamit ng Postgres para sa anumang workflow na mahalaga sa iyo: 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 n8n webhook ko?

Halos palagi itong dahil sa WEBHOOK_URL. Kapag unset o mali ito, nagpi-print ang n8n ng mga webhook address na binuo mula sa N8N_HOST:N8N_PORT. Kadalasan, may :5678 o localhost ang mga ito. Mukhang valid ang mga address pero hindi maaabot mula sa internet, kaya hindi nakakarating ang mga request ng caller. Itakda ang WEBHOOK_URL=https://n8n.example.com/ at tiyaking URL na walang port ang ipinapakita ng node. Ang ikalawang sanhi ay ang pagtawag sa production URL ng workflow na hindi mo pa na-publish, 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. Nae-encrypt gamit nito ang bawat naka-store na credential. Kapag nawala ito, permanente nang hindi made-decrypt ang mga credential. Kopyahin ito palabas ng server sa araw na gawin mo ito. Ikalawa, isang pg_dump ng Postgres database para sa mga workflow, history, at credential. Kailangan ng restore ang dalawang ito: 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. TLS termination ang ginagawa ng reverse proxy sa harap nito. I-bind ang n8n sa 127.0.0.1:5678 upang proxy lamang ang makakaabot dito. Pagkatapos, gumamit ng Traefik na may automatic certificates o nginx na may Let's Encrypt certificate. Itakda ang N8N_PROTOCOL=https at WEBHOOK_URL=https://your-host/, at tiyaking ipinapasa ng proxy ang WebSocket Upgrade headers; kung hindi, magha-hang ang editor.

Paano ako ligtas na mag-a-upgrade ng n8n?

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