Which e-signature fits: DocuSign or self-hosted OpenSign
If you are weighing a DocuSign renewal against running signing on your own servers, the choice comes down to who operates the system and where the records must live. DocuSign fits teams that want a managed service, with the vendor carrying hosting, upgrades and the signing infrastructure, and that are willing to match features to the plan tier they buy. OpenSign fits teams that want signing records, templates and audit data on their own infrastructure and have staff who can run Docker, a reverse proxy and MongoDB as a standing service.
The practical difference shows up in the operating model. OpenSign is licensed under AGPL-3, so you can run it without a per-user subscription, but the software is the smaller part of the bill. Your team owns the Docker host, TLS termination, backups and upgrades. The README warns that the default MongoDB instance in its Docker deployment is not persistent and is cleared on every restart unless you supply your own connection URL, so confirm that your MongoDB is persistent and backed up before any production document is signed. Ask DocuSign for the features your plan includes today, and confirm in OpenSign's current release notes which of your required features it supports, since its API and feature set change between versions.
The decision turns on four questions. First, how strong must signer identity be: an email OTP for guest signers may satisfy your internal policy, while documents needing advanced or qualified signatures need a different path. Second, which legal standard applies to each document type, because the ESIGN Act excludes several record categories. Third, who will operate the system after launch and who answers when a signing job fails at 2 a.m. Fourth, how much of DocuSign's API your integrations use, since every endpoint you call must be re-created or replaced before you cut over.
Which scenarios favor DocuSign and which favor OpenSign
This table maps common buyer scenarios to the platform that usually fits better and the condition that decides it. Read each row against your own signer types, volumes and operating capacity. The main takeaway is that OpenSign suits teams that can run Docker and MongoDB themselves and do not need qualified signatures, while DocuSign suits teams that need managed operations or eIDAS advanced or qualified signing.
| Scenario | Better fit | Condition that decides it |
|---|---|---|
| Short internal approvals with sequential sign-off | OpenSign, if you can host it | Your team can run Docker, git and a persistent MongoDB, and the approval chain is short and sequential. |
| Customer contracts with external signers | Depends on signer volume and checks | OpenSign verifies guest signers by email OTP. Confirm whether that level of verification meets your counterparties' expectations and your contract policy. |
| Qualified or advanced eIDAS signatures in the EU | DocuSign | DocuSign lists advanced and qualified signatures on Enhanced plans sold through sales. Confirm in writing whether OpenSign offers these levels before you rely on it. |
| API-driven signing inside your own product | Depends on your API review | OpenSign publishes an API with a v1.1 reference. Compare endpoints, webhooks and error handling against your integration before choosing either platform. |
| Contracts that must stay on your own servers | OpenSign | Self-hosting keeps documents, signer emails and audit records on infrastructure you control, provided backups and the MongoDB volume are also in scope. |
| Team with no infrastructure staff | DocuSign | Without people to patch containers, manage TLS, back up MongoDB and watch uptime, a managed service reduces the operating load you carry. |
Where signing records, signer data and keys sit under each model
Each model places signing records, signer data and signing keys in a different spot, and that decides who answers for retention, access and evidence. The cards below set out where each piece lives under DocuSign and under self-hosted OpenSign, and what to confirm before you commit.
Data location and residency
DocuSign stores envelopes and signer data in its own cloud, and its residency options depend on plan tier, so confirm the current terms in writing before relying on them. With OpenSign, data sits wherever you run MongoDB, the Docker host and the file storage that holds PDFs. Your team then owns the location, backups and access to all three, including any copies made by backups or log shipping.
Hosting models supported
DocuSign is a hosted service, and you do not operate its servers. OpenSign is self-hosted with Docker: one-line install commands fetch a docker-compose.yml, a Caddyfile and an environment file, then run docker compose up, with Docker and git as prerequisites. Confirm with the OpenSign project whether a managed or other hosting option exists before planning around one.
Signing keys and certificates
With DocuSign, the platform controls the signing certificate and completion records. With OpenSign, you control the Docker host, the environment file and the secrets it holds, so key handling becomes your responsibility. Ask which certificate OpenSign uses to seal completed PDFs and how you would rotate or replace it, because a completion certificate is only as trustworthy as the keys behind it.
Identity and sign-in options
Guest signers in OpenSign verify by email one-time passcode, which does not require them to hold an account. Staff sign-in to the OpenSign administration side is handled by the application and your deployment choices, so confirm which sign-in methods your version supports before you connect it to your directory. DocuSign's single sign-on options depend on plan tier, so check those terms with DocuSign directly.
Retention and deletion control
Under DocuSign, retention and deletion follow DocuSign's terms and your plan, so ask for those rules in writing. Under OpenSign, deletion is only real once the MongoDB data, the file storage and every backup are cleared, and the default MongoDB in the Docker deployment is not persistent and clears on every restart unless you supply your own connection URL. Write down a retention schedule that covers all three stores.
Compliance evidence and audit trails
OpenSign records activity logs with timestamps, IP addresses and signer email addresses or phone numbers, and generates a completion certificate when a document is finished. Those logs are only as good as their storage: you must keep them intact, restrict who can alter them, and retain them as records. Confirm with your auditors which evidence they will accept from a self-hosted system and which controls they expect you to document.
Why OpenSign needs your own persistent MongoDB before go-live
Before you point users at a self-hosted OpenSign instance, make sure its data survives a restart. OpenSign stores its data in MongoDB, and its README warns that the default MongoDB instance in the Docker deployment is not persistent and is cleared on every restart unless you supply your own MongoDB connection URL. The bundled database is a convenience for trying the product, not a place to keep contracts. If the connection URL is left at its default and the container restarts after an upgrade, a host reboot or a failed health check, the documents, signer records, templates and activity logs held in that database can be lost.
For a signing platform, that loss reaches every record you rely on. Signed PDFs, the activity logs with timestamps, IP addresses and signer contact details, and the completion certificates generated when a document finishes all depend on the same database. Reusable templates and the contact and role setup used for sequential signing would also need to be rebuilt by hand. In a regulated setting, losing a completed agreement or its audit trail can be as serious as losing the signature itself, so treat this as a go-live gate, not a later tuning task.
The operator's checklist is concrete. Provision a MongoDB service on storage you manage, with a backup schedule and a tested restore. Set the connection value in the OpenSign environment file to that service, then restart the stack and confirm that a test document, its certificate and a template still appear afterward. Also confirm the MongoDB version your OpenSign release requires in the project documentation at the OpenSign repository, since version support can change between releases. Record the restore test as evidence for your change and continuity files.
What each side pays for, and what recurs
DocuSign bills through a subscription tier. Its pricing page lists eIDAS simple electronic signatures on the Personal, Standard and Business Pro plans, and advanced and qualified signatures only on Enhanced plans sold through sales. Your total therefore depends on the lowest tier that covers the signature levels, features and users you need, plus any usage-based charges. The pricing page describes plan contents, but the quote is the only source for your total.
- Subscription tier: the signature level you require, and features such as SSO or data residency, can decide which tier you must buy. Confirm which features sit at each level.
- Seats: ask DocuSign whether seats are counted per sender, per administrator or per any user, and what it costs to add seats during a term.
- Envelope and API usage: confirm whether your tier includes an envelope allowance, what happens beyond it, and whether API access carries separate charges.
- Enhanced and sales-led items: advanced and qualified signatures are sold through sales, so get any compliance commitments written into the order form.
- Renewal terms: ask about renewal increases, notice periods and whether a tier change can be made mid-term.
Request the current quote in writing, listing the tier, seat count, envelope allowance, API terms and renewal notice period, before comparing it with the other side.
OpenSign is licensed under AGPL-3, so the software itself carries no license fee. The costs are the infrastructure and people needed to run it. Some items are one-time, such as setup, template rebuilding and the first configuration of MongoDB. Others recur, including hosting, storage, email delivery, backups, monitoring, upgrades and administrator time. Your actual figures depend on your infrastructure and signing volumes, so no amounts are given here.
- Setup of Docker hosts: one-time work to provision a host, install Docker and git, and run the README install path, then review the generated
docker-compose.yml,Caddyfileand environment file. - Persistent MongoDB: the default Docker MongoDB is not persistent and clears on every restart, so you must supply your own connection URL. That means recurring cost for storage, patching and operation, whether on your own servers or a managed service you already pay for.
- Reverse proxy, TLS and email delivery: recurring work to keep domains and certificates current, and an email service for OTP codes, invitations and completion notices, priced by your sending volume.
- Backups, monitoring and upgrades: recurring tasks covering database and document backups with tested restores, uptime monitoring, and applying releases. The latest release read in October 2026 was v2.41.3, so check the releases page regularly.
- Template rebuilding and staff time: one-time rebuilding of DocuSign templates and recipient flows, then ongoing administrator hours. Staff time is often the largest line, so estimate it against your own rates.
Costs rise with document volume, retention periods, the number of environments and any high availability requirement, and fall when you reuse an existing Docker or MongoDB platform. Ask any implementation partner for a written scope that names each item and who carries it.
What moving from DocuSign to OpenSign involves
The sequence below takes a DocuSign account from inventory to retirement, so that signing, templates and retained records run on OpenSign in your own infrastructure without losing completed agreements or open envelopes.
Inventory envelopes, templates and integrations
Someone from the contract owner team and the account administrator lists active templates, signer groups and routing orders, open envelopes still waiting on signers, and every integration that calls the DocuSign API or receives its webhooks. Record which templates use sequential routing, which send to guest signers who would need email OTP verification, and which are linked to downstream systems such as HR or procurement. The output is a written inventory that becomes the checklist for every later step.
Export completed agreements and audit records
Export every completed agreement that must be kept, together with its audit trail or certificate of completion, before the account is closed. DocuSign's export methods are covered on a separate page in this series. Confirm with counsel and your records team which documents, time periods and formats must be retained, and whether the audit records must stay in a non-editable form. Store the exports in a location with access controls and backups. The check is a sample of exported files opened and verified against the source envelopes.
Stand up OpenSign with persistent MongoDB
Your platform engineering team deploys OpenSign on Docker following its README, which fetches a docker-compose.yml, a Caddyfile and an environment file and starts the stack with docker compose up. Do not rely on the default MongoDB container for production data, because the README warns it is not persistent and is cleared on every restart. Supply your own MongoDB connection URL, set up backups for that database and test a restore on a separate host. The output is a running instance whose data survives a container restart and a restore test that has been documented.
Rebuild templates and email messages
The document owner recreates each retained template as an OpenSign PDF template, placing signature and field locations, signer roles and routing order, and then customizes the email templates that signers receive. Keep a mapping from each DocuSign template to its OpenSign equivalent so that the business owner can sign off on it. Expect manual rework for complex layouts. The output is an approved template register that lists each template, its owner and its test status.
Test guest OTP and sequential routing
Run test envelopes with real test documents and test mailboxes that cover each signer type: internal users, external guest signers who must pass email OTP verification, and signers in a sequential order. Test rejection with a reason, expiry and the reminder emails. Confirm that the activity log records timestamps, IP addresses and signer email addresses, and that a completion certificate is produced when the document is finished. Record each result. The check is a signed test log that shows every routing path passed.
Repoint API integrations and confirm version
Developers identify which DocuSign API calls each integration makes and map them to the OpenSign API, which has an official v1.1 reference. Confirm the API version your integration uses against that reference before you write code, because the API surface may differ from DocuSign's. Update webhook or callback handling, credentials and error handling, then test each integration in a staging environment. The output is a passing integration test suite and a record of the OpenSign version and API reference used.
Run both systems until open envelopes close
Keep the DocuSign account active while the open envelopes are completed, declined or expired, and direct new agreements to OpenSign from the cut-over date that your team sets. Monitor both systems for signers who are confused by the change and for integration errors. Do not void open envelopes unless the business owner decides to. The check is a daily count of open envelopes in DocuSign that reaches zero, recorded by the account administrator.
Archive and retire the old account
Once no envelopes are open and the retained records have been verified in the new archive, the account administrator downloads any remaining evidence, documents the retirement decision and cancels the DocuSign subscription at the end of its billing term. Confirm the cancellation terms and data deletion process with DocuSign in writing. Keep the archive and its index under your retention policy. The output is a signed retirement record and an archive that can be restored and searched.
Questions buyers ask before choosing OpenSign or DocuSign
Is an electronic signature legally valid in the United States?
In most cases, yes. Under the US ESIGN Act, a signature, contract or record tied to interstate or foreign commerce cannot be denied legal effect solely because it is electronic, according to 15 U.S.C. 7001. The Act has exceptions, including wills, codicils and testamentary trusts, most state family law matters such as adoption and divorce, most of the Uniform Commercial Code, and court orders or official court documents, as set out in 15 U.S.C. 7003. Check any document in those categories with counsel before relying on an electronic signature, whichever platform you choose.
Does self-hosted OpenSign provide eIDAS advanced or qualified signatures?
The European Commission describes simple, advanced (AdES) and qualified (QES) electronic signatures under eIDAS. A qualified signature requires a qualified certificate from a qualified trust service provider listed in a national Trusted List, which a self-hosted application does not provide on its own. Confirm with the OpenSign project and your counsel exactly which signature levels a given deployment produces, what certificate it uses and how signatures are validated. Do not assume a level until that is documented for your version and configuration. The European Commission eSignature FAQ explains the three levels.
Can our internal team run OpenSign without outside help?
A team with Docker and Linux operations experience can install OpenSign from its README, which uses Docker and git as prerequisites and a docker-compose.yml with a Caddyfile and environment file. Ongoing work includes upgrades, backups of MongoDB, TLS, SMTP delivery for signing emails, access control and monitoring. The project is built with JavaScript, Node.js, React and MongoDB, so someone must also own application patching and troubleshooting. Whether that fits your staff is an ownership question to settle before the pilot. A fixed-scope implementation from DeployOpen can cover planning, hardening, backup design and documentation inside your own infrastructure.
What drives the cost of self-hosting OpenSign compared with DocuSign?
Cost has four main parts: the software license, the infrastructure you run, the people who operate it and any outside implementation. OpenSign is AGPL-3 licensed, so there is no per-seat license fee from the project itself. The recurring costs are servers, storage, backups, email delivery, staff time for patching and support, and any retainer. DocuSign costs depend on the plan, the number of users and the envelopes sent, and its pricing page lists eIDAS advanced and qualified signatures only on Enhanced plans sold through sales. Ask any implementation partner for a fixed-scope quote that lists deliverables, environments, hardening, backup and handover in writing before work starts.
How long does it take to migrate from DocuSign to OpenSign?
The duration depends on the scope, not on a fixed number. The main factors are how many active templates and recipient roles must be rebuilt, how many open envelopes must finish on DocuSign before cutover, whether API integrations and webhooks need rewiring, how many completed agreements must be archived with their audit trails, and whether single sign-on or a production MongoDB cluster must be designed. Each of these should appear as a line item in the written scope. Ask for the timeline and its assumptions in the quote rather than accepting a generic estimate.
What does the AGPL-3 license require for an internal OpenSign deployment?
OpenSign is licensed under AGPL-3, which permits use, modification and internal deployment. The license's network clause can require that an organization offering a modified version to users over a network also makes its corresponding source available to those users. For a purely internal deployment, the practical question is whether any modifications are offered to outside users, such as signers or customers. Counsel should confirm how the license applies to your specific use, including any custom code, integrations and hosting by third parties. Treat this as a legal review, not a technical setting.
What happens to signed documents if MongoDB persistence is not configured?
The README warns that the default MongoDB instance in the Docker deployment is not persistent and is cleared on every restart unless you supply your own MongoDB connection URL. That means documents, signer records, activity logs and completion certificates stored in that default instance can be lost on restart. Before any production use, point OpenSign at a MongoDB deployment you operate, with persistent storage, replication and tested backups. Confirm the restore procedure with a test restore, and keep copies of finished documents outside the database if your retention rules require them.
How DeployOpen helps you evaluate, implement and migrate OpenSign
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, so OpenSign can be tested against your DocuSign templates, signer flows and audit needs before any decision. We work from a written scope, and the same team that builds the instance can carry it through handover and ongoing support.
How we scope
- Inventory your DocuSign templates, envelope types, routing orders and integrations before recommending OpenSign or another option.
- Define which signer flows need sequential routing, email OTP for guest signers, or rejection with reasons, and record the gaps.
- Agree deliverables, timelines and responsibilities in writing before work starts, since most engagements are fixed-scope.
How we build
- Deploy OpenSign with Docker in your own cloud account, data center or air-gapped network, following the project's documented install steps.
- Configure your own persistent MongoDB connection URL and confirm that signed documents and activity logs survive container restarts.
- Test completion certificates, activity log fields and API calls against your integration requirements, and document every gap found.
How we hand over
- Document the architecture, configuration keys, backup and restore procedures, and the signer and audit evidence your teams will rely on.
- Migrate exported DocuSign agreements and certificates into an archive structure your records team can search and retain.
- Run knowledge transfer sessions and a parallel period so open envelopes close in DocuSign before you retire it.
How we support
- Continue with ongoing support, upgrades and testing as a retainer after handover, including review of each new OpenSign release.
- Schedule periodic restore tests and confirm MongoDB persistence, TLS and access controls remain in place after updates.
- Prepare the systems, controls and evidence your compliance team needs for an assessment, while independent auditors issue any formal opinion.
