OpenSign: self-hosted e-signature with MongoDB, OTP guest signing and audit certificates

The gap OpenSign fills: signature workflows you can host yourself

Commercial e-signature platforms price per envelope and keep the signed artefacts on their infrastructure. For a legal team, a clinic, a university department or an agency that sends the same onboarding packet every week, that combination is awkward: the document leaves your network, the audit trail lives in someone else's dashboard, and the bill scales with volume. OpenSign targets exactly that gap. The README describes it as a free and open source alternative to DocuSign and lists comparable products (PandaDoc, SignNow, Adobe Sign, HelloSign, Zoho Sign) as the category it competes with. The intended audience is an organisation willing to run Node.js and MongoDB in exchange for keeping documents and signing logs on its own machines. It is not aimed at a single person who signs two PDFs a year; the installation section assumes a server, a database and an email path.

What actually happens between upload and completion certificate

The moving parts visible in the repository metadata are a JavaScript stack, MongoDB for storage, and a React front end. The README's feature list sketches the data flow. A sender uploads a PDF or picks a stored template, places signature and annotation fields on it, and invites recipients either by email or by sharing a signing link. Signers can draw, type, upload or reuse a saved signature. Where a signer is a guest rather than a registered user, the README states that the document can only be signed after the signer enters a unique code sent to their email address, which is an OTP gate in front of the signing action. Multi-signer requests can be ordered so that each participant is invited only after the previous one finishes. Documents can carry an expiry in days, after which signing is blocked, and a signer can reject with a reason that is surfaced to the sender. On completion the system writes an audit trail with timestamps, IP addresses, email IDs and phone numbers, and generates a completion certificate containing those logs. That certificate is the artefact you would hand to a counterparty or a regulator, so it is the part of the pipeline worth inspecting first in a real deployment.

The default MongoDB is ephemeral, and that is the first thing to fix

The deploy note in the README is blunt: the default MongoDB instance used in deployment is not persistent and will be cleared on every restart, and to retain data you must configure and supply your own MongoDB connection URL. Read that against the rest of the feature list. Audit trails, completion certificates, templates and the document drive all live in that database. A container restart on an unconfigured instance therefore wipes the signing history, not just cached state. Any evaluation that skips this step tests a system that forgets everything, which makes the audit-trail claim untestable. The practical order of operations is: stand up MongoDB first, set the connection URL, then create an account and send a test envelope, then restart the stack and confirm the envelope and its certificate are still there. The README does not spell out the environment variable name or the compose file layout, so that detail has to come from the repository itself or the linked help documentation rather than from this description.

Getting it running: what the README gives you and what it withholds

The README points to a website, help documentation at docs.opensignlabs.com, an API reference under docs.opensignlabs.com/docs/API-docs/opensign-api-v-1, a Discord server, a blog and a Twitter account. It also states that an API key is generated from inside the application, after which you follow the official API docs to integrate signing into existing systems. What the README does not contain is a copy-pasteable install sequence: no git clone line, no docker compose command, no npm script, no port number, no environment variable list. The only configuration instruction with operational weight is the MongoDB one quoted above. That is a real friction point for an engineer evaluating the project in an afternoon, because the deployment path lives behind the docs site rather than in the repository front page. It also means the API surface cannot be judged from the README alone; the endpoint names, authentication header format and webhook behaviour are only in the separate API documentation, and the README references more than one version of that documentation (v1 and v1.1 in different links), so check which one matches the release you deploy.

Where OpenSign is the wrong tool

Three cases stand out. First, regulated signing that depends on a specific legal regime. The README claims encryption and detailed logs but does not name a compliance certification, a qualified signature standard or a trust service provider. If your counterparty requires an eIDAS-qualified or similarly certified signature, a self-hosted JavaScript application whose README is silent on the subject is not the thing to reach for. Second, teams without database operations capacity. The ephemeral default is not a bug you patch once; it is a signal that persistence, backups and retention are your responsibility for the lifetime of the deployment, and signed documents are exactly the data you cannot afford to lose. Third, anyone who needs contractual certainty about the software itself. The repository's licence field reads NOASSERTION, meaning the automated classifier could not map the terms to a known licence. The README has a License section but the supplied material does not state what it contains. Until someone reads the LICENSE file, you cannot tell a legal reviewer what rights you have, and that blocks adoption in many organisations regardless of how well the signing flow works.

How it differs from DocuSign, and from building on a PDF library

Against DocuSign the difference is not a feature checklist, it is where the data and the cost sit. DocuSign operates the signing service, holds the envelopes, and prices per volume; OpenSign moves the same category of workflow into your own MongoDB and your own server, and the README's pitch is that signing is unlimited. The trade is operational: you take on uptime, email deliverability for invitation and reminder messages, database backups, and the burden of proving that your audit trail is trustworthy. Against the other obvious route, wiring a PDF signing library into your own application, OpenSign already ships the parts you would otherwise write: the signing pad with drawn, typed, uploaded and saved signatures, the template store, the drive, the expiry and rejection handling, the guest OTP gate, and the completion certificate with IP and timestamp logging. That is a meaningful amount of product surface. What you give up by not building it yourself is control over the exact audit format and the ability to shape the signing UI to your own product, since OpenSign is a standalone application with an API rather than a component you embed.

Maintenance, releases and the licence question

The release cadence visible in the metadata is tight: v2.41.1, v2.41.2 and v2.41.3 land within roughly ten days in August 2026, on a repository whose default branch is named staging. Frequent patch releases on a staging default branch suggest active development, and they also suggest you should pin a version rather than track the branch, because a moving default branch is not a stable deployment target. Budget for periodic upgrades and for reading release notes before each one, since a signing service holds in-flight envelopes that a mid-upgrade restart could interrupt. Upgrading also interacts with the persistence question: if your MongoDB URI is not configured, an upgrade restart behaves like the ephemeral default. On licensing, the only defensible statement is the one the metadata supports, which is that the licence field is NOASSERTION and therefore unclassified. That is not a legal opinion and it is not a claim that the terms are restrictive; it means the terms are unknown from this material. Before deploying for real work, open the LICENSE file in the repository and, if your organisation has a legal reviewer, put it in front of them alongside the question of whether a self-hosted audit certificate satisfies your counterparties.

Editorial conclusion

Adopt OpenSign if you have a MongoDB instance you control and you need signing links, sequencing, expiry and audit certificates inside your own network. Do not adopt it if you need a signed data processing agreement, a clear licence grant, or zero database operations work. Before anything else, read the LICENSE file in the repository, because the NOASSERTION field means the automated tooling could not classify the terms, and confirm which MongoDB URI your deployment writes to.

Official sources

1. Issues
2. OpenSignLabs/OpenSign on GitHub
3. Project website
4. README
5. Releases