n8n 3.0 beta a fost publicat pe 27 octombrie 2026, iar versiunea stabilă e anunțată pentru începutul lunii decembrie 2026. Lansarea nu aduce funcții noi, ci curăță moșteniri vechi, închide endpoint-uri riscante și mută self-hosting pe Docker. Toate schimbările sunt de tip breaking, fără rollback la 2.x.

Ce s-a schimbat efectiv față de 2.0

Compania a confirmat că 3.0 se concentrează pe fundație, nu pe feature-uri. De la 2.0, lansat în decembrie 2025, echipa a livrat peste 45 de versiuni, aproximativ una pe săptămână, iar funcțiile noi au mers în paralel. Asta explică de ce major version nu aduce nimic vizibil în interfață. Aduce în schimb modificări care pot rupe workflow-uri.

Concret, în 3.0 beta:

Este genul de release care arată bine în changelog și prost în producție, dacă îl tratezi ca pe un update obișnuit. Breaking changes înseamnă că workflow-urile care rulează azi pot să nu mai ruleze mâine.

De ce contează pentru echipele care automatizează marketing

Un workflow n8n în marketing nu e un hobby. E pipeline-ul care duce lead-uri din formular în CRM, care trimite evenimente către platformele de ads, care generează rapoarte de performanță și care alimentează dashboard-uri. Când o astfel de piesă se rupe, nu se rupe doar automatizarea, se rupe lanțul de măsurare.

Trei schimbări merită atenție mărită pentru echipele de marketing:

Timeout-ul de 1 minut la Code node. Dacă folosești noduri Code pentru procesări mai lungi, de exemplu transformarea unui export mare de clienți sau deduplicare pe volume mari, acele noduri vor eșua după 60 de secunde. Soluția e configurarea explicită a timeout-ului sau mutarea logicii grele în altă parte. Nu e o limită inventată, e o limită declarată care trebuie gestionată înainte de upgrade.

Binary data fără memorie. Workflow-urile care manipulează fișiere, imagini de produs, PDF-uri de facturi sau exporturi CSV depindeau de modul in-memory pe care 3.0 îl scoate. Migrarea la filesystem sau S3 e obligatorie, iar cine rulează pe un VPS mic simte imediat diferența la config.

Nodurile legacy dispărute. Cine a construit automatizări pe Function, Item Lists sau Cron în urmă cu doi sau trei ani are de migrat. Majoritatea au echivalent direct: Function devine Code, Item Lists se împarte în Split Out, Aggregate, Sort, Limit, Remove Duplicates sau Summarize. O parte migrează automat, restul cere muncă manuală.

Și aici apare detaliul care contează cel mai mult operațional: nu există rollback. Trecerea la 3.x e într-un singur sens. Dacă upgrade-ul strică ceva în producție, singura cale înapoi e restaurarea unui backup complet. Nu e un detaliu tehnic minor, e o decizie de management al riscului.

Migration Report: singurul lucru care trebuie citit înainte

Materialul sursei spune clar: dacă citești un singur lucru din anunț, citește partea despre Migration Report. Instanțele pe versiunea 2.39 sau mai nouă au raportul la Settings > Migration Report.

Ce face raportul, conform anunțului:

Recomandarea oficială de upgrade e simplă și o susțin: actualizează la ultima versiune 2.x, deschide raportul, rezolvă sau marchează fiecare problemă semnalată, fă un backup complet, testează pe o instanță de staging, abia apoi treci pe producție.

Aici e nuanța pe care o adaug din experiența de operare, nu din anunț: un raport de migrare nu dovedește că totul e în regulă, dovedește doar că nu au fost găsite problemele pe care le caută raportul. Un workflow care arată curat în raport poate să aibă dependențe externe, credențiale care expiră sau logică de business care nu e vizibilă pentru un scanner automat. Verificarea completă înseamnă și o rulare reală pe staging, cu date reale, nu doar bifarea raportului.

Ce înseamnă pentru tine, ca antreprenor sau marketer în România

Să luăm un scenariu concret, fără să pretind că e un caz real din portofoliu.

Ai un magazin online și ai construit în n8n un flux care ia comenzile din Shopify, le trimite în CRM, generează un raport zilnic în Google Sheets și trimite un mesaj în Slack când apar comenzi peste un prag. Ai și două workflow-uri mai vechi, făcute acum doi ani, care folosesc Function și Cron.

Pe 3.0 beta, acel flux de comenzi are șanse mari să treacă fără modificări mari, dar workflow-urile vechi nu. Cron și Function dispar. Dacă nu ai deschis Migration Report, vei afla de problemă în momentul în care fluxul nu mai rulează și raportul zilnic nu mai ajunge.

Trei lucruri concrete de făcut înainte de decembrie 2026:

  1. Actualizezi la ultima versiune 2.x. Raportul cel mai nou e acolo, iar versiunea 2.x primește în continuare suport 12 luni după lansarea stable.
  2. Deschizi Migration Report și triajezi. Nu fiecare avertisment e o urgență. Workflow-urile pe care nu le-ai rulat de luni de zile pot fi marcate "won't fix" și lăsate în pace.
  3. Separi testul de producție. Fără rollback, staging-ul nu e opțional. Un backup complet înainte de upgrade e obligatoriu, iar restaurarea de backup trebuie testată, nu presupusă.

Pentru cine rulează self-hosted pe VPS, mai apare o problemă practică: Docker devine singura cale. Dacă ai instalat n8n cu npm sau npx, va trebui să treci pe container. Anunțul menționează un script de setup într-o singură linie care reproduce viteza lui npx, dar nu promite că migrarea e trivială. Cine are configurații custom, volume montate sau dependențe de sistem trebuie să planifice asta separat.

Un detaliu care merită subliniat pentru echipele care lucrează cu AI: nodul OpenAI legacy dispare, iar modurile vechi de AI Agent sunt scoase. Cine avea automatizări AI construite pe versiunile vechi trebuie să le reconstruiască pe nodurile actuale. Nu e o schimbare cosmetică, e o migrare de logică. Merită comparat cu ce se întâmplă în restul ecosistemului AI, unde infrastructura se schimbă la fel de repede, așa cum arată și discuția despre GLM-5.3 pe Workers AI și scurgerea KV cache. Lecția e aceeași: actualizezi infrastructura cu ochii pe ce se rupe, nu doar pe ce se adaugă.

Pe partea de securitate, schimbările sunt binevenite. Credentialele Slack care cer signing secret înseamnă că nimeni nu mai poate trimite cereri false care să pară de la Slack. Lista SSRF mai mare înseamnă mai puține endpoint-uri interne expuse accidental. Pachetele community neverificate oprite implicit înseamnă mai puțină suprafață de atac din supply chain. Pentru o echipă de marketing care rulează automatizări cu acces la CRM și la platforme de ads, aceste schimbări contează mai mult decât orice feature nou. Dacă vrei context despre cât de real e riscul în stack-ul de marketing, avem o analiză pe breach-ul ENGIE și ce înveți despre securitatea martech.

Limite și ce nu știm încă

Anunțul e clar pe câteva puncte, dar lasă și goluri pe care nu le umplu cu presupuneri:

Un ultim punct de verificare: un raport de migrare curat nu înseamnă că workflow-urile tale sunt sigure. Înseamnă doar că nu au fost găsite problemele pe care raportul le caută. Verificarea serioasă înseamnă rulare pe staging, cu date reale, cu credențiale reale și cu un backup testat. Când probele sunt insuficiente, recomandarea e verificare, nu presupunere.

FAQ

Pot face rollback de la 3.x la 2.x? Nu. Anunțul spune explicit că trecerea la 3.x e într-un singur sens. Singura cale înapoi e restaurarea unui backup complet, făcut înainte de upgrade.

Trebuie să fac upgrade acum, în beta? Nu obligatoriu. Beta e pentru testare timpurie. Pentru producție, recomandarea e să actualizezi la ultima 2.x, să deschizi Migration Report, să rezolvi problemele semnalate și să testezi pe staging înainte de stabilul din decembrie 2026.

Ce se întâmplă dacă sunt încă pe 1.x? Nu există upgrade direct la 3.x. Treci mai întâi pe 2.x, apoi pe 3.x. Suportul pentru 1.x se termină pe 31 decembrie 2026.

AI-ul ajută, dar decizia rămâne umană

n8n 3.0 e un release care cere planificare, nu entuziasm. Un asistent AI poate să citească lista de breaking changes, să grupeze workflow-urile afectate, să pregătească un plan de migrare și să scrie primele drafturi de documentație internă. Poate chiar să sugereze ce noduri înlocuiesc cele vechi. Ce nu poate face e să decidă ce workflow-uri sunt critice pentru business, ce ordine de migrare minimizează riscul și cine răspunde de fiecare bucată din pipeline.

Aici intervine operatorul. Media buyer-ul știe ce automatizări duc bani și care sunt accesorii. Omul care administrează infrastructura știe ce se rupe primul. Decizia de a amâna upgrade-ul, de a-l face pe bucăți sau de a muta totul pe staging se ia cu date, nu cu speranțe. Iar execuția, de la backup la testare până la verificarea în producție, rămâne muncă umană, cu responsabilitate clară.

Dacă vrei să treci prin tranziția asta fără să pierzi pipeline-ul de marketing pe drum, pasul concret e să vorbești cu echipa ALLSoft Agency. Punem pe masă ce trebuie verificat înainte de decembrie 2026 și ce rămâne de făcut după.