Free and open-source electronic lab notebooks (ELNs) are software a lab can run without paying a license fee, and, for the fully open-source options, whose source code the institution can inspect, modify, and host itself. This page surveys the specific open-source and free-tier tools available, rather than the general selection criteria; for how to weigh those tools against paid commercial platforms and decide which category fits a given lab, see Lab Notebook Software: How to Choose an Electronic Lab Notebook.
“Free” covers several genuinely different things in ELN software, and the distinction matters for what an institution can actually rely on long-term:
- Open-source, self-hosted: the source code is public and licensed for reuse; the institution runs its own instance and owns the infrastructure and the data outright. eLabFTW, Chemotion ELN, and openBIS below are all in this category.
- Open-source core with a hosted commercial option: a vendor offers both a free, self-hostable community edition and a paid, vendor-hosted version with additional support or features.
- Free tier of a proprietary product: the source is not open, but a vendor offers a no-cost tier, usually capped on storage or collaborator count, as an on-ramp to a paid institutional license.
- DIY / adjacent-tool approaches: general-purpose tools, most commonly Jupyter notebooks under version control, repurposed as a lab record rather than built for the purpose.
This page focuses on the first and last of these: genuinely open-source, self-hostable ELN software, and the Jupyter/version-control approach computational labs sometimes use instead of a dedicated ELN. (RSpace’s open-source community edition and LabArchives’ free tier, both mentioned only briefly here, are covered in more detail in the buyer’s guide linked above.)
eLabFTW
eLabFTW is a self-hosted, open-source electronic lab notebook built specifically for research record-keeping, first released in 2012 and still actively maintained. Its source is published on GitHub under the GNU Affero General Public License (AGPL-3.0), a copyleft license that, unlike the plain GPL, also covers software accessed over a network — relevant here because an ELN is typically used entirely through a web interface rather than distributed as installed software.
eLabFTW pairs an experiments module with a linked inventory and resources database, so a lab gets basic sample/reagent tracking alongside the notebook itself without a separate LIMS. Because it is self-hosted (commonly deployed via Docker), the institution controls the server, the backups, and the export process directly; there is no vendor account to lose access to and no subscription to lapse. The trade-off is that local IT, not a vendor support line, is responsible for keeping the instance patched, backed up, and secure. It is one of the most widely cited and adopted open-source ELNs in the academic literature and is a credible option for any lab or institution with the IT capacity to run and maintain a self-hosted service, not a stripped-down alternative to a real ELN.
Chemotion ELN
Chemotion ELN is an open-source electronic lab notebook purpose-built for chemistry, developed at Karlsruhe Institute of Technology (KIT) and described in a peer-reviewed paper in the Journal of Cheminformatics (Tremouilhac et al., 2017). Where eLabFTW and openBIS are discipline-agnostic, Chemotion is built around organic-chemistry workflows specifically: structure drawing and editing, reaction documentation, and management of chemical samples and their associated analytical data. Its source code is publicly available and it is deployed at a number of academic chemistry departments in addition to KIT.
Chemotion is the more specialized choice of the three open-source options here: it is a strong fit for a synthetic or analytical chemistry lab that wants structure- and reaction-aware notebook entries out of the box, and a weaker fit for a lab outside chemistry that has no use for that discipline-specific tooling. For a closer look at what a chemistry-specific ELN needs to do with structures, reactions, and registry linking (a requirement that applies to commercial chemistry ELNs too, not just Chemotion), see Electronic Lab Notebooks for Chemistry.
openBIS
openBIS is an open-source ELN and Laboratory Information Management System (LIMS) combined, developed and maintained by the Scientific IT Services (SIS) group at ETH Zurich and under active development since 2007. It is described in the peer-reviewed literature as “an open-source database for academic laboratories” (Bauch et al., BMC Bioinformatics, 2011), and the ELN-LIMS interface built on top of the underlying openBIS data-management platform is documented in more recent institutional and preprint literature as well.
openBIS’s distinguishing feature relative to eLabFTW and Chemotion is scope: it is explicitly positioned as a combined ELN, inventory/sample management, and FAIR research-data-management platform, rather than a notebook with a lightweight inventory module bolted on. That makes it a heavier deployment to stand up than eLabFTW, but a more complete answer for a life-science group or core facility that wants notebook records, sample/material tracking, and structured, FAIR-aligned data management in one self-hosted system rather than stitching an ELN together with a separate repository or data management plan tooling.
Jupyter notebooks and version control as a DIY lab record
For computational and data-science-heavy work, some labs skip a dedicated ELN entirely and treat a version-controlled Jupyter notebook, or a Markdown lab log kept in the same git repository as the analysis code, as the record of what was done and when. This is free in the most direct sense (no software cost at all, since Jupyter is itself open-source and freely available), and it has a real advantage the dedicated tools above do not automatically offer: the record and the actual computational work live in the same place, so a git commit history doubles as a timestamped log of what changed, when, and by whom, with no separate notebook entry required to describe it.
The limits of this approach are the same ones the buyer’s guide flags for DIY approaches generally: a git history is not a tamper-evident, witnessed audit trail in the way a purpose-built ELN’s entry-locking and edit-history features are, and it provides nothing toward 21 CFR Part 11 or Good Laboratory Practice (GLP) compliance if the lab’s work is ever regulated. It is a defensible, low-friction choice for purely computational research where the code and its version history already constitute the meaningful record, and a materially weaker substitute for a purpose-built ELN in any wet-lab context where the notebook’s evidentiary role, for example supporting an invention disclosure, actually matters.
Comparing the three open-source platforms
| Platform | Discipline fit | Scope | Maintained by | License |
|---|---|---|---|---|
| eLabFTW | Discipline-agnostic | Notebook + basic inventory | Open-source community, active since 2012 | AGPL-3.0 |
| Chemotion ELN | Chemistry (organic/synthetic focus) | Notebook with structure/reaction tooling | Karlsruhe Institute of Technology | Open source (published, peer-reviewed) |
| openBIS | Discipline-agnostic, strong life-science use | Notebook + inventory + FAIR data management/LIMS | ETH Zurich, Scientific IT Services | Open source, active since 2007 |
All three require self-hosting and local IT ownership of the running instance; none of them is a hosted, sign-up-and-go SaaS product. That is the fundamental trade-off of this whole category, and the reason the choice between these tools and a paid, vendor-hosted platform is rarely just about price. See the evaluation criteria (compliance tier, export format, hosting model, IT capacity) in the ELN buyer’s guide for how to weigh that trade-off against a specific lab’s requirements.
What self-hosting actually commits an institution to
Choosing a free, open-source ELN shifts cost from a license fee to an operational commitment, and that commitment is worth naming explicitly before adoption:
- Server and infrastructure. Someone has to provision, run, and pay the hosting cost for the server the instance runs on, whether that is institutional infrastructure or a cloud VM.
- Patching and security. Software vulnerabilities in a self-hosted instance are the institution’s responsibility to track and patch, not a vendor’s.
- Backups and continuity. There is no vendor SLA guaranteeing data durability; backup strategy, retention, and disaster recovery are entirely local decisions.
- Upgrades. Open-source projects release new versions on their own schedule; someone needs to plan and execute upgrades rather than have them pushed automatically by a SaaS vendor.
- Support. Community forums, GitHub issues, and (for some of these projects) paid support contracts from affiliated organizations substitute for a dedicated vendor help desk.
None of this makes the open-source route wrong; institutions with established research-computing or IT infrastructure often already run comparable self-hosted research services and can absorb an ELN into that footprint at low marginal cost. It does mean the honest comparison against a paid platform is total cost and effort of ownership, not license price alone. For a broader look at how open-source licensing terms (including copyleft licenses like the AGPL that eLabFTW uses) work in a research and technology-transfer context, see Open Source Software Licensing in University Technology Transfer.
Frequently asked questions
Is eLabFTW really free?
Yes, for self-hosting: the software itself carries no license fee and the source code is public under the AGPL-3.0. The institution still bears the ordinary cost of running a server, backups, and IT staff time to maintain it, so “free” refers to the software license, not the total cost of running the service.
Which is easier to set up, eLabFTW or openBIS?
eLabFTW is generally the lighter deployment: it is a notebook with a basic inventory module, commonly run via Docker. openBIS is a larger platform that combines an ELN with a full inventory/LIMS and FAIR data-management layer, which makes it more capable but also a heavier system to stand up and administer. The right choice depends on whether the lab needs that broader data-management scope or just a notebook and basic inventory.
Do any of these support 21 CFR Part 11 compliance?
Not out of the box. These are open-source, community- or institution-maintained projects, not vendor products sold with a validated, Part 11-compliant configuration. A lab that genuinely needs regulatory-grade electronic signatures and validated system controls should treat that as a real, resource-intensive validation project if pursuing a self-hosted option, or should look at the commercial GxP-oriented platforms covered in the ELN buyer’s guide instead.
Can a Jupyter notebook actually replace an ELN?
For purely computational work, it can serve the same evidentiary function reasonably well, since the code, its outputs, and its version history together document what was done. For wet-lab or any regulated work, it is a materially weaker substitute: a git commit history is not the same as a tamper-evident, witnessed audit trail, and it provides nothing toward Part 11 or GLP compliance if that ever becomes relevant.
Is there a middle ground between fully self-hosted and a paid SaaS platform?
Yes. Some vendors, RSpace being the clearest example, offer an open-source or free self-hosted community edition alongside a paid, vendor-hosted commercial product, letting a lab start free and migrate to hosted support later without a full platform switch. See the buyer’s guide for how that option compares to the fully open-source platforms covered on this page.
