If you want a DocuSign alternative that runs on your own server, three open source apps cover the whole flow: they email the document, collect signatures in the browser, keep an audit log and seal the final PDF with a certificate. Documenso needs PostgreSQL and a certificate you supply, while DocuSeal starts from a single container and generates its own self-signed certificate. OpenSign runs on MongoDB, and its default configuration ships an expired certificate whose private key is public. @signpdf is an MIT-licensed Node.js library: it writes the signature into the PDF and leaves the interface and the sending to your application. By default, all three apps sign with the server's certificate rather than each signer's. A qualified signature under the EU's eIDAS rules costs extra with Documenso or DocuSeal, and OpenSign documents no way to get one.
A complete signing app, or a library to build on
Documenso, DocuSeal and OpenSign work the same way. You upload a PDF and place fields on it in a visual editor, then each recipient gets an email link to fill in and sign their part in the browser. Once everyone has signed, the instance renders the final PDF, signs it with its certificate and keeps an audit log of each step, with time and IP address. Documenso can enforce a signing order and ask for an access code. DocuSeal can email signers a one-time code, and keeps SMS verification for its Pro edition. OpenSign can also require an emailed code and enforce a strict order, and it accepts DOCX files, which it converts to PDF with LibreOffice.
Documenso and DocuSeal expose a REST API and webhooks. Documenso's v2 API has an OpenAPI reference. The free edition of DocuSeal creates signing requests from a template and tracks each signer, but has no route for building a template from a file: templates are prepared in the web UI, and creating them through the API is a Pro feature. OpenSign's API and webhooks belong to its cloud: a "Live" token or webhook needs the Professional or Teams plan, and the public code contains neither that API nor webhook delivery.
@signpdf works one layer down, and it is the library OpenSign signs with. A helper reserves a signature field in the PDF, then @signpdf/signpdf writes into it the signature computed by a signer; the only published one, @signpdf/signer-p12, signs with a P12 certificate. The library has no UI, sends nothing and records no consent, and the signature stays invisible until your code draws a box for it. The signature belongs to whoever holds the P12, so two people signing means two certificates.
What each tool writes into the PDF
A PDF signature's format shows in its subfilter. Documenso writes ETSI.CAdES.detached by default, the one used by PAdES signatures, and keeps adbe.pkcs7.detached as an option for older readers. DocuSeal signs through the HexaPDF Ruby library without changing its default signature type, which is a CMS signature in adbe.pkcs7.detached. @signpdf also writes adbe.pkcs7.detached by default, and its subFilter option switches to ETSI.CAdES.detached, which its README names as the requirement for a PAdES-compliant signature. OpenSign keeps that default. In all four cases the signature covers the file's bytes, so any later edit breaks it.
The certificate names who signed. With Documenso, it belongs to the instance and is applied by the platform rather than by each signer, and none ships with it: without a password-protected .p12 file, the app starts but every signing attempt fails. Documenso also accepts a key kept in Google Cloud HSM. DocuSeal generates its own certificate chain on first boot, "DocuSeal Self-Host Autogenerated", valid for 100 years. You can replace it with an uploaded certificate (.p12, .pfx) or, on Pro, with "DocuSeal Trusted Signature", where the instance sends the PDF's checksum to DocuSeal for signing. OpenSign reads its certificate from the PFX_BASE64 variable. The .env.local_dev file, which the README's install command copies to .env.prod, already contains one: self-signed, issued to OpenSign Labs, expired since 16 November 2024, with its passphrase, opensign, in the same file. Anyone who reads the repo therefore has its private key. @signpdf takes whatever P12 you hand it without checking the issuer or the expiry date, and the key has to be exportable: a key kept in an HSM or a cloud key vault means writing your own Signer.
A self-signed certificate proves the file hasn't changed, but Acrobat shows a warning. According to Documenso's docs, Adobe's green checkmark requires a certificate from an authority on the Adobe Approved Trust List, and OpenSign's docs also point to buying one from such an authority. DocuSeal calls only its cloud certificate "trusted by Adobe"; the one a self-hosted instance generates is unknown to every PDF reader.
A timestamp from an authority (TSA) is optional in Documenso and DocuSeal. Once you configure one, Documenso also adds long-term validation (LTV) data and an archival timestamp to the signature. DocuSeal accepts an RFC 3161 timestamp server, but in its code the method meant for LTV (maybe_enable_ltv) returns the file unchanged. OpenSign's public code calls no authority at all: the time it records comes from the server's clock. @signpdf requests no timestamp token at all: the time it records is the signingTime attribute, read from the machine's clock, and a 2021 request for timestamping was closed for inactivity.
Simple, advanced or qualified: what the signature is worth
The EU's eIDAS regulation sets three levels. Any electronic signature, even a simple one, can't be denied legal effect or refused as evidence in court just because it is electronic or isn't qualified (Article 25). An advanced signature must also be uniquely linked to the signer and able to identify them, be created with data the signer keeps under their control, and be tied to the document so that any later change is detectable (Article 26). A qualified signature is an advanced one made with a qualified signature creation device and based on a qualified certificate, and its legal effect equals a handwritten signature. The European Commission's eSignature FAQ sets out these definitions.
With default settings, Documenso, DocuSeal and OpenSign sign with the server's key. The document is sealed and any edit shows, but the signer's identity rests on access to their inbox, plus a code if you ask for one. Documenso's docs class this as a simple electronic signature under eIDAS, and state compliance with the US ESIGN Act and UETA. DocuSeal's documentation and security pages don't say which eIDAS level its default signature reaches. OpenSign says it complies with the ESIGN Act, UETA and eIDAS without naming a level.
For the advanced and qualified levels, Documenso and DocuSeal have each person sign through a trust service provider or with their own certificate. Documenso has done this since v2.13.0 (18 June 2026) with its csc mode, which routes signing to a provider that speaks the Cloud Signature Consortium API, and each recipient authenticates with that provider. That mode needs the Enterprise licence and a TSA, accepts a single provider per instance and enforces sequential signing, yet the "Signature Levels" page in the docs still lists AES and QES as "Planned". DocuSeal charges per qualified signature: $0.20 with an ID card reader or the signer's local certificate, $2 through a trust service provider, without saying which plan unlocks it. OpenSign documents no route to either level. With @signpdf, what the signature is worth depends on the certificate each signer holds and on the authority that issued it.
What each tool needs to run
Read from the repositories and documentation on 7 October 2026.
| Tool | Licence | What you run | Signature applied | Timestamp | Latest release |
|---|---|---|---|---|---|
| Documenso | AGPL-3.0, except the packages/ee/ directory | PostgreSQL 14 or later, SMTP, an HTTPS reverse proxy, a .p12 certificate you provide; 2 GB of RAM in production | PAdES, the instance's certificate | optional TSA, with LTV | 2.19.0, 29 Sep 2026 |
| DocuSeal | AGPL-3.0, with an attribution clause | one container; SQLite by default, PostgreSQL beyond 1,000 documents a year; 1 GB of RAM for 500 KB PDFs | CMS (adbe.pkcs7.detached), a self-signed certificate generated by the instance | optional RFC 3161 server, no LTV in the open source code | 3.3.1, 5 Oct 2026 |
| OpenSign | AGPL-3.0, except the cloud/customRoute directory | MongoDB, a Node.js server on Parse Server, a React client and Caddy; Mailgun or SMTP; memory not documented | CMS (adbe.pkcs7.detached), the instance's certificate, public and expired in the default configuration | no token: the server's clock | 2.41.3, 21 Aug 2026 |
| @signpdf | MIT | an npm dependency in a Node.js backend; one P12 certificate per signer | CMS by default, PAdES as an option; the integrator's certificate | no token: the machine's clock | 3.3.0, 29 Dec 2025 |
Documenso only runs on PostgreSQL, which holds the documents and the job queue by default; S3 and Redis are optional. Its docs allow 1 GB of RAM for a trial and 2 GB or more in production. DocuSeal makes do with one container: with no database configured it writes to SQLite, and with no Redis its Puma server starts its own and runs Sidekiq inside its process. Its docs recommend PostgreSQL beyond 1,000 documents a year or for production API use, and size memory by file size, up to 2 vCPUs and 4 GB for 100 MB PDFs. OpenSign starts as four containers, MongoDB, the Node.js server, the React client and Caddy, and its docs give no memory figure. Its database runs without authentication, and the docs say not to expose its port. According to the repo's configuration file, the server won't initialise without Mailgun or SMTP. @signpdf has nothing to host, though its development branch now requires Node 22, where the published release accepts Node 12.
Where the projects stand
DocuSeal ships almost every week, usually on a Monday: 173 releases since July 2023, 40 of them in 2026. Two accounts author 3,146 of the 3,154 commits on its main branch, and the 3.3.0 release notes, which mention security hardening, ask every self-hosted instance to update. Documenso shipped sixteen minor versions in 2026, from v2.4.0 in January to v2.19.0 on 29 September. Since June 2026 it no longer merges outside pull requests, except from a small group of contributors it invites.
OpenSign has published 83 releases since November 2023, 11 of them in 2026. Version 2.41.3 came out on 21 August 2026, and nothing has been pushed to the repo since. Its recent merges come from sync-to-public_repo branches on the nxglabs account, and the 2.39.0 notes link to nxglabs/OpenSign-Enterprise, a repository that isn't public. The release notes describe that edition as well: the per-recipient access code announced in 2.41.0 isn't in the public code.
@signpdf has published nothing in 2026: version 3.3.0 dates from 29 December 2025, and the develop branch has only had dependency bumps and one fix since. Valery Buchinsky, who owns the repository, authored 361 commits; the next human contributor has 14. The library is still heavily downloaded: 308,893 times for @signpdf/signpdf in the week of 28 September 2026, and still 34,014 times for the old node-signpdf package, deprecated and frozen since October 2023.
Licences and paid plans
Documenso, DocuSeal and OpenSign are under AGPL-3.0, and @signpdf under MIT, with no paid plan or cloud.
Documenso's packages/ee/ directory falls under a commercial licence that can only be used in production with an Enterprise subscription. It holds advanced and qualified signing through a provider, organisation SSO (SAML, OIDC), passkey or 2FA re-authentication before document actions, 21 CFR Part 11 compliance, custom email sending domains and the embeddable editor. Enterprise pricing isn't published. The docs state that internal use without modification, or calling the API from closed-source software, stays within the free Community Edition. The cloud runs from a free plan capped at 5 documents a month to $250 a month for white-label, with Enterprise on quote.
DocuSeal adds one term to the AGPL under its section 7(b): every copy keeps the original DocuSeal attribution in its interfaces, and white-label is a Pro feature. On-premises Pro costs $20 per user per month, billed yearly at $240, plus $0.20 per document signed through the API or embedding. Pro also keeps back user roles, automatic reminders, SMS verification, conditional fields, bulk send from a CSV or XLSX file, SSO and SAML, template creation through the API, and embeddable forms for React, Vue, Angular or plain JavaScript.
OpenSign's LICENSE file carves its server's cloud/customRoute directory (DOCX conversion, decrypting protected PDFs, account deletion) out of the AGPL, under "the license defined" in that directory, which contains none. Its free cloud tier has no signature limit. The Professional and Teams plans open up the API and webhooks, and each document created through the API uses up credits; a custom subdomain is an Enterprise feature. A self-hosted instance handles multiple users, which the cloud keeps for its Teams and Enterprise plans.