Protektahan ang editor
Ilagay ang editor sa likod ng HTTPS at sinusuportahang authentication. Limitahan ang administrative access at iwasan ang pampublikong registration kapag hindi kailangan. Ang mga webhook route ay nangangailangan ng sariling desisyon sa exposure at authentication.
Itago ang credential key
I-back up ang naka-configure na encryption key na may angkop na proteksyon. Ang pag-restore ng database nang walang tamang key ay maaaring mag-iwan sa mga naka-save na kredensyal na hindi magamit. Itago ang key sa labas ng mga screenshot, repository at unfiltered logs.
Sadyang i-scale ang execution path
Para sa abalang setup, suriin ang sinusuportahang database, queue at worker model. Ang Redis at hiwalay na worker ay nagdaragdag ng sarili nilang mga kinakailangan sa access at persistence. Limitahan ang sabay-sabay na job upang ang pagdagsa ay hindi maubos ang VPS o panlabas na API budget.
Itago lamang ang kapaki-pakinabang na execution data
Kayang hawakan ng mga workflow ang mga token, personal na rekord at dokumento. Itakda ang paglilinis ng execution history, i-redact ang mga sensitibong halaga at maingat na tukuyin ang mga retry. Ang na-duplicate na webhook ay hindi dapat magdulot ng hindi sinasadyang pangalawang bayad o mensahe.
Ituring ang encryption key bilang bahagi ng database
Ang mga naka-save na kredensyal ay nakadepende sa encryption key ng n8n. Panatilihin ang state directory na naglalaman ng awtomatikong nabuong key o itakda ang N8N_ENCRYPTION_KEY mula sa isang pribadong secret store. Kailangan ng lahat ng queue worker ang parehong key tulad ng pangunahing proseso. Subukan ang restoration gamit ang isang disposable credential; ang na-restore na database lamang ay maaaring mukhang maayos habang ang mga kredensyal nito ay nananatiling hindi mabasa.
- Panatilihin ang key sa labas ng pampublikong direktoryo at repository
- I-back up nang tuloy-tuloy ang database
- Gamitin ang sinusuportahang PostgreSQL para sa inilaan na production deployment
Opisyal na dokumentasyon: n8n encryption-key configuration
Bigyan ang webhooks ng kanilang pampublikong address
Ang reverse proxy tulad ng Caddy ay maaaring mag-terminate ng HTTPS habang ang n8n ay nakikinig sa loob. Ginagamit ng kasalukuyang dokumentasyon ang N8N_WEBHOOK_URL para sa external webhook origin at pinapalitan ang lumang pangalang WEBHOOK_URL mula sa bersyon 2.35.0. Itakda ang trusted proxy-hop count sa totoong path; ang isang proxy ay gumagamit ng N8N_PROXY_HOPS=1. Panatilihin ang forwarded host, protocol at impormasyon ng client. Subukan ang webhook mula sa labas ng server at i-verify ang production URL nito.
- Sadyang itakda ang timezone ng workflow
- Prune ang execution history na naglalaman ng sensitibong input
- Gamitin ang queue workers at Redis lamang kasama ang mga kinakailangang pribadong access control
# Example: one HTTPS reverse proxy
N8N_WEBHOOK_URL=https://automations.example.com/
N8N_PROXY_HOPS=1Opisyal na dokumentasyon: n8n sa likod ng reverse proxy
Tukuyin ang workload at ang pinapayagang integration
Ilista ang mga trigger, external account, inaasahang dami ng execution at ang maximum na gastos o side effect na maaaring likhain ng bawat workflow. Suriin ang n8n licence para sa aktwal na paggamit, lalo na kung iaalok ito bilang serbisyo sa iba. Magkaiba ang pangangailangan sa resource ng maliit na naka-iskedyul na workflow at ng public webhook processor. Magsimula sa sinusuportahang release, pribadong persistent state, TLS name at database na angkop sa deployment; iwasang ilantad ang database ports gamit ang editor.
- Gumamit ng hiwalay at limitadong kredensyal para sa bawat integration.
- Itakda ang nilalayong timezone ng workflow at retention ng execution history.
- Panatilihing walang naka-embed na tunay na secret ang mga na-export na workflow.
Opisyal na dokumentasyon: n8n Docker deployment
Itakda ang pampublikong webhook origin para sa naka-install na release
Ang reverse proxy tulad ng Caddy ay umaabot sa n8n sa loob habang tinatawag ng external service ang HTTPS webhook origin nito. Gamitin ang webhook URL variable na dokumentado para sa naka-install na release; pinangalanan ng kasalukuyang dokumentasyon ang N8N_WEBHOOK_URL, habang ginamit ng mas lumang release ang WEBHOOK_URL. Itakda ang totoong proxy-hop count sa halip na magtiwala sa arbitraryong forwarded header. Panatilihing hiwalay ang editor access policy sa webhook authentication, at i-verify na walang internal host o port ang production callback.
# Example values for a supported current release, behind one proxy:
N8N_WEBHOOK_URL=https://automations.example.com/
N8N_PROXY_HOPS=1Opisyal na dokumentasyon: n8n mga setting ng webhook reverse-proxy
Subukan ang isang hindi mapanganib na workflow bago magbigay ng write access
Magsimula sa isang read-only na kahilingan o isang disposable na test record. Subukan ang production webhook mula sa labas ng VPS, pagtanggi sa authentication at isang sadyang pagsubok muli. Ang paulit-ulit na kahilingan ay hindi dapat aksidenteng lumikha ng pangalawang makabuluhang aksyon. Suriin ang mga execution log para sa mga na-leak na input, pagkatapos ay maglapat ng retention policy. Kung gumagana lamang ang webhook sa test mode ng editor, siyasatin kung ang workflow ay nai-publish/aktibo at kung ang production at test routes ay umaabot sa tamang proseso.
- Gumamit ng disposable integration credential para subukan ang isang restore.
- Panatilihin ang independiyenteng naka-encrypt na kopya ng N8N_ENCRYPTION_KEY o ng nabuong key state.
- Huwag magpadala ng sample na password o API token sa mga napanatiling debugging output.
Opisyal na dokumentasyon: n8n encryption key
Mag-scale lamang pagkatapos maobserbahan ang bottleneck sa execution
Ang queue mode ay nagdadagdag ng Redis, worker at shared database; tumatanggap ang pangunahing proseso ng trigger habang nagsasagawa ng execution ang mga worker. Dapat gamitin ng bawat worker ang parehong credential encryption key. Sundin ang kasalukuyang binary-data storage requirement bago ilipat ang workflow na may file sa queue mode. Limitahan ang concurrency at upstream API budget, at subaybayan ang queue age at failure. I-backup nang sabay ang database, state at key; ang pag-restart ng container ay hindi recovery plan para sa hindi mababasang naka-save na credential.
Opisyal na dokumentasyon: n8n queue mode · Mga setting ng execution pruning