AstronRPA: Desktop-Automatisierung mit Agent-Anbindung unter Apache-2.0

Welches Problem AstronRPA adressiert und für wen

Viele Automatisierungsvorhaben scheitern nicht an der Logik, sondern an der Oberfläche. Fachanwendungen wie Kingdee oder YonYou, Office- und WPS-Dokumente, dazu Browser von IE bis Chrome: Diese Ziele lassen sich nicht über eine einzelne API ansprechen. AstronRPA setzt genau dort an und bietet laut README eine Abdeckung von Windows-Desktop-Anwendungen und Webseiten in einem Werkzeug. Der visuelle Designer erlaubt Low-Code- und No-Code-Entwicklung, sodass auch Fachanwender Workflows zusammenstellen können, nicht nur Entwickler. Die Zielgruppe reicht damit vom einzelnen Anwender bis zum Unternehmen mit mehreren Roboter-Teams. Wer heute Skripte pro Anwendung pflegt, bekommt hier eine gemeinsame Oberfläche für den gesamten Ablauf. Das ist der eigentliche Nutzen: ein Ort für prozessübergreifende Automatisierung statt einer Sammlung zusammenhangloser Makros.

Der Aufbau: Designer, Engine und Server getrennt

Das Repository beschreibt drei Teile, die getrennt betrieben werden. Der Client ist eine Desktop-Anwendung unter Windows 10 oder 11 mit mindestens 8 GiB RAM. Die RPA-Engine ist in Python 3.13 geschrieben, der Backend-Teil läuft auf Java ab JDK 8, die Oberfläche wird mit Node.js ab Version 22 und pnpm ab Version 9 gebaut. Der Server kommt als Docker-Compose-Stack, in dem unter anderem Casdoor für die Anmeldung sitzt. Diese Trennung hat Folgen für den Betrieb: Der Client führt die Automation aus, der Server verwaltet Anmeldung, Scheduler und Team-Funktionen. Fällt der Server aus, betrifft das die Verwaltung, nicht zwangsläufig die lokale Ausführung. Umgekehrt hängt die Anmeldung am Casdoor-Dienst, dessen externe Adresse über CASDOOR_EXTERNAL_ENDPOINT gesetzt wird. Die Agent-Anbindung läuft über die Plattform Astron Agent, in der sich RPA-Workflow-Knoten direkt aufrufen lassen und umgekehrt Agent-Workflows in AstronRPA nutzbar sind. Die Kopplung ist also in beide Richtungen angelegt, nicht als einseitiger Export.

Installation: Docker-Server und Windows-Client

Der Server wird aus dem Repository heraus gestartet. Nach git clone und cd astron-rpa wechselt man in das Verzeichnis docker, kopiert .env.example nach .env und setzt darin CASDOOR_EXTERNAL_ENDPOINT auf die eigene Adresse, im Beispiel http://{YOUR_SERVER_IP}:8000. Danach folgen docker compose up -d und docker compose ps. Der dokumentierte Prüfschritt ist der Aufruf von http://{YOUR_SERVER_IP}:32742/api/rpa-auth/user/login-check. Erscheint dort {"code":"900001","data":null,"message":"unauthorized"}, gilt die Bereitstellung laut README als korrekt. Wer statt dieser Fehlermeldung etwas anderes sieht, hat ein Konfigurationsproblem und nicht bloß eine fehlende Anmeldung. Der zweite Kontrollpunkt ist Port 8000: Zeigt der Browser die Casdoor-Anmeldeseite, läuft der Identitätsdienst. Für den Client gibt es zwei Wege. Empfohlen wird das Release-Paket, alternativ der Ein-Klick-Build über build.bat mit dem Schalter --python-exe und einem Pfad auf einen Python-3.13-Interpreter. Das README weist ausdrücklich darauf hin, dass dieser Interpreter eine saubere Installation ohne zusätzliche Pakete sein soll, um die Paketgröße klein zu halten. Nach der Installation wird in resources/conf.yaml im Installationsverzeichnis remote_addr auf die eigene Serveradresse mit Port 32742 gesetzt, skip_engine_start bleibt auf false.

Der Build-Skript-Pfad und seine Abhängigkeiten

Wer den Quellweg wählt, bindet mehr Werkzeuge ein, als die reine Laufzeit vermuten lässt. Neben Node.js, Python, Java, pnpm und UV listet die Tabelle 7-Zip zum Erstellen der Deployment-Archive und SWIG zur Verbindung von Python mit C- und C++-Code. Der Build-Ablauf umfasst sechs dokumentierte Schritte: Python-Umgebung nach build/python_core kopieren, Engine-Abhängigkeiten installieren, den Python-Kern nach resources/python_core.7z komprimieren, Frontend-Abhängigkeiten installieren, die Web-Anwendung bauen und die Desktop-Anwendung bauen. Fertig ist der Build, wenn die Konsole "Full Build Complete!" meldet. Diese Reihenfolge ist nicht beliebig: Die Engine-Abhängigkeiten müssen vor der Komprimierung stehen, sonst landet ein unvollständiges python_core.7z im Paket. Wer den Build in einer CI nachbaut, muss diese Stufen abbilden, statt einen einzelnen Build-Befehl zu erwarten. Für die meisten Anwender ist das Release-Paket daher der vernünftigere Weg; der Quellbuild lohnt sich vor allem, wenn eigene Komponenten ergänzt werden sollen.

Grenzen: Windows-Bindung und dünne Dokumentation im Repository

Die deutlichste Einschränkung steht im README selbst: Als Client-Betriebssystem wird Windows 10 oder 11 als primärer Support genannt. Wer Linux- oder macOS-Arbeitsplätze automatisiert, findet hier keine Grundlage. Der Server ist plattformunabhängig über Docker, der ausführende Teil ist es nicht. Ein zweiter Punkt betrifft die Dokumentation im Repository. Die README bricht nach dem Abschnitt Architect ab. Details zu den 300+ Komponenten, zum Berechtigungsmodell und zum Team-Marketplace stehen laut Verweisen in der externen Nutzerdokumentation, nicht im Repo. Wer vor der Einführung eine Bewertung anhand des Quellcodes vornehmen will, muss diese Lücke einplanen. Auch zur Fehlerbehandlung bei fehlgeschlagenen Läufen oder zur Wiederaufnahme nach Abbrüchen sagt das vorliegende Material nichts. Und der Hinweis auf einen sauberen Python-Interpreter ohne Drittpakete ist ein Trade-off: Er hält das Paket klein, erschwert aber den Fall, in dem ein Workflow eine zusätzliche Bibliothek benötigt. Ob und wie solche Abhängigkeiten nachinstalliert werden, lässt sich aus dem Material nicht beantworten.

Abgrenzung zu Selenium und Playwright

Der naheliegende Vergleich sind Browser-Automatisierungswerkzeuge wie Selenium oder Playwright. Der Unterschied liegt im Ansatz, nicht im Umfang. Selenium und Playwright steuern einen Browser und werden im Code eines Test- oder Skriptprojekts aufgerufen; die Ablauflogik, die Fehlerbehandlung und die Verteilung auf Rechner muss man selbst bauen. AstronRPA setzt eine Ebene höher an: Der Ablauf wird im visuellen Designer erstellt, die Komponenten sind vorgefertigt, und die Desktop-Anwendungen außerhalb des Browsers gehören zum Zielbild. Ein Workflow, der ein ERP-Fenster bedient und danach eine Webseite prüft, ist in einem Skript nur mit zusätzlichen Bibliotheken darstellbar. Umgekehrt gilt: Wer eine einzelne Web-Anwendung testet und die Ergebnisse in eine bestehende CI-Pipeline einspeisen will, fährt mit Playwright direkter, weil er keine Serverkomponente, keinen Casdoor-Dienst und keine Desktop-Laufzeit mitschleppt. Die Wahl hängt davon ab, ob das Ziel eine gepflegte Prozessbibliothek für Fachabteilungen ist oder ein Testfall in einem Entwickler-Repository.

Wartung, Lizenzen und der Blick auf die Versionen

Die Release-Historie zeigt einen regelmäßigen Rhythmus: v1.1.5 im Januar 2026, v1.1.6 im Februar 2026, dazwischen eine als Pre-Release markierte Nightly-Version v1.1.2-nightly. Wer produktiv geht, sollte die stabilen Releases verwenden und die Nightly-Version nur zum Ausprobieren. Der Server läuft als Docker-Compose-Stack, das heißt, ein Upgrade bedeutet im Regelfall, neue Images zu ziehen und den Stack neu zu starten. Der Client auf den Arbeitsplätzen wird separat aktualisiert, was bei vielen Rechnern der aufwendigere Teil ist. Die Lizenz ist Apache-2.0, also eine permissive Lizenz mit Patentgewährung und ohne Copyleft-Pflicht für eigene Änderungen. Das Repository enthält eine LICENSE-Datei. Zu beachten ist, dass der Stack Casdoor als separaten Dienst einbindet, der eigene Lizenzbedingungen mitbringt. Wer den Stack kommerziell weiterverbreitet, sollte diese Abhängigkeit prüfen. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass die Apache-2.0-Lizenz des Hauptprojekts nicht automatisch für jeden eingebundenen Dienst gilt.

Redaktionelles Fazit

Wer Windows-Desktops und Web-Oberflächen ohne Cloud-Zwang automatisieren will und einen eigenen Server betreiben kann, findet hier einen Apache-2.0-lizenzierten Stack mit breiter Anwendungsabdeckung. Wer ausschließlich Linux- oder macOS-Clients braucht, ist hier falsch. Vor dem Rollout zuerst den Login-Check auf Port 32742 gegen die eigene Serveradresse prüfen und danach remote_addr in resources/conf.yaml setzen, sonst startet der Client gegen die falsche Instanz.

Offizielle Quellen

1. iflytek/astron-rpa on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases