DEV Community: Daniel Wilson Kemp

Lifted Sign: a self-hostable e-signature server that runs on nothing but SQLite

Daniel Wilson Kemp — Thu, 23 Jul 2026 08:37:23 +0000

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.

Lifted ShipKit: open-source multi-carrier shipping labels with forced 3-D Secure

Daniel Wilson Kemp — Thu, 23 Jul 2026 08:36:26 +0000

Shipping labels are one of those features that look trivial until you actually build them. You need a carrier-rating API, a payment step, PCI scope for the card data, and — the part nobody warns you about — a fraud problem, because labels bought with stolen cards are a top chargeback category. Real goods, shipped fast, disputed weeks later.

We open-sourced Lifted ShipKit to collapse that whole stack into a few lines of code. It's MIT-licensed, self-hostable, and it ships with a drop-in checkout widget that forces 3-D Secure on every card charge.

Repo: https://github.com/LiftedHoldings/lifted-shipkit

What it actually is

ShipKit is a Kotlin/JVM backend plus a dependency-free browser widget. The backend wraps EasyPost for real multi-carrier shipping — address verification, live USPS/UPS/FedEx rate compare, SmartRates, label purchase, batch, scan forms, customs, and tracking webhooks — and adds a payment layer on top of it. The widget is a UMD global (window.ShipKit), so it mounts in plain HTML, React, Vue, Svelte, or anything else with a <script> tag and no build step.

The part I want to talk about is the payment layer, because that's the design decision that makes ShipKit different from "just call EasyPost yourself."

Why forced 3-D Secure is the whole point

Most teams that add shipping wire a rating API straight to a payment processor and then quietly own two things they didn't sign up for: the PCI scope for card data, and the chargeback liability when a fraudster buys a label with a stolen card.

ShipKit forces 3-D Secure on every card charge. The issuer authenticates the buyer before the label prints, which shifts fraud-and-chargeback liability off the merchant. Card data goes through hosted fields, so it stays out of your PCI scope. This isn't an enterprise upsell or a config flag you can forget to turn on — it's always on, by construction.

For a product whose fraud profile is "real goods, shipped immediately, disputed later," making authentication non-optional is the correct default.

60-second try

No account, no keys — the published Docker image comes up immediately (shipping and payment features return 503 until you supply an EasyPost key and 3DS credentials):

docker run --rm -e SHIPKIT_PORT=8080 -p 8080:8080 ghcr.io/liftedholdings/lifted-shipkit

Then open http://localhost:8080.

Drop it into your own checkout

The headline use case is keeping your app and your checkout and adding ShipKit for the rate-compare -> pay -> print-label step. Mount a node, point it at your backend, wire a callback:

<div id="ship"></div>
<script src="/js/shipkit.js"></script>
<script>
  ShipKit.init({
    mount: '#ship',
    endpoint: '/api',
    apiKey: 'pk_live_your_publishable_key',   // publishable pk_… key — safe in the browser
    onPurchase: ({ trackingCode, labelUrl }) => {
      // hand the finished label back to your order flow
    }
  });
</script>

Keys come in two scopes: the browser widget uses a publishable pk_… key (the backend confines it to the customer flow), while your server calls use a secret sk_… key that never appears in client code. Every surface restyles with --sk-* CSS variables — no !important, no build step.

Self-host it fully

git clone https://github.com/LiftedHoldings/lifted-shipkit.git
cd shipkit
cp .env.example .env                       # EASYPOST_API_KEY + your 3DS keys
./gradlew build                            # Kotlin 2.0.21, JVM 17
./gradlew shipkitKeygen -Plabel=my-store   # mint an API key
./gradlew run                              # API + widget on :8080

Every setting is read from the environment. Two optional, env-driven hooks let a platform operate a fleet of instances from a control plane — a bearer-guarded POST /api/config/markup to update the shipping markup remotely, and a fire-and-forget label.purchased webhook (carrier cost and buyer charge in integer cents) — both off by default when their tokens are unset.

Shipping as a profit center

One design choice worth calling out for anyone building a store: whoever owns the payments account owns the markup. ShipKit prices every label at the carrier rate plus your own percentage and fixed fee (percentage_markup + fixed_fee_cents), applied server-side and shown at checkout. Self-host it and that margin is 100% yours on every label.

Why open source it

Because the honest version of this tool is one you can read, fork, and run yourself. MIT license, dependency-free frontend, clean modular backend, no per-label SaaS fee when you self-host. If you'd rather not run infra, there's a managed tier and a 3-D Secure merchant-account tier — but the code, the widget, and self-hosting stay free.

Live demo: https://liftedholdings.com/shippingtool
Repo + docs: https://github.com/LiftedHoldings/lifted-shipkit
The payments side (interchange-plus merchant services with 3-D Secure, built by the same team): https://liftedpayments.com

If you build something with it, or you want ShipKit woven into your own framework, we'd genuinely like to hear about it. PRs and issues welcome.