Most e-signature tools send signatures. Very few let you own the whole thing — the documents, the signers, and the audit trail — on your own hardware. We built Lifted Sign to be the one you can self-host, and to be genuinely boring to run: it boots on nothing but SQLite.
Repo: https://github.com/LiftedHoldings/lifted-sign (AGPL-3.0)
The pitch, honestly
Upload a PDF, place fields, add signers, send single-use signing links. Each completed document is cryptographically sealed and ships with a Certificate of Completion — the audit trail of signer identities, timestamps, IP addresses, and consent records that ESIGN and UETA actually call for.
The difference is where all of that lives: your infrastructure, not a vendor's cloud. Data residency and air-gapped deploys are the default, not an enterprise tier.
SQLite by default
This is the part I'm happiest with. Lifted Sign boots with zero external services — one secret, and you're signing:
docker run --rm -e SIGN_SECRET=$(openssl rand -base64 48) -p 8080:8080 ghcr.io/liftedholdings/lifted-sign
Open http://localhost:8080 and you have a working signing server. SIGN_SECRET is the only required setting; every login session, signer-access cookie, and one-time code is keyed off it, so the server fails closed and loud if it's missing, too short, or a placeholder. Point it at Postgres with a single env var when you outgrow a file.
Real PAdES certification, not a flattened image
A lot of "e-signature" ends up being a signature image burned into a PDF. Lifted Sign gives completed PDFs a PKCS#7 / PAdES digital signature that any PDF reader can verify and that breaks visibly if the file is altered. No signing certificate installed yet? It falls back to a tamper-evident AES-integrity seal, so a completed document is never left unsealed.
How signing works
- Prepare. Drop in a PDF, place signature/date/text/checkbox fields by anchor, add signers.
- Send. Each signer gets a single-use link. They review, hit the ESIGN/UETA consent gate, and sign in the browser — no account required.
- Seal. Once everyone signs, the PDF is sealed with a PAdES certification signature and a Certificate of Completion. Download both, or pull them via the API.
Developer-first
There's a clean REST API under /api/mysign/* for creating envelopes, adding signers, placing fields, sending, reminding, voiding, and downloading sealed PDFs and certificates. The in-app /developers page documents the endpoints and serves an OpenAPI spec.
Ready-to-use, dependency-free clients are vendored in the repo — a Python client (3.8+, standard library only) and a Node client (18+, built-in fetch/FormData). Both are MIT-licensed even though the server is AGPL, so integrating against Lifted Sign never touches your application's licensing. Point either client's base_url at your own install and drive it.
Build from source
git clone https://github.com/LiftedHoldings/lifted-sign.git
cd lifted-sign
cp .env.example .env
python -c "import secrets; print('SIGN_SECRET=' + secrets.token_urlsafe(48))" # put this in .env
pip install -e .
python -m sign # or: docker compose up
Why AGPL, and why free
Self-hosting is GA and free forever under the AGPL — no seat limits, no volume policing, no "contact us." The license is the only agreement. Passwordless email magic-link sign-in works out of the box; SMTP, Postgres, Google/phone sign-in, and PAdES certificates are optional add-ons you switch on by env var as you grow.
If you'd rather not run it, there's a managed instance in free open beta at https://sign.liftedholdings.com — same software, TLS and backups handled — but the self-hosted path stays free regardless.
- Repo + docs: https://github.com/LiftedHoldings/lifted-sign
-
Architecture write-up (the ESIGN/UETA model, the three-runtime design, the persistence and security layers) lives in
docs/ARCHITECTURE.md - Built by Lifted Holdings; see also Lifted Payments for interchange-plus merchant services with 3-D Secure card processing.
It's a debut open-source project, so contributors are what turn it into a community — there are good first issue labels waiting. Bug reports, docs, tests, and code all welcome.
Top comments (1)
I appreciate how Lifted Sign uses SQLite as the default database, allowing for a self-contained and easy-to-deploy solution. The fact that it can be easily switched to Postgres with a single environment variable is also a great example of flexibility in design. What I'm curious about is how the choice of SQLite impacts the scalability of Lifted Sign, particularly in scenarios where a large number of users are accessing the system concurrently - have you considered any optimizations or limits to mitigate potential performance bottlenecks?