Documenso makes document signing an application you can own
Documenso covers the workflow around an electronic signature: upload a document, place fields, assign recipients, send requests, collect signatures, and keep the result. Teams can use the hosted product or run the AGPL-3.0 code themselves. The repository includes a web application, API layers, PDF viewing and manipulation, email templates, translations, payments, and browser end-to-end tooling in one TypeScript monorepo.
Self-hosting changes who controls the files and application database, which is the strongest reason to evaluate it. It also transfers responsibility for encryption keys, sender reputation, availability, backups, access control, and updates. The sample environment supports database or S3-compatible storage, several mail transports, optional Google and Microsoft login, OIDC, local or external signing transports, background-job choices, rate controls, and telemetry opt-out. Each switch creates another production decision.
Local development starts 3 supporting endpoints
The developer quickstart expects Node.js 22 or newer plus Docker and Compose. npm run dx starts PostgreSQL and Inbucket, then npm run dev serves the app. The README lists the application on port 3000, incoming development mail on 9000, PostgreSQL on 54320, and an S3 storage dashboard on 9001. These defaults make account and email flows testable without connecting a real provider.
Production is less forgiving. Stable encryption keys must replace the sample strings, SMTP needs a working sender domain, and the public and internal application URLs must be correct. Documents can remain in PostgreSQL or move to S3-compatible storage. The default signing transport is local, with options for Google Cloud HSM or a Cloud Signature Consortium provider. HSM and CSC paths require keys, certificates, credentials, and provider-specific testing.
What happened when we ran it
Our sandbox installed 2,506 npm packages in 70 seconds and occupied 2,473 MB on disk. The build completed successfully in 272 seconds on 3 CPUs and 8 GB of RAM. The measured commit 7533016 therefore compiled, but its dependency tree is large enough to affect CI cache size, container build time, and a new contributor's first checkout.
There was no tests script or target, so the harness skipped tests. That is not a passing suite. The repository had 2,839 files, about 270,445 source lines, 14 CI workflow files, workspace configuration, no top-level Dockerfile, and no tests directory. The README names Playwright for end-to-end testing and links official images, but our specified command surface did not expose a test target.
Npm audit found 9 known vulnerabilities: 6 high and 3 moderate, with 0 critical and 0 low. We did not exercise PDF signing, invitation email, document storage, OAuth, webhooks, or restore from backup. Those application paths matter more than compiler success for a signing service. A serious evaluation should test them on the exact image and environment that will be deployed.
Invite and embedded signing bugs touch core workflows
Issue 3302 documents an organization invitation problem in a current self-hosted image. A new user who follows an invite into account creation loses the invite token, completes registration, and remains outside the organization until opening the original link again. The report identifies a practical workaround, but inviting colleagues is a normal onboarding path. Test it with a new address before a wider rollout.
Issue 3195 concerns the multisign embed. Its code audit says an empty optional field is counted as unfinished, which keeps the Complete button hidden even after required fields are filled. The report was not reproduced in a browser, so it is evidence of a specific suspect code path rather than a confirmed universal failure. Still, embedded signing buyers should create one required signature and one optional text field, then verify completion on the pinned version.
Open source does not mean open pull-request intake
The code remains readable, runnable, auditable, and forkable under AGPL-3.0. The README also says outside pull requests are no longer accepted, except from a small group the maintainers invite. Everyone else is directed to detailed issues. That is a meaningful governance choice for adopters who expect upstream collaboration: a fork can carry changes, but getting them merged is not the usual open contribution path.
Commercial boundaries also need reading. The first variable in .env.example is a license key for enterprise features on self-hosted installations, and later settings are marked enterprise-only. The community code can still be useful, but teams should map required authentication, email-domain, analytics, and administration features against the licensed editions before designing a migration. AGPL obligations deserve counsel if the application will be modified and offered over a network.
Version 2.17.0 shows fast development and a busy queue
GitHub recorded 14,762 stars, 256 combined open issues and pull requests, and a last push on August 26, 2026. Version 2.17.0 was released August 19 with API rate-limit changes, endpoint deprecations, React 19 work, Docker health-check fixes, signing error logging, PDF rendering changes, recipient filters, bulk downloads, and webhook documentation fixes. The dates and queue both indicate active maintenance.
Documenso is credible infrastructure, but it is infrastructure. Our 4-minute 32-second build and 2.4 GB dependency footprint make the cost visible before Postgres, storage, and mail enter the picture. Run a proof with disposable documents, inspect generated PDFs and audit records, rotate the encryption keys, break and restore the database, and confirm invitation plus embed completion. If nobody owns those checks, the hosted service is the better fit.