Megfontolásra érdemes nyílt forráskódú RPA-eszközök és futtatási helyeik

A nyílt forráskódú RPA-eszközök szokásos szűkített listáján szereplő több eszköz nem futtatható grafikus környezet nélküli Linux-kiszolgálón. Asztali felületeket automatizálnak, és grafikus munkamenettől függenek, míg egy ilyen kiszolgálón nincs vezérelhető asztali munkamenet. Ez az egy tulajdonság két részre osztja a kategóriát, és eldönti, hol futhat a bot.

A legjobb nyílt forráskódú RPA-eszközökre irányuló keresések többségét a kereskedelmi RPA-licencelés ösztönzi. Az alábbi licenc-, aktivitási és csomagnyilvántartásokat 2026. október 5-én ismét ellenőriztem, és minden állapotra vonatkozó állítás arra a nyilvántartásra hivatkozik, amelyből származik.

Legfontosabb tanulságok

• A munkamenetre vonatkozó követelménnyel kezdjünk, ne a funkciólistával. Az Oculix, az OpenRPA és a taskt elsősorban GUI-alapú, és a helyi asztali munkához grafikus munkamenetet igényel. Az RPA Framework böngészőkkel, fájlokkal és adatokkal végzett munkához nem igényli ezt. A TagUI és az UI.Vision esetében a futtatási módtól függ.
• Az RPA Framework 2026 februárjában, márciusában, májusában, júniusában, augusztusában és októberében adott ki verziókat; az itt ellenőrzöttek közül ez a legegyenletesebb kiadási előzmény.
• A TagUI Apache-2.0 licencű, és továbbra is fogad hozzájárulásokat, de az AI Singapore megszüntette a karbantartását és támogatását. Python-wrappere 2023 júliusa óta nem kapott új kiadást.
• Az Automagica és az OpenBots nem való egy aktuális szűkített listára. Az Automagica megszűnt AGPL3 licencűnek lenni, amikor a Netcall 2020 októberében felvásárolta a céget, az OpenBotsnak pedig nincs karbantartott nyilvános kódtára RPA-termékhez.
• Ha az összekapcsolt rendszerek már biztosítanak API-kat vagy webhookokat, munkafolyamat-automatizálásra van szükség, nem RPA-ra. Más kategória, más eszközök, sokkal rövidebb fejlesztés.

Amit ez a cikk nem tárgyal

Három kapcsolódó kérdés kívül esik a cikk hatókörén, mindegyik saját okból.

• Ingyenes csomaggal rendelkező kereskedelmi platformok. Az UiPath Community Edition és a Power Automate ingyenes csomagja az itt tárgyalttól eltérő döntést jelent.
• Telepítés és konfigurálás. Az alábbiak egyike sem beállítási útmutató, és egyik eszközhöz sem adunk parancssori utasítást.
• Számítógépet kezelő AI-ügynökök. A listán szereplő egyik eszköz integrálható egy ilyennel; ez egy mondatot kap, nem összehasonlítást.

A továbbra is karbantartott nyílt forráskódú RPA-eszközök

Az alábbi hat projekt teljesíti az itt alkalmazott feltételt: valóban nyílt forráskódú RPA-szoftverek, amelyeknél 2025 közepe óta volt nyilvános aktivitás. Azok az ingyenes RPA-eszközök, amelyeknek megszűnt a karbantartása, továbbra is ingyenesek, ezért alább a dátumokat tartalmazó oszlop érdemli a legtöbb figyelmet, nem a licencoszlop. A többi oszlop arra válaszol, hogy az egyes eszközök mit automatizálnak, és mit igényelnek az alattuk működő géptől.

Az rpaframework könyvtárak gyűjteménye, nem alkalmazás. Pythonban vagy Robot Frameworkben írunk, és importáljuk a szükséges részeket; ez nehezebb indulást jelent, mint egy makró rögzítése, de jóval könnyebb karbantartást. A kódtár leírása szerint a Control Roomra optimalizálták, arra a kereskedelmi orchestrációs termékre, amelyet a Robocorp épített köré. A Sema4.ai csapatának egyik tagja egy r/rpa-beszélgetésben úgy írja le a Robocorpot, mint amely már a Sema4.ai része, és világosan kijelöli a határt. A könyvtár Apache-2.0 licencű, a platform nem. A tulajdonos változott, a határ nem. Az alapul szolgáló Robot Framework is Apache-2.0 licencű, és nem külön jelölt a szűkített listára.

Az UI.Vision böngészőbővítménye a nyílt forráskódú mag. Az asztali automatizálás külön letöltés, egy XModules nevű helyi alkalmazás, amely kép- és szövegfelismerést biztosít a bővítménynek, hogy a böngészőn kívüli elemekre is kattinthasson. A licenc kettős (AGPLv3 vagy kereskedelmi megállapodás). Ha módosítjuk a nyílt forráskódú magot, és nem akarjuk betartani az AGPLv3 forráskód-megosztási feltételeit, a kereskedelmi licenc az alternatíva.

A taskt a kényes tétel. Fejlesztési ágába 2025 júliusában került commit, a legutóbbi címkézett kiadása, a v3.5.0.0 pedig 2020 májusában jelent meg. A commitok és a kiadások különböző jelzések, és az, hogy ilyen régóta nincs verziózott build, nem jelenti azt, hogy a meglévő build működésképtelenné vált.

A SikuliX külön lábjegyzetet igényel, mert a név gyakorlatilag a régi termékvonalat jelöli. Eredeti kódtárát 2026 márciusában archiválták, az oculix-org tükör pedig a jelenlegi felhasználókat az Oculixhoz irányítja, az aktív, MIT-licencű folytatáshoz. Ezért most az Oculixot kell felvenni a szűkített listára; a SikuliX1 az eredet és a kompatibilitás háttereként hasznos, nem karbantartott tételként.

Két tétel újra és újra felbukkan a szűkített listákon, pedig nem kellene ott lenniük. Az Automagica saját README-je közli, hogy a Netcall 2020. október 13-án felvásárolta a céget, és a robot már nem érhető el AGPL3 alatt, míg az OpenBots nyilvános GitHub-szervezete egy statikus webhely kódtárát és egy terminálemulációs könyvtárat tartalmaz, RPA-magot viszont nem.

GUI-függő vagy headless: a különbség, amely eldönti a kiszolgálóválasztást

Egy nyílt forráskódú RPA-eszköz akkor igényel asztali munkamenetet, ha a munkafolyamat asztali felület automatizálásától függ. Az API-k, fájlok és adatok automatizálása futhat grafikus felület nélkül, és a böngészőautomatizálás is, ha a böngésző headless módban fut. A képfelismerő eszközöknek ezen felül vizsgálható pixelekre van szükségük, de az asztali automatizálás akkor is függhet grafikus munkamenettől, ha képek helyett szelektorokkal azonosítja a vezérlőelemeket.

Az asztali munkamenet a bejelentkezés után elérhető grafikus környezet: képernyő, ablakkezelő, koordinátákkal rendelkező egérmutató. A headless ennek az ellenkezőjét jelenti: csatlakoztatott kijelző nélkül működő gépet. A bérelhető Linux-kiszolgálók többsége alapértelmezés szerint headless állapotban érkezik.

A felosztás abból következik, hogy mitől függ az automatizálás. Az Oculix, akárcsak korábban a SikuliX, számítógépes látással talál meg egy gombot: egy tárolt képet összevet a képernyőn éppen látható pixelekkel, ezért vizsgálható grafikus felületre van szüksége. Az automatizálási API-n keresztül vezérelt böngésző futhat headless módban, asztali kijelző nélkül. A szelektoralapú asztali automatizálás megint más: pixelek helyett vezérlőelemeket azonosíthat, de továbbra is függhet grafikus asztali környezettől. Kiszolgálón futó nyílt forráskódú RPA esetén a gyakorlati kérdés az, hogy a munkafolyamat igényel-e grafikus munkamenetet.

A TagUI és az UI.Vision mindkét oldalon jelen van, és az oldal a használt módtól függ. A TagUI saját referenciadokumentációja szerint a -headless opció láthatatlan Chrome-böngészővel futtatja a folyamatot, és vizuális automatizáláshoz nem működik. Az UI.Vision böngészős munkája bővítményben fut, az asztali munka pedig az XModuleson keresztül történik, amely a képernyőn látható képeket ismeri fel, ezért szüksége van egy képernyőre, ahol felismerheti őket.

A virtuális kijelző részben áthidalja a különbséget. Az Xvfb szokásos megoldás arra, hogy egy headless Linux-gép memóriában lévő kijelzőt kapjon, amelyre a grafikus programok úgy rajzolhatnak, hogy senki sem nézi. Így képernyővezérelt automatizálás monitor nélküli kiszolgálón is lehetséges. Ettől egy kizárólag Windowson futó eszköz nem fog Linuxon működni, és újabb réteget ad hozzá, amelynek hajnali háromkor is működnie kell.

A licenc és a commit dátuma megmutatja, hogy jövőre is létezik-e az eszköz. A munkamenet-követelmény azt mutatja meg, hogy egyáltalán futtatható-e.

Hol futnak az egyes eszközök

A képernyővezérelt botnak vezérelhető grafikus munkamenetre van szüksége, legyen az valódi asztal, távoli munkamenet vagy virtuális kijelző. A headless botnak nincs. Mindkettő magától értetődőnek hangzik, amíg a botnak hajnali 3-kor kell elindulnia, és senki sem ül a billentyűzetnél.

A saját üzemeltetésű RPA egy olyan működési követelményt hordoz, amely minden eszközválasztásnál megmarad: a gépnek a megfelelő állapotban kell lennie az ütemezett futás indulásakor. Windowson ez az állapot konkrét, és a Microsoft pontosan dokumentálja a saját termékéhez. A Microsoft Power Automate felügyelet nélküli asztali folyamataihoz adott útmutatója szerint a termék távoli asztali munkamenetet hoz létre a célgépen a folyamat futtatásához, a gép konzolmunkamenetéhez való kapcsolódás nem érhető el felügyelet nélküli futásokhoz, és egy Windows 10 vagy Windows 11 rendszerű eszköz nem futtathat ilyen folyamatot, ha van felhasználói munkamenet, akkor sem, ha az zárolt. Windows Serveren ehelyett hibát okoz, ha ugyanazon felhasználó alatt van nyitott, zárolt munkamenet, mint amelyet a kapcsolat használ.

Ez egyetlen gyártó megvalósítása, nem a Windows törvénye, és hasznos térképe a hibalehetőségeknek, mert minden képernyővezérelt botnak ugyanazt a problémát kell megoldania. Valaminek rendelkeznie kell egy interaktív munkamenet felett, és általában a saját bejelentkezett asztalunk áll az útjában. Linuxon az ennek megfelelő probléma kisebb, de nem hiányzik: egy feladatnak, amely az SSH-munkamenet bezárása után is fut, ütemezőre és szolgáltatáskezelőre van szüksége, nem egy nyitva hagyott terminálra.

A Windows Server másként kezeli a munkameneteket, mint az asztali kiadások. RD Session Host szerepköre munkamenet-alapú asztalokat futtat egy gépen a több munkamenetes működés hatékonysága érdekében, így a bot munkamenete és a sajátunk egyszerre létezhet. Ha az RD Session Hostot több munkamenetes működésre használjuk, minden kapcsolódó felhasználónak vagy eszköznek RDS CAL-ra van szüksége. Ez olyan költség, amellyel korán kell számolni, nem későn felfedezendő részlet.

Az erőforrásigény szerény. Nem biztosítanék 1 vCPU-nál és 2 GB RAM-nál többet egy botnak, amely végigkattint egy űrlapot és kiír egy fájlt. Bárminek, ami teljes böngészőt vezérel, 2 vCPU-t és legalább 4 GB-ot adnék, különösen több lap használatakor, mert ennek a terhelésnek a költséges része a Chrome, nem a ráépülő automatizálási eszköz.

Egy szekrényben álló régi gép is megfelel ennek. Bekapcsolva és bejelentkezve kell maradnia, és nem lehet az a laptop, amelyet éjszakára becsukunk. Egy bérelt kiszolgáló megszünteti ezt a problémakört, mert a laptopunktól függetlenül bekapcsolva maradhat, és nem verseng azzal az asztali munkamenettel, amelyben dolgozunk.

Ha a gépbérlés előnyösebb, mint egy saját gép karbantartása, a felosztás elég egyértelműen két termékhez rendelhető. Egy Desktop vagy Server lemezképpel futó Windows VPS dedikált Windows-környezetet ad a képernyővezérelt botnak, a Linux VPS pedig a headless oldalt szolgálja ki. Mindkettő fut, függetlenül attól, hogy nyitva van-e a laptopunk.

Melyiket válasszuk

Ha a feladat böngészőben vagy fájlokban zajlik, és tudunk Pythonban írni, az RPA Framework a választás, a szakasz többi része pedig kivételes esetekről szól. A válasz abban a pillanatban megfordul, amikor a feladat API nélküli asztali alkalmazást érint, mert akkor grafikus asztallal együttműködni képes eszköz kell, és a szűkített lista rövidebb és régebbi lesz.

Linux-kiszolgálón végzett böngészős, fájl- és adatmunkához válasszuk az RPA Frameworköt. Headless módban fut, kijelző nélküli gépen is használható extra mechanizmusok nélkül, és még 2026 októberében is megjelent új verziója. Az ára az, hogy makrórögzítés helyett Pythonban vagy Robot Frameworkben írunk, ami az első napon költség, de minden célalkalmazás-változáskor megtérül.

Régi, API nélküli Windows-alkalmazáshoz, ahol teljes automatizálási kódbázis megírása helyett vizuális automatizálást szeretnénk, válasszuk az UI.Visiont, a hozzá tartozó feltétellel. Idén is kap commitokat, ami nem minden itt szereplő, asztali automatizálásra képes megoldásra igaz, és kettős licencének AGPLv3 része forráskód-megosztási kötelezettségekkel jár, ha módosítjuk és terjesztjük a nyílt forráskódú szoftvert. Itt a taskt a második választás. Fejlesztési ága él, legutóbbi címkézett kiadása 2020 májusában jelent meg, és éppen a commitokat fogadó és a verziókat kiadó projekt közötti különbséget kell mérlegelni.

Bármi képernyőn megjelenő dolog többplatformos vizuális automatizálásához válasszuk az Oculixot, a SikuliX aktív folytatását. Továbbra is elsősorban képalapú, nem szelektoralapú, de a projektnek már IDE-je és aktív kiadásai vannak, nem csupán képegyeztető alapfunkciók gyűjteménye. Akkor használjuk, ha a cél pixelekből áll, nem DOM-ból vagy akadálymentességi fából, és az archivált SikuliX1 kódtárat a régi termékvonalnak tekintsük, ne karbantartott terméknek.

A TagUI-t okkal ajánlják újra és újra. Szkriptnyelve közel áll a hétköznapi angolhoz, és a hat közül ennek a legkönnyebb az elsajátítása. Az ellensúly a saját README-jében szerepel, amely szerint az AI Singapore megszüntette a karbantartást és a TagUI támogatását, miközben a projektet nyílt forráskódú közreműködők és a közösség viszi tovább. Ez nem elhagyás. A közreműködők továbbra is javításokat adnak az alapértelmezett ághoz, és a kódtár nincs archiválva. Ugyanakkor ez nem is lendület, és a PyPI-n lévő rpa Python-wrapper évekkel elmarad a commitnaplótól. Olyan feladathoz válasszuk a TagUI-t, amelynek befagyasztását megengedhetjük magunknak, ne olyan platformhoz, amelyet három évig tervezünk bővíteni.

Az OpenRPA nehezebb döntés. Valódi orchestrációs funkciókat kínál MPL-2.0 alatt, de a legutóbbi kódcommitja és a legújabb címkézett kiadása is 2025 júniusából származik, azóta pedig a kódtár egyetlen aktivitását automatikusan létrehozott függőségfrissítő ágak adják. Ez nem elhagyás, hiszen semmi sincs archiválva, de semmi új sem jelent meg. Ezt a rést ahhoz mérjük, mennyi ideig kell a botoknak működniük.

Amikor egy dedikált RPA-eszköz a rossz válasz

A fentiek elleni legerősebb érv olyasvalakitől jött, aki ezzel dolgozik. Egy r/selfhosted-beszélgetésben, amelyet egy kereskedelmi RPA-szerződésből szabadulni próbáló üzemeltető indított, egy válasz inkább a Python és egy automatizálási keretrendszer, például a Selenium mellett érvel. Több erőfeszítés a megépítés, kevesebb meghibásodás az elkészülés után, és alacsonyabb folyamatos birtoklási költség, mint a hozzászóló által használt RPA-szoftvernél. Egy másik hozzászóló ugyanabban a beszélgetésben ettől függetlenül egyetért.

A döntő szempont a karbantartás. Ha a feladat évekig fut, a mennyiség nagy, és mi magunk vagy valaki a csapatból képes életben tartani egy kis kódbázist, írjuk meg a kódot. A Selenium és a Playwright az első napon többe, a négyszázadikon kevesebbe kerül, mert a saját szkriptünk olyan módon hibásodik meg, amelyet értünk. Ha a feladat időtávja hónapokban mérhető, vagy a csapatból senki sem ír kódot, az RPA-eszköz működő bothoz vezető rövidebb útja megéri a törékenységet.

A műveletrögzítő kimenete öregszik a legrosszabbul. A kattintásaink megfigyelésével generált szkript ahhoz az elrendezéshez kötődik, amelyen rögzítették, ezért egy áttervezett oldal vagy áthelyezett gomb olyan módon rontja el, amelyet a hibaüzenet ritkán magyaráz meg. A kategóriával szembeni szkepticizmus helyenként ennél mélyebb: egy hozzászóló a nyílt forráskódú lehetőségekről szóló r/rpa-beszélgetésben nem műszaki vezetőknek értékesített, újracsomagolt szkriptelésnek nevezi az RPA-t, és kellően szűk feladat esetén ez nem igazságtalan leírás.

Van egy kategóriatévesztés is, amelyet érdemes korán felismerni. Ha az összekapcsolt rendszerek API-kat vagy webhookokat kínálnak, egyáltalán nem RPA-ra van szükség. Az RPA felhasználói felületet vezérel, mert nincs más bejárat, míg a munkafolyamat-automatizálás közvetlenül a bejáratot hívja meg, ami gyorsabban fejleszthető és sokkal kevésbé törékeny. Ez más eszközkészlet saját költséggörbével, és elsőként az n8n licencét és saját üzemeltetésének költségét kell tisztázni. Az n8n, a Node-RED, az Apache Airflow, a Kestra és a Dagu mind egykattintásos alkalmazás a piacterünkön, ha még ma szeretnénk valamelyiket futtatni.

Az UI.Vision jelenlegi webhelye Anthropic Computer Use-integrációt hirdet, tehát a kategória már befogad olyan ügynököket, amelyek tárolt képek egyeztetése helyett a képernyőről való következtetéssel vezérlik azt.

Gyakran ismételt kérdések