Open source alternative to Docusign: the 3-year bill, not the sticker price
Docusign's list price is per seat, but the invoice is per seat plus every envelope over a pooled annual allowance. This page prices both sides over 36 months - the subscription as it actually bills, and a self-hosted Documenso or DocuSeal stack including the VPS, the transactional email and the hours you will spend on it.
Migration and sizing sheet
3-Year FinOps Migration & Sizing Sheet
| Line | Value | Unit | Basis |
|---|
Hosting lines are list prices for a mainstream KVM instance at 2 vCPU / 4 GB, rising through 4/8, 4/16, 8/32 and 16/64 as the stack grows; anything past 64 GB is priced as a second host rather than a bigger one. Block storage above the included NVMe is billed at $0.08 per GB per month, which is roughly the market rate for attached SSD plus an object-storage backup copy. Admin labour is your own rate, not a support contract - if nobody on the team can own this, add a managed-hosting line before you sign anything.
What Docusign actually charges for
Three separate meters run at once, and only one of them is on the pricing page in a size you can read.
The seat meter. Every person who sends an envelope needs a licence. Recipients who only sign have never been charged, which is why a 200-counterparty contract renewal costs the same as a 2-counterparty one. The trap is the word "send". A sales engineer who forwards a template to a colleague, a paralegal who re-sends a voided envelope, an ops lead who pushes offer letters from an ATS integration - each of those is a sending seat whether or not that person thinks of themselves as a Docusign user. Teams routinely discover at renewal that the true sending population is 40% larger than the list they budgeted for.
The allowance meter. On annual billing, Standard and Business Pro each include 100 envelopes per user per year, and the allowance is pooled across the whole account. That pooling is generous in one direction and invisible in the other. A 10-seat account gets 1,000 envelopes a year no matter how they are distributed, so a team that sends 40 envelopes a month is comfortably inside it. A team that sends 150 a month is at 1,800 a year - 80% over - and the surplus is billed per envelope. Envelopes that get voided, corrected and re-sent count twice. Envelopes sent through a bulk-send job count once each, which sounds obvious until a 400-recipient policy acknowledgement burns 40% of the annual pool in one afternoon.
The term meter. The published price assumes annual prepayment. Monthly billing is materially higher per seat, and mid-term seat reductions generally take effect at renewal rather than when you ask. That matters for a migration: the cheapest 36 months is not "cancel now", it is "cancel at the renewal boundary", and the calculator's three-year window is the right frame for that decision.
The same comparison across team sizes
The table below holds everything constant except headcount: 150 envelopes per seat per year, $65/hour of internal time, one admin hour a month. Read the third column against the seventh. The vendor bill is a straight line through the origin; the self-hosted bill is nearly flat, because a Compose stack that serves 10 seats serves 100 seats on the same $16-a-month box.
| Sending seats | Envelopes/yr | Vendor, 3 yr | Hosting/mo | Email/mo | Labour/mo | Self-host, 3 yr | Net saving |
|---|---|---|---|---|---|---|---|
| 3 | 450 | 4,500 | 8 | 1 | 65 | 2,664 | 1,836 |
| 5 | 750 | 7,500 | 8 | 1 | 65 | 2,664 | 4,836 |
| 10 | 1,500 | 15,000 | 8 | 1 | 65 | 2,664 | 12,336 |
| 25 | 3,750 | 37,500 | 16 | 1 | 65 | 2,952 | 34,548 |
| 50 | 7,500 | 75,000 | 16 | 1 | 65 | 2,952 | 72,048 |
| 100 | 15,000 | 150,000 | 56 | 2 | 65 | 4,428 | 145,572 |
| 150 | 22,500 | 225,000 | 56 | 2 | 65 | 4,428 | 220,572 |
| 200 | 30,000 | 300,000 | 112 | 3 | 65 | 6,480 | 293,520 |
Two things in that table are worth arguing with. The labour column does not rise with seats, which is optimistic above roughly 100 sending users - at that point you are doing user provisioning and support, not just patching. And the hosting column steps up at 25 and 100 seats, because the per-seat memory allowance finally crosses a tier boundary. Both are visible in the calculator above, so change the assumptions rather than trusting the defaults.
What the self-hosted stack is made of
Documenso and DocuSeal are both Docker Compose deployments with the same four-part shape, and the shape is what determines the hardware:
- Application container - Node (Documenso) or Ruby on Rails (DocuSeal). Handles the signing UI, PDF field placement and the webhook queue. Object storage or PostgreSQL is not optional here; it will not start without a database.
- PostgreSQL - documents, recipients, field values, the audit event log. This is the piece you must be able to restore, and the piece that grows without bound if you keep every draft forever.
- Object storage - MinIO in the reference Compose file, or any S3-compatible bucket. Holds the original and signed PDFs plus the certificate. Local disk works for a pilot and is a bad idea for production, because it couples your contract archive to the life of one VM.
- Reverse proxy - Caddy or Traefik terminating TLS. Public signing links must be HTTPS with a valid certificate, or recipients will not trust the page they are asked to sign.
On a 2 vCPU / 4 GB instance that stack idles around 1.1 GB and settles near 1.6 GB under a normal day of signing. Below 2 GB of total RAM the app container starts getting reaped during PDF rendering, which shows up as "signing failed" for the recipient and nothing at all in the application log. This is the single most common way a self-hosted e-signature pilot fails, and it is a $4-a-month problem.
Migration fidelity: what survives, line by line
| Capability | Status | What actually happens |
|---|---|---|
| Send, sign, decline, void | Full | Multi-party signing with ordering, reminders and expiry. Nothing lost. |
| Templates and field placement | Full | Rebuild templates once in the new UI. Fields are re-dragged; layouts do not import from Docusign. |
| Signed PDF with certificate | Full | Both tools append an audit certificate page. Existing Docusign certificates travel inside the PDFs you export. |
| Audit trail for new envelopes | Good | Event log covers send, view, sign, IP and timestamp. It is your database now, so retention and access control are your job. |
| Historical envelopes | Export | Platform-side identity history stays with the vendor. Export completed envelopes with certificates before cancelling. |
| Bulk send | Partial | Both expose APIs and webhooks; the batch UI is thinner and usually wants a small script. |
| Payments inside the envelope | Missing | Business Pro bundles payment collection at signing. Keep Stripe alongside, or keep the vendor for that flow. |
| SSO / SAML | Edition-dependent | Available in the self-hosted enterprise builds. Budget the licence, not just the container. |
| Qualified signature (eIDAS QES) | Not viable | Requires a qualified trust service provider. Do not self-host this; it is a legal identity, not software. |
| FedRAMP / 21 CFR Part 11 | Not viable | The authorisation belongs to the vendor's environment. Self-hosting moves the obligation onto you. |
Backup and restore, in the order that matters
Database first, and test it. A nightly pg_dump compressed and copied off the host is the minimum. The restore drill matters more than the dump: once a quarter, restore into a scratch container, open a signed envelope, confirm the certificate renders. A backup you have never restored is a file, not a backup.
Object storage second. If you run MinIO on the same host, the dump and the PDFs share a failure domain, so a nightly sync to off-host object storage is not redundancy theatre - it is the only thing standing between a dead NVMe and a lost contract archive. Versioning on the bucket is worth the few dollars it costs, because a mistaken delete is far more likely than a disk failure.
Keys and configuration third. The application encryption key, the SMTP credentials and the DNS records that make signing links resolve. Without the key, a restored database is a pile of ciphertext. Keep them in a password manager with a break-glass procedure, not in the same repository as the Compose file.
When you should keep paying
Self-hosting is the cheaper answer for a 10-to-200-seat team that sends a few thousand envelopes a year and has someone who can own a Postgres instance. It is the wrong answer when the requirement is a qualified signature, a FedRAMP authorisation, a validated 21 CFR Part 11 environment, or when there is no engineer on staff and the alternative to a subscription is a system nobody patches. A $25 seat is expensive at 100 seats and cheap compared to an unpatched public signing endpoint.
Independent estimate. SelfHostTCO is a third-party cost tool with no commercial relationship to Docusign Inc., Documenso, DocuSeal or any hosting provider named here. Plan prices, envelope allowances and overage rates change; confirm them on the vendor's own pricing page and in your contract before you budget against them. Hosting prices are list prices for a representative KVM instance and will differ by region, commitment and included egress. Labour estimates are yours to set. Nothing here is legal or compliance advice - signature validity and records retention are jurisdiction-specific questions for your counsel.
Related cost pages
If the document problem is PDF editing rather than signatures, the Acrobat alternative TCO page prices a hybrid stack where only the heavy desktop users keep a licence. If the subscription you are auditing is hosting rather than software, the Vercel vs Coolify calculator runs the same three-year method over bandwidth overage and self-hosted PaaS. The method page explains where every price on this site comes from and how the tables are recomputed before publication.