eLabFTW ELN Installation and Research Team Features

Why eLabFTW Exists for Research Teams

eLabFTW addresses the problem of recording research experiments and locating the physical or digital objects associated with them. The intended users are research teams, research institutions, and companies that need a traceable record of laboratory work. An experiment notebook can hold the record of a study, while the separate resource database can hold objects such as antibodies, plasmids, cell lines, boxes, and other laboratory materials. That distinction matters because an experiment is a record of work, whereas a resource is something that may be referenced, stored, booked, or tracked across multiple experiments.

The README also frames eLabFTW as an institute-level service. Several research teams can be hosted in one installation, which means that a central operator can provide a common service instead of requiring every group to run a separate notebook application. The project describes this arrangement as suitable for improving the traceability and reproducibility of processes. It is therefore aimed more at an organized laboratory environment than at a private notes application with a notebook-shaped interface.

The feature list includes more than experiment writing. eLabFTW offers trusted and blockchain timestamping, import and export in several formats, equipment booking through a calendar, molecule editing, LaTeX support, scientific file format support, a todo list, advanced permissions, and a public REST API. The README does not explain the exact audit trail, export format list, or blockchain service configuration, so those capabilities should be checked against the current documentation before they are treated as compliance controls.

Browser Access and Server-Centered Data Flow

eLabFTW is designed as a server application accessed through a browser. Users authenticate to the installation and work with the notebook through the web interface. The architecture is self-contained from the user's perspective: the README says that the service does not leak data to third parties. It does not describe a client-side offline mode, local database, or synchronization mechanism, so the documented operating model assumes a server connection rather than disconnected notebook editing.

The repository layout reflects a full web application rather than a small command-line program. The `src/`, `web/`, `containers/`, `apidoc/`, `tests/`, `documentation/`, and `var/` directories indicate application source, browser-facing code, container deployment content, API documentation, automated tests, documentation, and variable or runtime data. The primary language is PHP, while `package.json` also declares Node.js tooling for development. That combination indicates a PHP application with a JavaScript build process, although the README does not document the production request path or internal module boundaries in detail.

The public REST API is the clearest documented extension point. The repository lists separate `elabftw/elabapi-python` and `elabftw/elabapi-javascript-example` projects for interacting with APIv2. This gives an institution a way to connect eLabFTW to scripts or other applications, but the README does not document authentication details, rate limits, endpoint names, or which resources are writable through the API. Those details must come from the API documentation and the referenced client libraries.

Docker Installation Requirements and Missing First-Use Steps

The README identifies Docker as the installation method and says that eLabFTW can be installed on a GNU/Linux server. The server needs at least 512 MB of RAM, with 1 GB recommended, and 300 MB of disk space. The documented reason for using containers is version isolation: PHP, web servers, and MySQL are provided by the containers, so those components do not need to be installed directly on the server. This can simplify dependency management and make version upgrades easier.

The repository contains `containers/`, but the README does not include a complete installation command, image name, port mapping, environment variable, initialization procedure, or database configuration. It links to the installation instructions at `https://doc.elabftw.net`. This article therefore cannot provide a safe `docker run` or `docker compose` example. A command assembled from the repository layout would risk inventing an image name, port, mount path, or variable that the installation does not use.

The first-use path is also only partly documented. After installation, the README says users can log in from a browser. It identifies experiments, resources, calendar bookings, imports, exports, and the REST API as available functions, but it does not state the exact menu names, default administrator account, initial database schema, or setup sequence. A new operator should follow the linked installation instructions, create the initial account according to that documentation, and then verify that the browser interface can open an experiment record and save it before configuring integrations.

Experiment Records and Laboratory Resource Tracking

The core value is the relationship between a research record and the materials connected to it. A laboratory team can use the experiment notebook for the written and structured history of work, while the object database records entities that need their own identity and metadata. The README explicitly names antibodies, plasmids, cell lines, boxes, and chemical products as examples. It also mentions equipment and storage, which indicates that the database is intended to cover both consumable and physical laboratory resources.

This design is useful when an experiment needs context beyond a prose note. For example, a record can be associated conceptually with a plasmid or cell line, although the README does not specify the exact relationship model or whether every object type has the same metadata fields. The advanced permissions system is relevant for institute-level use because multiple teams share one installation. However, the README does not define team boundaries, object visibility, or whether permissions can vary by experiment and resource type. Those are configuration questions that should be answered before sensitive work is uploaded.

The calendar is specifically described as a tool for booking equipment. That is a narrower operational feature than a general asset-management system, and the README gives no details about reminders, conflict handling, recurring bookings, or integration with inventory. Likewise, the molecule editor and scientific file support are listed, but no supported formats are enumerated. The presence of these features expands the possible workflow, while the absence of configuration details makes them unsuitable as the sole basis for an adoption decision.

Timestamps, Import, Export, and API Boundaries

eLabFTW includes two timestamp-related features: trusted timestamping and blockchain timestamping. The README does not explain which trusted timestamp provider is used, what events can be timestamped, how the resulting evidence is stored, or how blockchain timestamping is configured. Those omissions are significant for regulated or audit-sensitive laboratories because a timestamp feature is only useful if the organization understands what it attests to and how the record is retained.

Import and export are also advertised as supporting various formats, but the README does not name the formats or describe mapping behavior. The repository includes `rspace2elabftw`, a Python script described as importing `.eln` files from RSpace, and `any2eln`, described as importing data from LabFolder through its API. These are migration utilities, not proof that every RSpace or LabFolder object can be transferred without loss. The scripts should be examined for field mapping, attachments, timestamps, permissions, and error handling before migration.

The REST API is public in the sense that the project advertises it as an extension mechanism, not that it is unauthenticated. The README does not provide credentials, scopes, or endpoint examples. The related API libraries can help with client implementation, but application developers still need to confirm how authentication, authorization, rate limits, and failures are handled in the current APIv2 documentation.

Upgrade, Maintenance, and AGPL Responsibilities

The last push was on 2026-10-16, and the repository includes releases 6.0.8, 6.0.7, and 6.0.6 in October 2026. This indicates recent project activity, but it does not by itself establish compatibility with an existing deployment. The README states that Docker makes upgrading easier because the surrounding runtime versions are isolated. It does not document the upgrade command, migration behavior, rollback procedure, backup requirements, or release support window.

For an institute-level installation, maintenance is therefore an operational responsibility rather than only a software choice. An operator must account for the container images, persistent data, MySQL data, uploaded files, configuration, and any external timestamp or blockchain service. The repository layout includes `containers/`, `var/`, and configuration-related files, but the README does not identify which directories must be backed up or restored together. The README is also silent on rollback, so an operator should not assume that replacing a container is a complete upgrade or recovery plan.

The source code is licensed under the GNU AGPL. That matters for an organization that modifies eLabFTW and distributes or makes the modified service available to others. This article does not provide legal advice. The `LICENSE`, `SECURITY.md`, and `TRADEMARK.md` files should be reviewed directly, and legal requirements should be checked when deciding whether to operate, modify, or redistribute the application. The eLabFTW name and logo are separately governed by `TRADEMARK.md`.

RSpace, LabFolder, and Hosted Deployment Trade-offs

The repository names RSpace and LabFolder as systems from which data may be imported. That is an actual difference in approach: those tools are treated here as source platforms in migration paths, while eLabFTW is the destination for `.eln` files or API-imported data. The README does not provide enough information to compare their native experiment models, permissions, timestamping, or deployment requirements, so a direct product comparison would be misleading.

For an organization already using RSpace or LabFolder, the practical alternative is to evaluate the migration script rather than recreate every record manually. The repository's description of `rspace2elabftw` specifically mentions `.eln` files from RSpace, while `any2eln` is described as using the LabFolder API. Before relying on either path, check whether attachments, object relationships, audit metadata, user identities, and timestamps survive the import. The README does not promise lossless migration.

A second operational alternative is hosted deployment. The README lists dedicated hosting from Deltablot separately from community support and the open-source Docker installation. A hosted service changes the responsibility for server administration, but the README does not document its pricing, data export terms, hosting architecture, or feature differences. A self-hosted Docker installation gives the institution control over the server, while it also assigns more responsibility for updates, backups, access controls, and recovery to that institution.

Editorial conclusion

eLabFTW is a reasonable choice for research teams or institutions that want a shared, self-hosted notebook with structured resource records and a public REST API. It is less suitable for an individual who cannot operate a server or for organizations requiring a simple hosted workflow without evaluating the separate hosting and documentation path. Before adoption, verify the current installation instructions, database and storage requirements, backup procedures, permission model, import behavior, and the division of responsibility between the project and the institution operating the service. The first project-specific decision is whether the Docker deployment and AGPL-licensed codebase fit the organization's operational and licensing requirements.

Frequently asked questions

Official sources

1. elabftw/elabftw on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases