The Opentrons repository holds the API, the desktop app and the designer for one lab robot platform
Software for writing protocols and running them on the Opentrons Flex and Opentrons OT-2
At a glance
- What is it?
- The Opentrons monorepo contains the Python API used to write lab protocols, the OT App desktop client, the Protocol Designer, the shared data library and the hardware support for the OT-2 and Flex robots. It suits a lab that wants to automate pipetting with readable protocol code, and it is a single repository spanning several products with different release trains.
- Who is it for?
- Opentrons fits a lab that wants to automate experiments with protocol code that reads like a notebook rather than like a robot script, and the API, the app and the designer are all in one place with shared labware data between them. It does not fit a team that wants to drive third-party instruments with the same protocol, because the API targets Opentrons hardware specifically.
- 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 3 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 October 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What the platform is for
Opentrons makes robots for biologists, and the stated mission is to provide the scientific community with a common platform to easily share protocols and reproduce each other's work.
The robots automate experiments that would otherwise be done by hand, allowing users to spend more time pursuing answers to what the README calls the 21st century's most important questions, and less time pipetting.
That framing matters for how the software is designed. The unit of work is a protocol, and a protocol is meant to be shared and reproduced by other labs, which means the representation of what the robot does has to be legible and portable rather than clever.
The repository contains the source code for the Opentrons API and the OT App, and the README invites contributors to explore it, hack it and build upon it.
Three products come out of this one repository, and each has its own documentation and its own source directory. The Opentrons API is described as a simple framework designed to make writing automated biology lab protocols easy, with the source under ./api. The Opentrons App is the desktop application for uploading a protocol, calibrating positions and running an experiment, with the source under ./app. The Opentrons Protocol Designer is the graphical tool for creating a protocol to run on the robot, with the source under ./protocol-designer.
The repository description says the software is for writing protocols and running them on the Opentrons Flex and the Opentrons OT-2, so those are the two robot platforms in scope.
The API design goal, and what two lines of code look like
The API's design goal is stated with unusual clarity: it was designed in a way the team hopes is accessible to anyone with basic computer and wetlab skills, and as a bench scientist you should be able to code your automated protocols in a way that reads like a lab notebook.
The example in the README is two lines.
pipette.aspirate(location=trough['A1'], volume=30)
pipette.dispense(location=well_plate['A1'], volume=30)That example tells the Opentrons OT-2 to pipette 30 microlitres of liquid from a trough to a well plate.
The vocabulary is the vocabulary of the bench. You aspirate and dispense, you name locations by their plate and well identifiers, and you pass a volume in microlitres. There is no motion planning, no coordinate system to learn and no gantry to think about. The instrument and the labware abstractions absorb all of that.
That is a real design constraint with a cost. A protocol written this way only runs on hardware that shares those abstractions, so the API is deliberately not a general-purpose robot interface. For an Opentrons lab that is exactly right, and for anyone hoping to write one protocol and run it on several different instruments, it is a wall.
The documentation for the API is at docs.opentrons.com and the source is in the ./api directory of the repository.
The App, the Designer and the shared data library
The Opentrons App is the desktop client, and the README describes it as the place to easily upload a protocol, calibrate positions, and run your experiment from your computer. It is downloadable from opentrons.com/ot-app, documented at support.opentrons.com, and its source is under ./app.
The screenshot caption in the README describes the interface in detail, which tells you what the app is actually for. It shows a sortable list of four protocols on the Protocols page, where each entry shows a small map of the OT-2 deck and lists the protocol's name, pipettes and modules used, and when the protocol was updated.
So the app is a protocol library and runner, and the deck map plus the hardware inventory per protocol is the metadata that makes a shared protocol meaningful to someone who has never run it.
The Protocol Designer is the graphical counterpart, at designer.opentrons.com, with the source under ./protocol-designer. It exists because the API's readability advantage disappears for scientists who do not code, and because a protocol has to be built and verified visually before it runs on real hardware.
Underneath both is a shared data layer, and the JavaScript workspace list in package.json shows it: api-client, app, app-shell, app-shell-odd, components, discovery-client, labware-designer, labware-library, opentrons-ai-client, protocol-designer, protocol-visualization, react-api-client, shared-data, step-generation and usb-bridge/node-client.
shared-data and labware-library are the ones worth noting for anyone building on top, because they are the canonical definitions of labware and deck layout that the app, the designer and the API all have to agree on.
A monorepo spanning several products and several release trains
The repository root is wide, and the directory list is the best evidence of what the project actually is.
Alongside api/, app/, app-shell/ and protocol-designer/ there is api-client/, react-api-client/, discovery-client/ and components/ on the JavaScript side, shared-data/ and labware-library/ for the shared definitions, and labware-designer/ and protocol-visualization/ for the design tools.
Then the parts that are not the product. There is hardware-testing/, hardware/, e2e-testing/, js-package-testing/, package-testing/ and performance-metrics/, which is a list of test and measurement strategies rather than one. There is abr-testing/, which stands for the testing lab setup the Opentrons team runs against physical robots. There is audit-server/, auth-server/ and key-server/, which is server-side infrastructure for the hosted product rather than for the robot. And there is opentrons-ai-client/ and opentrons-ai-server/, which are the newer AI features.
The build system is a mix too. The package.json declares pnpm workspaces with [email protected] as the package manager and Node >=22.22.0 as the engine. But there is a Makefile, external.mk and external.desc for the Python side, and a Config.in which is the Autoconf pattern, so the repository contains a Python package built with the older GNU toolchain alongside a JavaScript monorepo built with pnpm.
That split has a consequence for versioning, and the release list shows it. The listed releases are v10.1.0, labelled robot stack version 10.1.0, from 2026-10-15, then two releases with build-style names, 0-vacuum-module-qc-26.10.14 and 0-vacuum-module-qc-26.10.13. So there is a numbered robot stack version and a separate set of dated build tags for other components.
A single version number does not describe this tree, and that is worth knowing before you pin anything.
Contributing and the documentation you are expected to read
The contributing section is short and sets the tone.
The first step is filing a bug report, with the promise that the team will fix these as quickly as they can and that they appreciate help uncovering bugs in the code.
The second is submitting a pull request with new features on a branch of the API or the App, and the note that the team will reach out to talk about integration testing and launching it into the product.
That second half is the important part and it is easy to miss. A pull request to the API or the App is not just a code contribution, it is a change to a product that runs laboratory hardware, and the team wants to talk about how it gets integrated and tested before it ships. The existence of abr-testing/ and hardware-testing/ at the repository root is the physical counterpart to that sentence.
For setup, the README points to the contributing guide at ./CONTRIBUTING.md, and the repository root carries DEV_SETUP.md, DOCKER.md, OT2_ARCHITECTURE.md and RELEASING.md. There is a docker-compose.yml and a Dockerfile for running pieces of it in containers, and a NOTICE file alongside the LICENSE.
The LICENSE is Apache-2.0, and the README's own framing of the project as something to explore, hack and build upon is consistent with that licence and with the openness the mission implies.
Where Opentrons is the wrong choice
Four cases argue against it.
The first is a lab that needs to drive instruments from several vendors with one protocol. The API's readability comes precisely from being specific to Opentrons hardware and labware, and a protocol that talks about a trough and a well plate and a pipette does not generalise to a liquid handler with a different deck model. Writing an abstraction above the Opentrons API to expose a common protocol model across vendors is a project in itself.
The second is a workflow where the bottleneck is not pipetting. The pitch is that automating the liquid handling frees scientists to spend more time on the science, but if the experiment's limiting factor is sample prep, instrument time or analysis, the robot does not help, and the capital cost is significant.
The third is a team that wants to run the software somewhere other than a supported robot. The API is a robot control library, not a general laboratory automation framework, and the desktop App is built around the OT-2 and Flex hardware and their calibration model.
The alternative in the same direction is a general liquid handling platform with its own SDK, or a vendor-neutral automation interface layered on top of several robots. The difference in approach is that Opentrons optimises for the shared protocol, which is the whole point of the project: a protocol written in one lab runs in another, and the abstraction that makes that possible is the one that stops it from being portable across vendors. If your requirement is reproducibility across labs with the same robots, Opentrons is a strong answer. If your requirement is one protocol across mixed hardware, it is the wrong abstraction and you would be fighting it.
Editorial conclusion
Opentrons fits a lab that wants to automate experiments with protocol code that reads like a notebook rather than like a robot script, and the API, the app and the designer are all in one place with shared labware data between them. It does not fit a team that wants to drive third-party instruments with the same protocol, because the API targets Opentrons hardware specifically. Read the contributing guide and DEV_SETUP.md before setting up a development environment, keep the robot stack version in mind when pinning, and note that this repository carries several products with separate release cycles, so a single version number does not describe the whole tree.
Frequently asked questions
What is the Opentrons repository?
It contains the source code for the Opentrons API and the OT App, and it is the home of the Protocol Designer, the shared labware data and the hardware support for the Opentrons Flex and OT-2 robots. The stated mission is to provide the scientific community with a common platform to share protocols and reproduce each other's work.
How do you write a protocol with the Opentrons API?
In Python, using the vocabulary of the bench. The README example is `pipette.aspirate(location=trough['A1'], volume=30)` followed by `pipette.dispense(location=well_plate['A1'], volume=30)`, which tells the OT-2 to move 30 microlitres from a trough to a well plate.
What is the Opentrons App and the Protocol Designer?
The App is the desktop client for uploading a protocol, calibrating positions and running an experiment, with a sortable protocol list showing each deck map, its pipettes and modules, and its last update. The Protocol Designer is the graphical tool for creating a protocol to run on the robot, at designer.opentrons.com.
How do I contribute to the Opentrons code?
File a bug report or submit a pull request on a branch of the API or the App. The README notes the team will reach out to talk about integration testing and launching it into the product, and the contributing guide is at ./CONTRIBUTING.md with setup details in DEV_SETUP.md and DOCKER.md.
What licence is the Opentrons software under?
Apache-2.0, with the LICENSE and NOTICE files at the repository root. The project describes itself as free for anyone to explore, hack and build upon, and the default branch is edge with the robot stack release at v10.1.0 from 2026-10-15.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/opentrons-opentrons)Was this useful?