RPA Framework: Robot Framework libraries for RPA, installed with pip
Collection of open-source libraries and tools for Robotic Process Automation (RPA), designed to be used with both Robot Framework and Python
At a glance
- What is it?
- RPA Framework is a collection of open source Python libraries that plug into Robot Framework. It installs from PyPI, splits into per-domain packages, and is sponsored by Robocorp, which shapes both its strengths and its limits.
- Who is it for?
- Adopt RPA Framework if your automation already lives in Robot Framework or Python and you want browser, PDF, OCR, cloud and desktop libraries under one Apache-2.0 licence. Skip it if you need a visual designer or a scheduler, because it ships neither.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 21 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What RPA Framework actually solves for robot developers
Building a software robot means gluing together a dozen unglamorous capabilities: opening a browser, reading a PDF, calling an AWS bucket, hashing a token, waiting for a desktop window. Each one has its own Python library with its own API style and its own dependency conflicts. RPA Framework's answer is a set of libraries that expose those capabilities through Robot Framework keywords and through plain Python, so a robot author writes one consistent vocabulary instead of five.
The audience is narrow and specific. You need to be comfortable with Robot Framework's tabular test syntax or with Python, because there is no drag-and-drop designer in this repository. The README describes the goal as offering "well-documented and actively maintained core libraries for Software Robot Developers", and the library table is the real product: Archive, Browser.Selenium, Browser.Playwright, Calendar, Cloud.AWS, Cloud.Azure, Cloud.Google, Crypto, and more. If you are evaluating RPA tools generally, this is not a platform. It is the library layer that a platform would sit on.
How the packages and libraries fit together
The repository is a monorepo. Top-level entries include packages/, docs/, examples/, invocations/, tools/ and a pyproject.toml that defines a metapackage named rpaframework-meta. That metapackage does not contain code; it is a dependency list. Installing it pulls in rpaframework, rpaframework-aws, rpaframework-google, rpaframework-hubspot, rpaframework-openai, rpaframework-recognition, rpaframework-windows, robotframework-browser and robotframework.
The library table in the README documents the split. A column marked x means the library ships inside the main rpaframework package; a column naming a package means you install that package separately. RPA.PDF is marked x,pdf, so it is available both ways. RPA.Cloud.Google is only in rpaframework-google. RPA.Assistant is only in rpaframework-assistant. Two packages, rpaframework-core and rpaframework-recognition, are support packages that "alone do not contain any libraries", so installing them gives you nothing to call.
Browser.Playwright is the exception that proves the rule: the table marks it "special (more below)", meaning it is not delivered through the same dependency chain as the Selenium-based browser library. The README defers the detail rather than restating it, which is worth reading in full before you pick a browser backend.
Installing RPA Framework with pip and running a first robot
The README points to PyPI at pypi.org/project/rpaframework/ and to Robocorp's page on installing Python package dependencies. The metapackage requires Python >=3.10,<3.14, which is a hard boundary: 3.14 is excluded, and so is anything below 3.10.
The dependency list in the repository's pyproject.toml is the authoritative install target. The metapackage declares rpaframework>=31.0.0, rpaframework-aws>=7.0.0, rpaframework-google>=11.0.0, rpaframework-hubspot>=3.0.0, rpaframework-openai>=4.0.0, rpaframework-recognition>=7.0.0, rpaframework-windows>=10.0.0, robotframework-browser>=17.2.0 and robotframework>=5.0.1.
requires-python = ">=3.10,<3.14"
dependencies = [
"h11>=0.16.0",
"robotframework-browser>=17.2.0",
"rpaframework>=31.0.0",
"rpaframework-aws>=7.0.0",
"rpaframework-google>=11.0.0",
]Individual packages are released separately. The release list shows rpaframework-pdf at 11.0.2 and rpaframework-recognition at 8.0.2, both dated 2026-08-23, which is what you would pin if you only need document handling.
The libraries are then imported by name in a Robot Framework suite. The README's library table gives those names, such as RPA.PDF and RPA.Archive, and the repository ships a worked example under examples/manipulating-pdf/ alongside examples/README.md. The README's own contents block shows the convention it uses for local tables:
.. contents:: Table of Contents
:local:
:depth: 1What you should see is a Robot Framework run that loads the libraries named in the table without an import error. The keyword signatures themselves are in the library documentation rather than the README, so check the docs site before writing anything longer than this.
Where RPA Framework stops being the right tool
The metapackage's dependency list is the first warning. Installing rpaframework-meta brings AWS, Google Cloud, HubSpot, OpenAI, Windows and browser automation whether or not your robot touches any of them. In a locked-down environment that is a large dependency surface, and the pyproject.toml carries an override-dependencies block pinning versions of h11, protobuf, pillow, cryptography, requests, PyJWT, pypdf, pyasn1, lxml, urllib3, msgpack, setuptools and httplib2. Those overrides exist because the transitive graph otherwise resolves badly. If your project pins any of those libraries independently, expect to reconcile the two.
The second limit is scope. RPA Framework is libraries, not a runtime. Control Room and the Developer Tools are Robocorp products referenced in the README, not parts of this repository. There is no scheduler, no queue, no credential vault and no visual editor here. If your team's actual problem is "we need a place to run and monitor robots", the Python packages do not answer it.
Third, platform reach. RPA.Windows is a distinct package, rpaframework-windows, and the pyproject.toml includes pyobjc build dependencies for macOS, so the desktop side is not uniform across operating systems. A robot that drives native Windows applications will not behave the same way on Linux, and the README does not promise otherwise.
How it compares with Robot Framework alone, and with OpenRPA
Robot Framework on its own is a generic test automation framework. It gives you the syntax, the runner and the reporting, and nothing about PDFs, cloud APIs or desktop windows. RPA Framework is the layer above it: the same runner, plus libraries that a business-process robot needs. The practical difference is that a Robot Framework project doing RPA work ends up writing and maintaining its own keyword libraries for exactly the things RPA.PDF, RPA.Cloud.AWS and RPA.Windows already provide. Choosing RPA Framework is choosing to depend on someone else's keyword surface instead of your own.
OpenRPA sits at the opposite end. It is a visual, Windows-centric automation tool where flows are built by recording and dragging rather than by writing keywords in a text file. That is a real difference in who can maintain the automation: an OpenRPA flow is editable by someone who does not read Python, while a Robot Framework suite is not. The trade is portability and reviewability. Robot Framework suites live in version control as plain text, which is why teams with existing Python skills tend to prefer this side of the line.
Maintenance, releases and the Apache-2.0 licence
The repository is not archived and the last push was on 2026-08-29. Releases are frequent and per-package: the three most recent are rpaframework-sema4ai 1.1.1, rpaframework-recognition 8.0.2 and rpaframework-pdf 11.0.2, all published on 2026-08-23. There is an RSS feed at rpaframework.org/releases.xml for tracking them, and the README links release notes at rpaframework.org/releasenotes.html.
The upgrade cost is the interesting part. Because the project is split into independently versioned packages, a new rpaframework-pdf does not force a new rpaframework. That is good for stability and awkward for support: a bug report is only meaningful with the version of each sub-package attached. The metapackage's minimum constraints, such as rpaframework>=31.0.0 and rpaframework-recognition>=7.0.0, are floors rather than pins, so a fresh install resolves to whatever is current that day.
Licensing is Apache-2.0, stated in the README and in the LICENSE file at the repository root. That permits commercial use and modification and requires attribution and notice retention. It says nothing about the Robocorp hosted products, which have their own terms; the licence here covers the libraries. This is a description of what the repository states, not legal advice, and a legal review is the right place to settle obligations.
Editorial conclusion
Adopt RPA Framework if your automation already lives in Robot Framework or Python and you want browser, PDF, OCR, cloud and desktop libraries under one Apache-2.0 licence. Skip it if you need a visual designer or a scheduler, because it ships neither. Before committing, verify the Python version range (>=3.10,<3.14), which of the sub-packages you actually need rather than the metapackage, and whether the libraries you depend on are the ones Robocorp is still releasing; the most recent releases in the repository are rpaframework-sema4ai 1.1.1, rpaframework-recognition 8.0.2 and rpaframework-pdf 11.0.2, all dated 2026-08-23.
Frequently asked questions
How do you install RPA Framework?
Install from PyPI with pip, either the metapackage rpaframework-meta for the full library set or an individual package such as rpaframework-pdf or rpaframework-recognition. The metapackage requires Python >=3.10 and below 3.14.
What is RPA Framework?
It is a collection of open source libraries and tools for Robotic Process Automation, designed to be used with both Robot Framework and Python. The README describes the goal as offering well-documented core libraries for software robot developers.
What is the difference between RPA Framework and Robot Framework?
Robot Framework is the automation framework that provides the syntax and runner. RPA Framework is a set of libraries built to be used with it, covering tasks such as PDF reading, browser control, cloud services and Windows automation through Robot Framework keywords.
What is Robot Framework used for?
The README does not describe Robot Framework's general uses beyond the fact that RPA Framework is designed to be used with it and requires robotframework>=5.0.1 in the metapackage. Consult the Robot Framework project itself for its own scope.
What is an RPA in automation?
The README does not define RPA in general terms; it points readers to Robocorp Documentation to learn more about it. What this repository covers is the library layer used to build software robots.
Community notes