Protejează editorul
Plasează editorul în spatele HTTPS și al autentificării acceptate. Restrânge accesul administrativ și evită înregistrarea publică atunci când nu este necesară. Rutele webhook necesită propriile decizii de expunere și autentificare.
Păstrează cheia de autentificare
Faceți o copie de rezervă a cheii de criptare configurate cu protecție adecvată. Restaurarea unei baze de date fără cheia corectă poate lăsa credențialele salvate inutilizabile. Țineți cheia în afara capturilor de ecran, depozitelor și jurnalelor nefiltrate.
Scalați deliberat calea de execuție
Pentru o configurație solicitantă, verificați baza de date, coada și modelul de workeri acceptate. Redis și workerii separați adaugă propriile cerințe de acces și persistență. Limitați sarcinile concurente astfel încât un vârf să nu epuizeze VPS sau un buget extern API.
Păstrează doar datele de execuție utile
Fluxurile de lucru pot gestiona tokenuri, date personale și documente. Setați curățarea istoricului de execuție, mascați valorile sensibile și definiți cu atenție reîncercările. Un webhook duplicat nu trebuie să provoace o a doua plată sau un al doilea mesaj nedorit.
Tratați cheia de criptare ca parte a bazei de date
Credențialele salvate depind de cheia de criptare a n8n. Păstrați directorul de stare care conține o cheie generată automat sau setați N8N_ENCRYPTION_KEY dintr-un depozit privat de secrete. Toți workerii din coadă au nevoie de aceeași cheie ca procesul principal. Testați restaurarea cu o credențială de unică folosință; o bază de date restaurată singură poate părea sănătoasă în timp ce credențialele sale rămân ilizibile.
- Păstrează cheia în afara directorului public și a depozitului
- Faceți backup consecvent al bazei de date
- Utilizați PostgreSQL acceptat pentru implementarea de producție prevăzută
Documentație oficială: configurarea cheii de criptare n8n
Oferă webhook-urilor adresa lor publică
Un reverse proxy precum Caddy poate termina HTTPS în timp ce n8n ascultă intern. Documentația actuală folosește N8N_WEBHOOK_URL pentru originea webhook externă și înlocuiește numele mai vechi WEBHOOK_URL din versiunea 2.35.0. Setați numărul de salturi de proxy de încredere la calea reală; un singur proxy folosește N8N_PROXY_HOPS=1. Păstrați gazda, protocolul și informațiile clientului transmise. Testați un webhook din afara serverului și verificați URL sa de producție.
- Setați în mod deliberat fusul orar al fluxului de lucru
- Curățați istoricul de execuție care conține intrări sensibile
- Folosește lucrători de coadă și Redis doar cu controalele de acces privat necesare
# Example: one HTTPS reverse proxy
N8N_WEBHOOK_URL=https://automations.example.com/
N8N_PROXY_HOPS=1Documentație oficială: n8n în spatele unui proxy invers
Definiți volumul de lucru și integrările permise
Enumerați declanșatoarele, conturile externe, volumul de execuție așteptat și cheltuiala maximă sau efectul secundar pe care îl poate crea fiecare flux de lucru. Verificați licența n8n pentru utilizarea reală, mai ales dacă o oferiți ca serviciu altora. Un mic flux de lucru programat și un procesator public de webhook au nevoi diferite de resurse. Începeți cu o versiune acceptată, stare persistentă privată, un nume TLS și o bază de date adecvată implementării; evitați expunerea porturilor bazei de date cu editorul.
- Folosiți credențiale restricționate separate pentru fiecare integrare.
- Setați fusul orar dorit al fluxului de lucru și retenția istoricului de execuție.
- Menține fluxurile de lucru exportate lipsite de secrete reale încorporate.
Documentație oficială: n8n Deployment Docker
Setează originea publică a webhook-ului pentru versiunea instalată
Un reverse proxy precum Caddy ajunge la n8n intern, în timp ce serviciile externe apelează originea sa de webhook HTTPS. Folosiți variabila URL de webhook documentată pentru versiunea instalată; documentația actuală o numește N8N_WEBHOOK_URL, în timp ce versiunile mai vechi foloseau WEBHOOK_URL. Setați numărul real de salturi de proxy în loc să aveți încredere în antete transmise arbitrar. Păstrați politica de acces la editor separată de autentificarea webhook și verificați că apelul invers de producție nu conține o gazdă sau un port intern.
# Example values for a supported current release, behind one proxy:
N8N_WEBHOOK_URL=https://automations.example.com/
N8N_PROXY_HOPS=1Documentație oficială: n8n setări de reverse-proxy pentru webhook
Testați un flux de lucru inofensiv înainte de a acorda acces de scriere
Începe cu o cerere doar în citire sau cu o înregistrare de test de unică folosință. Testează webhook-ul de producție din afara VPS, respingerea autentificării și o reîncercare deliberată. O cerere repetată nu trebuie să creeze accidental o a doua acțiune cu consecințe. Verifică jurnalele de execuție pentru date de intrare scurse, apoi aplică o politică de retenție. Dacă un webhook funcționează doar în modul de test al editorului, verifică dacă fluxul de lucru este publicat/activ și dacă rutele de producție și de test ajung la procesul corect.
- Folosește o acreditare de integrare de unică folosință pentru a testa o restaurare.
- Păstrați o copie criptată independentă a N8N_ENCRYPTION_KEY sau a stării cheii generate.
- Nu trimiteți parole de exemplu sau tokenuri API în rezultatele de depanare păstrate.
Documentație oficială: cheie de criptare de n8n
Scalați numai după ce observați blocajul de execuție
Modul coadă adaugă Redis, lucrători și o bază de date partajată; procesul principal primește declanșatoare în timp ce lucrătorii efectuează execuții. Fiecare lucrător trebuie să folosească aceeași cheie de criptare a acreditărilor. Urmați cerințele actuale de stocare a datelor binare înainte de a muta un flux de lucru cu fișiere în modul coadă. Limitați concurența și bugetele upstream API și monitorizați vechimea cozii și eșecurile. Faceți copii de siguranță ale bazei de date, stării și cheii împreună; repornirea unui container nu este un plan de recuperare pentru acreditările salvate ilizibile.
Documentație oficială: modul coadă n8n · Setări de curățare a execuțiilor