Jinsi ya ku-host n8n kwenye VPS kwa Docker na HTTPS

Unachojenga

n8n ni zana ya otomatiki ya workflow: kihariri cha kuona ambapo trigger, webhook, ratiba, au uwasilishaji wa fomu, huanzisha msururu wa nodes zinazoita API, kubadilisha data, na kuandika kwenye mifumo mingine. Imekuwa kiunganishi kikuu cha workflows za AI-agent kwa sababu inawasiliana na kila mtoa huduma wa model na database bila wewe kuandika huduma yoyote. docker run moja hupata kihariri kinachofanya kazi ndani ya dakika mbili. Mwongozo huu unahusu asilimia tisini nyingine: kuifanya iwe imara kwa kutumia Postgres badala ya faili la SQLite chaguo-msingi, kuifikia kupitia HTTPS, na, sehemu ambayo karibu kila mtu hukosea, kufanya webhooks kutoa URL ambayo ulimwengu wa nje unaweza kuifikia kweli.

Stack iliyokamilika ni containers mbili kwenye Docker network moja: n8n yenyewe, na database ya Postgres inayohifadhi workflows na credentials zake. Reverse proxy kwenye host inafanya TLS termination na kupeleka maombi kwa n8n kwenye localhost, kwa hivyo hakuna kitu kinachokabili Internet isipokuwa kupitia proxy hiyo. Inakaa pamoja na huduma nyingine kwenye orodha fupi ya self-hosting ya 2026.

Mahitaji ya awali, na mipaka ya kweli

Unahitaji VPS yenye angalau 1 GB ya RAM. Panga kutumia 2 GB workflows zikianza kufanya kazi halisi, kwa sababu executions pamoja na Node.js runtime hutumia memory. OOM killer ikisimamisha container katikati ya execution, utajifunza hilo kwa njia yenye usumbufu mkubwa. vCPU moja inatosha kuanzia.

Ikiwa server hii itaendesha pia huduma nzito zaidi, ipangie rasilimali kulingana na huduma hiyo kwanza. Photo library ndiyo chanzo cha kawaida cha mahitaji makubwa. Mahitaji halisi ya chini ya RAM ya PhotoPrism na Immich ni makubwa sana kuliko chochote kinachohitajika na n8n.

Hali ni hiyo hiyo kwa media box. Jellyfin server pamoja na front end ya kuvinjari maudhui yake, kama Halcyon, inayounda upya library kama duka la kukodisha la miaka ya 90, zitatumia RAM na uwezo wa transcoding muda mrefu kabla n8n haijatambua upungufu huo.

Unahitaji domain au subdomain, tuseme n8n.example.com, yenye A record inayoelekeza kwenye IP ya umma ya VPS ambayo inatatuliwa (resolve) kabla ya kuomba cheti. Ports 80 na 443 lazima ziwe wazi kwa proxy; port ya n8n yenyewe, 5678, haipaswi kukabili Internet. Unahitaji Docker Engine na Compose plugin; ikiwa docker compose version inaleta hitilafu ya docker: 'compose' is not a docker command, basi unatumia binary ya zamani ya standalone, na plugin hiyo ni sudo apt install docker-compose-plugin.

SQLite inafaa kwa majaribio, Postgres inafaa kwa huduma unayotegemea

Database chaguo-msingi ya n8n ni faili ya SQLite iliyopo /home/node/.n8n/database.sqlite. Kwa majaribio ya awali inafaa, lakini usipoweka volume utapoteza data kila unapounda upya container, jambo ambalo ni funzo tosha. Sababu ya kuhamia Postgres si kasi pekee; ni kwamba SQLite inashikilia lock moja ya uandishi, hivyo instance inayoendesha workflow nyingi kwa wakati mmoja, au mode ya queue utakayohitaji baadaye, itatoa SQLITE_BUSY: database is locked wakati wa concurrency. Postgres haina kizuizi hicho, inachelezwa (backup) kwa usahihi na pg_dump, na ndiyo database inayopendekezwa katika nyaraka za n8n kwa seva unayotegemea. Kubadili database baadaye kunamaanisha kuhamisha data kwa mikono, hivyo kama seva hii ni muhimu, anza na Postgres.

DNS na firewall

Elekeza record ya DNS na ufungue port kwanza, ili hatua ya cheti isifeli baadaye kwa sababu ya jina lisiloweza kutatuliwa (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

Usifungue port 5678. Faili la compose hufunga n8n kwenye 127.0.0.1:5678 ili reverse proxy ya host pekee iweze kuifikia, na ufw allow 5678 ingeondoa utengano huo.

Faili la Compose

Tengeneza saraka ya kazi na docker-compose.yml. Hii ndiyo stack nzima, huduma mbili, mtandao mmoja wa ndani, na volumes mbili zenye majina.

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:

Maamuzi machache yanayostahili kuwekwa wazi. DB_POSTGRESDB_HOST=postgres ndilo jina la huduma, ambalo Docker hulitatua kwenye mtandao ulioshirikiwa, si localhost, ambalo ndani ya container ya n8n linamaanisha n8n yenyewe. depends_on yenye condition: service_healthy huizuia n8n kushindana na Postgres wakati wa boot; bila hiyo n8n huanza, haioni database, na kisha hujifunga. Named volume n8n_data iliyopo kwenye /home/node/.n8n huhifadhi ufunguo wa encryption na, kwenye SQLite, database, ambayo ni saraka moja ambayo hupaswi kuipoteza. Funga image kwenye toleo kamili, usitumie kamwe latest; sababu ziko kwenye sehemu ya uboreshaji hapa chini.

Faili la siri

Usiweke kamwe nywila kwenye faili la compose. Ziweke kwenye faili la .env lililopo karibu nalo ambalo Compose hulitambua kiotomatiki, na uzitengeneze ili ziwe za kubahatisha kweli.

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 ndiyo kamba muhimu zaidi hapa, ndiyo ufunguo ambao kila kitambulisho kilichohifadhiwa husimbwa kwa njia fiche (encrypted) nao. Iweke wazi badala ya kuruhusu n8n itengeneze moja, kwa sababu thamani uliyotengeneza wewe ni ile unayoweza kuiandika na kuirejesha. Mara tu n8n inapoisimba kitambulisho chake cha kwanza kwa ufunguo huu, kuubadilisha hufanya kila kitambulisho kutoweza kusomeka, kwa hivyo iweke mara moja, sasa, na usiguse kamwe mstari huo tena.

Vigezo vya mazingira vinavyoamua kama webhooks zinafanya kazi

Vigezo vinne hudhibiti jinsi n8n inavyojitambulisha kwa ulimwengu wa nje, na kukosea hapa ndilo swali la kwanza la msaada wa kiufundi kwa n8n.

• N8N_HOST ni hostname ya umma, n8n.example.com. Iache ikiwa katika thamani ya awali ya localhost ukiwa nyuma ya proxy, vinginevyo editor itajaribu kupakia API yake yenyewe kutoka localhost katika browser yako, jambo ambalo litafeli.
• N8N_PROTOCOL=https huiambia n8n kuwa inahudumiwa kupitia TLS, kwa hivyo huweka alama kwenye session cookie yake kama Secure na kutengeneza URL za https://.
• N8N_PORT=5678 ni port ambayo n8n inasikiliza ndani ya container. Hii si port ya umma; proxy ndiyo inayomiliki 443.
• WEBHOOK_URL=https://n8n.example.com/ ndiyo inayokwamisha watu. n8n huchapisha anwani za webhook unazozinakili kwenye Stripe, GitHub au mpigaji yeyote wa nje kwa kuzijenga kutoka kwa thamani hizi. Ikiwa haijawekwa au ni mbaya, n8n itatumia N8N_HOST:N8N_PORT na kukupa https://n8n.example.com:5678/webhook/... au, mbaya zaidi, http://localhost:5678/webhook/..., zikichapishwa bila hitilafu yoyote, zikionekana kuwa sahihi, lakini haziwezi kufikiwa kutoka kwenye Internet, hivyo maombi ya mpigaji hayafiki kimyakimya. Iweke iwe URL kamili ya umma yenye slash mwishoni, kisha thibitisha kuwa node ya webhook inaonyesha URL isiyo na port.

N8N_PROXY_HOPS=1 huiambia Express server ya n8n kuamini proxy moja iliyo mbele yake, ili rate-limiting na kipengele chochote kinachosoma IP ya mteja kione anwani halisi badala ya ile ya proxy. Kigezo kimoja ambacho kwa makusudi hupaswi kukiweka hapa ni N8N_RUNNERS_ENABLED: task runners, n8n inayoendesha mantiki ya Code-node katika mchakato tofauti uliotengwa (sandboxed), imekuwa ya kawaida tangu toleo la 1.69 na ni ya lazima kuanzia mfululizo wa 2.x ambao mwongozo huu unautumia, kwa hivyo chaguo la zamani limepitwa na wakati. Ikiwa utaiweka sasa, n8n itatoa tu notisi ikikuambia uiondoe.

Kuanza kwa mara ya kwanza

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

Boot ya kwanza yenye afya huishia na mstari wa Editor is now accessible via:, ukiwa na mstari wa n8n ready on ..., port 5678 juu yake. docker compose ps inapaswa kuonyesha kontena zote mbili Up, huku postgres ikiwa imewekwa alama ya (healthy). Ikiwa n8n itakwama katika mzunguko wa Restarting, soma logi; mara nyingi tatizo huwa ni muunganisho wa database au ruhusa za volume zilizoelezwa hapa chini.

TLS kwa kutumia reverse proxy

n8n yenyewe hutumia HTTP ya kawaida kwenye 5678; kitu kilicho mbele yake hufanya TLS termination. Kuna chaguo mbili rahisi.

Ikiwa tayari unaendesha containers kadhaa, weka n8n nyuma ya reverse proxy ya Traefik inayotoa vyeti vya TLS kiotomatiki kwa kutumia labels chache, Traefik huomba na kuhuisha cheti kwa ajili yako.

Ikiwa hii ndiyo programu pekee kwenye seva, virtual host ya nginx yenye cheti cha Let's Encrypt ni rahisi zaidi. Tumia usanidi wa Certbot na TLS wa nginx kwa Ubuntu 24.04 ili kupata cheti, kisha tumia block hii ya seva:

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 za Upgrade na Connection "upgrade" si za hiari. n8n hutuma masasisho ya moja kwa moja ya utekelezaji kwenye kihariri kupitia WebSocket, na bila mistari hiyo miwili, ukurasa wa kuingia hupakia kisha hukwama na kuonyesha ujumbe wa muunganisho uliopotea. proxy_read_timeout 3600 huzuia utekelezaji wa muda mrefu kukatizwa na muda wa kawaida wa nginx wa sekunde 60. Header ya X-Forwarded-Proto $scheme ni mwenza wa N8N_PROXY_HOPS=1: inaiambia n8n kuwa ombi la awali lilikuwa HTTPS ingawa proxy inafika kwenye huduma hiyo kupitia HTTP ya kawaida, hivyo n8n haiamui kuwa muunganisho si salama na kukataa cookie yake yenyewe.

Workflow yako ya kwanza, ili kuifanya iwe halisi

Fungua https://n8n.example.com/, tengeneza akaunti ya mmiliki (sehemu inayofuata), na ujenge workflow ndogo zaidi inayothibitisha kuwa njia inafanya kazi: webhook ya kuingia, HTTP call, na jibu la kutoka.

1. Ongeza node ya Webhook. Weka method iwe POST na path kama hello. Inaonyesha URL mbili, Test URL na Production URL, ambazo ndizo chanzo cha nusu ya ripoti za "webhook yangu haifanyi kazi". Test URL hujibu ombi moja, na pale tu unapobofya Listen for test event; baada ya hapo huisha muda wake. Production URL hujibu wakati wowote workflow inapokuwa Active.
2. Ongeza node ya HTTP Request baada yake, ikielekezwa kwenye API yoyote ya umma ya JSON, GET kwenda https://api.github.com/zen inarudisha string ya mstari mmoja, ambayo inatosha.
3. Ongeza node ya Respond to Webhook, na uweke chaguo la Respond la node ya Webhook kuwa "Using Respond to Webhook node" ili mpigaji apate matokeo ya node ya HTTP.
4. Washa workflow kwa kubofya Active (kulia juu) na uipigie simu: curl -X POST https://n8n.example.com/webhook/hello. Unapaswa kupata mstari wa zen kurudi, POST ikiingia, API call ikifanyika, na jibu likitoka, ambayo ndiyo muundo wa automation nyingi za kweli.

Toleo la ratiba (scheduled) hubadilisha node ya Webhook na Schedule Trigger na kupiga model endpoint badala yake, ile inayojiendesha yenyewe kutoka Ollama inayofanya kazi kwenye VPS hiyo hiyo ni njia nzuri ya kujenga kifupishi cha kila usiku.

Usimamizi wa watumiaji, si basic auth

Miongozo ya zamani ya n8n inakuambia uweke N8N_BASIC_AUTH_ACTIVE=true. Vigezo hivyo viliondolewa katika n8n 1.0 na sasa havifanyi chochote. Siku hizi uthibitishaji unatumia akaunti ya owner: unapofungua editor mara ya kwanza, n8n inakulazimisha uunde owner mwenye email na password, na kizuizi hicho ni cha lazima; hakuna mode ya anonymous. Iunde mara moja baada ya boot ya kwanza, kabla hujawapa wengine URL: kati ya docker compose up na kutumwa kwa mara ya kwanza kwa form hiyo, instance inaweza kudaiwa na mtu yeyote anayeifikia kwanza. Layer ya basic-auth kwenye reverse proxy inaweza kuwa kizuizi cha ziada kinachofaa, lakini ni safu ya pili, si uthibitishaji halisi. Akaunti ya owner na kila kitu kingine katika mwongozo huu hufanya kazi kwenye free community edition; ukihitaji baadaye users wa ziada wenye roles za kina, au SSO, kusoma ni vipengele gani vya n8n vinahitaji leseni ya kulipia kutakusaidia kabla hujapanga kulingana navyo.

Backup: ufunguo wa usimbaji kwanza, kisha database

Vitu viwili vinahitaji kuhifadhiwa (backup), na havina uzito sawa wa kurejeshwa.

N8N_ENCRYPTION_KEY. Kila kitambulisho unachohifadhi kwenye n8n, token za API, nywila za database, na siri za OAuth, husimbwa kwa njia fiche (encrypted) ukiwa umepumzika kwa kutumia ufunguo huu. Workflow zilizopo kwenye Postgres hazina maana bila ufunguo huu: ukirejesha database kwenye seva mpya ukiwa na ufunguo tofauti, n8n haitaweza kusoma kitambulisho chochote, na hakuna njia ya kurejesha au kuweka upya (reset). Faili lako la .env ndilo linaloshikilia ufunguo huu; nakili faili hilo nje ya seva, bora zaidi kwenye meneja wa nywila (password manager), siku ile ile unayolitengeneza. Hii ndiyo backup muhimu zaidi.

Database ya Postgres, kwa ajili ya workflow, historia ya utekelezaji, na vitambulisho vyenyewe vilivyosimbwa:

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

Tekeleza amri hiyo kwa ratiba na unakili dump hiyo nje ya seva. Ili kurejesha kwenye VPS mpya: anzisha stack mara moja ili database iwepo, simamisha n8n, pakia dump hiyo kwa kutumia psql, weka ufunguo uleule wa N8N_ENCRYPTION_KEY kwenye .env, kisha uanzishe n8n. Ufunguo uleule pamoja na dump ndiyo njia ya kupata instance inayofanya kazi; ufunguo mpya unamaanisha workflow ambazo haziwezi kutumia kitambulisho hata kimoja.

Uboreshaji: funga tag

Faili ya compose inafunga n8nio/n8n:2.29.10 badala ya latest kwa makusudi. n8n hutoa toleo jipya la minor karibu kila wiki na mara nyingine hubadilisha schema ya database au tabia ya node kati ya matoleo hayo, kwa hivyo latest inamaanisha kuwa pull isiyosimamiwa inaweza kukupa build inayohamisha (migrate) database yako punde tu inapoanza. Funga toleo maalum, soma maelezo ya toleo kabla ya kupandisha toleo, n8n huainisha mabadiliko yanayoweza kuvunja utendaji (breaking changes) hapo, na ufanye uboreshaji kwa uangalifu:

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

Kuruka kwa major-version ndiko ambako hili ni muhimu zaidi. Mstari wa 2.0, kwa mfano, ulibadilisha N8N_BLOCK_ENV_ACCESS_IN_NODE kuwa true kwa chaguo-msingi, kwa hivyo node yoyote ya Code iliyosoma process.env hupoteza ufikiaji kimya kimya hadi utakapoiweka tena kuwa false; toleo hilo hilo lilianza kutekeleza ruhusa kali kwenye faili ya settings. Soma ukurasa wa mabadiliko ya 2.0 kabla ya kuvuka mpaka wa major-version. n8n huendesha uhamiaji wowote wa database unaohitajika kiotomatiki wakati wa kuanza, na ndiyo sababu hasa ya pg_dump kabla ya uboreshaji si ya hiari. Kwa sababu vitambulisho (credentials) vinakaa vikiwa vimesimbwa kwa ufunguo katika .env na data inakaa katika Postgres, container zinaweza kutupwa: unafanya uboreshaji kwa kuzibadilisha, na unarudisha toleo la awali kwa kufunga tag iliyotangulia na kurejesha dump.

Njia za kufeli, pamoja na ujumbe utakaouona

The requested webhook "POST hello" is not registered. Hitilafu ya 404 inatokea unapopiga webhook ambayo workflow yake haijawa Active, au unapopiga njia ya majaribio (test path) wakati hakuna anayesikiliza. Njia za majaribio (/webhook-test/...) hujibu tu pale unapobofya "Listen for test event"; njia za uzalishaji (/webhook/...) hujibu tu wakati swichi ya workflow imewashwa. Hitilafu ndugu ya This webhook is not registered for GET requests. Did you mean to make a POST request? inamaanisha mbinu (method) si sahihi, node inatarajia POST na wewe umetuma GET.

URL ya webhook inaonyesha :5678 au localhost. Node inaonyesha https://n8n.example.com:5678/webhook/... au http://localhost:5678/.... WEBHOOK_URL haijawekwa au si sahihi, kwa hivyo n8n ilijenga anwani hiyo kutoka N8N_HOST:N8N_PORT badala ya anwani yako ya umma (public base). Weka WEBHOOK_URL=https://n8n.example.com/, tengeneza upya container kwa kutumia docker compose up -d, na port hiyo itatoweka.

There was a problem loading init data kwenye kivinjari. Editor imepakia lakini haiwezi kufikia API yake ya backend. Nyuma ya proxy, hii karibu kila mara inamaanisha N8N_HOST au WEBHOOK_URL si sahihi, proxy inakosa header za WebSocket Upgrade, au N8N_PROTOCOL hailingani na jinsi unavyounganisha. Thibitisha vigezo vinne vya umma (public-facing variables) na uhakikishe proxy inapitisha Upgrade na Connection.

password authentication failed for user "n8n" kwenye logi, huku container ikianzishwa upya. Nenosiri ambalo n8n inatuma halilingani na lile ambalo database ilianzishiwa. Mtego: Postgres inasoma POSTGRES_PASSWORD tu wakati inapoanzisha saraka ya data iliyo tupu. Anzisha stack mara moja, kisha ubadilishe POSTGRES_PASSWORD katika .env, na volume ya postgres_data iliyopo bado itashikilia nenosiri la zamani. Rudisha nenosiri la asili, au, ikiwa huna data ya kuhifadhi, docker compose down na docker volume rm volume ya postgres, kisha uianzishe upya ikiwa safi.

EACCES: permission denied, open '/home/node/.n8n/config' wakati wa kuanza. n8n inaendeshwa kama mtumiaji node (UID 1000) na haiwezi kuandika kwenye saraka yake ya usanidi. Hili huwakuta watu wanaotumia bind-mount ya folda ya host (./n8n_data:/home/node/.n8n) inayomilikiwa na root. Tumia volume yenye jina (named volume) iliyoonyeshwa hapo juu, au ikiwa unasisitiza kutumia bind mount, fanya sudo chown -R 1000:1000 ./n8n_data kwanza.

Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide. Changing permissions to 0600.. Kuanzia toleo la 2.x, n8n inatekeleza 0600 kwenye faili hiyo ya mipangilio kwa chaguo-msingi na inajirekebisha yenyewe wakati wa boot. Mstari huu wa logi unamaanisha kuwa tayari imerekebisha mode hiyo, mara nyingi baada ya bind mount au baada ya restore kunakili faili hiyo ikiwa na ruhusa (permissions) zisizo sahihi. Hakuna hatua inayohitajika; weka N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false tu ikiwa mfumo wako wa faili hauwezi kuhimili ruhusa hizo.

Mismatching encryption keys, mstari kamili unasema ufunguo wa usimbaji (encryption key) katika faili ya mipangilio /home/node/.n8n/config hailingani na N8N_ENCRYPTION_KEY iliyo katika mazingira yako (environment). Ufunguo uliopo kwenye mazingira yako unatofautiana na ule ambao n8n iliandika kwenye volume yake ya data katika uendeshaji uliopita, mara nyingi kwa sababu n8n ilizalisha ufunguo wa nasibu (random key) wakati wa boot ya awali ambapo kigezo hicho hakikuwa kimewekwa, na kisha wewe ukaweka ufunguo tofauti. Rudisha ufunguo wa asili katika .env, au, ikiwa kweli huna vitambulisho (credentials) vilivyohifadhiwa ambavyo vina thamani ya kuhifadhiwa, futa faili ya config iliyo ndani ya volume ya n8n_data na uiruhusu n8n izalishe upya, ukikubali kuwa vitambulisho vilivyopo vitashindwa kusomeka.

Bango la kuingia (login banner) kuhusu 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. Uliweka N8N_PROTOCOL=https lakini ukaifikia n8n kupitia HTTP ya kawaida, kwa kawaida kwa kugonga IP na port moja kwa moja badala ya HTTPS proxy. Ifikie kupitia https://n8n.example.com/. Ni pale tu ambapo huwezi kutumia HTTPS ndipo unapaswa kuweka N8N_SECURE_COOKIE=false, na usifanye hivyo kamwe kwenye mashine inayotazama Internet.

Ili kuweka mfano wa lugha (language model) ndani ya workflow hizo, angalia kujenga AI workflows kwa kutumia Claude na n8n.

FAQ

Je, nitumie SQLite au Postgres kwa ajili ya n8n?

SQLite (chaguo-msingi) inafaa kwa kujaribu n8n na kwa matumizi ya kibinafsi ambapo workflow moja huendeshwa kwa wakati mmoja. Hamia kwenye Postgres kwa huduma yoyote unayoitegemea: kufuli ya mwandishi mmoja (single writer lock) ya SQLite husababisha database is locked wakati wa concurrency, na Postgres inawezesha backup safi kwa kutumia pg_dump. Uhamiaji wa baadaye ni wa mikono, kwa hivyo ikiwa seva ni muhimu, anza na Postgres.

Kwa nini webhooks zangu za n8n hazifanyi kazi?

Karibu kila mara ni WEBHOOK_URL. Ikiwa haijawekwa au si sahihi, n8n huchapisha anwani za webhook zilizoundwa kutoka N8N_HOST:N8N_PORT, mara nyingi zikiwa na :5678 au localhost ndani yake, ambazo huonekana sahihi lakini haziwezi kufikiwa kutoka kwenye Internet, hivyo maombi ya mpigaji hayafiki. Weka WEBHOOK_URL=https://n8n.example.com/ na uhakikishe kuwa node inaonyesha URL bila port. Sababu ya pili ni kupiga webhook ambayo workflow yake haijawashwa (Active), jambo linalorejesha The requested webhook ... is not registered..

Ni nini lazima nifanyie backup katika n8n?

Vitu viwili. N8N_ENCRYPTION_KEY kutoka kwenye faili yako ya .env, kwa sababu kila credential iliyohifadhiwa imesimbwa kwa njia fiche (encrypted) nayo na kuipoteza kutafanya credentials hizo zisiweze kusomeka milele; nakili faili hiyo nje ya seva siku unayoiunda. Na pg_dump ya database ya Postgres kwa ajili ya workflows, historia na credentials. Urejeshaji (restore) unahitaji vyote viwili: ufunguo uleule pamoja na dump.

Ninawezaje kuweka n8n nyuma ya HTTPS?

n8n hutoa HTTP ya kawaida kwenye port 5678; reverse proxy iliyo mbele yake hufanya TLS termination. Funga n8n kwenye 127.0.0.1:5678 ili proxy pekee iweze kuifikia, kisha tumia Traefik yenye vyeti vya kiotomatiki au nginx yenye cheti cha Let's Encrypt. Weka N8N_PROTOCOL=https na WEBHOOK_URL=https://your-host/, na uhakikishe kuwa proxy inasambaza headers za WebSocket Upgrade vinginevyo editor itakwama.

Ninawezaje kuboresha (upgrade) n8n kwa usalama?

Tumia image tag maalum badala ya latest, chukua pg_dump kwanza kwa sababu n8n huendesha migrations kiotomatiki wakati wa kuanza, soma maelezo ya toleo (release notes) kwa ajili ya mabadiliko makubwa, kisha badilisha tag na uendeshe docker compose pull n8n && docker compose up -d n8n. Container inaweza kutupwa, kwa hivyo unaweza kurudi kwenye toleo la awali kwa kuweka tag ya awali na kurejesha dump ya kabla ya upgrade.