Open-source RPA: which tools to use, and what the free licence leaves out

The short version

• Open-source RPA removes the licence fee but not the cost of building, hosting and maintaining bots.
• Robot Framework, Playwright and Selenium are widely used open-source foundations for automating work in a web browser.
• Commercial RPA platforms bundle orchestration, credential vaults and audit logs. With open source, you assemble those yourself.
• Screen-driven bots break when the interface changes, whichever tool drives them, so use an API wherever one exists.
• Check an automation project's licence file and release history before building on it, because 'open source' is used loosely.

Which open-source RPA tools are worth evaluating?

Start with Robot Framework, Playwright and Selenium. Add OpenRPA or TagUI if you need desktop automation or a lower-code way to write scripts. Between them they cover the two things RPA does: driving a web browser and driving a desktop application, the way a person at a keyboard would.

Robot Framework is a Python-based automation framework with a keyword syntax that people outside engineering can read. The open-source RPA Framework libraries extend it with the pieces process work needs, including Excel, PDF, email and Windows desktop handling. Playwright and Selenium are browser automation libraries. They are not sold as RPA, but browser-based RPA is, underneath, browser automation with a scheduler and some error handling wrapped around it.

OpenRPA provides a recorder and a visual designer for Windows desktop work. TagUI uses a plain-language script format and handles both web and desktop steps. Both have smaller communities than the first three, so look at when each last shipped a release before you depend on it.

How do the open-source RPA options compare?

Is open-source RPA cheaper than UiPath or Power Automate?

It is cheaper to license and not always cheaper to run. Open source removes the per-bot or per-user fee. It does not remove the engineering time to build, host, monitor and repair each bot, and that time is the figure to compare against the licence.

Commercial vendors publish list prices you can check. Microsoft lists prices for its Power Automate Premium and Process plans, and UiPath lists a price for its Basic tier. Read the current figure from the vendor's own page when you budget. List prices change, and larger agreements are negotiated.

The other side of the comparison is people. The US Bureau of Labor Statistics publishes a median annual wage for software developers. Take the share of an engineer's year your bots will consume, for the initial build and for every month of upkeep after it, and set that against the licences you would otherwise buy.

Open source tends to come out ahead in two situations. The first is when you already employ engineers who write automation code, so one more script costs little. The second is when you run enough bots that per-bot licensing adds up faster than maintenance does. It comes out behind when one person in operations wants one task automated and nobody will own the bot afterwards.

What do you have to build yourself with open-source RPA?

You build the control layer. Open-source tools give you the bot itself. Much of what a commercial platform charges for is everything around it: scheduling, a credential vault, work queues, retries, logs with screenshots, and a dashboard showing what ran and what failed.

None of this is exotic. Schedulers, secrets managers and logging stacks are standard, and many are open source too. The work is in wiring them together and keeping them running, which is why open-source RPA suits teams that already operate software in production.

What does a production RPA bot need besides the bot?

• •A scheduler that starts runs, stops two copies of the same bot colliding, and queues work items.
• •A secrets store for the bot's logins, so passwords are not sitting in a script or a spreadsheet.
• •Logs that capture the step, the input and a screenshot at the moment of failure.
• •Retries for transient errors, and a hard stop for errors a retry would make worse, such as a half-submitted payment.
• •Alerts that reach a person who can act, during the hours the bot runs.
• •A dedicated machine or virtual desktop, with its own service account and only the permissions the task needs.
• •Version control, and a test run against a staging copy of the target system before every change.

Why do RPA bots break so often?

They depend on a screen that nobody promised to keep stable. A bot finds a field by its label, position or an underlying selector. When the application renames that field, moves a menu or adds a pop-up, the bot either stops or, worse, clicks the wrong thing and carries on.

Open source does not change this. The fragility belongs to screen automation, whichever tool drives it. What changes is who fixes it. With a commercial platform you have a vendor to call. With open source the fix is yours, so the person who understands the bot needs to still be around.

Write bots defensively. Prefer stable identifiers to screen coordinates. Wait for an element to be ready rather than sleeping for a fixed time. Confirm the result of each important step, such as a record actually saving, instead of assuming the click worked. Make every run safe to repeat, so a retry cannot create a second invoice.

When should you use an API or an AI agent instead of RPA?

Use an API whenever the system offers one, and keep RPA for the systems that do not. An API is a contract: it returns structured data and fails with an error code. A screen is a presentation layer that can change in any release.

A sensible order of preference is a native API first, then an integration tool built on that API, then browser automation, and desktop screen automation last. Check this before choosing a tool. A process that looks like screen work is sometimes API work that nobody has looked into.

AI agents solve a different problem. RPA follows fixed rules on structured inputs. An agent built on a language model can read an email, classify a document or choose between several paths. That flexibility makes its behaviour less predictable, so keep deterministic steps deterministic and use the model only where a rule cannot be written. Log what it decided, and send uncertain cases to a person.

Is open-source RPA safe to use with business systems?

It is as safe as the way you run it. A bot is a user with real credentials and real permissions, so treat it like one: a named account, the minimum access the task needs, passwords held in a secrets store, and a log of every action it takes.

The risk that is specific to open source is the software supply chain. Your bots depend on packages pulled from public registries, so pin versions, review updates before deploying them, and keep a list of what each bot depends on. This is ordinary engineering hygiene. RPA projects that start outside an engineering team are the ones that tend to skip it.

How do you pilot an open-source RPA tool?

Pick one process that is high-volume, rule-based and stable. Automate it end to end, including failure handling, and run it alongside the manual process before you switch over. One process done properly tells you more about a tool than five demos.

What are the steps in an open-source RPA pilot?

1. Write the process down step by step, including the exceptions people handle without thinking.
2. Check each system for an API, and replace screen steps with API calls wherever you can.
3. Match the tool to what is left: a browser library for web applications, a desktop tool for Windows applications.
4. Build failure handling before polishing the happy path: logs, screenshots, retries and alerts.
5. Run the bot alongside the manual process long enough to see month-end, holidays and unusual inputs.
6. Name the person who owns the bot after launch. If nobody will, stop the project here.