AstronRPA: A Self-Hosted, Agent-Ready RPA Suite from iFlytek

What AstronRPA automates, and who is expected to run it

AstronRPA targets a specific kind of automation: desktop software and web pages on a Windows machine. The README lists WPS and Office, financial and ERP systems such as Kingdee and YonYou, and the IE, Edge and Chrome browsers. That list is the product's centre of gravity. This is not a headless scraper or a Linux cron wrapper. The unit of work is a workflow that drives a GUI, and the intended author is someone using a visual designer rather than writing code, since the project describes low-code and no-code development through drag-and-drop as a first-class capability.

The second audience is the operations side. The README describes an excellence centre and team marketplace, terminal monitoring, scheduling modes and robot team sharing. Those are control-plane features, not editor features. If you only need one person's laptop to click through a form, most of the repository is overhead. If you need several people sharing robots across departments with permissions attached, the shape of the project starts to make sense.

The third audience is agent builders. The project states that Astron Agent is its native agent platform, and that RPA workflow nodes can be called inside Astron Agent while agent workflows can be used inside AstronRPA. That two-way arrangement is the reason the repository is tagged with agent and mcp topics. Treat the RPA suite as the execution layer and the agent as the reasoning layer, and the design intent is clear.

The client, server and engine split

The repository layout tells you more about the architecture than the README prose does. At the top level there are backend/, engine/, frontend/, docker/, resources/, docs/ and build.bat. The engine directory is the Python component, and the README states Python 3.13.x is the RPA engine core. The backend is Java, and the README lists JDK 8+ as the backend runtime. The frontend is the Node.js side, requiring Node.js 22 or later and pnpm 9 or later. Three languages, three toolchains, one product.

Deployment is split in two. The server runs through Docker Compose from the docker directory, and it includes Casdoor for identity, reachable on port 8000 by default. The application API listens on port 32742 by default. The client is a Windows desktop application that you either download as a release package or build yourself, and it talks to the server through an address set in resources/conf.yaml. That file also carries a skip_engine_start flag, which implies the packaged client can start the local engine itself rather than relying on a remote one.

The build script reveals the packaging strategy. build.bat copies a Python installation into build/python_core, installs the engine dependencies, compresses that directory into resources/python_core.7z, then installs frontend dependencies, builds the frontend web application and builds the desktop application. The README asks for a clean Python installation without extra third-party packages, explicitly to keep the archive small. That is a reasonable trade-off, but it means the Python interpreter you point at is effectively frozen into the shipped client.

Installing the AstronRPA server with Docker

The README presents the Docker path as the recommended quick deployment for the server. You clone the repository, move into the docker directory, copy the environment template, edit one value, and start the stack. The Casdoor external endpoint must be set to an address the browser can reach, using your server IP and port 8000.

git clone https://github.com/iflytek/astron-rpa.git
cd astron-rpa
cd docker
cp .env.example .env

After copying, open .env and set the Casdoor endpoint. The README gives this example line, with 8000 as the default port.

CASDOOR_EXTERNAL_ENDPOINT="http://{YOUR_SERVER_IP}:8000"

Then start everything and check what came up.

docker compose up -d
docker compose ps

Verification is two browser visits. First, the auth check endpoint on port 32742. The README states that seeing `{"code":"900001","data":null,"message":"unauthorized"}` means the deployment is correct, which is unusual advice but unambiguous: an authorization failure here is the success signal. Second, port 8000 should show the Casdoor login page. For production hardening the README points to docker/QUICK_START.md rather than repeating the steps.

Building the AstronRPA client and pointing it at your server

The README recommends downloading the latest release package, and only falls back to building from source when you need to. That ordering is sensible, because the build chain is long. The dependency table lists Node.js 22 or later, Python 3.13.x, JDK 8+, pnpm 9 or later, UV 0.8 or later, 7-Zip and SWIG. SWIG is there to connect Python with C and C++, which hints at native bindings inside the engine.

If you do build, prepare a Python 3.13.x installation directory first. The README notes the script copies that directory to create python_core, and warns that the interpreter should be a clean installation without additional third-party packages to keep the package size down.

./build.bat --python-exe "C:\Program Files\Python313\python.exe"

Running build.bat with no arguments uses the default configuration when Python is in the default path. The README says the build is successful when the console displays "Full Build Complete!". The documented sequence is: detect or copy the Python environment to build/python_core, install engine dependencies, compress the Python core to resources/python_core.7z, install frontend dependencies, build the frontend web application, then build the desktop application.

After installing the packaged client, the server address lives in resources/conf.yaml in the installation directory. The README shows this shape, with 32742 as the default port.

remote_addr: http://YOUR_SERVER_ADDRESS:32742/
skip_engine_start: false

Set remote_addr to your server and leave skip_engine_start false unless you have a reason to point the client at a remote engine. This file is the single link between a client installation and a server, so it is the first thing to check when a client cannot reach anything.

Where AstronRPA is the wrong tool

The clearest limitation is in the system requirements. The client operating system is Windows 10 and 11, described as primary support, and the RAM floor is 8 GiB. There is no documented macOS or Linux client. If your automation estate is Linux servers running scheduled jobs, this project does not address it, and no amount of Docker on the server side changes that, because the server is the control plane and the client is what drives the desktop.

The second constraint is the build surface. Three language toolchains, a native-code bridge through SWIG, and a packaging step that freezes a Python interpreter into a 7z archive. Building a client is not a five-minute operation, and the README itself steers you to the release package first. Teams that cannot use a prebuilt binary and cannot maintain this toolchain should treat that as a real cost, not a footnote.

The third is scope. The README describes enterprise modules, terminal monitoring and scheduling, but the repository also carries an AGENTS.md file and a Makefile that includes makefiles/git-pr.mk with a warning that PR operations require repository write permissions. That is developer tooling for people working on the project, not product features. Do not read the presence of a git-pr makefile as evidence of anything about the RPA runtime. Finally, the README does not document rollback behaviour for a failed client upgrade, and it does not state what happens to in-flight workflows when the server is restarted. Those are questions to answer before production use, not after.

AstronRPA against OpenRPA and scripted Python

OpenRPA is the closest comparison in the search data around this project, and the difference is architectural. OpenRPA is a desktop automation client built around Windows workflows with its own designer and a node-based execution model. AstronRPA adds a server tier that OpenRPA does not require: Docker Compose, Casdoor identity on port 8000, an API on port 32742, and a client that reads a remote_addr from conf.yaml. That server tier is what makes scheduling, team sharing and permission control possible, and it is also what makes a single-laptop deployment heavier than it needs to be.

The second alternative is writing the automation in Python directly. For a one-off task, a script is faster to write and has no server, no Casdoor, no 7z-packaged interpreter and no build.bat. The trade-off is everything the visual layer buys: non-developers can author and debug workflows, the 300+ pre-built atomic capabilities described in the README cover UI operations and data processing without you writing them, and the same workflow can be triggered by schedule, API or MCP service. Choose scripting when the task is narrow and you own the code. Choose AstronRPA when the people maintaining the automation are not the people writing the Python.

The third comparison is Astron Agent, which is not really a competitor. It is the reasoning layer the README pairs with this execution layer. Using one without the other is a legitimate configuration; the bi-directional call support is an option, not a requirement.

Maintenance, licensing and what to verify

The repository is not archived, and the last push was on 2026-09-04. The most recent release listed is v1.1.6 from 2026-02-25, preceded by v1.1.5 on 2026-01-29 and a v1.1.2-nightly pre-release on 2025-12-01. Two stable releases roughly a month apart in early 2026, then a gap to the September push. That pattern suggests work continues on the main branch between tagged releases, but it also means you should not assume a release cadence. Pin to a tag and read the release notes rather than tracking main.

The licence is Apache-2.0, and the repository carries both a LICENSE and a NOTICE file. Apache-2.0 permits commercial use and modification, and the NOTICE file typically carries attribution requirements. Read both before redistributing a modified client, especially if you ship it to customers rather than using it internally. That is a factual description of the licence family, not legal advice, and the NOTICE file is the document to check.

Upgrade cost is asymmetric. The server side is a Docker Compose stack, so upgrading means pulling new images and restarting, with Casdoor configuration in .env to preserve. The client side is a Windows installation whose conf.yaml must survive the upgrade, and the README does not describe a migration path for that file or for saved workflows. Verify first that your conf.yaml settings persist across an upgrade, that your workflows still open in the new client, and that the server version you deploy matches the client release you distribute.

Editorial conclusion

Adopt AstronRPA if your automation targets are Windows desktop applications and browsers, you need the control plane on your own hardware, and you can accept a client build chain of Node.js 22, Python 3.13, JDK 8+, pnpm 9, UV 0.8+ and SWIG. Do not adopt it if your endpoints are macOS or Linux, since the README lists Windows 10/11 as primary support, or if you want a hosted service with no server to run. Before committing, clone the repository, run docker compose up -d in the docker directory and confirm the login-check endpoint returns the unauthorized JSON, then build the client with build.bat and check that resources/conf.yaml points at your server address.

Frequently asked questions

Official sources

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