AstronRPA: A Self-Hosted RPA Suite That Pairs Visual Workflows with an Agent Platform

What AstronRPA actually is, and who it targets

AstronRPA is a desktop RPA application that runs on Windows 10 and 11. It provides a visual designer for building automation workflows without writing code, aimed at both individual users and enterprises. The project describes itself as an enterprise-grade RPA desktop application, with 300+ pre-built atomic capabilities covering UI operations, data processing, and system interactions. The intended users are people who need to automate desktop software like WPS, Office, Kingdee, YonYou, and browsers such as IE, Edge, and Chrome. The core differentiator is the native integration with Astron Agent, iFlytek's agent platform, which lets RPA workflows be called from an agent and agent workflows be used inside RPA. That makes it more than a standalone RPA tool; it is positioned as the execution layer for an AI agent ecosystem. The repository is written in Java, but the RPA engine core is Python, and the frontend is built with Node.js. That mix is important because it affects deployment complexity.

The architecture: a client-server split with a Python engine

The repository layout shows a clear separation between a server and a client. The server is deployed with Docker and includes Casdoor for authentication, plus an API service that listens on port 32742 by default. The client is a desktop application that connects to that server via a remote address configured in conf.yaml. The client bundles a Python runtime, called python_core, which is compressed into a 7z archive during the build process. The build script copies a clean Python 3.13 installation, installs RPA engine dependencies, and then packages it alongside the frontend and desktop app. That design means the RPA execution engine is not a separate service; it runs inside the desktop client, which is why the client is Windows-only. The server handles orchestration, user login, and presumably scheduling, while the client does the actual UI automation. This is a common pattern for RPA, but it also means that every machine that runs automations needs the full desktop client installed, not just a lightweight agent.

Getting it running: Docker for the server, a build script for the client

The quick start guide gives concrete commands. For the server, you clone the repository, enter the docker directory, copy .env.example to .env, and edit one key: CASDOOR_EXTERNAL_ENDPOINT. Then docker compose up -d starts all services. After that, you check two URLs: the API health endpoint at http://{SERVER_IP}:32742/api/rpa-auth/user/login-check, which should return a JSON with code 900001 and message unauthorized if the connection works, and the Casdoor login page at port 8000. The client can be downloaded as a release package or built from source. The build script is build.bat, run from the project root. It accepts a --python-exe argument pointing to a clean Python 3.13 installation. The script copies that Python environment, compresses it, installs frontend dependencies, and produces an installable client. After installation, you edit resources/conf.yaml to set remote_addr to your server address and port. The documentation notes that the Python interpreter must be clean, without additional third-party packages, to keep the package size down. That is a practical constraint: you cannot reuse an existing Python environment that has packages installed.

Agent integration: the feature that sets it apart

The most distinctive aspect of AstronRPA is its bidirectional integration with Astron Agent. The README states that users can directly call RPA workflow nodes in Astron Agent, and also use Agent workflows in AstronRPA. That means an AI agent can trigger a desktop automation, such as filling a form in an ERP, and the RPA workflow can also invoke an agent for decision-making steps. This is not just an API hook; it is a designed collaboration model where the agent handles task reasoning and the RPA handles execution. The project also supports multiple trigger channels: direct execution, scheduled tasks, API calls, and MCP services. MCP, or Model Context Protocol, is a standard for connecting AI models to tools, so this suggests that AstronRPA workflows can be exposed as tools for any MCP-compatible agent, not just Astron Agent. However, the README does not give concrete examples of how to configure an MCP endpoint or how the agent call is structured. That is a gap in the documentation. If you plan to rely on agent-driven automation, you need to verify the actual API surface by looking at the repository code or the user documentation, because the README only promises the capability without showing a request-response example.

Enterprise features: scheduling, monitoring, and team sharing

AstronRPA includes enterprise modules that go beyond basic RPA. The README mentions terminal monitoring, scheduling modes, robot team sharing, and collaborative functions. There is a built-in excellence center and a team marketplace, which suggests a governance layer for managing automation assets across a team. The scheduling modes and API calls are important for production use, because they allow automations to run unattended or be triggered by external systems. The terminal monitoring likely gives administrators a view of which robots are running and their status. The team marketplace suggests a way to share components or workflows, which is useful for standardizing automation across an organization. However, the README does not describe the permission model in detail. It says there is process security and permission control, but not how roles are defined or how access to specific workflows is scoped. For an enterprise deployment, that is a key detail to investigate before adopting. The Casdoor integration implies that authentication is centralized, but authorization within the RPA platform is not documented in the material I have.

Limitations and failure modes you should know about

The biggest limitation is the platform constraint: the client only runs on Windows 10 and 11. There is no mention of macOS or Linux support for the execution client. If your organization uses a mix of operating systems, you cannot deploy the client on non-Windows machines. Another limitation is the dependency on a clean Python 3.13 environment for building the client. The build script copies that environment, so any third-party packages you have installed will bloat the package, and the documentation warns against that. The server deployment requires Docker and a multi-service setup, which is heavier than a single binary. The README also notes that the client needs at least 8 GiB of RAM, which may be high for some older desktop machines. A failure mode to watch: the login check endpoint returns an unauthorized code when deployment is correct, which is a clever health check, but if you misconfigure the CASDOOR_EXTERNAL_ENDPOINT, the server may start but authentication will fail. The documentation says to change the default port if you modify the configuration, but it does not explain all the places where that port appears. You need to read the docker/.env and the conf.yaml carefully to keep them in sync. Finally, the README is explicit that the primary support is for Windows desktop and web automation; if your automation targets are mobile apps or legacy terminal emulators, this is likely the wrong tool.

Alternatives and how they differ in approach

The most direct alternative is UiPath, a commercial RPA platform that also offers a visual designer and enterprise orchestration. The difference is that UiPath is a closed-source, cloud-centric product, whereas AstronRPA is open source and self-hosted. If your requirement is data privacy and on-premise control, AstronRPA's Apache-2.0 license and Docker-based server give you that without per-robot licensing fees. Another alternative is Robot Framework, which is an open-source automation framework but not a visual RPA tool. Robot Framework uses keyword-driven test syntax and runs on multiple platforms, including Linux and macOS. It does not come with a visual designer or an agent integration, so you would need to build those layers yourself. The key difference is that Robot Framework is a library and a command-line tool, while AstronRPA is a full application with a server and a desktop client. There is also the Astron Agent project itself, which is the companion agent platform. If you do not need the visual designer and only want to call automation from an agent, you might use Astron Agent with a different execution backend, but AstronRPA is the one that provides the RPA engine.

Maintenance and upgrade cost, and license implications

The project has a regular release cadence: v1.1.5 in January 2026 and v1.1.6 in February 2026, with nightly pre-releases in between. That suggests active development, but it also means you need to track releases for bug fixes and security updates. The server is deployed as a set of Docker containers, so upgrading likely involves pulling new images and running docker compose up again, but the README does not document a migration path. The client is a packaged desktop application, so each machine must be updated individually, unless you have a software distribution tool. The build process is complex enough that you probably want to use the pre-built release packages rather than building from source, unless you need to customize the engine. The license is Apache-2.0, which permits commercial use, modification, and distribution, but you must preserve the license notice. There is no mention of a separate enterprise license, so the open-source version appears to be the full product. However, the README references enterprise modules, which may have additional terms in the documentation. You should check the LICENSE file and any third-party notices, especially because the client bundles Python and other dependencies, each of which has its own license.

Editorial conclusion

Adopt AstronRPA if you need a self-hosted RPA platform with visual workflow design, agent integration, and enterprise controls like scheduling and team sharing, especially if you are already on Windows and comfortable running a multi-container Docker server. Do not adopt it if you require macOS or Linux clients, if you want a lightweight single-process tool, or if your automation targets are not Windows desktop or web applications. Before committing, verify the maturity of the agent integration path, confirm that the 300+ components cover your specific applications (WPS, Office, Kingdee, YonYou, and browsers are named, but not every ERP), and test the Casdoor-based authentication flow in your own environment, since the deployment depends on it. The project is actively released (v1.1.6 in February 2026), so check the changelog for breaking changes between versions, and note that the Apache-2.0 license permits commercial use but you should review how you handle any bundled third-party components.

Official sources

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