OpenSign

OpenSign is a self-hostable, open source e-signature platform that gives individuals and organizations a secure, fully-featured alternative to commercial signing services like DocuSign, Adobe Sign, and PandaDoc. It handles the entire document lifecycle — from uploading and annotating PDFs to collecting multi-signer approvals, storing signed documents, and generating tamper-evident completion certificates — without subscription fees or vendor lock-in.

The platform is built around a React 19 frontend with native browser PDF rendering and drag-and-drop widget placement, paired with a Parse Server backend on MongoDB. Cryptographic signatures are embedded directly into PDF structure using P12/PFX certificates via the @signpdf library, making each signed document independently verifiable. File storage is flexible, supporting local filesystem or any S3-compatible object store.

OpenSign covers scenarios that typically require paid tiers on commercial platforms: bulk sending to up to 1,000 signers via CSV upload, kiosk mode for in-person signing stations, SSO integration, webhook support with authentication, API access with per-token rate limits, and a built-in email template designer. All of this is available in the self-hosted open source version.

Deployment takes minutes using Docker Compose with Caddy handling TLS termination automatically. The project has maintained a rapid release cadence of roughly two to three releases per month since its launch in late 2023, with active community contributions and comprehensive help documentation at docs.opensignlabs.com.

What You Get

• Cryptographic PDF Signing - Documents are signed using P12/PFX certificate-based digital signatures embedded directly into PDF structure via @signpdf, producing independently verifiable signed files rather than image overlays.
• Drag-and-Drop Widget Placement - A browser-based PDF editor lets you place signature, initials, text, date, checkbox, dropdown, radio, stamp, draw, and cells widgets on any page using a coordinate system that maps pixel positions to percentage-based page coordinates for cross-device fidelity.
• Multi-Signer Workflows with Sequence Enforcement - Invite multiple signers with optional signing order enforcement, link-based access without requiring accounts, and automatic progression to the next signer upon completion.
• Bulk Send to 1,000 Signers - Upload a CSV with signer details and prefill data to dispatch a template to up to 1,000 recipients simultaneously, with each receiving their own uniquely tracked document instance.
• OpenSign Drive - Centralized document vault with folder hierarchies for storing, organizing, sharing, and archiving both signed and unsigned documents within the same deployment.
• Audit Trails and Completion Certificates - Every document action is logged with timestamps, IP addresses, and email IDs. A cryptographically signed completion certificate is auto-generated when all signers complete the document.
• Visual Email Template Builder - A drag-and-drop email designer built on @usewaypoint/email-builder lets you customize signing invitations, reminders, and completion notifications with your own branding, colors, and layout.
• REST API with Per-Token Rate Limits - A versioned REST API (v1.1) with key-based authentication supports creating documents from templates, sending for signature, querying status, and managing contacts — with admin-configurable API credit limits per token.
• Kiosk Mode - Deploy a shared signing station where walk-up signers complete documents on a single device without accessing the sender’s account.
• SSO and Webhook Integration - Enterprise-grade authentication via SSO with support for multiple domains under a single tenant, plus authenticated webhooks that deliver real-time events including signer IP tracking.

Common Use Cases

• Replacing DocuSign for a small business - A consultancy sends client service agreements using OpenSign templates, collects signatures with OTP verification, and stores signed copies in OpenSign Drive — eliminating per-envelope fees entirely.
• HR onboarding at scale - An HR team uploads a CSV of new hire email addresses to bulk-send offer letters from a pre-configured template, with each recipient receiving an individual signing link and completion tracked in the reports dashboard.
• Embedding e-signatures in a SaaS product - A developer integrates the v1.1 API to trigger document creation and signature requests programmatically when users complete checkout, without ever leaving the application UI.
• Regulated-industry document compliance - A healthcare provider self-hosts OpenSign on-premises to keep patient consent forms within their own infrastructure, using audit trails and completion certificates as the compliance record.
• In-person document signing - A retail store deploys a tablet in kiosk mode so customers can sign warranty agreements and membership forms on-site without staff accessing the admin account.
• Contract management with custom branding - A law firm customizes email templates with their logo and color scheme, creates reusable contract templates with pre-positioned signature and date widgets, and uses Zapier to automatically file completed documents in their case management system.

Under The Hood

Architecture OpenSign follows a monorepo structure with two independently deployable applications: a React single-page frontend built with Vite and a Parse Server backend running on Express. Frontend-to-backend communication uses the Parse SDK for data operations and custom Express REST endpoints for file processing operations like DOCX-to-PDF conversion and PDF decryption. Business logic lives primarily in Parse Cloud Functions organized as individual files triggered by lifecycle hooks — BeforeSave, AfterSave, AfterFind — on MongoDB collections. This event-driven hook pattern enforces data consistency reactively but creates implicit coupling between the trigger system and application behavior. Redux Toolkit manages shared application state across the frontend while Zustand handles component-local state. The infrastructure layer is defined entirely in Docker Compose with Caddy as the TLS-terminating reverse proxy, giving operators a single-command deployment path.

Tech Stack The frontend runs React 19 with Vite as the build tool, using Tailwind CSS, DaisyUI, and MUI for UI components. PDF rendering relies on react-pdf (PDF.js), interactive widget placement uses react-dnd with a multi-backend for touch and mouse support, and react-rnd handles resizable and draggable widget containers. Canvas-based signature drawing uses react-konva. The pdf-lib library handles PDF manipulation on both client and server, while @signpdf with P12/PFX certificates performs the actual cryptographic signing that embeds verifiable digital signatures into PDF structure. The backend runs Parse Server on Express 5 with MongoDB as the primary data store. File storage is configurable between local filesystem and any S3-compatible object store via AWS SDK. Email delivery uses Mailgun or SMTP through Nodemailer, and internationalization is handled by i18next with browser language detection supporting multiple locales including Korean.

Code Quality Test coverage is minimal across both applications. The server-side test suite consists of a single Jasmine spec file with five boilerplate tests covering Parse Server example functions rather than any business logic. The frontend has Vitest configured but no test files exist. Error handling is inconsistent — some cloud functions propagate structured Parse.Error objects while others rely on console.log with swallowed exceptions. The codebase is predominantly JavaScript with partial TypeScript adoption in the frontend, leaving most component props and API responses untyped. ESLint and Prettier are configured and enforced at commit time via husky and lint-staged. No CI pipeline configuration was found in the repository. The high release velocity and large component surface area have outpaced quality infrastructure investment.

What Makes It Unique OpenSign’s most technically interesting contribution is its browser-based PDF widget coordinate system: widget positions are tracked as percentage-based coordinates relative to each PDF page, which means placements remain accurate when the document is rendered at different viewport sizes or on different devices during signing. The email template builder uses @usewaypoint blocks serialized to JSON and stored via URL hash fragments, enabling shareable email designs without a dedicated database schema for templates. Cryptographic signature embedding uses @signpdf to place a proper PDF signature placeholder before applying the P12 certificate, resulting in documents where the signature can be independently verified in any standards-compliant PDF reader — not just a visual stamp. The kiosk mode and bulk-send-to-1000 capability are features that competing open source alternatives either lack or limit to paid tiers.

Self-Hosting

OpenSign is licensed under the GNU Affero General Public License version 3 (AGPL-3.0), with a specific carve-out: code under the apps/OpenSignServer/cloud/customRoute directory carries its own separate license. The AGPL-3.0 is a strong copyleft license with a network-use clause — if you run a modified version of OpenSign as a service accessible over a network, you are required to make the source code of your modifications available to users of that service. For internal self-hosting where the application is only used by employees or within a private network, the practical implications are minimal. Commercial use is permitted, but distributing OpenSign as part of a product or offering it as a managed service to others while keeping modifications private conflicts with the license terms.

Running OpenSign yourself requires Docker and a domain with DNS configured. The standard deployment brings up four containers: the Parse Server backend, MongoDB, the React frontend, and Caddy for automatic TLS. MongoDB’s persistence is opt-in — the default compose configuration uses an ephemeral volume that is cleared on container restart, so configuring an external MongoDB connection string or ensuring volume persistence is a necessary first step before storing real documents. Ongoing operational responsibilities include database backups, MongoDB version upgrades, container updates when new releases are published, and monitoring storage consumption as signed PDFs accumulate. The release cadence of roughly two to three versions per month means operators need a reliable update process to stay current with security patches.

The hosted version at opensignlabs.com provides the same feature set without infrastructure overhead, including managed uptime, automatic updates, and customer support. The self-hosted path trades that convenience for data sovereignty and elimination of per-user or per-signature fees — a significant consideration for high-volume use cases. There is no documented commercial support tier for self-hosted deployments; operators rely on GitHub Issues and the Discord community for help. Features that commonly appear behind enterprise paywalls in commercial alternatives — SSO, bulk send, webhooks, API access, and white-labeling — are all included in the open source version, making the self-hosted path particularly attractive for organizations with straightforward infrastructure capabilities.