Fiabilité
Vos utilisateurs continuent, même quand le serveur de licences ne répond plus.
Une API de licences se trouve sur votre chemin de revenu. Le SDK est conçu pour survivre à un serveur injoignable. Aujourd'hui, ce serveur est le vôtre : Paperkey tourne en auto-hébergement, sous licence MIT. L'édition managée n'est pas ouverte.
Où en est Paperkey
Pas encore de service managé.
Il n'y a pas d'API hébergée à laquelle s'inscrire, donc pas de status page ni de chiffre d'uptime à publier. La seule façon de faire tourner Paperkey aujourd'hui, c'est l'édition auto-hébergée du dépôt GitHub.
Lire le guide d'auto-hébergement →Mode hors ligne 72 h
Intégré au SDK, activé par défaut.
Quand validate() renvoie valid:true, le SDK écrit le verdict dans un cache local. Si l'appel suivant échoue parce que l'API est injoignable (erreur réseau, timeout, 5xx), le SDK rejoue le verdict en cache pendant 72 h au plus. La révocation, l'expiration et tout 4xx ne sont jamais mis en cache. Une licence révoquée reste révoquée.
- 72 h par défaut, réglable via gracePeriodMs (30 jours au plus, 0 pour le désactiver).
- Stockage au choix : memoryCache (par défaut), fileSystemCache({ path }), ou le vôtre.
- Seuls les verdicts positifs sont mis en cache.
- Les clés de licence sont hachées (SHA-256) avant de servir de clé de cache. Aucune clé en clair n'est écrite sur disque.
import { createClient, fileSystemCache } from '@paperkeyhq/sdk';
const paperkey = createClient({
apiKey: process.env.PAPERKEY_PK!,
baseUrl: 'https://api.example.com',
cache: fileSystemCache({ path: app.getPath('userData') }),
});
const result = await paperkey.validate(licenseKey, fingerprint);
if (result.source === 'cache') {
// On tourne sur le dernier verdict vérifié.
// La session continue normalement.
}Disponible depuis @paperkeyhq/sdk v0.3.0. Faites pointer baseUrl vers votre instance.
Ce que vous faites tourner
Une stack petite et prévisible.
Pas de magie. Tout le monorepo est sous licence MIT, et la recette d'auto-hébergement reste volontairement simple : une base Postgres, l'API, le dashboard et un reverse proxy, le tout dans Docker sur un seul serveur.
- Caddy en frontal : certificats Let's Encrypt, HTTP/2 et HTTP/3, en-têtes de sécurité.
- Postgres 16 sur un réseau interne, jamais exposé. Le guide fournit un cron pg_dump pour les sauvegardes.
- Webhooks signés en HMAC-SHA-256, timeout de 5 secondes, mise en pause après 10 échecs consécutifs.
- Dashboard authentifié par cookie de session httpOnly. API publique via clés Bearer, avec limitation de débit par IP.
- Aucune télémétrie, aucun appel vers nos serveurs. Vos données de licence restent sur votre machine.
Zéro verrouillage
Rien dont il faudrait sortir.
Vous faites tourner le code, la base vous appartient. Le code lui-même sert de porte de sortie.
- SDK sous licence MIT : @paperkeyhq/sdk sur npm. Forkez-le, embarquez-le, ou faites pointer son baseUrl vers n'importe quel backend compatible.
- Export depuis le dashboard ou l'API : toutes les licences et activations d'un produit, en CSV ou en JSON.
- Monorepo sous licence MIT : API, dashboard, SDK et serveur MCP. Aucune fonction n'est bridée en auto-hébergement.
Liste honnête
Ce qu'on ne revendique pas.
Un fournisseur de licences qui exagère sa posture est un risque.
- Pas de service managé, pas de SLA, pas de status page publique. Rien de tout ça n'existe encore.
- Pas de SOC 2 ni d'ISO 27001. Un faux badge n'aiderait personne.
- Pas de périmètre PCI. Paperkey ne traite aucune carte bancaire, il émet et valide des licences.
- Pas de badge « trusted by », pas de logos clients.
Une question sur le fonctionnement de Paperkey ?
Écrivez à un humain, ou ouvrez une issue sur GitHub.
L'édition managée n'est pas encore ouverte
Laissez votre adresse pour être prévenu de son ouverture, sans date promise. L'édition self-host, elle, tourne dès aujourd'hui sous licence MIT.