Auto-héberger Keyright

Keyright existe sous deux formes : managée (nous l’exécutons) et auto-hébergée (vous l’exécutez — une seule VM, un cluster Kubernetes ou un réseau entièrement isolé (air-gapped)). Le build auto-hébergé est le même build que le service managé, de sorte que chaque SDK, chaque endpoint et chaque comportement décrits dans cette documentation s’appliquent à l’identique ; les seules parties inactives sont la surface opérateur multi-tenant et la facturation des plans hébergés.

Cette page explique ce que vous exécutez. Quand vous êtes prêt à le mettre en place, passez au guide de déploiement pas à pas.

La section Auto-hébergement, dans l’ordre

1. Vue d’ensemble et architecture — vous êtes ici.
2. Guide de déploiement (pas à pas) — de zéro à une instance vérifiée et sous licence.
3. Référence de configuration — chaque variable d’environnement, les secrets, la marque blanche, la base de données.
4. Licence et éditions — le modèle fail-closed, l’essai, Standard vs Enterprise.
5. Raccorder votre produit à votre instance — pointez le SDK de votre application vers votre propre Keyright.
6. Exploitation et dépannage — mise à l’échelle, sauvegardes, mises à niveau, isolé (air-gapped), FAQ.

Architecture

Keyright auto-hébergé comporte exactement deux composants — une application sans état et votre base de données :

• L’application — ghcr.io/delta1-labs/keyright, un service ASP.NET Core sans état sur le port 8080. L’image ne contient que l’application — aucune base de données incluse. Elle ne conserve aucun état entre les requêtes, vous pouvez donc exécuter autant de réplicas que vous le souhaitez derrière un répartiteur de charge, sans affinité de session.
• PostgreSQL 14+ — contient tout l’état. Vous y pointez l’application avec KEYRIGHT_DB ; l’application crée et migre son propre schéma au premier démarrage (il n’y a aucun SQL à exécuter à la main).

Le chemin chaud sollicité par vos clients (/v1/activate, /v1/validate) se résume à une vérification de signature plus un décompte de sièges, et les clients vérifient les licences hors ligne entre deux activations — vous ne recevez donc pas une requête à chaque lancement de l’application. C’est pourquoi la couche applicative est peu gourmande en CPU et que la mise à l’échelle relève en réalité de la redondance et de la capacité de la base de données (voir Exploitation → Mise à l’échelle).

Ce qu’il vous faut, en un coup d’œil

• Un runtime de conteneurs — Docker 24+ avec Compose v2, ou Kubernetes 1.24+ avec Helm 3. Ou Windows/IIS avec le .NET 8 Hosting Bundle (sans conteneurs).
• PostgreSQL 14+ (16 recommandé), UTF-8. Les bundles peuvent en démarrer un pour vous à des fins d’évaluation ; en production, utilisez votre propre Postgres managé/HA.
• Une licence Keyright ou une clé d’essai fournie par Delta1 — requise pour démarrer (Keyright est fail-closed ; voir Licence). Contactez le service commercial pour un essai Enterprise de 30 jours ou une licence payante.
• L’accès Internet sortant n’est pas requis à l’exécution — Keyright fonctionne isolé (air-gapped).

Les éditions, en bref

Édition	Durée	Fonctionnalités
Essai Enterprise	30 jours	L’ensemble complet des fonctionnalités Enterprise, pour évaluer
Standard	annuelle ou perpétuelle	Le moteur de licences complet — activation hors ligne + en ligne, verrouillage par machine et sièges, droits et niveaux, révocation, le portail en libre-service, la mesure d’usage, tous les SDK
Enterprise	annuelle ou perpétuelle	Tout ce que contient Standard, plus le SSO (SAML/OIDC), la marque blanche du tableau de bord/portail, et les blocs de crédits isolés (air-gapped)

Les deux éditions payantes incluent des licences et des produits illimités — c’est votre infrastructure, donc aucun plafond de décompte. Le cycle de vie complet (essai vs payant, fenêtres de grâce, ce qui se passe à l’expiration) se trouve dans Licence et éditions.

---

Prêt à le mettre en place ? Commencez par le guide de déploiement pas à pas →