Open-source RPA-tools voor je shortlist en waar je ze uitvoert

Verschillende tools op een gebruikelijke open-source RPA-shortlist kunnen niet op een kale Linux-server draaien. Ze automatiseren desktopinterfaces en vereisen een grafische sessie, terwijl een kale server geen desktopsessie heeft om te besturen. Alleen al die eigenschap verdeelt de categorie in tweeën en bepaalt waar je bot kan draaien.

Commerciële RPA-licenties zijn de reden voor de meeste zoekopdrachten naar de beste open-source RPA-tools. Ik heb de onderstaande licentie-, activiteits- en pakketgegevens op 5 oktober 2026 opnieuw gecontroleerd. Elke statusclaim verwijst naar de bijbehorende bron.

Belangrijkste punten

• Begin bij de sessievereisten, niet bij de functies. Oculix, OpenRPA en taskt richten zich op grafische interfaces en hebben voor lokaal desktopwerk een grafische sessie nodig. RPA Framework heeft die niet nodig voor browser-, bestands- en datataken. Bij TagUI en UI.Vision hangt het af van de gebruikte modus.
• RPA Framework bracht releases uit in februari, maart, mei, juni, augustus en oktober 2026: het meest regelmatige releaseverloop dat hier is gecontroleerd.
• TagUI gebruikt Apache-2.0 en accepteert nog bijdragen, maar AI Singapore is gestopt met onderhoud en ondersteuning. De Python-wrapper heeft sinds juli 2023 geen release gehad.
• Automagica en OpenBots horen niet op een actuele shortlist. Automagica stopte met AGPL3 toen Netcall het bedrijf in oktober 2020 overnam. OpenBots heeft geen onderhouden openbare repository voor een RPA-product.
• Als de gekoppelde systemen al API's of webhooks aanbieden, wil je workflowautomatisering, geen RPA. Een andere categorie, andere tools en veel minder ontwikkelwerk.

Wat dit artikel niet behandelt

Drie aanverwante vragen vallen buiten het bereik, elk om een andere reden.

• Commerciële platforms met gratis aanbiedingen. UiPath Community Edition en het gratis abonnement van Power Automate vragen een andere afweging dan die hier.
• Installatie en configuratie. Dit is geen installatiehandleiding en geen enkele tool krijgt opdrachten om uit te voeren.
• AI-agenten die computers bedienen. Eén tool biedt zo'n integratie; die krijgt een zin, geen vergelijking.

De open-source RPA-tools die nog worden onderhouden

De zes projecten hieronder voldoen aan de gekozen norm: echte open-source RPA-software met openbare activiteit sinds medio 2025. Gratis RPA-tools blijven gratis als het onderhoud stopt. Daarom verdient de datumkolom meer aandacht dan de licentiekolom. De andere kolommen laten zien wat elke tool automatiseert en wat hij van de onderliggende machine vraagt.

rpaframework is een verzameling bibliotheken, geen toepassing. Je schrijft Python of Robot Framework en importeert de benodigde onderdelen. Beginnen vraagt meer dan een macro opnemen, maar het onderhoud is veel eenvoudiger. De repository noemt het geoptimaliseerd voor Control Room, het commerciële orkestratieproduct dat Robocorp eromheen bouwde. Een Sema4.ai-medewerker in een r/rpa-discussie beschrijft Robocorp als inmiddels onderdeel van Sema4.ai en benoemt de grens duidelijk. De bibliotheek is Apache-2.0, het platform niet. De eigenaar veranderde, die grens niet. Het onderliggende Robot Framework is ook Apache-2.0 en geen afzonderlijk extra shortlist-item.

De browserextensie van UI.Vision is de open-source kern. Desktopautomatisering is een aparte download: een lokale app genaamd XModules biedt beeld- en tekstherkenning om buiten de browser te klikken. Er geldt een dubbele licentie (AGPLv3 of een commerciële overeenkomst). Als je de open-source kern aanpast en niet aan de AGPLv3-voorwaarden voor broncodedeling wilt voldoen, is de commerciële licentie het alternatief.

taskt is het lastige geval. De ontwikkeltak kreeg een commit in juli 2025, maar de laatste getagde release, v3.5.0.0, verscheen in mei 2020. Commits en releases zijn verschillende signalen. Zo lang zonder nieuwe versie betekent niet dat de bestaande build niet meer werkt.

SikuliX verdient een voetnoot, omdat de naam inmiddels vooral voor de oudere lijn staat. De oorspronkelijke upstream werd in maart 2026 gearchiveerd en de oculix-org-spiegel verwijst huidige gebruikers naar Oculix, de actieve voortzetting onder MIT. Daardoor hoort Oculix nu op de shortlist; SikuliX1 biedt vooral herkomst- en compatibiliteitscontext, geen onderhouden optie.

Twee namen blijven op shortlists verschijnen terwijl ze daar niet thuishoren. Automagica meldt in de README dat Netcall het bedrijf op 13 oktober 2020 overnam en dat de robot niet langer onder AGPL3 beschikbaar is. De openbare GitHub-organisatie van OpenBots bevat een repository voor statische websites en een terminalemulatiebibliotheek, maar geen RPA-kern.

Grafische interface of headless: de scheiding die je serverkeuze bepaalt

Een open-source RPA-tool heeft een desktopsessie nodig wanneer de workflow desktopinterfaces automatiseert. API-, bestands- en data-automatisering kan headless draaien, net als browserautomatisering als de browser in headless-modus loopt. Beeldherkenningstools hebben daarnaast pixels nodig om te onderzoeken. Desktopautomatisering kan echter ook een grafische sessie vereisen wanneer ze besturingselementen via selectors herkent in plaats van via afbeeldingen.

Een desktopsessie is de grafische omgeving na het aanmelden: een scherm, vensterbeheerder en muisaanwijzer met coördinaten. Headless is het tegenovergestelde: een machine zonder aangesloten scherm. De meeste gehuurde Linux-servers worden standaard zo geleverd.

De scheiding volgt uit de afhankelijkheden van de automatisering. Oculix gebruikt, net als SikuliX vroeger, computer vision om een knop te vinden door een opgeslagen afbeelding met de huidige schermpixels te vergelijken. Daarom moet het een grafisch oppervlak kunnen onderzoeken. Een browser via een automatiserings-API kan zonder desktopscherm draaien. Desktopautomatisering via selectors is weer anders: ze herkent besturingselementen in plaats van pixels, maar kan nog steeds een grafische desktopomgeving nodig hebben. De praktische vraag bij open-source RPA op een server is of de workflow een grafische sessie vereist.

TagUI en UI.Vision vallen afhankelijk van de modus aan beide kanten. TagUI zegt in de referentiedocumentatie dat -headless een flow met een onzichtbare Chrome-browser uitvoert en niet werkt voor visuele automatisering. UI.Vision doet browserwerk in een extensie en desktopwerk via XModules, dat beelden op het scherm herkent en dus een scherm nodig heeft.

Een virtueel scherm overbrugt een deel van de kloof. Xvfb geeft een headless Linux-machine een scherm in het geheugen waarin grafische programma's tekenen zonder toeschouwer. Zo wordt schermgestuurde automatisering op een server zonder monitor mogelijk. Het maakt een uitsluitend voor Windows bedoelde tool niet geschikt voor Linux en voegt een extra laag toe die om drie uur 's nachts moet blijven werken.

Een licentie en een commitdatum vertellen je of een tool volgend jaar nog bestaat. De sessievereisten vertellen je of je hem überhaupt kunt uitvoeren.

Waar elke tool draait

Een schermgestuurde bot heeft een grafische sessie nodig die hij kan besturen: een echte desktop, externe sessie of virtueel scherm. Een headless bot niet. Beide klinken vanzelfsprekend totdat de bot om 3 uur moet starten zonder iemand achter het toetsenbord.

Zelf gehoste RPA kent een operationele eis ongeacht de tool: de machine moet bij de geplande start in de juiste toestand zijn. Onder Windows is die toestand specifiek en Microsoft documenteert hem voor het eigen product. Volgens de documentatie voor onbeheerde desktopflows van Power Automate maakt het product een externe desktopsessie op de doelmachine, kunnen onbeheerde runs de consolesessie niet gebruiken en kan een Windows 10- of Windows 11-apparaat geen run uitvoeren als er een gebruikerssessie aanwezig is, zelfs een vergrendelde. Op Windows Server geeft een vergrendelde sessie onder dezelfde gebruiker als de verbinding een fout.

Dat is de implementatie van één leverancier, geen wet van Windows, maar wel een bruikbaar overzicht van fouten: elke schermgestuurde bot moet hetzelfde probleem oplossen. Iets moet een interactieve sessie bezitten en vaak staat je eigen aangemelde desktop in de weg. Onder Linux is het equivalente probleem kleiner, maar aanwezig: een taak die na het sluiten van je SSH-sessie doorgaat heeft een planner en servicebeheerder nodig, geen open gelaten terminal.

Windows Server behandelt sessies anders dan desktopedities. De RD Session Host-rol voert sessiegebaseerde desktops op één machine uit voor efficiënt gebruik van meerdere sessies, zodat een botsessie en je eigen sessie naast elkaar kunnen bestaan. Bij die inzet van RD Session Host heeft iedere aangesloten gebruiker of ieder aangesloten apparaat een RDS CAL nodig. Dat zijn kosten om vroeg mee te rekenen, geen detail om achteraf te ontdekken.

De benodigde capaciteit is bescheiden. Ik zou niet meer dan 1 vCPU en 2 GB RAM toewijzen aan een bot die een formulier doorloopt en een bestand schrijft. Voor een volledige browser zou ik 2 vCPU en minstens 4 GB kiezen, vooral met meerdere tabbladen. Chrome is het zware deel van die belasting, niet de automatiseringstool erboven.

Een oude machine in een kast voldoet. Ze moet aan en aangemeld blijven en niet de laptop zijn die je 's avonds dichtklapt. Een gehuurde server voorkomt dat soort problemen: hij blijft onafhankelijk van de laptop draaien en concurreert niet met je eigen werksessie op de desktop.

Als huren beter uitkomt dan een eigen machine onderhouden, past de scheiding vrij goed bij twee producten. Een Windows VPS met een Desktop- of Server-image biedt een schermgestuurde bot een eigen Windows-omgeving. Een Linux VPS dekt de headless-kant. Beide werken ongeacht of je laptop open is.

Welke kies je?

Als de taak in een browser of bestanden zit en je Python kunt schrijven, is RPA Framework de keuze. De rest gaat over uitzonderingen. Zodra een desktopapplicatie zonder API meedoet, verandert het antwoord: je hebt een tool nodig die met een grafische desktop kan werken. De shortlist wordt dan korter en ouder.

Kies RPA Framework voor browser-, bestands- en datataken op een Linux-server. Het draait headless, vraagt op een machine zonder scherm geen extra voorzieningen en bracht nog in oktober 2026 een versie uit. De prijs is Python of Robot Framework schrijven in plaats van een macro opnemen. Dat kost op dag één moeite, maar betaalt zich terug bij elke verandering van de doelapplicatie.

Kies UI.Vision voor een oudere Windows-app zonder API als je visuele automatisering wilt in plaats van een volledige codebasis, met een voorwaarde. Het krijgt dit jaar commits, anders dan sommige desktopopties. De AGPLv3-helft van de dubbele licentie vereist broncodedeling wanneer je de open-source software aanpast en verspreidt. taskt is de tweede keuze: de ontwikkeltak leeft, maar de laatste getagde release verscheen in mei 2020. Dat verschil tussen commits ontvangen en versies uitbrengen moet je afwegen.

Kies Oculix, de actieve voortzetting van SikuliX, voor platformonafhankelijke visuele automatisering van alles op het scherm. Het werkt nog steeds primair met beelden in plaats van selectors, maar heeft nu een IDE en actieve releases, in plaats van alleen een verzameling basisfuncties voor beeldvergelijking. Gebruik het wanneer pixels je doel zijn in plaats van een DOM of toegankelijkheidsboom. Beschouw de gearchiveerde SikuliX1-repository als de oudere lijn, niet het onderhouden product.

TagUI wordt met reden aanbevolen. De scripttaal lijkt op gewoon Engels en de leercurve is de laagste van de zes. De keerzijde staat in de README: AI Singapore is gestopt met onderhoud en ondersteuning, terwijl open-source bijdragers en de community doorgaan. Dat is geen verlaten project: er komen nog fixes op de standaardtak en de repository is niet gearchiveerd. Het is ook geen sterke dynamiek. De rpa-Python-wrapper op PyPI loopt jaren achter op het commitlog. Kies TagUI voor een taak die je kunt bevriezen, niet voor een platform dat je drie jaar wilt uitbreiden.

OpenRPA is moeilijker te beoordelen. Het heeft echte orkestratiefuncties onder MPL-2.0, maar de laatste code-commit en de nieuwste getagde release dateren allebei van juni 2025, en de enige activiteit in de repository sindsdien bestaat uit geautomatiseerde branches voor het bijwerken van afhankelijkheden. Dat is geen verlatenheid, want er is niets gearchiveerd, maar er is ook niets uitgebracht. Weeg die kloof af tegen hoe lang de bots moeten blijven draaien.

Wanneer een speciale RPA-tool het verkeerde antwoord is

Het sterkste argument tegen alles hierboven kwam van iemand die dit werk doet. In een r/selfhosted-discussie, gestart door een beheerder die van een commercieel RPA-contract af wilde, beveelt een reactie Python met een automatiseringsframework zoals Selenium aan. Meer ontwikkelwerk, daarna minder breuk en lagere eigendomskosten dan de RPA-software die de reageerder gebruikte. Een andere deelnemer aan dezelfde discussie is het daar onafhankelijk mee eens.

De grens is onderhoud. Als de taak jarenlang loopt, het volume hoog is en jij of iemand in je team een kleine codebasis kan onderhouden, schrijf dan code. Selenium en Playwright kosten op dag één meer en op dag vierhonderd minder, omdat een zelfgeschreven script faalt op manieren die je kunt begrijpen. Bij een horizon van maanden, of als niemand in het team code schrijft, is de kortere route van de RPA-tool naar een werkende bot de kwetsbaarheid waard.

Recorderoutput veroudert het slechtst. Een script dat je klikken vastlegt, hangt aan de toenmalige indeling. Een vernieuwde pagina of verplaatste knop breekt het daardoor op een manier die de foutmelding zelden uitlegt. Sommige kritiek gaat verder: een deelnemer aan een r/rpa-discussie over open-source opties noemt RPA opnieuw verpakt scripting voor niettechnische managers. Voor een voldoende beperkte taak is dat geen oneerlijke beschrijving.

Let ook vroeg op een categoriefout. Als systemen API's of webhooks hebben, wil je helemaal geen RPA. RPA bestuurt een interface omdat er geen andere ingang is. Workflowautomatisering gebruikt die ingang rechtstreeks, is sneller te bouwen en veel minder kwetsbaar. Het is een andere toolset met een eigen kostenprofiel; de licentie van n8n en de kosten van zelfhosting moet je daar eerst uitzoeken. n8n, Node-RED, Apache Airflow, Kestra en Dagu zijn met één klik te installeren via onze marketplace als je vandaag wilt beginnen.

De huidige UI.Vision-site adverteert met een Anthropic Computer Use-integratie. De categorie neemt dus al agenten op die een scherm besturen door erover te redeneren, niet door opgeslagen beelden te vergelijken.

Veelgestelde vragen