Open-source nástroje RPA, které stojí za zvážení, a kde je provozovat

Několik nástrojů z obvyklého užšího výběru open-source RPA nelze spustit na linuxovém serveru bez grafického prostředí. Automatizují desktopová rozhraní a závisejí na grafické relaci, zatímco takový server nemá žádnou desktopovou relaci, kterou by mohly ovládat. Tato jediná vlastnost rozděluje kategorii na dvě části a rozhoduje o tom, kde může váš bot běžet.

Komerční licence RPA jsou důvodem většiny hledání nejlepších open-source nástrojů RPA. Níže uvedené záznamy o licencích, aktivitě a balíčcích jsem znovu ověřil 5. října 2026 a každé tvrzení o stavu odkazuje na záznam, z něhož vychází.

Klíčové poznatky

• Začněte požadavkem na relaci, nikoli seznamem funkcí. Oculix, OpenRPA a taskt jsou zaměřené především na GUI a pro místní práci na desktopu potřebují grafickou relaci. RPA Framework ji pro práci s prohlížečem, soubory a daty nepotřebuje. U TagUI a UI.Vision záleží na režimu, který spustíte.
• RPA Framework vydal nové verze v únoru, březnu, květnu, červnu, srpnu a říjnu 2026, což je nejpravidelnější historie vydávání ověřená v tomto článku.
• TagUI používá Apache-2.0 a stále přijímá příspěvky, ale AI Singapore ukončila jeho údržbu a podporu. Jeho wrapper pro Python neměl nové vydání od července 2023.
• Automagica a OpenBots do současného užšího výběru nepatří. Automagica přestala používat AGPL3, když společnost v říjnu 2020 koupila Netcall, a OpenBots nemá udržovaný veřejný repozitář produktu RPA.
• Pokud systémy, které propojujete, už poskytují API nebo webhooky, potřebujete automatizaci pracovních postupů, nikoli RPA. Jiná kategorie, jiné nástroje, mnohem kratší vývoj.

Co tento článek nepokrývá

Tři související otázky jsou mimo rozsah článku, každá z vlastního důvodu.

• Komerční platformy s bezplatnými tarify. UiPath Community Edition a bezplatný tarif Power Automate představují jiné rozhodování než to zde.
• Instalace a konfigurace. Nic z následujícího není instalační návod a u žádného nástroje zde nenajdete příkaz pro příkazový řádek.
• AI agenti pro ovládání počítače. Jeden nástroj ze seznamu nabízí integraci s takovým agentem a věnujeme jí jednu větu, nikoli srovnání.

Open-source nástroje RPA, které se stále udržují

Šest níže uvedených projektů splňuje zde použité kritérium: skutečně open-source software RPA s veřejnou aktivitou od poloviny roku 2025. Bezplatné nástroje RPA, které se přestaly udržovat, jsou stále bezplatné, takže největší pozornost si níže zaslouží sloupec s datem, nikoli s licencí. Ostatní sloupce říkají, co každý nástroj automatizuje a co potřebuje od stroje, na němž běží.

rpaframework je sada knihoven, nikoli aplikace. Píšete v Pythonu nebo Robot Framework a importujete části, které potřebujete. Začátek je tak náročnější než nahrání makra, ale údržba mnohem snazší. Jeho repozitář jej popisuje jako optimalizovaný pro Control Room, komerční orchestrační produkt, který kolem něj vytvořila Robocorp. Člen týmu Sema4.ai ve vlákně r/rpa popisuje Robocorp jako současnou součást Sema4.ai a hranici vymezuje jasně. Knihovna používá Apache-2.0, platforma nikoli. Vlastnictví se změnilo, hranice ne. Základní Robot Framework je také pod Apache-2.0 a není samostatnou položkou do užšího výběru.

Rozšíření UI.Vision pro prohlížeč je open-source jádrem. Automatizace desktopu se stahuje samostatně jako místní aplikace s názvem XModules, která rozšíření poskytuje rozpoznávání obrazu a textu, aby mohlo klikat i mimo prohlížeč. Licence je dvojí (AGPLv3 nebo komerční smlouva). Pokud upravujete open-source jádro a nechcete plnit podmínky AGPLv3 pro sdílení zdrojového kódu, alternativou je komerční licence.

taskt je problematickou položkou. Do jeho vývojové větve přibyl commit v červenci 2025 a jeho poslední vydání s tagem, v3.5.0.0, vyšlo v květnu 2020. Commity a vydání jsou různé signály a tak dlouhá doba bez verzovaného sestavení neznamená, že stávající sestavení přestalo fungovat.

SikuliX potřebuje vlastní poznámku, protože tento název se prakticky stal označením starší řady. Jeho původní repozitář byl archivován v březnu 2026 a zrcadlo oculix-org odkazuje současné uživatele na Oculix, aktivní pokračování s licencí MIT. Právě Oculix tedy dnes patří do užšího výběru; SikuliX1 je užitečný jako kontext původu a kompatibility, nikoli jako udržovaná položka.

Dvě položky se v užších výběrech stále objevují, ale neměly by tam být. Vlastní README Automagica oznamuje, že Netcall společnost koupila 13. října 2020 a že robot již není dostupný pod AGPL3, zatímco veřejná organizace OpenBots na GitHubu obsahuje repozitář statického webu a knihovnu pro emulaci terminálu, ale žádné jádro RPA.

Závislost na GUI, nebo provoz bez grafického rozhraní: rozdíl, který rozhodne o serveru

Open-source nástroj RPA potřebuje desktopovou relaci, když pracovní postup závisí na automatizaci desktopového uživatelského rozhraní. Automatizace API, souborů a dat může běžet bez grafického rozhraní a automatizace prohlížeče také, pokud prohlížeč běží v režimu headless. Nástroje pro rozpoznávání obrazu navíc potřebují pixely, které mohou zkoumat, ale automatizace desktopu může záviset na grafické relaci i tehdy, když ovládací prvky identifikuje pomocí selektorů místo obrázků.

Desktopová relace je přihlášené grafické prostředí, které uživatel dostane po přihlášení: obrazovka, správce oken a ukazatel myši se souřadnicemi. Headless znamená opak: stroj běžící bez připojeného displeje. Většina pronajatých linuxových serverů je ve výchozím stavu bez grafického rozhraní.

Rozdělení vychází z toho, na čem automatizace závisí. Oculix, stejně jako před ním SikuliX, používá počítačové vidění k nalezení tlačítka porovnáním uloženého obrázku s pixely právě zobrazenými na obrazovce, takže potřebuje grafickou plochu, kterou může zkoumat. Prohlížeč ovládaný přes automatizační API může běžet bez grafického rozhraní a bez desktopového displeje. Automatizace desktopu založená na selektorech je opět jiná: může identifikovat ovládací prvky místo pixelů, ale stále může záviset na grafickém desktopovém prostředí. U open-source RPA na serveru je praktickou otázkou, zda pracovní postup potřebuje grafickou relaci.

TagUI a UI.Vision stojí na obou stranách a záleží na režimu, který používáte. Vlastní referenční dokumentace TagUI uvádí, že volba -headless spouští postup s neviditelným prohlížečem Chrome a nefunguje pro vizuální automatizaci. Práce UI.Vision s prohlížečem běží uvnitř rozšíření, zatímco práce na desktopu probíhá přes XModules, které rozpoznává obrazy na obrazovce, a proto potřebuje obrazovku, na níž je může rozpoznávat.

Virtuální displej část rozdílu překonává. Xvfb je běžný způsob, jak linuxovému stroji bez displeje poskytnout displej v paměti, do něhož mohou grafické programy kreslit, aniž by se někdo díval. Automatizace podle obrazovky je tak možná i na serveru bez monitoru. Nástroj určený jen pro Windows tím na Linuxu nerozběhnete a přidává to další vrstvu, která musí fungovat i ve tři ráno.

Licence a datum commitu vám řeknou, zda tu nástroj bude i příští rok. Požadavek na relaci vám řekne, zda jej vůbec můžete spustit.

Kde který běží

Bot řízený obrazovkou potřebuje grafickou relaci, kterou může ovládat, ať jde o skutečný desktop, vzdálenou relaci nebo virtuální displej. Bot v režimu headless ji nepotřebuje. Obojí zní samozřejmě, dokud se bot nemá spustit ve 3 ráno a u klávesnice nikdo není.

Vlastní hosting RPA přináší jeden provozní požadavek, který platí bez ohledu na výběr nástroje: v okamžiku naplánovaného spuštění musí být stroj ve správném stavu. Ve Windows je tento stav konkrétní a Microsoft jej pro svůj vlastní produkt přesně dokumentuje. Pokyny Microsoftu pro bezobslužné desktopové toky Power Automate uvádějí, že produkt vytvoří na cílovém stroji relaci vzdálené plochy pro spuštění toku, že připojení ke konzolové relaci stroje není pro bezobslužná spuštění dostupné a že zařízení s Windows 10 nebo Windows 11 nemůže takový tok spustit, pokud existuje uživatelská relace, i když je zamčená. Na Windows Server místo toho vyvolá chybu zamčená relace otevřená pod stejným uživatelem jako připojení.

To je implementace jednoho dodavatele, nikoli zákon Windows, a představuje užitečnou mapu způsobů selhání, protože každý bot řízený obrazovkou musí řešit tentýž problém. Něco musí mít interaktivní relaci pod kontrolou a váš vlastní přihlášený desktop tomu obvykle stojí v cestě. Na Linuxu je obdobný problém menší, ale nezmizel: úloha, která přežije zavření vaší SSH relace, potřebuje plánovač a správce služeb, nikoli terminál, který jste nechali otevřený.

Windows Server zachází s relacemi jinak než desktopové edice. Jeho role RD Session Host provozuje desktopy založené na relacích na jednom stroji pro efektivní souběh více relací, takže relace bota a vaše vlastní mohou existovat vedle sebe. Pokud RD Session Host používáte pro provoz více relací, každý připojující se uživatel nebo zařízení potřebuje RDS CAL. To je náklad, který je třeba zahrnout včas, nikoli detail, který objevíte pozdě.

Dimenzování není náročné. Pro bota, který prokliká formulář a zapíše soubor, bych nevyhradil více než 1 vCPU a 2 GB RAM. Čemukoli, co řídí plnohodnotný prohlížeč, bych dal 2 vCPU a 4 GB nebo více, zejména při práci s několika kartami, protože náročnou částí této zátěže je Chrome, nikoli automatizační nástroj nad ním.

Starý počítač ve skříni tuto laťku splní. Musí zůstat zapnutý, přihlášený a nesmí to být notebook, který na noc zavíráte. Pronajatý server tuto kategorii problémů odstraňuje, protože může zůstat zapnutý nezávisle na vašem notebooku a nesoupeří o desktopovou relaci, v níž pracujete.

Pokud pronájem stroje vychází lépe než údržba vlastního, rozdělení se poměrně jasně promítá do dvou produktů. Windows VPS s obrazem Desktop nebo Server poskytne botovi řízenému obrazovkou vyhrazené prostředí Windows a Linux VPS pokryje stranu bez grafického rozhraní. Oba běží bez ohledu na to, zda máte notebook otevřený.

Který vybrat

Pokud se úloha odehrává v prohlížeči nebo souborech a umíte psát v Pythonu, volbou je RPA Framework a zbytek této části tvoří okrajové případy. Odpověď se obrátí v okamžiku, kdy úloha zasáhne desktopovou aplikaci bez API, protože pak potřebujete nástroj, který umí pracovat s grafickým desktopem, a užší výběr se zkrátí a zestárne.

Pro práci s prohlížečem, soubory a daty na linuxovém serveru vyberte RPA Framework. Běží bez grafického rozhraní, na stroji bez displeje nevyžaduje další mechanismy a novou verzi vydal ještě v říjnu 2026. Cenou je, že píšete v Pythonu nebo Robot Framework místo nahrávání makra. To vás něco stojí první den, ale vrátí se vám to pokaždé, když se cílová aplikace změní.

Pro starší aplikaci Windows bez API, u níž chcete vizuální automatizaci místo psaní celé automatizační kódové základny, vyberte UI.Vision, ovšem s uvedenou podmínkou. Letos do něj přibývají commity, což neplatí pro každou zdejší možnost schopnou práce na desktopu, a část jeho dvojí licence AGPLv3 přináší povinnosti sdílení zdrojového kódu, pokud open-source software upravujete a distribuujete. Druhou volbou je zde taskt. Jeho vývojová větev žije, poslední vydání s tagem vyšlo v květnu 2020 a právě tento rozdíl mezi projektem přijímajícím commity a projektem vydávajícím verze je třeba zvážit.

Pro multiplatformní vizuální automatizaci čehokoli na obrazovce vyberte Oculix, aktivní pokračování SikuliX. Stále upřednostňuje obrazy před selektory, ale projekt má nyní IDE a aktivní vydávání místo pouhé sady základních funkcí pro porovnávání obrazů. Použijte jej, když cílem jsou pixely, nikoli DOM nebo strom přístupnosti, a archivovaný repozitář SikuliX1 berte jako starší řadu, nikoli udržovaný produkt.

TagUI se stále doporučuje z dobrého důvodu. Jeho skriptovací jazyk se čte skoro jako běžná angličtina a ze všech šesti má nejmírnější křivku učení. Protiváha je uvedena v jeho vlastním README, podle něhož AI Singapore ukončila údržbu a podporu TagUI, zatímco projekt pokračuje díky open-source přispěvatelům a komunitě. To není opuštění. Přispěvatelé stále přidávají opravy do výchozí větve a repozitář není archivovaný. Není to ale ani rozmach a wrapper rpa pro Python na PyPI je o roky pozadu za historií commitů. Vyberte TagUI pro úlohu, kterou si můžete dovolit zmrazit, nikoli pro platformu, kterou plánujete tři roky rozšiřovat.

U OpenRPA je rozhodnutí obtížnější. Nabízí skutečné orchestrační funkce pod MPL-2.0, ale jeho poslední commit kódu i nejnovější vydání s tagem pocházejí z června 2025 a jedinou aktivitou v repozitáři od té doby jsou automaticky vytvářené větve s aktualizacemi závislostí. Nejde o opuštění, protože nic není archivováno, ale zároveň nic nevyšlo. Zvažte tento rozdíl vzhledem k tomu, jak dlouho musejí boti fungovat.

Kdy je specializovaný nástroj RPA špatnou odpovědí

Nejsilnější argument proti všemu výše uvedenému přišel od někoho, kdo tuto práci dělá. Ve vlákně r/selfhosted, které založil provozovatel snažící se uniknout komerční smlouvě RPA, jedna odpověď místo toho doporučuje Python s automatizačním frameworkem, jako je Selenium. Větší úsilí při vývoji, méně poruch po dokončení a nižší průběžné náklady na vlastnictví než u softwaru RPA, který komentující používal. Jiný komentující v témže vlákně nezávisle souhlasí.

Rozhodujícím kritériem je údržba. Pokud úloha poběží roky, objem je vysoký a vy nebo někdo z týmu dokážete udržovat malou kódovou základnu, napište kód. Selenium a Playwright stojí více první den a méně čtyřstý den, protože skript, který jste napsali, selhává způsoby, které umíte přečíst. Pokud má úloha horizont měsíců nebo v týmu nikdo nepíše kód, kratší cesta nástroje RPA k funkčnímu botovi za tu křehkost stojí.

Výstup z nahrávání akcí stárne nejhůře. Skript vygenerovaný sledováním vašich kliknutí je svázán s rozložením, v němž byl nahrán, takže přepracovaná stránka nebo přesunuté tlačítko jej rozbije způsobem, který chybová zpráva málokdy vysvětlí. Skepse vůči této kategorii jde místy hlouběji: jeden komentující ve vlákně r/rpa o open-source možnostech označuje RPA za přebalené skriptování prodávané netechnickým manažerům a u dostatečně úzké úlohy to není nespravedlivý popis.

Je tu také záměna kategorií, kterou je dobré odhalit včas. Pokud propojované systémy poskytují API nebo webhooky, RPA vůbec nechcete. RPA ovládá uživatelské rozhraní, protože neexistuje jiný vstup, zatímco automatizace pracovních postupů volá přímo tento vstup, což se rychleji vyvíjí a je mnohem méně křehké. Jde o jinou sadu nástrojů s vlastní nákladovou křivkou a nejprve je zde třeba vyřešit licenci n8n a náklady na vlastní hosting. n8n, Node-RED, Apache Airflow, Kestra a Dagu jsou všechny aplikace dostupné na jedno kliknutí na našem tržišti, pokud chcete některou spustit už dnes.

Současný web UI.Vision propaguje integraci Anthropic Computer Use, takže tato kategorie už přebírá agenty, kteří ovládají obrazovku tím, že o ní uvažují, místo porovnávání uložených obrázků.

Časté dotazy