# Electronic Lab Notebook Setup: A Step-by-Step Guide By the end of this electronic [lab notebook](/knowledge/molecular-biology/lab-notebook) setup guide, you will be able to choose a platform that fits your lab, deploy or activate it, build a reusable lab notebook template, write a properly timestamped first entry, and put a backup and export routine in place. The walkthrough uses eLabFTW, a widely used open-source electronic lab notebook (ELN), as the concrete worked example, and every step maps onto the same logic you would follow for a commercial cloud product such as Benchling, RSpace, SciNote, or LabArchives. Here is what you need on hand before you start. - A computer with a modern browser - Administrator access to a server if you are self-hosting, or an institutional email address if you are using a cloud product - Docker installed if you plan to follow the self-hosting example - About 2 gigabytes of free RAM on the host for a small deployment - A short written decision from your principal investigator or lab manager about where lab records will live, because that decision shapes every later step ## What an Electronic Lab Notebook Has to Do A paper notebook is legal and organizational scaffolding for research. It records what you did, when you did it, and who did it, in a form that another scientist can later follow. Any electronic lab notebook setup has to reproduce those functions in software. At minimum, look for these capabilities. 1. **Timestamped, attributable entries.** Each record needs a creation date and time and a named author. 2. **Immutability or version history.** Once saved, an entry should not be silently overwritable. Either the entry locks after a set period or every edit is kept as a revision. 3. **Full-text search.** You need to find an experiment from 18 months ago by a reagent name or a mouse ID. 4. **Structured attachments.** Raw instrument files, gel images, plasmid maps, and analysis spreadsheets should attach to the entry they belong to. 5. **Export in an open format.** You should be able to export your notebook to PDF or another portable format so records survive if the vendor or server goes away. 6. **Access control.** You decide who reads and who writes, per project or per entry. These are not optional extras. They are the same record-keeping principles that govern paper notebooks under good research practice, and regulated environments add formal electronic-record requirements on top of them. If a product fails any of the six points, treat that as disqualifying for real research records. ## Electronic Lab Notebook Comparison: Picking a Platform ![Decision path asking about an existing institutional license, regulated work and server maintenance to pick a platform.](/article-images/illustrations/electronic-lab-notebook-setup-guide-platform-choice.webp) The single biggest cause of failed rollouts is choosing a platform that does not fit how the lab already works. Use this electronic lab notebook comparison to narrow the field before you install anything. | Platform | Deployment | Cost model (qualitative) | Best fit | Watch out for | |--|--|--|--|--| | eLabFTW | Self-hosted on your own server | Free and open source, you pay in hosting time | Academic labs with some IT support | You own backups and updates | | LabArchives | Cloud, institutional license | Site license paid by the institution | Course labs and universities with an existing license | Limited flexibility outside licensed features | | RSpace | Cloud, institutional license | Site license | Labs wanting strong integration with data repositories | Feature depth varies by license tier | | SciNote | Cloud, team plans | Subscription per team | Small to mid-size wet labs | Data lives on vendor servers | | Benchling | Cloud, enterprise and free academic tiers | Subscription | [Molecular biology](/blog/careers/molecular-biology), sequence-heavy workflows | Advanced features concentrate in enterprise tiers | | Notion, OneNote, Google Docs | Cloud, general purpose | Free to low cost | Individual pilot notes, never regulated work | Weak timestamps, weak immutability, weak export guarantees | Three decision rules keep this comparison honest in practice. First, if your institution already licenses a product, use it. A mediocre platform everyone actually opens beats a perfect platform nobody logs into. Second, if your work falls under regulatory expectations for data integrity, such as studies intended for FDA submissions, choose a product whose vendor documents its audit trail and electronic-signature controls rather than a general note-taking app. Third, if no one in the lab can maintain a server, self-hosting is the wrong choice regardless of licensing cost. The rest of this guide follows the self-hosting path with eLabFTW because every parameter is visible and the same steps teach you what to look for in any product. If you chose a cloud product, read Steps 1, 6, 7, 8, and 10, because the logic transfers directly. ## Electronic Lab Notebook Setup Guide: Step by Step ![Flow of ten setup steps from writing requirements through provisioning, installing, configuring, templating, timestamping and backups.](/article-images/illustrations/electronic-lab-notebook-setup-guide-setup-sequence.webp) ### Step 1: Write Down Your Requirements Before You Install Spend 30 minutes producing a one-page document that answers these questions. - Who writes to the notebook? (One person, one lab, or a whole department) - Who must be able to read entries without editing them? (PI, collaborators, auditors) - Do any records need to satisfy formal data-integrity or regulated-research expectations? - What is your retention period? Many universities require research records to be kept for several years after publication, so check your institutional policy and write the number down. - Where do raw instrument files live, and does the ELN need to link to them? This page is your acceptance checklist for Step 9. Skipping it is the most common setup mistake, because teams that skip it discover six months in that the tool cannot meet a requirement they never articulated. ### Step 2: Provision the Host For self-hosting you need a Linux server or a machine that will stay on. A small lab of up to roughly 20 active users runs comfortably on a virtual machine with 2 gigabytes of RAM and 20 gigabytes of disk, though attachment-heavy workflows need more storage. Confirm Docker is installed and running. ```bash docker --version ``` Expected output looks like this. ``` Docker version 27.3.1, build 941b380 ``` If instead you see `command not found`, install Docker Engine from the official Docker documentation for your Linux distribution, then return here. ### Step 3: Install the Notebook Modern eLabFTW deployments use Docker Compose. Create a working directory and a `compose.yml` file that defines two services, the application and its MySQL database. ```yaml services: elabftw: image: elabftw/elabimg:latest container_name: elabftw environment: - ELABFTW_...=(see the official eLabFTW install documentation for the current, complete list of required environment variables) ports: - "443:443" volumes: - elab-uploads:/elabftw/uploads elabdb: image: mariadb:latest container_name: elabdb environment: - MYSQL_ROOT_PASSWORD=(choose a strong password) - MYSQL_DATABASE=elabftw - MYSQL_USER=elabftw - MYSQL_PASSWORD=(choose a strong password) volumes: - elab-mysql-data:/var/lib/mysql volumes: elab-uploads: elab-mysql-data: ``` The environment variable list for eLabFTW changes between releases, and the official eLabFTW documentation publishes the exact required set for each version. Copy it from there rather than guessing, because the container will refuse to start if a required variable is missing, and the error message will name the missing variable. Bring the stack up. ```bash docker compose up -d ``` Expected output. ``` [+] Running 3/3 ✔ Network elabftw_default Created ✔ Container elabdb Started ✔ Container elabftw Started ``` Verify both containers are healthy. ```bash docker ps ``` Expected output shows two lines, one for `elabftw` and one for `elabdb`, both with status `Up`. If the database container exits immediately, the usual cause is a bad database password pairing between the two environment blocks. Point your browser at `https://localhost` on the host, or at the server's hostname. On first launch the application creates an administrator account and prints a temporary password to the container log. ```bash docker logs elabftw | grep -i password ``` Expected output is a single line containing a randomly generated initial admin password. Copy it, log in, and change the password immediately. ### Step 4: Initial Administrator Configuration Log in as the administrator and configure these items, in this order. 1. **Force HTTPS.** The application serves over port 443 by default. Confirm the certificate is valid in your browser before creating any user accounts. A certificate warning at this stage means the setup is not finished. 2. **Set the password policy.** Require a minimum length of at least 12 characters. Weak shared passwords are the most realistic security failure in a small lab. 3. **Create the team.** Name it after the lab, for example `rodent-behavior-core`. 4. **Configure email sending.** The platform needs a working SMTP relay to send password resets and notifications. Enter your institution's SMTP host, port, and credentials in the admin panel, then use the built-in test action and confirm a test message arrives in a real inbox. If email fails, users will silently fail to reset passwords, which becomes your support burden. 5. **Set the backup policy.** Configure scheduled backups of both the uploads directory and the MySQL data volume, covered in detail in Step 10. 6. **Set the timestamp source.** The platform can cryptographically timestamp entries against a trusted timestamping authority. Enable it. A timestamped entry is far stronger evidence of when work was done than a plain saved page. Cloud products present the same settings through their admin dashboards. If you cannot find one of these six controls in a cloud product, that gap belongs in your Step 1 requirements document as a known limitation. ### Step 5: Create Your User Account and Profile Create a normal user account for yourself, separate from the administrator account. Daily work should never happen as an administrator, because administrative actions can alter settings that regular records depend on. Complete your profile with your full name and your role. Every entry you create will display this identity, so an incomplete profile produces notebooks that read like they were written by "user 4", which undermines the attributability the notebook exists to provide. ### Step 6: Set Up Experiment Types and Statuses Before writing anything, define the small controlled vocabulary your entries will use. - **Experiment types**, such as `Molecular cloning`, `Cell culture`, `Animal procedure`, `Data analysis`, and `Instrument run` - **Statuses**, such as `In progress`, `Complete`, `Failed`, and `Waiting on instrument` - **Tags**, such as project codes, plasmid names, and cell line names In eLabFTW these live in the admin panel under the items and statuses settings. Keep the list short. Five experiment types and four statuses are enough for most labs. A vocabulary of 40 overlapping tags is a vocabulary nobody maintains. ### Step 7: Build Your First Lab Notebook Template A lab notebook template is a reusable entry skeleton. Every experiment starts from it, which means every experiment records the same categories of information, and a reader twelve months later can find things without asking you. Paste this template into the platform's template editor. ```markdown # [Experiment title] **Date:** [YYYY-MM-DD] **Author:** [Full name] **Project code:** [tag] ## Objective One or two sentences. What question is this experiment answering? ## Hypothesis or rationale What outcome do you expect and why? ## Materials | Reagent or item | Vendor | Catalog or lot number | Concentration or dose | |---|---|---|---| ## Protocol Numbered steps. Record actual parameters as you perform them, not planned parameters. Include deviations in real time. ## Data Where the raw files live. Attach them to this entry or record their storage path. ## Observations What you saw, including anything that went wrong. ## Analysis What the data show so far. ## Next steps What happens next and who owns it. ``` Save this as your default template named `Standard experiment`. Most platforms, including eLabFTW, also support metadata fields, which are structured fields such as dropdowns that you can add to a template so the values are searchable as data rather than buried in prose. Add at least a project code field and a species or sample type field if those matter to your lab. The most valuable rule for templates is small. If filling the template takes more than two minutes per session, people will skip fields, and a half-empty structured record is worse than an honest paragraph. ### Step 8: Write and Timestamp a First Entry Create a new entry from the template. For a realistic first test, record a trivial but genuine task, for example a [buffer preparation](/knowledge/molecular-biology/buffer-preparation). ```markdown # 10x PBS stock preparation **Date:** 2026-11-11 **Author:** J. Okafor **Project code:** AMPA-01 ## Objective Prepare 1 L of 10x phosphate-buffered saline for the tissue processing series. ## Materials | Reagent | Vendor | Lot number | Amount | |---|---|---|---| | Sodium chloride | [your vendor] | [lot] | 80 g | | Potassium chloride | [your vendor] | [lot] | 2 g | | Disodium hydrogen phosphate | [your vendor] | [lot] | 14.4 g | | Potassium dihydrogen phosphate | [your vendor] | [lot] | 2.4 g | ## Protocol 1. Tared 1 L bottle on benchtop balance. 2. Added solids per table, added ~900 mL ultrapure water. 3. Stirred until fully dissolved, adjusted pH to 7.4. 4. Brought volume to 1 L, autoclaved 20 min at 121 °C. ## Observations All solids dissolved without heating. ``` Fill every field, attach one real file such as the balance printout photograph, and save. Then apply the timestamping or signing action the platform provides. In eLabFTW this is the timestamp action on the entry. After timestamping, open the entry and confirm you can see the creation timestamp and the timestamp certificate state. This check is what makes the notebook an evidentiary record rather than a convenience app. ### Step 9: Permissions, Sharing, and Cross-Checking Against Requirements Return to the Step 1 document and test each requirement against the working system. - Create a second test user and confirm they cannot edit your entries unless you intend them to. - Confirm the PI's account can read every project they need to oversee. - Export one entry to PDF and open the file. Verify the PDF carries the timestamps and your identity. - Run a search for a word you know appears in your test entry, such as `PBS`, and confirm it returns the entry. If any check fails, fix it now, while the notebook contains two test entries instead of two thousand. ### Step 10: Backups and Export A self-hosted notebook without verified backups is a single point of failure for the lab's entire experimental record. Back up two things separately. 1. The uploads volume, which holds attachments. 2. The MySQL data volume, which holds the entries themselves. A practical schedule is a nightly automated dump plus an off-site copy. ```bash # Nightly database dump, run from cron 0 2 * * * docker exec elabdb mysqldump -u root -p"(root password)" elabftw > /backups/elabftw-$(date +\%F).sql ``` Then verify backups monthly by restoring one dump to a scratch database and confirming the entries appear. An untested backup is a hope, not a backup. Cloud products handle infrastructure backups for you, but you still own data portability. Schedule a quarterly full export to PDF or the platform's open export format, and store that export outside the vendor's system. For eLabFTW, the admin panel provides a full export action that produces a portable archive of the notebook. ## Common Setup Errors and Their Fixes | Error message or symptom | Likely cause | Fix | |--|--|--| | `Cannot connect to the Docker daemon` | The Docker service is not running | Start it with `sudo systemctl start docker`, then retry | | `bind: address already in use` on port 443 | Another service, often a web server, holds the port | Stop the conflicting service or map the container to a different host port | | Database container exits immediately after `docker compose up` | Mismatched database passwords between the two service blocks | Make the root and application passwords consistent, delete the data volume, and start fresh | | Password reset emails never arrive | SMTP settings are wrong or blocked by the institutional relay | Re-enter SMTP host, port, and credentials, then send the built-in test message | | `ERROR 1045 (28000): Access denied for user` during a manual database dump | Wrong credentials in the dump command | Use the exact credentials defined in the compose file | | Entries exist but search finds nothing | The search index has not rebuilt after a large import | Trigger the platform's reindex or rebuild action from the admin panel | | Uploaded file downloads as corrupt | Disk quota exhausted on the uploads volume | Check disk space with `df -h` and expand the volume | ## Checking That Your Setup Is Right Run through this short list and treat every unchecked item as unfinished work. - Both containers report `Up` and the application loads over HTTPS with no certificate warning - The admin password has been changed from the generated default - SMTP test email arrives in a real inbox - A timestamped entry shows both creation time and timestamp evidence - A second account is correctly denied edit access - A PDF export opens and carries the timestamps - A restored backup dump produces readable entries - The `Standard experiment` template is the default for new entries ## Common Mistakes and Limitations These are the failures that show up repeatedly in real rollouts, listed so you can avoid them rather than discover them. **Treating the ELN as a document store.** Uploading a week of scanned paper pages into a single entry defeats the purpose. One experiment, one entry. Attachments belong on the entry that interprets them. **Building a template nobody fills honestly.** If the template demands 15 fields, people will write `N/A` everywhere. A five-field template that is filled correctly every time preserves more information than a fifteen-field template that is ignored. **Skipping the timestamp.** Saving an entry and timestamping it are different actions. Records without timestamps are weaker evidence of when work was performed, which matters in disputes, authorship questions, and patent contexts. **No naming convention for experiments.** Agree early on a title format, for example `YYYYMMDD-project-short-description`. Free-form titles make the search box nearly useless after a year. **Admin work done from the admin account.** Create personal accounts and keep administrative powers for configuration tasks only. **No backup verification.** Labs discover dead backups exactly when they need them, usually during an equipment failure or a departure. Restore-test monthly. **Assuming a general note app is compliant.** Consumer note tools rarely provide immutable revision histories, cryptographic timestamps, or controlled exports. Fine for a recipe scratchpad, not for primary research records, and not for any regulated work. **Importing old paper notebooks wholesale.** Scan the important pages, but do not commit to re-entering five years of paper records. Set a start date, usually the first of the next month, and run forward from there. One limitation applies to everything above. Institutional data-governance policies, retention rules, and any regulatory obligations that touch your records vary between institutions and between study types, so confirm your specific requirements with your institution's research office before committing records to any platform. ## Frequently Asked Questions ### What is an electronic lab notebook? An electronic lab notebook is software that replaces the bound paper notebook for recording experimental work, with timestamped entries, attached raw data, version history, and search. It serves the same evidentiary and organizational purpose as a paper notebook and adds searchability and backup. ### Is an electronic lab notebook legally valid as a research record? Yes, when it provides attributable, timestamped, tamper-evident records. Enable timestamping or signing, keep version history on, export regularly, and follow your institutional retention policy. For regulated studies, use a platform whose vendor documents its audit-trail and electronic-signature controls. ### Can I use Notion or Google Docs as my lab notebook? Not for primary research records. They lack immutable revision histories, cryptographic timestamps, and reliable long-term export guarantees, and their search cannot distinguish an experiment from a grocery list. They are acceptable for scratch ideas and lab logistics only. ### How much does an electronic lab notebook cost? It depends entirely on the route you choose. Open-source self-hosted options cost nothing in licensing but require server time and maintenance effort. Cloud products are usually priced per user or as institutional site licenses, with quotes that vary by lab size and contract length, so request pricing directly from vendors or check whether your university already holds a license. ### What should go in a lab notebook template? At minimum, a title, date, author, project code, objective, materials with lot numbers, the protocol as actually performed, where raw data live, observations, analysis, and next steps. Keep it to fields you will genuinely fill in every session. ### Do I still need to keep paper records? Some instruments and safety forms still generate paper. The practical rule is that the ELN is the record of experimental work, and anything on paper either gets attached as a scan or referenced with its physical location. Follow your institution's policy on which medium is authoritative. ### How do I migrate from a paper notebook? Do not try to transcribe years of paper entries. Scan the pages you will need to reference, attach or store the scans, set a fixed start date for the ELN, and record all new work there from that date forward. ### Who owns the data in an electronic lab notebook? Ownership and access typically follow your institution's intellectual property and research-data policies, not the software. The platform's role is to preserve attribution and access controls. Read your institution's data policy and your funder's data-sharing requirements before the first entry, not after.