Open-Source-RPA-Werkzeuge für die engere Auswahl und ihre Ausführungsumgebungen

Mehrere Werkzeuge auf einer typischen Open-Source-RPA-Auswahlliste können nicht auf einem Linux-Server ohne grafische Oberfläche laufen. Sie automatisieren Desktop-Oberflächen und benötigen eine grafische Sitzung; ein reiner Server besitzt jedoch keine Desktop-Sitzung zum Steuern. Diese eine Eigenschaft teilt die Kategorie in zwei Gruppen und entscheidet, wo Ihr Bot laufen kann.

Die Lizenzierung kommerzieller RPA-Produkte ist der Anlass für die meisten Suchen nach den besten Open-Source-RPA-Werkzeugen. Ich habe die unten genannten Lizenz-, Aktivitäts- und Paketnachweise am 5. Oktober 2026 erneut geprüft. Jede Aussage zum Status verlinkt den zugrunde liegenden Nachweis.

Die wichtigsten Erkenntnisse

• Beginnen Sie mit den Sitzungsanforderungen, nicht mit der Funktionsliste. Oculix, OpenRPA und taskt sind auf grafische Oberflächen ausgerichtet und benötigen für lokale Desktop-Aufgaben eine grafische Sitzung. RPA Framework benötigt sie für Browser-, Datei- und Datenaufgaben nicht. Bei TagUI und UI.Vision hängt es vom verwendeten Modus ab.
• RPA Framework veröffentlichte im Februar, März, Mai, Juni, August und Oktober 2026 neue Versionen. Das ist der regelmäßigste hier überprüfte Veröffentlichungsverlauf.
• TagUI steht unter Apache-2.0 und nimmt weiterhin Beiträge an, doch AI Singapore hat Wartung und Support eingestellt. Sein Python-Wrapper hat seit Juli 2023 keine neue Version erhalten.
• Automagica und OpenBots gehören nicht auf eine aktuelle Auswahlliste. Automagica steht seit der Übernahme durch Netcall im Oktober 2020 nicht mehr unter AGPL3. OpenBots besitzt kein gepflegtes öffentliches Repository für ein RPA-Produkt.
• Wenn die zu verbindenden Systeme bereits APIs oder Webhooks anbieten, brauchen Sie Workflow-Automatisierung statt RPA. Eine andere Kategorie, andere Werkzeuge und deutlich weniger Entwicklungsarbeit.

Was dieser Artikel nicht behandelt

Drei verwandte Fragen bleiben aus jeweils unterschiedlichen Gründen außerhalb des Umfangs.

• Kommerzielle Plattformen mit kostenlosen Angeboten. UiPath Community Edition und der kostenlose Tarif von Power Automate betreffen eine andere Entscheidung als die hier behandelte.
• Installation und Konfiguration. Die folgenden Abschnitte sind keine Installationsanleitung, und für keines der Werkzeuge werden Befehle angegeben.
• KI-Agenten, die Computer bedienen. Ein Werkzeug der Liste bietet eine entsprechende Integration. Sie erhält einen Satz, keinen Vergleich.

Die weiterhin gepflegten Open-Source-RPA-Werkzeuge

Die sechs folgenden Projekte erfüllen den verwendeten Maßstab: tatsächlich quelloffene RPA-Software mit öffentlicher Aktivität seit Mitte 2025. Kostenlose RPA-Werkzeuge bleiben auch nach dem Ende ihrer Wartung kostenlos. Deshalb verdient die Datumsspalte mehr Aufmerksamkeit als die Lizenzspalte. Die übrigen Spalten zeigen, was jedes Werkzeug automatisiert und was es von der zugrunde liegenden Maschine verlangt.

rpaframework ist eine Bibliothekssammlung, keine Anwendung. Sie schreiben Python oder Robot Framework und importieren die benötigten Teile. Der Einstieg ist anspruchsvoller als das Aufzeichnen eines Makros, die Wartung jedoch deutlich einfacher. Das Repository beschreibt es als für Control Room optimiert, das kommerzielle Orchestrierungsprodukt, das Robocorp darum aufgebaut hat. Ein Sema4.ai-Mitarbeiter in einem r/rpa-Thread beschreibt Robocorp als inzwischen zu Sema4.ai gehörend und benennt die Grenze klar. Die Bibliothek steht unter Apache-2.0, die Plattform nicht. Die Eigentümerschaft änderte sich, diese Grenze nicht. Das darunterliegende Robot Framework steht ebenfalls unter Apache-2.0 und ist kein zusätzliches eigenständiges Werkzeug für die Auswahlliste.

Die Browser-Erweiterung von UI.Vision ist der quelloffene Kern. Desktop-Automatisierung erfordert einen separaten Download: eine lokale Anwendung namens XModules, die Bild- und Texterkennung bereitstellt, um außerhalb des Browsers zu klicken. Es gilt eine Doppellizenz (AGPLv3 oder eine kommerzielle Vereinbarung). Wenn Sie den quelloffenen Kern verändern und die AGPLv3-Bedingungen zur Bereitstellung des Quellcodes nicht erfüllen möchten, ist die kommerzielle Lizenz die Alternative.

taskt ist der schwierige Eintrag. Sein Entwicklungszweig erhielt im Juli 2025 einen Commit, seine letzte getaggte Veröffentlichung, v3.5.0.0, stammt jedoch aus Mai 2020. Commits und Veröffentlichungen sind unterschiedliche Signale. Eine so lange Zeit ohne versionierten Build bedeutet nicht, dass der vorhandene Build nicht mehr funktioniert.

SikuliX benötigt eine eigene Anmerkung, weil der Name inzwischen im Wesentlichen für die ältere Linie steht. Der ursprüngliche Upstream wurde im März 2026 archiviert, und der oculix-org-Spiegel verweist aktuelle Nutzer auf Oculix, die aktive Fortsetzung unter MIT. Daher gehört heute Oculix in die engere Auswahl; SikuliX1 liefert Herkunfts- und Kompatibilitätskontext statt einen gepflegten Eintrag.

Zwei Namen erscheinen weiterhin auf Auswahllisten, obwohl sie dort nicht hingehören. Automagicas README erklärt, dass Netcall das Unternehmen am 13. Oktober 2020 übernommen hat und der Roboter nicht mehr unter AGPL3 verfügbar ist. OpenBots' öffentliche GitHub-Organisation enthält ein Repository für statische Websites und eine Terminalemulationsbibliothek, aber keinen RPA-Kern.

Grafische Oberfläche oder Headless: die Entscheidung für Ihren Server

Ein Open-Source-RPA-Werkzeug benötigt eine Desktop-Sitzung, wenn der Workflow Desktop-Oberflächen automatisiert. API-, Datei- und Datenautomatisierung kann ohne grafische Oberfläche laufen. Das gilt auch für Browser-Automatisierung, wenn der Browser im Headless-Modus läuft. Bilderkennungswerkzeuge brauchen zusätzlich Pixel zum Untersuchen. Desktop-Automatisierung kann aber auch eine grafische Sitzung voraussetzen, wenn sie Steuerelemente über Selektoren statt Bilder erkennt.

Eine Desktop-Sitzung ist die grafische Umgebung nach der Anmeldung: Bildschirm, Fenstermanager und Mauszeiger mit Koordinaten. Headless bezeichnet das Gegenteil: eine Maschine ohne angeschlossenen Bildschirm. Die meisten gemieteten Linux-Server werden standardmäßig so bereitgestellt.

Die Trennung folgt aus den Abhängigkeiten der Automatisierung. Oculix verwendet wie zuvor SikuliX Computer Vision, um einen Button durch den Vergleich eines gespeicherten Bilds mit den aktuellen Bildschirmpixeln zu finden. Es benötigt deshalb eine grafische Fläche zum Untersuchen. Ein Browser, der über eine Automatisierungs-API gesteuert wird, kann ohne Desktop-Anzeige laufen. Selektorbasierte Desktop-Automatisierung ist wiederum anders: Sie erkennt Steuerelemente statt Pixel, kann aber trotzdem eine grafische Desktop-Umgebung benötigen. Für Open-Source-RPA auf einem Server ist die praktische Frage, ob der Workflow eine grafische Sitzung braucht.

TagUI und UI.Vision liegen je nach Modus auf beiden Seiten. Laut TagUIs Referenzdokumentation führt die Option -headless einen Ablauf mit einem unsichtbaren Chrome-Browser aus und funktioniert nicht für visuelle Automatisierung. UI.Vision erledigt Browser-Aufgaben innerhalb einer Erweiterung und Desktop-Aufgaben über XModules. Dieses erkennt Bilder auf dem Bildschirm und braucht daher einen Bildschirm, auf dem es sie erkennen kann.

Eine virtuelle Anzeige schließt einen Teil der Lücke. Xvfb gibt einer Headless-Linux-Maschine eine Anzeige im Arbeitsspeicher, in die grafische Programme ohne Zuschauer zeichnen können. Damit wird bildschirmgesteuerte Automatisierung auf einem Server ohne Monitor möglich. Es macht ein Windows-exklusives Werkzeug nicht unter Linux lauffähig und fügt eine weitere Schicht hinzu, die um drei Uhr morgens noch funktionieren muss.

Eine Lizenz und ein Commit-Datum sagen Ihnen, ob ein Werkzeug nächstes Jahr noch existieren wird. Die Sitzungsanforderungen sagen Ihnen, ob Sie es überhaupt ausführen können.

Wo jedes Werkzeug läuft

Ein bildschirmgesteuerter Bot benötigt eine grafische Sitzung, die er kontrollieren kann: einen echten Desktop, eine Remote-Sitzung oder eine virtuelle Anzeige. Ein Headless-Bot benötigt sie nicht. Beides klingt selbstverständlich, bis der Bot um 3 Uhr ohne jemanden an der Tastatur starten muss.

Selbst gehostete RPA hat unabhängig vom Werkzeug eine betriebliche Anforderung: Die Maschine muss beim geplanten Start im richtigen Zustand sein. Unter Windows ist dieser Zustand spezifisch, und Microsoft dokumentiert ihn für das eigene Produkt genau. Die Anleitung für unbeaufsichtigte Desktop-Flows von Power Automate erklärt, dass das Produkt auf der Zielmaschine eine Remote-Desktop-Sitzung erstellt, unbeaufsichtigte Läufe nicht über die Konsolensitzung ausgeführt werden können und ein Windows-10- oder Windows-11-Gerät keinen solchen Lauf ausführen kann, wenn eine Benutzersitzung vorhanden ist, selbst wenn sie gesperrt ist. Auf Windows Server verursacht eine gesperrte Sitzung unter demselben Benutzer wie die Verbindung einen Fehler.

Das ist die Implementierung eines Herstellers, kein allgemeines Windows-Gesetz. Sie zeigt jedoch mögliche Fehlerquellen, weil jeder bildschirmgesteuerte Bot dasselbe Problem lösen muss. Irgendetwas muss eine interaktive Sitzung besitzen, und oft steht Ihr eigener angemeldeter Desktop im Weg. Unter Linux ist das entsprechende Problem kleiner, aber vorhanden: Eine Aufgabe, die nach dem Schließen Ihrer SSH-Sitzung weiterläuft, benötigt einen Zeitplaner und einen Dienstmanager statt eines offen gelassenen Terminals.

Windows Server behandelt Sitzungen anders als Desktop-Editionen. Seine Rolle RD Session Host führt sitzungsbasierte Desktops auf einer Maschine aus, um mehrere Sitzungen effizient zu nutzen. Eine Bot-Sitzung und Ihre eigene können daher nebeneinander bestehen. Wenn Sie RD Session Host für Mehrsitzungsbetrieb nutzen, braucht jeder verbindende Benutzer oder jedes Gerät eine RDS CAL. Diese Kosten gehören früh in die Planung, nicht erst ans Ende.

Die Größenanforderungen sind gering. Für einen Bot, der ein Formular durchklickt und eine Datei schreibt, würde ich nicht mehr als 1 vCPU und 2 GB RAM vorsehen. Für alles, was einen vollständigen Browser steuert, würde ich 2 vCPU und mindestens 4 GB einplanen, besonders bei mehreren Tabs: Chrome ist der aufwendige Teil dieser Last, nicht das darüberliegende Automatisierungswerkzeug.

Ein alter Rechner im Schrank erfüllt diese Anforderungen. Er muss eingeschaltet und angemeldet bleiben und darf nicht der Laptop sein, den Sie abends zuklappen. Ein gemieteter Server beseitigt diese Art von Problem: Er läuft unabhängig vom Laptop und konkurriert nicht mit Ihrer Arbeitssitzung auf dem Desktop.

Wenn Mieten besser passt als die Wartung einer eigenen Maschine, entspricht die Trennung recht klar zwei Produkten. Ein Windows VPS mit einem Desktop- oder Server-Image gibt einem bildschirmgesteuerten Bot eine dedizierte Windows-Umgebung. Ein Linux VPS deckt die Headless-Seite ab. Beide laufen unabhängig davon, ob Ihr Laptop geöffnet ist.

Welches Werkzeug wählen?

Wenn die Aufgabe im Browser oder in Dateien stattfindet und Sie Python schreiben können, ist RPA Framework die Wahl. Der Rest dieses Abschnitts behandelt Sonderfälle. Sobald eine Desktop-Anwendung ohne API beteiligt ist, ändert sich die Antwort: Sie benötigen ein Werkzeug für die Interaktion mit einem grafischen Desktop. Die Auswahl wird dadurch kürzer und älter.

Für Browser-, Datei- und Datenaufgaben auf einem Linux-Server wählen Sie RPA Framework. Es läuft headless, braucht auf einer Maschine ohne Bildschirm keine zusätzliche grafische Infrastruktur und veröffentlichte noch im Oktober 2026 eine neue Version. Dafür schreiben Sie Python oder Robot Framework statt ein Makro aufzuzeichnen. Das kostet am ersten Tag Arbeit, zahlt sich aber bei jeder Änderung der Zielanwendung aus.

Für eine ältere Windows-Anwendung ohne API wählen Sie UI.Vision, wenn Sie visuelle Automatisierung statt einer vollständigen Codebasis möchten, allerdings mit einer Bedingung. Es erhält dieses Jahr Commits, anders als manche Desktop-Optionen. Der AGPLv3-Teil seiner Doppellizenz verpflichtet bei Veränderung und Verteilung der quelloffenen Software zur Bereitstellung des Quellcodes. taskt ist die zweite Wahl: Sein Entwicklungszweig lebt, doch die letzte getaggte Veröffentlichung stammt aus Mai 2020. Diese Lücke zwischen Commits und veröffentlichten Versionen ist abzuwägen.

Für plattformübergreifende visuelle Automatisierung beliebiger Bildschirminhalte wählen Sie Oculix, die aktive Fortsetzung von SikuliX. Es arbeitet weiterhin vorrangig mit Bildern statt Selektoren, besitzt aber inzwischen eine IDE und aktive Veröffentlichungen anstatt nur eine Sammlung von Grundfunktionen zum Bildabgleich zu sein. Verwenden Sie es, wenn Pixel statt eines DOM oder Barrierefreiheitsbaums das Ziel sind. Betrachten Sie das archivierte SikuliX1-Repository als ältere Linie statt als gepflegtes Produkt.

TagUI wird aus gutem Grund weiter empfohlen. Seine Skriptsprache ähnelt einfachem Englisch, und die Lernkurve ist die flachste der sechs. Das Gegengewicht steht im README: AI Singapore hat die Wartung eingestellt, ebenso den Support, während Open-Source-Mitwirkende und die Community das Projekt weitertragen. Das bedeutet nicht, dass das Projekt aufgegeben wurde: Auf dem Standardzweig landen weiterhin Korrekturen, und das Repository ist nicht archiviert. Es ist aber auch kein kräftiger Aufschwung. Der rpa-Python-Wrapper auf PyPI liegt Jahre hinter dem Commit-Verlauf. Wählen Sie TagUI für eine Aufgabe, die Sie einfrieren können, nicht für eine Plattform, die Sie drei Jahre lang erweitern wollen.

OpenRPA ist schwieriger einzuschätzen. Es bietet echte Orchestrierungsfunktionen unter MPL-2.0, aber sein letzter Code-Commit und seine neueste getaggte Veröffentlichung stammen beide aus dem Juni 2025, und die einzige Aktivität im Repository seitdem besteht aus automatisierten Branches für Abhängigkeits-Updates. Das ist keine Aufgabe des Projekts, da nichts archiviert ist, aber veröffentlicht wurde eben auch nichts. Wägen Sie diese Lücke gegen die notwendige Betriebsdauer der Bots ab.

Wann ein dediziertes RPA-Werkzeug die falsche Antwort ist

Das stärkste Argument gegen all das kam von jemandem, der diese Arbeit ausführt. In einem r/selfhosted-Thread, den ein Betreiber zum Ausstieg aus einem kommerziellen RPA-Vertrag eröffnete, empfiehlt eine Antwort stattdessen Python und ein Automatisierungsframework wie Selenium. Mehr Entwicklungsaufwand, danach weniger Ausfälle und geringere laufende Gesamtkosten als bei der vom Kommentator verwendeten RPA-Software. Ein weiterer Kommentator im selben Thread stimmt unabhängig davon zu.

Der Maßstab ist Wartung. Wenn die Aufgabe jahrelang läuft, das Volumen hoch ist und Sie oder jemand in Ihrem Team eine kleine Codebasis pflegen können, schreiben Sie den Code. Selenium und Playwright kosten am ersten Tag mehr und am vierhundertsten weniger, weil ein selbst geschriebenes Skript auf Arten scheitert, die Sie verstehen können. Liegt der Zeithorizont bei Monaten oder programmiert niemand im Team, ist der kürzere Weg des RPA-Werkzeugs zu einem funktionierenden Bot seine Fragilität wert.

Die Ausgabe eines Recorders altert am schlechtesten. Ein Skript, das Ihre Klicks aufzeichnet, ist an das damals vorhandene Layout gebunden. Eine überarbeitete Seite oder ein verschobener Button bricht es daher auf eine Weise, die die Fehlermeldung selten erklärt. Manche sind gegenüber der Kategorie noch skeptischer: Ein Kommentator in einem r/rpa-Thread über Open-Source-Optionen nennt RPA neu verpacktes Scripting, das an nichttechnische Führungskräfte verkauft wird. Für eine eng genug begrenzte Aufgabe ist diese Beschreibung nicht unfair.

Auch ein Kategorienfehler sollte früh auffallen. Wenn die verbundenen Systeme APIs oder Webhooks anbieten, brauchen Sie gar keine RPA. RPA bedient eine Oberfläche, weil kein anderer Zugang existiert. Workflow-Automatisierung verwendet diesen Zugang direkt, lässt sich schneller entwickeln und ist deutlich weniger fragil. Das ist ein anderer Werkzeugsatz mit einer eigenen Kostenkurve. Die Lizenz von n8n und die Kosten des Selbsthostings sind dort zuerst zu klären. n8n, Node-RED, Apache Airflow, Kestra und Dagu stehen auf unserem Marketplace als Ein-Klick-Anwendungen bereit, wenn Sie heute eine starten möchten.

Die aktuelle Website von UI.Vision wirbt mit einer Anthropic-Computer-Use-Integration. Die Kategorie nimmt damit bereits Agenten auf, die einen Bildschirm steuern, indem sie darüber nachdenken, statt gespeicherte Bilder abzugleichen.

Häufig gestellte Fragen