n8n frissítés 2.37-től 2.40-ig: admin által kezelt hitelesítő adatok, MCP-javítások és Claude Sonnet 5 alapértelmezetten

Az n8n három kiadása, a 2026. augusztus 25-i 2.37.0, a szeptember 8-i 2.39.0 és a szeptember 15-i 2.40.0 együtt több száz változtatást hozott, így ez az idei ősz egyik legtartalmasabb n8n frissítése. A hírekbe leginkább az került be, hogy az Anthropic Chat Model node alapértelmezett modellje a Claude Sonnet 5 lett, a saját szerveren futó példányok gazdáinak viszont a csendesebb tételek fontosabbak: a hitelesítő adatok (credentialök) kezelése, a titkosítási kulcsok betöltése, az MCP-integráció hibajavításai és az, hogy queue módban végre érvényesül az időkorlát a beragadt feladatokra.

Ha a céged automatizálásai egy saját üzemeltetésű n8n-en futnak, akkor ezek a kiadások nem opcionális csinosítások. Ugyanakkor vakon sem érdemes rájuk frissíteni, mert a 2.40 a GitHubon kiadáskor még előzetes (pre-release) jelölést kapott, az n8n dokumentációja pedig 2026. szeptember 22-i állapot szerint a 2.39-es ágat tartja stabilnak. Az alábbiakban végigvesszük, mi változott, mit jelent ez egy 5 és 50 fő közötti cég automatizálásaira, végül lépésről lépésre azt is, hogyan frissíts úgy, hogy hétfő reggel ne a hibás futások listájával kezdődjön a nap.

Röviden

• Az n8n 2.37.0 (augusztus 25.), 2.39.0 (szeptember 8.) és 2.40.0 (szeptember 15.) kiadásai a hitelesítő adatok kezelését, a titkok kitakarását, az OAuth-folyamatokat, az MCP-integrációt és a queue mode megbízhatóságát javították. A releasebot összesítése szerint a 2.37 hozta be az admin által kezelt credentialök keretrendszerét.
• A 2.37.0 óta az Anthropic Chat Model node alapértelmezett modellje a Claude Sonnet 5, amelynek API-ára az Anthropic szerint 2 dollár millió bemeneti és 10 dollár millió kimeneti tokenenként, kerekített 320 Ft-os dollárárfolyammal 640 Ft és 3 200 Ft.
• A 2.40.0 queue módban kikényszeríti a végrehajtási időkorlátot a beragadt feladatokra, megőrzi az Anthropic gondolkodási blokkjait az eszközhívások között, valamint több credential-formátumra kiterjeszti a titkok kitakarását.
• 2026. szeptember 22-i állapot szerint az n8n dokumentációja a 2.39.10-et jelöli stabil, a 2.40.5-öt béta verziónak, ezért éles rendszeren a 2.39-es ág legfrissebb javítókiadása az ésszerű cél, míg a 2.40-et előbb tesztpéldányon próbáld ki.
• Frissítés előtt mindenképp ments adatbázist és titkosítási kulcsot (N8N_ENCRYPTION_KEY), queue módban pedig a fő példány, a workerek és a webhook-feldolgozók mindig ugyanazon a verzión fussanak.

Mi újult meg az n8n-ben augusztus 25. és szeptember 15. között?

A három vizsgált minor kiadás közül a 2.37.0 az AI-ügynököket, a Claude Sonnet 5 alapértelmezést és a credential-kezelést hozta, a 2.39.0 a titkosítási modult, a chatfelületek hitelesítését és a webhookokat javította, a 2.40.0 pedig a queue mode időkorlátját, a titokkitakarást és az MCP-eszközfelfedezést csiszolta.

Az n8n dokumentációja szerint a cég szinte minden héten kiad egy új minor verziót. A stable jelölésű verzió az éles, produktív használatra való, a beta pedig mindig a legfrissebb kiadás. Ez a ritmus azt jelenti, hogy aki három-négy hétig nem nyúl a példányához, az már több kiadásnyi lemaradásban van. A kiadási jegyzetek hossza miatt ráadásul könnyű elsiklani a számára fontos tételek fölött. A 2.37.0 és a 2.40.0 GitHub-oldalán például külön-külön is több tucat új funkció és ennél is hosszabb hibajavítási lista szerepel, amelyek nagy része a szerkesztőfelületet vagy az AI Assistant belső működését érinti, egy futó automatizálást viszont nem.

Az alábbi táblázat a GitHub kiadási jegyzetei és a releasebot összesítése alapján azt foglalja össze, ami egy KKV saját üzemeltetésű példányánál számít.

A táblázat persze csak a legfontosabb tételeket emeli ki. A három kiadásban visszatérő motívum, hogy az n8n egyre komolyabban veszi a többfelhasználós, vállalati működést: projektekhez kötött ügynök-munkamenetek, jóváhagyási folyamat a munkafolyamat-verziókhoz (review inbox), szerepkör-leképezési API-végpontok, valamint olyan figyelmeztetés, amely jelzi, ha valaki a projekt-szerepkörök kezelésén keresztül saját magának adna több jogot. Ezek egy háromfős csapatnál még kényelmi funkciónak tűnnek, egy húszfős cégnél viszont már azon múlik, ki férhet hozzá a könyvelés vagy a HR munkafolyamataihoz.

A másik nagy téma az AI: a 2.40.0-ban az AI Assistant új nevet kapott (n8n Assistant), az Agent Builder és az ügynökök munkamenetei mindhárom kiadásban tucatnyi javítást kaptak. Ezekből csak azokat emeljük ki, amelyek egy működő, éles automatizálásnál is érezhetők, a többit a kiadási jegyzetek részletesen tartalmazzák.

Mit jelentenek az admin által kezelt, példányszintű hitelesítő adatok?

Az admin által kezelt, példányszintű hitelesítő adat olyan credential, amelyet nem egy-egy munkatárs hoz létre a saját fiókja alá, hanem a példány adminisztrátora állít be és tart karban központilag. A releasebot összesítése szerint ennek keretrendszere a 2.37-tel érkezett, a 2.39 és a 2.40 pedig a láthatóságát és a kiválasztását finomította.

Kezdjük az alapfogalommal. A hitelesítő adat (credential) az n8n-ben az a mentett belépési információ, amellyel egy node hozzáfér egy külső szolgáltatáshoz: egy API-kulcs, egy OAuth-token, egy adatbázis-jelszó vagy egy SMTP-fiók. A munkafolyamat csak hivatkozik rá, maga a titok titkosítva az n8n adatbázisában ül. A gyakorlatban ez a pont szokott elcsúszni, amikor egy cég az első két-három automatizálás után belejön: mindenki létrehozza a saját Gmail-, OpenAI- vagy Számlázz.hu-hozzáférését, fél év múlva pedig senki nem tudja, melyik munkafolyamat kinek a kulcsával fut és mi történik, ha az illető kilép.

Vegyünk egy képzeletbeli, 18 fős győri gépészeti céget, ahol hárman építenek munkafolyamatokat. Az árajánlatkérések feldolgozása az értékesítési vezető saját Anthropic-kulcsával fut, a szállítói számlák beolvasása a pénzügyes kolléga Google-fiókján keresztül, a CRM-szinkron egy volt gyakornok CRM-fiókjához kötött API-kulccsal. Amikor a gyakornok CRM-fiókját a kilépésekor megszüntetik, a hozzá tartozó kulcs is érvénytelenné válik, a szinkron pedig csendben leáll. A központilag kezelt credential pont ezt a helyzetet előzi meg: a kulcs gazdája a cég (az adminisztrátor), a munkafolyamatot építő kolléga használhatja, de a titok nincs nála.

Mi változott konkrétan a három kiadásban?

A GitHub kiadási jegyzeteiben a téma nem egyetlen látványos funkcióként, hanem több kisebb tételként jelenik meg. A 2.37.0-ban a munkafolyamat-kódgenerálás már kezeli a menedzselt credentialöket, bekerült egy új jogosultsági kör (project:manageUsers), amely a projekttagság módosítását szabályozza, a szerkesztő pedig figyelmeztet, ha valaki a projekt-szerepkörök kezelésén keresztül saját jogosultságát emelné. Javították azt a hibát is, amely miatt néha projekten kívüli credentialök jelentek meg a választható lehetőségek között. A 2.40.0-ban a felület már megmutatja a minden felhasználóval és projekttel megosztott credentialöket. Az AI Builder ügynökkártyája az újrahasznosítható hitelesítő adatokat is jelzi.

Párhuzamosan halad egy másik szál is, a végfelhasználói credentialöké (end-user credentials). Itt az a cél, hogy egy chatfelületen vagy MCP-kapcsolaton érkező felhasználó a saját fiókjával azonosítsa magát, így az ügynök az ő jogosultságaival dolgozzon, ne egy közös szolgáltatásfiókkal. A 2.37.0 ehhez funkciókapcsolót (feature flag) és hitelesítésimód-ellenőrzést vezetett be a chat és az MCP triggereknél, a 2.39.0-ban a chat trigger OAuth2 identitáskezelése feltétel nélkülivé vált, a 2.40.0 pedig csak az elérhető node-okra szűkítette a végfelhasználói credential-ellenőrzést.

Mit kezdj ezzel egy KKV-nál?

Tapasztalatunk szerint a legtöbb 5 és 50 fő közötti cégnél nincs szükség bonyolult jogosultsági mátrixra, egy egyszerű rend viszont sok kellemetlenségtől megóv. A javasolt gyakorlat a következő:

• A közös, céges szolgáltatások (AI-szolgáltatók API-kulcsai, számlázó, CRM, céges postafiók) credentialjét az adminisztrátor hozza létre és ossza meg, lehetőleg egy erre a célra létrehozott technikai fiókkal, nem valakinek a személyes belépésével.
• A személyes jellegű hozzáféréseket (saját naptár, saját postafiók) hagyd a munkatársaknál. Ahol lehet, használj projektet, hogy a pénzügyi munkafolyamatokat ne lássa mindenki.
• Negyedévente nézd át a credentialök listáját, töröld a gazdátlanokat és rögzítsd egy egyszerű táblázatban, melyik kulcs melyik munkafolyamatot hajtja.
• Kilépéskor a fiók törlése előtt nézd meg, milyen credentialök és munkafolyamatok tartoznak a távozó kollégához, mert a gazdátlanná váló hozzáférés tipikus oka a csendben leálló automatizálásnak.

Hogy a menedzselt credentialök pontosan milyen formában érhetők el nálad, az a licenctől és a verziótól is függ, ezért a frissítés után a saját felületeden nézd meg a credentialök megosztási beállításait, mielőtt a teljes állományt átszervezed.

Biztonság: titkok kitakarása, credential-titkosítás, OAuth-folyamatok

A három kiadás biztonsági tételei három csoportba rendeződnek. Az első a titkok kitakarása (redaction), vagyis az, hogy jelszó, token vagy API-kulcs ne jelenjen meg olvasható formában a futási adatokban, a naplókban és a beállítási válaszokban. A második a credentialöket védő titkosítási kulcsok kezelése, a harmadik pedig az OAuth-alapú bejelentkezési folyamatok szigorítása.

Titkok kitakarása: kevesebb jelszó a futási naplóban

Minden n8n-futás elmenti a node-ok bemenetét és kimenetét, ami hibakeresésnél áldás, biztonsági szempontból viszont kockázat. Ha valaki a Bearer tokent credential helyett közvetlenül a HTTP-kérés fejlécébe írta, vagy egy hibaüzenet visszaírja a kapcsolódási karakterláncot a jelszóval együtt, akkor a titok bárki számára látható, aki a futási előzményekhez hozzáfér. A 2.37.0 a böngészőautomatizálás pillanatképeiben takarja ki a címkéjük mellett megjelenő titkokat, a 2.39.0 az OpenTelemetry-fejlécek értékét minden beállítási válaszban kitakarja, a 2.40.0 pedig egy közös csomagba (@n8n/utils) vonta össze a kitakarási logikát. A GitHub-jegyzet szerint a 2.40.0 további credential-formátumokat ismer fel, kitakarja a megerősített titoktárolók átlátszatlan mezőértékeit, sőt a futási adatokat is, amikor egy futás csak részben használt privát credentialt.

Ez akkor számít igazán, ha a futási előzményeket többen látják, mint ahányan a credentialöket kezelik. Egy képzeletbeli 10 fős budapesti könyvelőirodában a gyakornok nyugodtan ránézhet, miért akadt el a NAV Online Számla lekérdezése, a technikai felhasználó jelszavát viszont nem kell látnia.

Credential-titkosítás: a kulcs, amelyet senki nem akar elveszíteni

Az n8n a credentialöket titkosítva tárolja az adatbázisban. A titkosítás kulcsát az N8N_ENCRYPTION_KEY környezeti változó vagy az n8n adatkönyvtárában tárolt beállítás adja. Ha ez a kulcs elvész, az adatbázis-mentés gyakorlatilag használhatatlan, mert a benne lévő hitelesítő adatok nem fejthetők vissza, így minden credentialt újra létre kell hozni.

A 2.39.0 ezen a területen a motorháztető alatt dolgozott: a titkosítási modul mostantól mindig betöltődik és indításkor biztonságosan inicializálja a kulcsokat, a kulcsokat memóriában gyorsítótárazza, a titkosítás írási útvonala cserélhetővé vált, a kulcsrotáció döntése pedig a modulba került. A telepítések aláírókulcsait ugyanabban a becsomagolt formában tárolja, mint az adattitkosító kulcsokat. A 2.40.0 ehhez indításkori javítást tett hozzá a régi formátumú adattitkosító kulcsokra, valamint megfigyelhetőséget a visszafejtési útvonalon.

Egy KKV-tulajdonos számára ebből egyetlen gyakorlati tanulság következik, de az nagyon: mivel a frissítések a kulcskezelést érintik, frissítés előtt a titkosítási kulcsot is mentsd el biztos helyre, ne csak az adatbázist. Queue módban az n8n dokumentációja szerint a fő példány titkosítási kulcsát minden workernek és webhook-feldolgozónak meg kell kapnia, ellenkező esetben a workerek nem tudják visszafejteni a credentialöket.

OAuth-folyamatok: szigorúbb tokenellenőrzés, kevesebb kézi újracsatlakozás

Az OAuth az a szabványos bejelentkezési folyamat, amelyben a „Bejelentkezés Google-fiókkal” jellegű jóváhagyás után az n8n hozzáférési tokent kap, majd ennek birtokában dolgozik a te nevedben a külső szolgáltatásban. A három kiadásban több ilyen folyamat is változott:

• A 2.37.0 az OAuth2 credential-feloldóban ellenőrzi a hozzáférési token címzettjét (audience), vagyis azt, hogy a token valóban az adott szolgáltatásnak szól-e. A Typeform node egyedi OAuth2-jogosultsági köröket kapott.
• A 2.39.0-ban a hosztolt chat munkamenetváltáskor újrahitelesít, a sikertelen OIDC-bejelentkezés a bejelentkezési oldalra irányít vissza, a WordPress node az OAuth2 kliensadatokat a kérés törzsében küldi, a Confluence és a Jira pedig Atlassian szolgáltatásfiókos (2LO) hitelesítést is támogat.
• A 2.40.0-ban a Confluence és a Jira OAuth2-tokenje lejáratkor automatikusan frissül, a Grist node OAuth2-t kapott, valamint a Microsoft Entra credential tesztje már nem követeli meg az Organization.Read.All jogosultságot.

Egy apró, de beszédes részlet: a 2.37.0 általánosan elérhetővé tette a Form Trigger OAuth2-hitelesítését, majd ugyanebben a kiadásban vissza is vonta ezt a lépést. Ez nem hiba a jegyzetben, hanem jól mutatja, milyen tempóban dolgozik a fejlesztőcsapat, egyben azt is, miért nem jó ötlet egy vadonatúj funkcióra azonnal éles folyamatot építeni.

Frissítés után mindig futtass le egy tesztet minden OAuth-os credentiallel (Google, Microsoft, Atlassian, Slack), mert egy megváltozott ellenőrzés miatt előfordulhat, hogy egy régi token újra jóváhagyást kér.

Miért lett a Claude Sonnet 5 az alapértelmezett Anthropic-modell és mennyibe kerül?

Az n8n 2.37.0 kiadási jegyzete szerint az Anthropic Chat Model node alapértelmezett modellje a Claude Sonnet 5 lett, ráadásul a node pontosabb útmutatást ad a modellválasztáshoz. A döntés logikus, hiszen az Anthropic 2026. június 30-án kiadott középkategóriás modellje ügynöki munkára készült, az ára pedig 2 dollár millió bemeneti és 10 dollár millió kimeneti tokenenként.

Az Anthropic bejelentése szerint a Claude Sonnet 5 saját fordításunkban „képes tervet készíteni, böngészőt és terminált használni, továbbá olyan szinten önállóan dolgozni, amelyhez néhány hónapja még nagyobb és drágább modellek kellettek”. A cég azt is közölte, hogy a Sonnet 4.6-nál összességében ritkábban mutat nemkívánatos viselkedést, ügynöki környezetben pedig általában biztonságosabb. Az Anthropic az árat eredetileg bevezető árként hirdette, a bejelentés augusztus 10-i kiegészítése szerint azonban ez az ár véglegessé vált. Az n8n AI Agent node-ja pontosan ilyen feladatokra épül: a modell eldönti, melyik eszközt hívja, az n8n végrehajtja, az eredményt pedig visszaadja a modellnek. Ez a kör addig ismétlődik, amíg el nem készül a válasz.

A 2.37.0-ban az Anthropic Chat Model node prompt caching (prompt-gyorsítótárazás) támogatást is kapott. Ennek lényege, hogy a minden hívásnál ismétlődő, változatlan rész, például a hosszú rendszerprompt és az eszközök leírása, gyorsítótárba kerülhet, így a szolgáltató az ismételt beolvasását a normál bemeneti árnál kedvezőbben számlázza. A pontos díjat mindig az Anthropic aktuális árlistáján nézd meg. Ügynököknél ez különösen sokat számít, mert egy több eszközhívásos feladatban a bemeneti tokenek száma körről körre nő.

Mennyibe kerül egy ügynöki feladat forintban?

Vegyünk egy képzeletbeli szegedi webshopot, ahol egy n8n-ügynök a beérkező vevői leveleket olvassa, megkeresi a rendelést a webshop adatbázisában, ellenőrzi a szállítási státuszt, végül választervezetet ír. Saját becslésünk szerint egy ilyen feladat négy modellhívásból áll, összesen nagyjából 12 000 bemeneti tokennel (a rendszerprompt, az eszközleírások és az egyre hosszabb beszélgetés együtt) és 1 600 kimeneti tokennel. Kerekített, 320 Ft-os dollárárfolyammal számolunk, az Astra és a Muse Spark 1.3 árát az OpenAI, illetve a Meta szeptember eleji bejelentése alapján vettük.

A számítás jól mutatja, miért ésszerű alapértelmezés egy középkategóriás modell. Az OpenAI GPT-6 Astra modellje ugyanerre a feladatra ötször annyiba kerülne, egy egyszerű levélkategorizáláshoz pedig ritkán van szükség a képességeire. A Meta Muse Spark 1.3 olcsóbb, de elsősorban ügynöki kódolásra készült, ezért a saját folyamataidon kell kipróbálni, hogy ügyfélszolgálati feladatban is ugyanolyan megbízhatóan hívja-e az eszközöket. A prompt caching a Claude-os sort tovább csökkentheti, mert a 12 000 bemeneti token jelentős része minden körben ugyanaz a rendszerprompt és eszközleírás.

Gondolkodási blokkok: miért állt le időnként az Anthropic-ügynök?

A Claude modellek kiterjesztett gondolkodás (extended thinking) módban a válasz előtt egy külön gondolkodási blokkot is visszaadnak. Ha a gondolkodás be van kapcsolva és a modell eszközt hív, az Anthropic API elvárja, hogy a következő kérésben a korábbi gondolkodási blokk változatlanul visszakerüljön a modellhez. Ha ez a lánc megszakad, a kérés hibára fut, az ügynök pedig félúton elakad.

Az n8n két kiadásban is ezen a ponton javított. A 2.39.0 a kikapcsolt gondolkodást is jelzi a szolgáltatónak és helyesen dolgozza fel a tartalomblokk formátumú választ, egy másik javítás pedig megakadályozza, hogy az Anthropic-ügynökök beszélgetési szálai véglegesen elromoljanak, miközben a futási hibák láthatók maradnak. A 2.40.0 megőrzi az üres szövegű gondolkodási blokkokat is az eszközhívások között. Ha tehát az elmúlt hetekben azt láttad, hogy egy Claude-alapú ügynököd néha minden látható ok nélkül elhasal a második vagy harmadik eszközhívásnál, akkor ezek a javítások neked szólnak.

Egy gyakorlati megjegyzés az alapértelmezéshez: a változás az újonnan behúzott Anthropic Chat Model node kiinduló beállítását érinti. Hogy a meglévő munkafolyamataid ténylegesen melyik modellt hívják, azt a frissítés után node-onként ellenőrizd. Ha egy régebbi modellre hangoltad a promptjaidat, a váltás előtt egy tucatnyi valós példán hasonlítsd össze a kimenetet.

MCP a gyakorlatban: eszközfelfedezés, hibakezelés

A Model Context Protocol (MCP) az Anthropic által 2024 novemberében bemutatott nyílt szabvány, amely egységes módon köti össze az AI-modelleket és -ügynököket külső eszközökkel és adatforrásokkal. Az n8n ma négy ponton is MCP-t beszél, ezek mindegyikét érintette valamilyen javítás a 2.37 és a 2.40 között. A protokoll 2026. július 28-i specifikációs változásairól külön írásunk szól, itt kizárólag az n8n-es oldalra koncentrálunk.

Eszközfelfedezés: mit lát az ügynök?

Amikor egy AI-ügynök MCP-szerverhez kapcsolódik, először lekéri a szerver eszközeinek listáját: minden eszköz nevét, leírását és a bemeneti paraméterek sémáját. Ezekből dönti el a modell, melyik eszközt mikor és milyen adatokkal hívja. Az n8n dokumentációja szerint az MCP Client Tool node-ban három lehetőség közül választhatsz: az „All” a szerver összes eszközét átadja az ügynöknek, a „Selected” esetén te választod ki a használható eszközöket, az „All Except” pedig mindent átenged a kizártak kivételével.

A három kiadás több ponton is ezt a felfedezési folyamatot tette megbízhatóbbá. A 2.37.0-ban az MCP Server Trigger a JSON Schema 2020-12 szabvány szerint adja ki az eszközök sémáját, az Agent Builder megkapja az MCP-connectorok eszközeit, a példányszintű MCP munkafolyamat-keresője pedig mappák szerint is szűrhet. A 2.39.0 óta az MCP registryben (az n8n-be előre felvett MCP-szolgáltatások katalógusában) meglévő credentialt is használhatsz, ha pedig hiányzik egy szolgáltatás, a node-választóból új MCP-szolgáltatást javasolhatsz. A 2.40.0-ban az ügynök eszközfelfedezése felismeri a mindig betöltött eszközöket, az MCP-eszközkészlet tagjai queue módban a workereken futnak, a registry API-ja pedig már a hiányzó (null) fejlécekkel is elboldogul.

Egy KKV-nál gyakori hiba, hogy kényelemből az „All” marad beállítva. Egy CRM vagy egy projektmenedzsment-eszköz MCP-szervere könnyen húsz-harminc eszközt kínál, köztük törlést és tömeges módosítást is. Minden eszköz leírása minden körben a modell kontextusába kerül, ami tokenben mérhető költség, a felesleges eszköz pedig felesleges kockázat. Egy árajánlat-előkészítő ügynöknek elég a kereső és az olvasó eszköz, a törlés joga nem kell neki.

Hibakezelés: amikor az eszköz nem válaszol

Az MCP-hívás sokféleképpen elbukhat: lejár a token, a szerver túl lassan válaszol, megváltozik az eszköz sémája, vagy a hívott n8n-munkafolyamatot időközben valaki visszavonta. A régebbi verziókban ilyenkor gyakran csak egy általános hibaüzenet maradt, amelyből nehéz volt kideríteni a valódi okot.

A 2.37.0 az ügynök-munkamenet idővonalán külön jelzi az eszközök kemény és puha hibáit, az ügynök hibáit pedig hasznos üzenettel, az eredeti okkal együtt jeleníti meg. A 2.39.0 frissíti az MCP-szerver állapotát az asszisztens felületén, ha egy eszközhívás elbukott vagy a credential megváltozott, illetve elrejti a példányszintű MCP OAuth-felfedezését, ha az MCP-hozzáférés ki van kapcsolva. A 2.40.0 megakadályozza, hogy az MCP-n keresztüli munkafolyamat-módosítás elhagyja az ismeretlen műveleti mezőket, vagyis egy külső asszisztens által szerkesztett munkafolyamatból nem tűnnek el csendben beállítások.

Gyakorlati beállítások MCP-hez saját szerveren

Az n8n dokumentációja néhány olyan beállítást is rögzít, amelyek nélkül az MCP saját üzemeltetésű példányon ritkán működik stabilan:

• Az MCP Server Trigger hitelesítésnél a „None”, a „Bearer auth” és a „Header auth” közül választhatsz. Éles, internetről elérhető végponton mindig Bearer vagy Header hitelesítést használj.
• A trigger Server-Sent Events (SSE) és streamable HTTP átvitelt támogat, standard bemenet-kimenetet (stdio) viszont nem, így a helyi, parancssoros MCP-klienseket egy közvetítő (proxy) eszközön keresztül lehet bekötni.
• A teszt-URL a tesztesemény figyelésekor, az éles URL pedig a munkafolyamat közzétételekor (publish) regisztrálódik, ezért a kliensben mindig az éles URL-t add meg.
• Queue módban, több webhook-replika esetén az összes /mcp kezdetű kérést egyetlen, dedikált webhook-replikára kell irányítani, különben a kapcsolatok a dokumentáció szerint gyakran megszakadnak.
• Nginx fordított proxy mögött kapcsold ki a proxy pufferelését ezen a végponton, mert a folyamatos (streamelt) válaszok enélkül akadozhatnak.

Mi változott az AI Agent node-ban és az ügynökök működésében?

Az AI Agent és a köré épülő eszközök megbízhatóbbak lettek: az ügynök-munkamenetek a 2.37.0 óta projektekhez kötődnek, a munkafolyamat-eszközök a 2.39.0-ban védelmet kaptak a hiányzó vagy közzé nem tett munkafolyamatok ellen, a 2.40.0 pedig javította a tartalékmodell beállítását és bevezette a kötelező első eszközhívás lehetőségét.

Az n8n-ben egy ügynök gyakran más munkafolyamatokat hív eszközként, például egy „Rendelés lekérdezése” vagy egy „Ügyfél létrehozása a CRM-ben” nevű alfolyamatot. A 2.39.0 előtt gondot okozhatott, ha egy ilyen alfolyamatot valaki visszavont, törölt vagy inkompatibilis módon átírt. A 2.39.0 megerősítette az ügynök munkafolyamat-eszközeit a közzé nem tett, hiányzó vagy inkompatibilis munkafolyamatok ellen. Ha az ügynök által használt munkafolyamat-eszközök között közzé nem tett is van, az n8n elutasítja az ügynök közzétételét, a hibaüzenetben pedig meg is nevezi a hiányzó folyamatokat. Felfüggesztett (várakozó) szülő munkafolyamat esetén a munkafolyamat-eszköz hibadobás helyett kivár.

A 2.40.0-ban két, éles ügynököknél különösen hasznos beállítás változott. Az egyik a tartalékmodell (fallback model): a javítás után az AI node-okon az elsődleges modell mellett megbízhatóan beállítható egy tartalék, így ha a fő szolgáltató hibát ad vagy túlterhelt, a munkafolyamat a tartalékkal folytathatja. A másik újdonság, hogy az AI Agent node-ban kikényszeríthető, hogy az első körben mindenképp eszközt hívjon, ami akkor hasznos, ha az ügynök hajlamos fejből válaszolni ahelyett, hogy megnézné az adatbázist. A 2.40.0 emellett megszünteti az ügynökmodell streamjének téves elakadásjelzéseit.

A csatornák oldalán is mozgás van. A 2.37.0 Slack Agent nézetet hozott és a Message an Agent munkafolyamatokba streamelést vezetett be, a releasebot összesítése szerint a 2.36.0 már a Discordot is csatornaként kötötte be. A 2.39.0 lehetővé tette, hogy a chatcsatornák új ügynök-munkamenetet indítsanak. Ez a gyakorlatban azt jelenti, hogy ugyanaz az ügynök elérhető lehet a belső Slack-csatornán és egy weboldalas chatablakban is, munkamenetenként elkülönített előzménnyel.

A tartalékmodellt ne ugyanannál a szolgáltatónál válaszd, mint az elsődlegeset. Ha a Claude Sonnet 5 a fő modell, a tartalék lehet például egy OpenAI- vagy Google-modell, így egy szolgáltatói kiesés sem állítja le a folyamatot.

Milyen integrációk javultak a Microsofttól a webhookokig?

A három kiadás legnagyobb integrációs csomagja a Microsoft-ökoszisztémát érinti: a Teams node online megbeszéléseket és csatornaüzeneteket kezel, az Excel node jobban választja ki a munkafüzeteket, érkezett egy Microsoft Dataverse node, a webhookok pedig a 2.39.0 óta Set-Cookie fejlécet is küldhetnek.

A Microsoft Teams node a 2.39.0-ban csatornaüzenet-lekérdezést és -választ, online megbeszélés létrehozását és lekérdezését, valamint chattagok listázását kapta meg. A 2.40.0 ehhez online megbeszélés módosítását és törlését, csatorna- és chatüzenetek törlését és visszaállítását, chattagok hozzáadását és eltávolítását tette hozzá. Egy képzeletbeli 25 fős pécsi mérnökirodában ebből például olyan folyamat épülhet, amely a CRM-ben rögzített ügyféltalálkozóhoz automatikusan Teams-megbeszélést hoz létre, a projekt csatornájába pedig összefoglalót küld.

Az Excel node a 2.40.0-ban elfogadja a személyes OneDrive-munkafüzetek azonosítóit, a választóban pedig már csak munkafüzetfájlokat mutat. A Microsoft Outlook Trigger kézi futtatáskor a legfrissebb levelet hozza le, ami a tesztelést könnyíti meg. A SharePoint node 2-es verziója már a 2.37.0-ban alapértelmezetté vált.

A levelezésen alapuló folyamatoknál is volt javítanivaló. A 2.39.0-ban a Gmail Trigger minden lekérdezési körét az időkeretén belül fejezi be, a 2.40.0-ban az Email Trigger (IMAP) helyreállítja a kapcsolatot, ha a levelezőszerver bontotta, továbbá minden közzétételkor újracsatlakozik, ahogy a Postgres Trigger is. Vegyünk egy képzeletbeli balatoni panziót, ahol a foglalási e-maileket IMAP-trigger dolgozza fel. Ha a levelezőszerver éjszaka bontja a kapcsolatot, a javított trigger magától helyreállítja azt, így a reggeli foglalások nem ragadnak a postafiókban egy kézi újraindításig.

Néhány további tétel, amely egy-egy konkrét felhasználási esetnél sokat számíthat:

• A webhook node-ok a 2.39.0 óta Set-Cookie válaszfejlécet is beállíthatnak, így egy n8n-webhookra épített egyszerű űrlap vagy belső eszköz sütit is küldhet a böngészőnek.
• Az AMQP Trigger a 2.39.0-ban újracsatolja a fogadó kapcsolatot, ha az üzenetközvetítő (broker) leválasztotta.
• A HTTP Request node a 2.40.0-ban PROPFIND, MKCOL, MOVE, COPY és REPORT metódusokat is kapott, ami a WebDAV-alapú tárhelyek (például egy saját Nextcloud) fájlműveleteinél jön jól.

Frissítési tippek self-hosted példányokhoz: queue mode és timeout

A queue mode (sormód) az n8n skálázható üzemmódja, amelyben az n8n dokumentációja szerint egy fő példány fogadja a triggereket és a webhookokat, a futtatandó feladatokat egy Redis-alapú sorba teszi, a tényleges végrehajtást pedig külön worker példányok végzik, amelyek az eredményt az adatbázisba írják. Opcionálisan külön webhook-feldolgozók is beállíthatók a bejövő kérések szétterítésére.

Egy 5 és 50 fő közötti cégnél a legtöbb n8n egyetlen példányként fut, ami teljesen rendben van. Queue módra akkor érdemes váltani, ha sok párhuzamos futás van, vagy ha a hosszú AI-ügynökös feladatok miatt a szerkesztőfelület is belassul. A dokumentáció szerint queue módban Postgres adatbázis kell (SQLite-tal nem ajánlott), a workerek alapértelmezett párhuzamossága 10, az ajánlott minimum pedig 5, mert sok, alacsony párhuzamosságú worker kimerítheti az adatbázis kapcsolatkészletét.

Mit javított a három kiadás a queue mode-ban?

A 2.40.0 legfontosabb üzemeltetési újdonsága, hogy queue módban kikényszeríti a végrehajtási időkorlátot a beragadt feladatokra. Ez azért lényeges, mert egy beragadt feladat a worker egyik futtatási helyét foglalja: tegyük fel, hogy egy 10-es párhuzamosságú workeren három futás ragad be egy nem válaszoló külső API miatt, ilyenkor a kapacitás 30%-a addig kiesik, amíg valaki kézzel le nem állítja őket. A 2.40.0 emellett összeomlottként számolja el azokat a futásokat, amelyeket az összeomlás utáni helyreállítás megjelöl, a Code node-okat futtató task runner indítója pedig 1.5.0-s verzióra frissült.

A 2.39.0 a leállási folyamatot tette rendezettebbé: a task runner feladatainak időkorlátját a szabályos leállás (graceful shutdown) időablakára korlátozza, a task brokert a task runner folyamatok előtt állítja le, a worker pedig megvárja a leválasztott alfolyamatokat, mielőtt leállítja a task runnert. Ugyanebben a kiadásban javították, hogy elutasított futás után is lefusson a takarítás, valamint megmaradjon az eredeti hibaüzenet akkor is, ha a feladat kulcsa már nem létezik. A 2.37.0 már nem indítja újra azokat a task runnereket, amelyek csak lassúak, de nem álltak le.

Időkorlát beállítása: két környezeti változó

Az n8n dokumentációja szerint a végrehajtási időkorlátot két környezeti változó szabályozza. Az EXECUTIONS_TIMEOUT másodpercben adja meg, mennyi idő után szakítja meg az n8n a munkafolyamatot, alapértéke -1, vagyis alapból nincs időkorlát. Ha a munkafolyamat a fő folyamatban fut, puha időkorlát érvényesül, ami az éppen futó node befejezése után lép életbe. Saját folyamatban futó munkafolyamatnál az n8n előbb puha leállítást kísérel meg, majd a megadott idő ötödének elteltével leállítja a folyamatot. Az EXECUTIONS_TIMEOUT_MAX azt a felső határt rögzíti, amelynél hosszabb időkorlátot egyetlen munkafolyamat sem kaphat a saját beállításaiban.

A dokumentáció példájában az általános időkorlát egy óra (3 600 másodperc), a felső határ két óra (7 200 másodperc). Egy KKV-nál jó kiindulópont, ha az általános időkorlátot a leghosszabb, rendesen lefutó munkafolyamatod futási idejének nagyjából kétszeresére állítod, a kivételesen hosszú folyamatoknak (például egy éjszakai teljes CRM-szinkronnak) pedig munkafolyamat-szinten adsz több időt a felső határon belül.

A frissítéskor két további beállítást is nézz át:

• A N8N_GRACEFUL_SHUTDOWN_TIMEOUT a szabályos leállásra szánt időt adja meg, alapértéke a dokumentáció szerint 30 másodperc. Mivel a 2.39.0 óta a task runner feladatainak időkorlátja ehhez az ablakhoz igazodik, hosszú Code node-futásoknál nézd meg, elég-e ennyi.
• A 2.40.0 figyelmeztet, ha még az elavult N8N_DB_PING_TIMEOUT változót használod, ezért a frissítés után nézd át a naplót, majd takarítsd ki a konfigurációból a figyelmeztetésben szereplő elavult változókat.

Queue módban két szabály alól nincs kivétel. A dokumentáció szerint a fő példány titkosítási kulcsát minden workernek és webhook-feldolgozónak meg kell kapnia, a fő példánynak és a workereknek pedig ugyanazon az n8n-verzión kell futniuk. Ha csak a fő példányt frissíted, a régi verziójú workerek egy újabb adatbázis-sémával találkoznak, ami könnyen hibás futásokhoz vezet.

Hogyan csináld végig az n8n frissítést lépésről lépésre?

Egy saját üzemeltetésű n8n frissítés négy szakaszból áll: mentés, próba tesztpéldányon, a verzió rögzítése és frissítése éles környezetben, végül ellenőrzés az első napokban. Tapasztalati becslésünk szerint egy egypéldányos, Dockerben futó rendszernél ez egy-két óra, queue módban tesztkörnyezettel együtt inkább fél nap.

Az alábbi sorrend egy tipikus, Docker Compose-zal futtatott példányra vonatkozik, de a logikája más telepítésnél is ugyanez:

• Nézd meg a jelenlegi verziót a szerkesztőfelület súgómenüjében vagy a futó Docker-image címkéjén, utána a kiadási jegyzetekben olvasd végig a jelenlegi és a célverzió közötti törésváltozásokat (breaking changes).
• Készíts teljes adatbázis-mentést (Postgres esetén dumpot, SQLite esetén az adatkönyvtár másolatát), a titkosítási kulcsot pedig mentsd el külön, biztos helyre.
• Exportáld a munkafolyamatokat a parancssori eszközzel (n8n export:workflow --all), hogy egy esetleges visszaállításnál ne csak a teljes adatbázis-mentésre támaszkodhass.
• Indíts egy tesztpéldányt az adatbázis másolatával és ugyanazzal a titkosítási kulccsal, majd frissítsd azt a célverzióra.
• A tesztpéldányon futtasd le kézzel a három-öt legfontosabb munkafolyamatot: legalább egy Anthropic-ügynököt, egy MCP-eszközt használó folyamatot, egy webhookot és egy OAuth-os credentialt használó integrációt.
• Élesben rögzítsd a Docker-image pontos verziószámát (például 2.39.10) mozgó címke helyett, hogy a következő újraindításkor ne frissüljön magától egy újabb, teszteletlen verzióra.
• Queue módban állítsd le a teljes stacket, frissíts minden komponenst ugyanarra a verzióra, majd először a fő példányt indítsd el. A workereket és a webhook-feldolgozókat csak az adatbázis-migrációk lefutása után kapcsold vissza.
• Ellenőrizd a környezeti változókat: az EXECUTIONS_TIMEOUT értékét, a szabályos leállás időablakát és az elavultként jelzett változókat.
• Nézd át az OAuth-os credentialöket: ahol a felület újbóli jóváhagyást kér, csatlakoztasd újra a fiókot.
• Az első 48 órában naponta nézd meg a sikertelen futások listáját, a visszaállítási tervet pedig tartsd készenlétben.

A visszaállítási tervnél van egy kevéssé ismert csapda. A frissítés során az n8n adatbázis-migrációkat futtathat, ezért a régi image visszaállítása önmagában nem mindig elég. Ha vissza kell lépned, a régi verzió mellé a frissítés előtti adatbázis-mentést is vissza kell töltened, a közben lefutott munkafolyamatok eredményei pedig ilyenkor elvesznek. Ezért a frissítést olyan időpontra tedd, amikor utána van idő figyelni és reagálni, tehát inkább kedd délelőttre, mint péntek délutánra.

Stable vagy beta: melyik verzióra állj át most és mennyi munkával jár?

Éles rendszeren 2026. szeptember 22-i állapot szerint a stabilnak jelölt 2.39-es ág legfrissebb javítókiadása, a dokumentáció szerint a 2.39.10 az ésszerű cél. A 2.40-et, amely a dokumentációban béta (2.40.5), előbb tesztpéldányon próbáld ki, kivéve ha pont az általa javított hibák valamelyike okoz gondot.

A 2.37.0 és a 2.40.0 a GitHubon a megjelenéskor előzetes kiadásként (pre-release) szerepelt, vagyis az n8n maga is jelzi, hogy ezek a verziók még érési szakaszban vannak. A heti kiadási ritmus alapján a 2.40 valószínűleg hamarosan stabil jelölést kap, addig viszont nincs okod sietni, ha a mostani rendszered nem küzd a 2.40 által javított hibákkal.

A távolabbi jövőre is gondolni kell. A 2.40.0 kiadási jegyzete szerint a migrációs riport (migration report) már a következő főverzió, a v3 törésváltozásaira is figyelmeztet, például a tárolókönyvtár átnevezésére, a riport arra is figyelmeztet, hogy a chat hub megszűnik. Aki most rendszeresen frissít, annak a v3-ra való átállás várhatóan egy nagyobb, de jól előkészíthető lépés lesz, aki viszont fél évig nem nyúl a példányához, az egyszerre kapja meg a kihagyott kiadások és a főverzió-váltás összes változását.

A munkaigény forintban is kifejezhető. Tegyük fel, hogy egy képzeletbeli 12 fős kecskeméti asztalosüzem n8n-példányát egy külsős szakember üzemelteti feltételezett 12 000 Ft-os óradíjjal. Ebben az esetben egy egypéldányos frissítés tesztekkel együtt két óra, azaz 24 000 Ft, egy queue módú rendszer félnapos frissítése négy óra, azaz 48 000 Ft. Ezzel szemben egy beragadt rendelésfeldolgozó folyamat vagy egy lejárt token miatt csendben leálló számlaimport gyakran csak napok múlva derül ki, a kieső bevétel és a kézi pótlás pedig könnyen többe kerülhet ennél.

Miben segít a Convergo?

Ha a céged automatizálásai saját üzemeltetésű n8n-en futnak, de nincs házon belül valaki, aki hetente követi a kiadási jegyzeteket, a Convergo ezt a terhet leveszi a válladról. A support, üzemeltetés és tárhely csomagunk (30 000 Ft/hó, benne 3 fejlesztői óra) keretében rendszeresen, tesztpéldányon ellenőrizve frissíthetjük a példányodat és felügyelhetjük a mentéseket. A workflow automatizáció keretében rendbe tesszük a credentialök gazdáit és az időkorlátokat, egyedi AI-integráció formájában pedig Claude- vagy MCP-alapú ügynököket építünk a meglévő rendszereidre. Az első lépés egy ingyenes egyeztetés, amelyen átnézzük a jelenlegi példányodat és megmondjuk, mi az, ami sürgős.