Self-hosted is a compliance requirement, not a preference
For a testing lab pursuing ISO/IEC 17025, where the data lives isn't an IT decision — it's often the thing that disqualifies a cloud ELN before an assessor ever looks at the audit trail.
Ask a lab director why they haven’t moved their electronic lab notebook to a cloud platform and you’ll usually hear something that sounds like a preference: “we’d rather keep things in-house,” or “our IT policy is conservative.” It rarely sounds like what it actually is, which is a constraint with a name and a clause number.
The policy is not a suggestion
A testing laboratory pursuing ISO/IEC 17025 accreditation, a public-health lab operating under a national data-residency law, or a research group holding Gates Foundation or Global Fund grant funding is often contractually or legally barred from sending records to infrastructure it doesn’t control. That isn’t a soft preference an IT team can override with a good enough SLA — it’s a precondition the lab has to satisfy before an assessor will even open the audit trail.
This is the detail that gets lost when cloud ELN vendors pitch reliability, uptime, and automatic backups. Those are real advantages. They’re also irrelevant to a lab that is disqualified from using the product before any of them come into play.
What actually changes when you self-host
Self-hosting doesn’t mean giving up the things a modern ELN is supposed to provide — it means the guarantees have to hold without a vendor’s cloud backing them up:
- The audit trail has to be tamper-evident on its own. If records live on infrastructure the lab operates, “trust us, nothing was altered” isn’t good enough — the notebook itself needs to prove it. That’s why Archon chains every audit entry with SHA-256 hashes per organization: an assessor isn’t asked to take anyone’s word for it.
- Finalization has to be genuinely irreversible. A draft notebook entry can be edited freely; a finalized one is signed and locked. There is no admin override that quietly undoes that, because the entire point of finalization is that it means something.
- Compliance readiness has to be measured, not asserted. A checklist that says “we have an audit trail” is a claim. A readiness score computed live from the actual state of the database is evidence. The difference matters to an assessor who has seen plenty of checklists.
- It has to work with no internet connection at all. Some of the labs this matters most for — public-health labs in low-connectivity regions, field research stations — can’t assume a network path to anywhere. Licence verification, offline mode, and the desktop app all exist because “self-hosted” should mean self-hosted, not “cloud with extra steps.”
The honest comparison isn’t Archon versus a cloud ELN — a lab that’s disqualified from the cloud was never choosing between the two. It’s Archon versus a spreadsheet, a paper notebook, or a free self-hosted tool that gets a lab through the door but not through the audit.
Why this is the harder product to build
It would be simpler to build a cloud product. Multi-tenancy is easier when you control every deployment; shipping a fix is a deploy, not a version bump someone has to pull. Self-hosting trades that convenience for something a compliance officer actually needs: a laboratory that can point at its own server and say, correctly, that its records never left the building.
That’s the bet behind Archon — that for the labs this applies to, sovereignty isn’t a feature to bullet-point next to dark mode. It’s the reason the product gets to exist for them at all. If that’s the constraint you’re building around too, the docs are a reasonable place to see how the pieces fit together, and pricing lays out what each tier is actually for.