Security & data
Your license data stays on your server.
The managed edition is not open. Today Paperkey runs on infrastructure you control, from MIT-licensed code you can read. This page lists what is true today, no more.
- Built in Paris
- MIT-licensed
- No cookies on this site
- No phone-home
Data residency
Where license data lives.
With the self-hosted edition, licenses, activations and your customers' emails live in the Postgres database on your server, in the region you choose. Nothing is sent to us.
- No telemetry and no phone-home in the code.
- Postgres stays on an internal Docker network and is never exposed.
- Backups are yours: the self-host guide ships a pg_dump cron, off-server copies are up to you.
- Export per product as JSON or CSV, from the dashboard or the API.
This website
One email address, if you give it.
This site sets no cookie and loads no analytics or third-party tracker. The only personal data it handles is the email you leave on the waitlist.
- Waitlist: your email, plus the date and proof of your consent (double opt-in).
- Used for one thing: telling you when the managed edition opens. Every email has an unsubscribe link.
- Your light/dark preference is kept in your browser's localStorage and never sent anywhere.
- Full details in the privacy policy.
Providers
Who handles waitlist data.
The waitlist runs on a self-hosted listmonk instance. Two providers are involved, both in the EU. No billing provider, no error tracker, no analytics.
- Hetzner Online GmbH Helsinki, Finland
Server hosting the waitlist (self-hosted listmonk)
- OVH SAS France
Sending waitlist emails (paperkey.dev SMTP)
Secrets & auth
What the code does with secrets.
All of this can be checked in the repository.
- API secret keys are shown once at creation. Only a scrypt hash is stored.
- Passwords are hashed with bcrypt. A timing decoy means unknown emails pay the same cost, so response time does not reveal accounts.
- Webhooks are signed with HMAC-SHA-256 (X-Paperkey-Signature header). The secret is shown once and never returned by the API.
- Dashboard sessions use an httpOnly, Secure, SameSite=Lax cookie.
- The self-host recipe puts Caddy in front: Let's Encrypt TLS, HTTP/2 and HTTP/3, security headers.
Access control
Least privilege in the code.
Authorization rules live in the API and are covered by integration tests.
- Optional two-factor authentication (TOTP) with recovery codes.
- Ownership checks on every authenticated route, tested on every change.
- Per-IP rate limits, with a stricter limit on auth endpoints.
- Team roles: owner, admin, viewer. Viewers are read-only.
- State-changing actions are written to an audit log.
Threat model
What license validation protects against, and what it does not.
We tell you the boundary so you can layer the right complement on top.
- Server-side: the activation cap per license is enforced, revoked and expired licenses are refused, and the SDK never caches a negative verdict.
- Your side: signing your binary and protecting the call site. Server-side validation cannot stop a binary patched to skip validate().
- Not a DRM: Paperkey does not prevent reverse engineering or memory tampering. Pair it with code signing if your threat model needs anti-tamper.
Vulnerability reports
Found a security issue?
Write to hello@paperkey.dev with the details. Please give us a reasonable delay before going public. Fixes land in the public repository.
Honest list
What we do not claim.
A licensing provider that overstates its posture is a liability.
- No managed service, so no SLA, no status page and no incident history.
- No SOC 2, no ISO 27001, no external audit.
- No PCI scope. Paperkey does not process payment cards.
- No "trusted by" badge and no customer logos.
The managed edition is not open yet
Leave your email to hear when it opens. There is no date. The self-hosted edition runs today, under the MIT license.