Інструменти RPA з відкритим кодом, які варто розглянути, і де їх запускати

Кілька інструментів із типового списку кандидатів RPA з відкритим кодом не можуть працювати на Linux-сервері без графічного середовища. Вони автоматизують інтерфейси настільних програм і залежать від графічного сеансу, а на такому сервері немає сеансу робочого стола, яким можна керувати. Ця одна властивість ділить категорію надвоє й визначає, де може працювати ваш бот.

Вартість комерційних ліцензій RPA спонукає більшість людей шукати найкращі інструменти RPA з відкритим кодом. Я повторно перевірив наведені нижче записи про ліцензії, активність і пакети 5 жовтня 2026 року, і кожне твердження про стан проєкту містить посилання на запис, з якого його взято.

Ключові висновки

• Почніть із вимог до сеансу, а не зі списку функцій. Oculix, OpenRPA і taskt орієнтовані на GUI й потребують графічного сеансу для роботи з локальними настільними програмами. За використання RPA Framework для роботи з браузером, файлами та даними він не потрібен. У TagUI та UI.Vision усе залежить від режиму запуску.
• RPA Framework випускав релізи в лютому, березні, травні, червні, серпні та жовтні 2026 року: це найпослідовніша історія випусків серед перевірених тут проєктів.
• TagUI поширюється під Apache-2.0 і досі приймає внески учасників, але AI Singapore припинила його супровід і підтримку. Його обгортка для Python не отримувала релізів із липня 2023 року.
• Automagica та OpenBots не місце в актуальному списку кандидатів. Automagica перестала поширюватися під AGPL3, коли Netcall придбала компанію в жовтні 2020 року, а OpenBots не має підтримуваного публічного репозиторію RPA-продукту.
• Якщо системи, які ви з'єднуєте, вже надають API або вебхуки, вам потрібна автоматизація робочих процесів, а не RPA. Інша категорія, інші інструменти й значно коротша розробка.

Чого ця стаття не охоплює

Три суміжні питання залишаються поза межами статті, кожне зі своєї причини.

• Комерційні платформи з безкоштовними тарифами. UiPath Community Edition і безкоштовний план Power Automate вимагають окремого рішення, відмінного від розглянутого тут.
• Установлення й налаштування. Нижче немає посібника з налаштування, і для жодного інструмента не наведено команд командного рядка.
• ШІ-агенти для керування комп'ютером. Один інструмент зі списку пропонує інтеграцію з таким агентом, і їй присвячено речення, а не порівняння.

Інструменти RPA з відкритим кодом, які досі супроводжуються

Шість проєктів нижче відповідають застосованому тут критерію: це справді RPA-програми з відкритим кодом, які мали публічну активність із середини 2025 року. Безкоштовні інструменти RPA, супровід яких припинився, залишаються безкоштовними, тому найбільшої уваги заслуговує стовпець із датами, а не з ліцензіями. Інші стовпці показують, що автоматизує кожен інструмент і чого він потребує від машини, на якій працює.

rpaframework — це набір бібліотек, а не застосунок. Ви пишете на Python або Robot Framework та імпортуєте потрібні компоненти: почати складніше, ніж із запису макросу, зате супроводжувати значно легше. Репозиторій описує його як оптимізований для Control Room, комерційного продукту оркестрації, який Robocorp створила навколо нього. Учасник команди Sema4.ai в обговоренні r/rpa пише, що Robocorp тепер входить до Sema4.ai, і чітко окреслює межу. Бібліотека поширюється під Apache-2.0, платформа — ні. Власник змінився, а межа залишилася. Базовий Robot Framework також має ліцензію Apache-2.0 і не є окремим кандидатом для цього списку.

Браузерне розширення UI.Vision — це ядро з відкритим кодом. Для автоматизації настільних програм потрібно окремо завантажити локальний застосунок XModules, який додає розширенню розпізнавання зображень і тексту, щоб воно могло натискати елементи поза браузером. Ліцензія подвійна (AGPLv3 або комерційна угода). Якщо ви змінюєте відкрите ядро й не хочете виконувати вимоги AGPLv3 щодо надання вихідного коду, альтернативою є комерційна ліцензія.

taskt — неоднозначний учасник списку. У його гілці розробки з'явився коміт у липні 2025 року, а його останній реліз із тегом, v3.5.0.0, вийшов у травні 2020 року. Коміти й релізи — різні сигнали, і такий тривалий період без збірки з новим номером версії не означає, що наявна збірка перестала працювати.

SikuliX потребує окремого пояснення, адже ця назва фактично стала позначати попередню лінію проєкту. Його початковий репозиторій архівували в березні 2026 року, а дзеркало oculix-org скеровує нинішніх користувачів до Oculix, продовження, що активно розвивається під ліцензією MIT. Тому зараз до списку кандидатів варто включати Oculix; SikuliX1 корисний для розуміння походження й сумісності, а не як підтримуваний варіант.

Дві назви постійно з'являються в списках кандидатів, хоча їм там не місце. README самої Automagica повідомляє, що Netcall придбала компанію 13 жовтня 2020 року і що робот більше не доступний під AGPL3, а публічна організація OpenBots на GitHub містить репозиторій статичного сайту та бібліотеку емуляції термінала, але не ядро RPA.

Залежність від GUI чи робота без графічного середовища: відмінність, що визначає вибір сервера

Інструмент RPA з відкритим кодом потребує сеансу робочого стола, коли робочий процес залежить від автоматизації інтерфейсу настільної програми. Автоматизація API, файлів і даних може працювати без графічного середовища, як і автоматизація браузера, якщо браузер запущено в режимі headless. Інструментам розпізнавання зображень додатково потрібні пікселі для аналізу, але автоматизація настільних програм може залежати від графічного сеансу навіть тоді, коли визначає елементи керування селекторами, а не зображеннями.

Сеанс робочого стола — це графічне середовище, яке користувач отримує після входу: екран, віконний менеджер, вказівник миші з координатами. Headless означає протилежне: машина працює без підключеного дисплея. Більшість орендованих Linux-серверів за замовчуванням надаються без графічного середовища.

Цей поділ визначається тим, від чого залежить автоматизація. Oculix, як раніше SikuliX, використовує комп'ютерний зір, щоб знайти кнопку, порівнюючи збережене зображення з поточними пікселями на екрані, тож потребує графічної поверхні для аналізу. Браузер, керований через API автоматизації, може працювати в режимі headless без відображення робочого стола. Автоматизація настільних програм на основі селекторів — ще один випадок: вона може визначати елементи керування замість пікселів, але все одно залежати від графічного середовища робочого стола. Для RPA з відкритим кодом на сервері практичне питання полягає в тому, чи потрібен процесу графічний сеанс.

TagUI та UI.Vision перебувають по обидва боки цього поділу залежно від режиму. Власна довідкова документація TagUI пояснює, що параметр -headless запускає процес із невидимим браузером Chrome і не працює для візуальної автоматизації. Браузерні дії UI.Vision виконуються всередині розширення, а дії в настільних програмах — через XModules, який розпізнає зображення на екрані й тому потребує екрана, на якому їх можна розпізнати.

Віртуальний дисплей частково усуває розрив. Xvfb — стандартний спосіб надати Linux-машині без графічного дисплея екран у пам'яті, на якому графічні програми можуть малювати без спостерігача. Це дає змогу виконувати екранну автоматизацію на сервері без монітора. Він не змусить інструмент лише для Windows працювати на Linux і додає ще один шар, який має не переставати працювати о третій ночі.

Ліцензія та дата коміту підказують, чи існуватиме інструмент наступного року. Вимога до сеансу підказує, чи зможете ви взагалі його запустити.

Де працює кожен інструмент

Бот, який керує екраном, потребує графічного сеансу, яким може керувати: справжнього робочого стола, віддаленого сеансу або віртуального дисплея. Боту в режимі headless він не потрібен. Обидва твердження здаються очевидними, доки бот не має запуститися о 3-й ночі, коли біля клавіатури нікого немає.

Самостійно розміщена RPA має одну експлуатаційну вимогу, що зберігається незалежно від вибору інструмента: машина має бути в потрібному стані під час запуску за розкладом. У Windows цей стан має конкретні умови, і Microsoft докладно документує їх для власного продукту. У рекомендаціях Microsoft для настільних потоків Power Automate без участі користувача сказано, що продукт створює сеанс віддаленого робочого стола на цільовій машині для виконання потоку, що підключення до консольного сеансу машини для таких запусків недоступне і що пристрій Windows 10 або Windows 11 не може виконати такий потік, якщо існує сеанс користувача, навіть заблокований. На Windows Server заблокований сеанс під тим самим користувачем, що використовується для підключення, натомість повертає помилку.

Це реалізація одного виробника, а не закон Windows, і вона корисна як карта можливих збоїв, бо кожен бот, який керує екраном, вирішує ту саму проблему. Щось має володіти інтерактивним сеансом, і зазвичай перешкодою стає ваш власний робочий стіл із виконаним входом. На Linux аналогічна проблема менша, але теж існує: завданню, яке продовжує працювати після закриття SSH-сеансу, потрібні планувальник і менеджер служб, а не залишений відкритим термінал.

Windows Server керує сеансами інакше, ніж настільні редакції. Його роль RD Session Host запускає сеансові робочі столи на одній машині для ефективної багатосеансової роботи, тому сеанс бота і ваш власний можуть співіснувати. Якщо ви використовуєте RD Session Host для кількох сеансів, кожному підключеному користувачу або пристрою потрібна ліцензія RDS CAL. Це витрата, яку слід врахувати заздалегідь, а не виявити запізно.

Вимоги до ресурсів невисокі. Для бота, який натискає елементи форми й записує файл, я б не виділяв більше 1 vCPU та 2 ГБ RAM. Для всього, що керує повноцінним браузером, я б виділив 2 vCPU та 4 ГБ або більше, особливо з кількома вкладками: ресурсомістка частина цього навантаження — Chrome, а не інструмент автоматизації над ним.

Стара машина в шафі відповідає цим вимогам. Вона має залишатися ввімкненою, із виконаним входом, і це не має бути ноутбук, який ви закриваєте ввечері. Орендований сервер усуває цей клас проблем: він може працювати незалежно від ноутбука й не конкурує за сеанс робочого стола, у якому ви працюєте.

Якщо оренда машини вигідніша за її обслуговування, цей поділ досить чітко відповідає двом продуктам. Windows VPS з образом Desktop або Server надає екранному боту виділене середовище Windows, а Linux VPS покриває роботу без графічного середовища. Обидва працюють незалежно від того, чи відкритий ваш ноутбук.

Що вибрати

Якщо завдання виконується в браузері або з файлами й ви вмієте писати на Python, вибір — RPA Framework, а решта розділу присвячена окремим випадкам. Відповідь змінюється, щойно завдання зачіпає настільну програму без API: тоді потрібен інструмент, здатний взаємодіяти з графічним робочим столом, і список кандидатів стає коротшим та старішим.

Для роботи з браузером, файлами й даними на Linux-сервері вибирайте RPA Framework. Він працює без графічного середовища, встановлюється на машину без дисплея без додаткової інфраструктури й отримав нову версію ще в жовтні 2026 року. Ціна — написання на Python або Robot Framework замість запису макросу: витрати першого дня окупаються щоразу, коли змінюється цільова програма.

Для застарілої програми Windows без API, коли потрібна візуальна автоматизація замість написання повної кодової бази, вибирайте UI.Vision, але з умовою. Цього року проєкт отримує коміти, що не можна сказати про всі варіанти для настільних програм у цьому списку. А AGPLv3, одна з двох його ліцензій, передбачає зобов'язання надавати вихідний код, якщо ви змінюєте й поширюєте відкрите програмне забезпечення. taskt — другий вибір у цьому випадку. Його гілка розробки жива, останній реліз із тегом вийшов у травні 2020 року, і зважити потрібно саме розрив між проєктом, який приймає коміти, та проєктом, який випускає версії.

Для кросплатформної візуальної автоматизації всього, що є на екрані, вибирайте Oculix, продовження SikuliX, що активно розвивається. Він усе ще насамперед орієнтований на зображення, а не селектори, проте тепер проєкт має IDE й активно випускає релізи, а не є лише набором примітивів зіставлення зображень. Використовуйте його, коли ціль — пікселі, а не DOM або дерево доступності, і розглядайте архівований репозиторій SikuliX1 як попередню лінію, а не підтримуваний продукт.

TagUI продовжують рекомендувати не без причини. Його мова сценаріїв близька до звичайної англійської, а крива навчання найпологіша серед шести інструментів. Противага цьому зазначена у власному README: AI Singapore припинила супровід і підтримку TagUI, а проєкт продовжують учасники розробки з відкритим кодом та спільнота. Це не означає, що проєкт покинуто. Учасники досі додають виправлення в гілку за замовчуванням, і репозиторій не архівований. Але це й не активне прискорення розвитку, а обгортка Python rpa на PyPI на роки відстає від журналу комітів. Вибирайте TagUI для завдання, яке можете дозволити собі зафіксувати, а не для платформи, яку плануєте розширювати три роки.

З OpenRPA вибір складніший. Він має справжні можливості оркестрації під MPL-2.0, але і його останній коміт коду, і найновіший реліз із тегом датуються червнем 2025 року, а єдина активність у репозиторії відтоді — автоматично створені гілки оновлення залежностей. Це не покинутість, адже нічого не заархівовано, але й нічого не випущено. Зіставте цей розрив із тим, як довго мають працювати боти.

Коли спеціалізований інструмент RPA — хибний вибір

Найсильніший аргумент проти всього переліченого висловив той, хто займається цією роботою. В обговоренні r/selfhosted, розпочатому оператором, який намагався відмовитися від комерційного договору RPA, один допис пропонує натомість Python із фреймворком автоматизації на кшталт Selenium. Більше зусиль на розробку, менше збоїв після неї й нижча постійна вартість володіння, ніж у RPA-програми, якою користувався автор коментаря. Інший учасник того самого обговорення незалежно погодився з ним.

Визначальний критерій — супровід. Якщо завдання працюватиме роками, обсяг великий і ви або хтось у команді може підтримувати невелику кодову базу, пишіть код. Selenium і Playwright коштують дорожче першого дня й дешевше чотирьохсотого, бо власний сценарій ламається у зрозумілий вам спосіб. Якщо горизонт завдання — місяці або ніхто в команді не пише код, коротший шлях RPA-інструмента до робочого бота виправдовує його крихкість.

Найгірше старіє результат запису дій. Сценарій, створений зі спостереження за вашими натисканнями, прив'язаний до компонування, на якому його записали, тож оновлена сторінка або переміщена кнопка ламають його так, що повідомлення про помилку рідко пояснює причину. Подекуди скепсис щодо категорії йде далі: один учасник обговорення r/rpa про відкриті варіанти називає RPA перепакованими сценаріями, які продають нетехнічним менеджерам, і для достатньо вузького завдання цей опис не можна назвати несправедливим.

Є також помилка у виборі категорії, яку варто помітити заздалегідь. Якщо з'єднувані системи надають API або вебхуки, RPA вам узагалі не потрібна. RPA керує користувацьким інтерфейсом, бо іншого входу немає, а автоматизація робочих процесів звертається безпосередньо, що швидше розробити й значно важче зламати. Це інший набір інструментів зі своєю кривою витрат, і насамперед слід з'ясувати ліцензію n8n та вартість самостійного розміщення. n8n, Node-RED, Apache Airflow, Kestra і Dagu є застосунками з установленням в один клік у нашому маркетплейсі, якщо хочете запустити щось уже сьогодні.

Поточний сайт UI.Vision рекламує інтеграцію з Anthropic Computer Use, тож категорія вже включає агентів, які керують екраном, міркуючи про нього замість зіставлення збережених зображень.

Часті запитання