OpenSign: A Self-Hosted Open-Source Alternative to DocuSign

What OpenSign Does and Who Needs It

Commercially hosted e-signature services charge per document, per user, or per seat. For high-volume document workflows or organisations with strict data sovereignty requirements, those costs and constraints drive the search for a self-hosted alternative. OpenSign provides the full signing workflow, including PDF upload, signature field placement, multi-party signing, email notifications, and a document vault, on infrastructure the operator controls.

The target users are legal teams, HR departments, contract-heavy sales teams, and developers building document workflows into existing applications via the API. The README explicitly positions it against DocuSign, PandaDoc, SignNow, Adobe Sign, Smartwaiver, SignRequest, HelloSign, and Zoho Sign.

The platform is JavaScript-based (the package.json identifies it as such), uses MongoDB as the database, and deploys as a Docker Compose stack. The latest release is v2.41.3, tagged on 2026-08-21. The last repository push was also on 2026-08-21. The AGPL-3.0 licence covers the platform.

The Document Signing Process

A signing request in OpenSign works as follows. The document sender uploads a PDF, places signature, text, date, and other fields on the document at defined positions, and invites signers by email. Signers receive a notification and access the document through a browser-based signing interface.

The signing interface supports four input types: hand-drawn signatures from a signing pad, uploaded images of signatures, typed signatures, and saved signatures for repeat users. Multiple signers can be invited simultaneously or in a defined sequence, enforcing an order when the workflow requires it.

For guest signers (signers who do not have an OpenSign account), the platform sends a unique code to the signer's email address. The signer must enter this code before accessing the document. This is the email OTP verification described in the README, and it provides a verification record that the correct email address was used.

Documents can be set to expire after a defined number of days. Signers can also reject signing, providing a reason that is recorded and shared with the document sender. Both the expiry mechanism and the rejection flow require no extra configuration; they are part of the base platform.

Deploying OpenSign with Docker

The simplest deployment method uses Docker Compose with pre-built images. For Linux and macOS, the README provides this single-line setup command:

export HOST_URL=https://opensign.yourdomain.com && curl --remote-name-all https://raw.githubusercontent.com/OpenSignLabs/OpenSign/main/docker-compose.yml https://raw.githubusercontent.com/OpenSignLabs/OpenSign/main/Caddyfile https://raw.githubusercontent.com/OpenSignLabs/OpenSign/main/.env.local_dev && mv .env.local_dev .env.prod && docker compose up --force-recreate

This downloads the docker-compose.yml, the Caddyfile (for the Caddy reverse proxy), and the environment template. The Compose stack runs four containers: the OpenSign client (port 3000), the server API (port 8080), a MongoDB instance (port 27018), and a Caddy reverse proxy (ports 80, 443, and 3001) that handles HTTPS termination.

The README includes a critical note: the default MongoDB instance used in this deployment is not persistent. Data will be cleared on every container restart. To retain documents and user data, you must configure and supply your own MongoDB connection URL in MONGODB_URI inside .env.prod.

The .env.example shows additional required variables. APP_ID and REACT_APP_APPID must be the same 12-character identifier. MASTER_KEY is a 12-character secret that grants access to all data via the Parse dashboard. These values should be generated before the first startup and kept out of version control.

OpenSign Drive, Templates, and Audit Trails

Beyond the core signing flow, OpenSign includes three features that distinguish it from minimal e-signature tools.

OpenSign Drive is described in the README as a centralised secure vault for digital documents. It provides storage, organisation, sharing, and archiving of documents within the platform, so signed documents do not need to be exported to a separate storage system immediately after completion.

PDF templates allow teams to save a pre-positioned document with signature and field locations for repeated use. A contract template used weekly can be saved once and reused without repositioning fields each time. The README names this as a time-saving feature for standard document types.

Audit trails are generated for every document. The README describes the logged information as document activity logs with timestamps, IP addresses, email IDs, and phone numbers. A completion certificate is generated as soon as all required signers have completed the document. This certificate bundles the audit log with the document itself, providing a single artefact with the signing record.

The email templates for invitations, completion notifications, and reminders are described as configurable. The README notes that the styling of the invitation emails can be customised, which is relevant for organisations that need branded communications.

The API and Third-Party Integrations

OpenSign provides a documented REST API for embedding document signing into existing applications. API keys are generated from within the application. The API documentation is at docs.opensignlabs.com/docs/API-docs/opensign-api-v-1. Version 1.1 of the API is also referenced in the README.

Integrations with cloud storage systems, CRMs, and enterprise platforms are listed as available. A Zapier integration is mentioned specifically as a way to connect OpenSign to virtually any application that Zapier supports, without writing custom integration code.

The API path is configured via PARSE_MOUNT in the environment variables, set to /app by default. The SERVER_URL environment variable in the Docker Compose configuration constructs the full API URL from the HOST_URL value, which means the API endpoint changes with the deployment URL.

For developers building on the API, the REACT_APP_APPID variable (set in the frontend .env) and the APP_ID variable (set in the backend .env) must match. The README notes this is a requirement that will likely be consolidated in a future version.

Limitations and Data Retention Risks

The non-persistent default MongoDB is the highest-risk default for new deployers. The README states this explicitly, but it is easy to miss during a quick deployment trial. Any documents signed in the default configuration will be lost the next time the containers restart. Production deployments must point MONGODB_URI at a persistently hosted MongoDB instance before any real documents are processed.

The platform uses MongoDB exclusively. Teams that require a SQL database cannot substitute Postgres or MySQL without significant architectural changes. The .env.example shows no SQL database option.

AGPL-3.0 has a network use provision: deploying a modified version of OpenSign and making it accessible over a network to others is treated as distribution, requiring the modified source to be released. Organisations that want to customise OpenSign for their internal use and not distribute it externally are not affected by this requirement, but those building a document signing SaaS on OpenSign need to review the licence terms.

The README does not document a native mobile app. Signing happens through a browser. Mobile users sign through a mobile browser rather than a dedicated app.

Caddy handles HTTPS in the default deployment. If the HOST_URL value is set incorrectly, TLS certificate provisioning by Caddy will fail. The Caddyfile reads the HOST_URL environment variable for the domain that certificates should cover.

OpenSign Compared to DocuSeal

DocuSeal is an open-source e-signature platform that is frequently compared to OpenSign. Both provide PDF signing, multi-signer flows, and self-hosting. The qualitative difference is in the technology stack and deployment complexity.

DocuSeal uses a SQL database (Postgres or SQLite) rather than MongoDB, which some teams find easier to operate and back up. OpenSign's stack is MongoDB plus a Node.js backend; DocuSeal uses Ruby on Rails as its backend. DocuSeal can run as a single Docker container with an embedded SQLite database for small deployments, which reduces setup complexity compared to OpenSign's four-container Compose stack.

OpenSign includes a broader set of integrations through Zapier and an API with documented endpoints. It also provides the OpenSign Drive vault and completion certificates as built-in features. Teams that need Zapier connectivity out of the box, or that have an existing MongoDB infrastructure, may find OpenSign better suited than DocuSeal.

Both are AGPL-3.0 licensed, so the licence implications are the same.

Editorial conclusion

OpenSign is the right fit for organisations that need document e-signing, want to avoid vendor lock-in, and have the technical capacity to operate a Docker-based deployment with MongoDB. The critical configuration step before going to production is supplying a persistent MongoDB URI; the default Docker Compose MongoDB instance clears on restart. AGPL-3.0 licensing means any team offering OpenSign as a managed service to other organisations must release their modifications. DocuSeal is the closest open-source alternative with a simpler stack if MongoDB operations are a concern. Whether e-signatures produced by OpenSign are legally binding in a specific jurisdiction is a question for local legal counsel, not this guide.

Frequently asked questions

Official sources

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