LabOps
A flexible, self-hosted workflow of free and open source tools for research lab collaboration, chat, file sharing, document editing, and calendars, without the costs or restrictions of proprietary platforms.
What it is
Is there anything beyond Slack, Microsoft Teams, Google Drive, and OneDrive? Most research labs end up piecing together whatever combination of these tools their institution happens to license. LabOps started from a simpler question: what happens if a lab self-hosts its own infrastructure instead, using tools that are free, open source, and fully under the lab's own control?
LabOps is a workflow with five categories of collaboration (team communication, file storage, document editing, calendars, and reference management), each filled by an open source tool that can be self-hosted on a NAS, a server, or even a spare laptop. The GitHub repository associated with the paper has ready-to-deploy configuration files for the core pieces, along with setup instructions for the reverse proxy and HTTPS certificates that let lab members reach these tools from outside the building.
The workflow
Team communication
Mattermost, a Slack-style chat platform with channels, threads, and boards for task tracking. No time limit on message history, unlike the free tiers of most proprietary chat tools.
File storage & sharing
Nextcloud, a shared drive the lab fully controls, with public links, edit permissions for outside collaborators, and no arbitrary storage caps beyond what the hardware provides.
Document editing
OnlyOffice, real-time collaborative editing for DOCX, XLSX, and PPTX files, with version history and a Zotero plugin for inserting citations directly while writing.
Calendars
Radicale (or Nextcloud Calendar), a shared calendar server for scheduling lab meetings and deadlines across every member's own calendar app.
Reference management
Zotero, not self-hosted here, but integrated into OnlyOffice through its plugin so citations stay linked to the lab's shared library while writing.
Setting it up for your own lab
The repository linked below documents the full deployment used in the paper: a server/NAS running Docker containers through Portainer, with a reverse proxy and wildcard HTTPS certificate so lab members can reach these tools from outside the building. In general:
- Set up a wildcard certificate and enable HTTP/2 and HTTP compression on your NAS or server, so every subdomain (chat, files, docs) can run securely under one HTTPS certificate.
- Install Docker and Portainer to manage containers through a web interface instead of the command line.
- Configure a reverse proxy so each tool gets its own subdomain (e.g. chat.yourlab.org) pointing at the right container port.
- Deploy each tool as a Portainer stack, using the ready-made YAML files in the repository for Mattermost, ownCloud, OnlyOffice, and Radicale.
The GitHub repository has the full step-by-step instructions, including exact folder structures and the YAML configuration for each tool.
Go to the LabOps repository
Is this the right fit for your lab?
Self-hosting isn't the right call for every lab, and the paper is direct about this: LabOps is presented as an alternative worth knowing about, not something every lab should feel obligated to run. A few honest things worth weighing before adopting it:
- Hardware is a real upfront cost. The deployment described in the paper used a Synology NAS, comfortably handling around 10 simultaneous users and roughly 1 TB of shared data. Although that represents a one-time purchase, it's still money and a physical device someone has to own and maintain.
- Someone has to maintain it. Self-hosted tools need updates, backups, and occasional troubleshooting. There's no vendor support line, help mostly comes from community forums, GitHub issues, and documentation. Scientists shouldn't be expected to act as a full IT department, and for labs without any spare technical capacity, this can be the deciding factor either way.
- Security is on you. Exposing any service to the internet carries risk. Running behind a university network can help by leaning on existing institutional security, but universities also often restrict which ports or applications outside users can reach, which can complicate remote access.
- It's not archival storage. LabOps is built for small to medium active collaboration, not long-term data archiving. A lab with large-scale data needs will likely still need a separate archival solution alongside it.
- Tools can go stale. Most of the software here is actively maintained today, but open source projects can lose momentum or get discontinued. Reviewing the current state of each tool before committing to it is worth doing, not just following the paper's setup blindly.
A phased approach tends to work better than switching everything at once. Nothing about LabOps requires going all in from day one.
Cite LabOps
If LabOps was useful for setting up your own lab's workflow, please cite:
- García-Verdugo, H. D., & Román-Palacios, C. (2025). LabOps: A flexible self-hosted workflow of open source tools for efficient collaboration within research laboratories. PLOS Computational Biology, 21(7), e1013248.
LabOps on GitHub