n8n: ce este, cum o folosești pentru automatizări, cloud vs self-hosted

n8n este o platformă open-source pentru automatizări vizuale, în care lipești noduri (triggeri, integrări, transformări) ca să construiești workflows fără să scrii cod sau scriind cod custom unde e nevoie. Pentru cele mai multe agenții de software, n8n a înlocuit Zapier și Make.com (sau Microsoft Power Automate) prin combinația de cost zero, control complet, și posibilitatea de a executa cod custom. Pentru proiecte mici-medii, este uneltea de bază pentru lipit servicii.

Proiectul a apărut în 2019, scris în TypeScript, oferit cu o licență fair-code (open-source cu restricții comerciale specifice). Comunitatea contribuie cu peste 600 de integrări gata făcute; restul le scrii tu, fie ca node-uri custom, fie ca apeluri HTTP generice.

Ce este n8n mai exact?

Un proces Node.js care expune o interfață web pentru construirea de workflows vizuale. Fiecare workflow este o secvență de noduri conectate, unde un nod primește date de la nodurile anterioare, le procesează, și le pasează către cele următoare.

Patru tipuri principale de noduri:

• Triggers: punctul de start al workflow-ului. Cron (la interval), webhook (la cerere HTTP), manual (la click), polling (verifică periodic un endpoint).
• Action nodes: integrări cu servicii externe (Slack, Google Sheets, Notion, Stripe, baze de date) sau cu API-uri generice (HTTP Request).
• Logic nodes: control de flux. If (ramificare), Switch (multi-ramificare), Loop, Merge.
• Custom code: JavaScript sau Python evaluat în sandbox. Acolo unde integrările gata făcute nu sunt suficiente.

Datele circulă între noduri ca array-uri de obiecte JSON. Fiecare nod transformă input-ul și produce output, vizibil în UI după execuție. Dezvoltarea iterativă este vizuală: rulezi un nod, vezi rezultatul, ajustezi, rulezi din nou.

Cum funcționează un workflow?

Un workflow tipic are trei părți: declanșatorul (cum începe), procesarea (ce face), și livrarea (unde livrează rezultatul).

Exemplu concret, contact form-ul crawlerra.com:

• Browserul postează datele pe un webhook n8n pe care îl ținem self-hosted.
• Nodul Webhook primește payload-ul, îl trece mai departe.
• Nodul Function validează câmpurile (email valid, nume non-gol, lungime body).
• Nodul Set adaugă timestamp și ID unic.
• Nodul HTTP Request trimite email prin Resend către contact@crawlerra.com.
• Nodul Respond to Webhook răspunde browserului cu 204 (succes).

Totul vizual, fără cod scris pentru integrarea Resend (deși ai putea adăuga cod custom pentru reguli specifice). Pentru workflows cu execuție lungă, n8n suportă queue mode: trigger-ul scrie în Redis, worker-i separați execută în paralel. Asta scalează orizontal, dar adaugă complexitate operațională.

Care sunt capcanele frecvente?

• Workflows fără idempotență. Webhook-ul tău primește același payload de două ori (din Stripe sau dintr-un retry de la nginx). Workflow-ul creează două facturi, două emailuri, două dezastre. Adaugă verificare de duplicat (event_id, hash al payload-ului) la fiecare workflow cu efecte secundare.
• Memory leaks la executions mari. Pentru loop-uri peste sute de obiecte sau payload-uri mari, n8n în modul main ține totul în memorie. La 20.000 de elemente, procesul ajunge la 2 GB RSS. Folosește queue mode sau procesează în batch-uri de 100.
• Credențiale în clear text. n8n criptează credențialele cu o cheie (N8N_ENCRYPTION_KEY) pe care o setezi prin variabilă de mediu. Dacă o pierzi, toate credențialele devin inutilizabile. Backupul cheii alături de backupul bazei e obligatoriu.
• Webhook URLs publicate fără autentificare. Endpoint-ul webhook este public; oricine cu URL-ul poate trimite payload. Pentru workflows cu efecte secundare critice, verifică un secret partajat în payload sau pune nginx în față cu auth_basic.
• Lipsă de monitoring pentru workflows critice. Workflow-ul de billing tăcut nu execută două zile pentru că nodul HTTP Request a primit o eroare 503 și a fost marcat ca failed. Conectează rezultatele execuțiilor la stack-ul de observabilitate și alertează pe execuții eșuate.

Cum folosim n8n la crawlerra?

Rulăm n8n self-hosted, în Docker Compose, cu Postgres dedicat pentru persistența workflow-urilor și a execuțiilor. Pentru proiecte cu cerințe de izolare distincte (de exemplu, datele clienților din verticala medicală) folosim instanțe separate, ca să respectăm strict GDPR-ul fiecărui proiect.

Cazuri concrete de utilizare:

• Contact form crawlerra.com. Webhook primește submit-ul, validează, trimite email. Folosit live, ~5 submit-uri pe săptămână.
• Routarea alertelor de operațiuni. Alertmanager trimite la n8n, care decide canalul (Slack pentru critic, SMS pentru noaptea, email pentru info). Logica de decizie e mai simplă într-un workflow vizual decât în config Prometheus.
• Sincronizări periodice. Trigger cron care extrage date dintr-un API, le transformă, le pune în Postgres-ul nostru sau în Google Sheets pentru un client.
• Notificări de publicare. La fiecare articol publicat din CMS, un webhook spre n8n care postează pe LinkedIn și trimite newsletter via Resend (planificat pentru Phase 8 a noastră).

Detalii complete de setup, secrets management, backup, monitorizare sunt în ghidul nostru despre n8n self-hosted în producție; pentru workflows care fac scraping de date publice, vezi entry-ul dedicat. Persistența workflow-urilor folosește Postgres bind-uit pe 127.0.0.1, exact ca restul backendurilor noastre.

Cum verifici că un workflow rulează corect?

După publicarea unui workflow nou, fă trei verificări înainte să-l declari „done". Trigger manual cu payload de test: în UI-ul n8n, rulează workflow-ul cu input artificial similar cu cel de producție. Verifică output-urile fiecărui nod; dacă unul produce null sau o eroare tăcută, ai un bug ascuns.

Test cu eroare provocată: trimite intenționat un payload invalid sau credențiale greșite. Workflow-ul trebuie să eșueze grațios (eroare logged, alertă trimisă) sau să continue cu fallback. Dacă eșuează tăcut, ai o capcană de producție.

Monitorizare după go-live: în interfața de execuții, filtrează pe failed; alertează pe orice eșec consecutiv (3+ în 10 minute). Pentru workflows critice (billing, comunicare cu clienții), alertează la primul eșec. Pe crawlerra folosim direct stack-ul de observabilitate care primește metrici prin endpoint-ul Prometheus al n8n; orice creștere bruscă în rata de execuții eșuate produce alertă imediat¹. Asta e parte din principiul „răspundem propriilor noastre alerte" descris în articolul nostru editorial.

1. Endpoint-ul Prometheus al n8n e activat prin N8N_METRICS=true și este scraped de Prometheus odată la 30 de secunde. [crawlerra.n8n_metrics]