happier
GitHubDocumentation
Relay auto-hébergé

Héberge toi-même le relay Happier : SSO, mTLS et ta propre base de données

Happier est sous licence MIT, et le relay par lequel passent tous les appareils est un conteneur que tu peux faire tourner toi-même. Cette page liste les contrôles qui l’accompagnent — ce que le serveur impose, ce qu’il stocke, et ce qu’il transmet à tes clients au runtime.

Autant clarifier la forme avant la liste. Les sessions tournent sur les ordinateurs de tes développeurs, avec les CLI de providers qu’ils ont déjà. Le relay transporte les messages entre ces ordinateurs et leurs téléphones, navigateurs et desktops. C’est la seule pièce qui doit être joignable depuis l’extérieur, et c’est la pièce qu’on te demande d’héberger.

Tout ce qui suit relève de la configuration du serveur : des variables d’environnement sur ce conteneur, appliquées par ce conteneur, sans aucun service opéré par Happier sur le chemin. La posture par défaut d’un serveur neuf, c’est un stockage chiffré de bout en bout et une inscription ouverte, en partant du principe que la plupart des gens le placent derrière Tailscale. Si tu lis cette page, tu veux presque certainement l’inverse de la seconde moitié de cette phrase.

Ce que ce défaut chiffré signifie en dessous — quelle clé est générée où, ce qu’il reste à ton relay entre les mains, et les colonnes qu’il peut lire sans clé — c’est l’architecture de chiffrement, écrite pour le développeur plutôt que pour toi. C’est la page à envoyer à quiconque demande ce que le serveur peut voir ; celle-ci s’en tient à ce que tu peux imposer.

SSO : orgs GitHub, groupes OIDC et certificats client

L’identité est déléguée à ce que tu fais déjà tourner. Le rôle de Happier est de la faire respecter à chaque requête, et pas seulement à l’inscription — puis de continuer à la redemander.

Exiger un fournisseur d’identité, revérifié à chaque requête
L’inscription anonyme est activée par défaut, parce que la plupart des auto-hébergeurs placent le relay derrière Tailscale et en restent là. Désactive-la et exige un fournisseur d’identité à la place : l’éligibilité est alors vérifiée sur chaque route HTTP authentifiée et sur le handshake temps réel — pas seulement à la porte d’entrée. Une requête venant de quelqu’un qui ne remplit plus les conditions est refusée, pas dégradée.
Connexion GitHub, restreinte à tes organisations
Autorise des logins précis, ou exige l’appartenance à une ou plusieurs organisations GitHub, en correspondance avec l’une d’elles ou toutes. Le chemin recommandé vérifie l’appartenance via une GitHub App plutôt qu’avec le token OAuth de l’utilisateur, de sorte que l’accès ne survit pas au retrait de consentement d’un développeur — et ne casse pas quand celui-ci le retire.
Authentification unique OIDC, avec des règles d’autorisation par provider
Okta, Entra ID, Auth0, Keycloak, tout ce qui expose un document de découverte. Chaque provider a ses propres règles d’autorisation : une liste de logins autorisés, des domaines d’e-mail permis, des groupes dont l’utilisateur doit faire partie d’au moins un, des groupes dont il doit tous faire partie. Si ton IdP omet les groupes dans le token et renvoie à la place un pointeur de dépassement, Happier considère l’utilisateur comme non éligible plutôt que comme sans groupe.
Certificats client mTLS depuis ton MDM
Termine le mTLS sur ton reverse proxy et transmets une identité vérifiée à Happier. Fais-la correspondre à l’e-mail SAN ou à l’UPN SAN du certificat, pour qu’un appareil qui renouvelle son certificat reste la même personne, et encadre-la par des listes d’émetteurs et de domaines d’e-mail autorisés. Les certificats inconnus sont rejetés, sauf si tu as délibérément activé l’auto-provisionnement.
Départs : appartenance revérifiée à l’intervalle que tu définis
L’appartenance est revérifiée à un intervalle que tu définis — quotidien par défaut, jusqu’à la minute — et le résultat est mis en cache sur la fiche d’identité. Le réglage intéressant, c’est ce qui se passe quand ton IdP est injoignable : permissif par défaut, ou strict, où le serveur ferme la porte plutôt que de laisser une vérification d’éligibilité périmée tenir lieu de vérification en direct.

Politique de stockage, rétention et base de données que tu héberges

Les contrôles qu’un auditeur demande en deuxième, une fois qu’il en a fini avec l’authentification.

Trois politiques de stockage, et celle par défaut est la stricte
Chiffré de bout en bout uniquement, ce qui rejette les écritures en clair et correspond au comportement d’un serveur neuf. Optionnel, où un compte ou une session décide. Ou texte clair uniquement, pour les organisations qui gèrent le chiffrement au niveau infrastructure et veulent une indexation côté serveur — un vrai compromis, énoncé sans détour : dans ce réglage, le serveur peut lire le contenu stocké.
Des fenêtres de rétention que tu définis, appliquées sans lire une transcription
Désactivé par défaut : ne règle rien et le serveur garde les sessions indéfiniment. Active-le et la règle sur les sessions est volontairement conservatrice — un arbre de sessions n’est supprimé que s’il est inactif selon le drapeau persisté, plus ancien que la limite selon deux horodatages distincts, et non observé comme vivant en mémoire, la limite étant revérifiée à l’intérieur de la transaction de suppression. Il n’a jamais besoin de déchiffrer une transcription pour décider.
Désactiver des fonctionnalités pour tout le monde d’un coup
La voix, le social, l’envoi de rapports de bug, les pièces jointes, le terminal intégré, le transfert de session, les services connectés, les jauges de quota — chacun est une variable d’environnement sur le serveur, annoncée aux clients à l’exécution. Les clients s’adaptent à ce que le serveur déclare disponible : une capacité désactivée est donc absente de l’interface plutôt que présente et en échec.
Des limites de débit et un endpoint de diagnostic que tu contrôles
Un limiteur global plus des limites par route, chacune avec sa propre fenêtre et une stratégie de clé que tu choisis — par IP, ou par utilisateur avec repli sur l’IP, ce qui est exactement ce que tu veux quand une centaine de développeurs partagent une seule adresse de sortie VPN. L’instantané de diagnostic du serveur est désactivé tant que tu ne l’actives pas, et réservé au propriétaire une fois activé.
Une image Docker, avec SQLite ou Postgres derrière
L’image relay-server publiée tourne sous un utilisateur non-root avec l’interface web embarquée, utilise SQLite par défaut sous un unique volume monté, et accepte une surcharge Postgres documentée. MySQL fonctionne aussi, depuis une image construite depuis les sources — l’image pré-construite laisse délibérément ce client de côté. Épingle un tag immuable ; l’image ne se met pas à jour toute seule.

Si ton organisation applique une rétention de données nulle

Si tu lis cette page, tu as peut-être déjà heurté le mur dans l’autre sens. La documentation Remote Control d’Anthropic est explicite : les organisations soumises à des exigences de conformité comme le Zero Data Retention ne peuvent pas l’activer. Dans cet état, l’interrupteur dans la console d’administration de Claude Code est grisé : ce n’est donc pas quelque chose qu’un Owner peut trancher autrement. Il est aussi indisponible sur Amazon Bedrock, sur l’Agent Platform de Google Cloud et sur Microsoft Foundry, et désactivé quand le trafic est dirigé vers une gateway LLM plutôt que vers api.anthropic.com.

Rien de tout cela n’est une critique. Remote Control garde la transcription de la session sur les serveurs d’Anthropic pour pouvoir la synchroniser entre tes appareils, et une organisation qui a contractualisé une rétention nulle a, à juste titre, exclu cela. C’est simplement une autre réponse à une autre question, et si ton organisation est dans ce cas, un relay que tu fais tourner toi-même est la forme de réponse qui reste.

Ce que reçoit le service achats : une licence MIT et une image de conteneur

MIT. Pas « source-available », pas de l’open core avec la couche d’authentification derrière un palier commercial, pas de l’AGPL. Tout ce qui est sur cette page se trouve dans le même dépôt que le client, sous la même licence, et rien n’est conditionné à un contrat avec nous. Si la politique de ton organisation veut que le copyleft n’entre pas dans la maison, cette politique ne bute pas ici.

Aucun des contrôles ci-dessus n’est derrière un achat : il n’y a pas de palier entreprise à acheter ni de nombre de sièges à négocier pour l’un d’eux. Selon ton processus d’achat, c’est soit la partie rassurante de cette page, soit la partie inquiétante. Ce que tu obtiens à la place, c’est le code source, une licence MIT et une image de conteneur.

Monte un relay de test et vérifie ce qu’il impose

L’ordre honnête est le suivant : monte le relay sur un hôte jetable, dirige un développeur dessus, et lis GET /v1/features pour voir exactement ce que ce serveur annonce à ses clients. Cette réponse est le contrat, et c’est le moyen le plus rapide de confirmer qu’une politique que tu as définie est une politique que les clients respecteront vraiment.

curl -fsSL https://happier.dev/install | bash

Le guide de déploiement Docker couvre l’image, le volume et la surcharge Postgres. La référence d’authentification du serveur couvre chaque variable nommée ci-dessus, y compris les recettes pour un serveur public exigeant GitHub ou un provider OIDC.