Relay self-hosted

Ospita da te il relay di Happier: SSO, mTLS e il tuo database

Happier ha licenza MIT, e il relay attraverso cui parla ogni dispositivo è un container che puoi eseguire tu stesso. Questa pagina è l’elenco dei controlli che ne fanno parte — cosa impone il server, cosa memorizza e cosa consegna ai tuoi client a runtime.

Vale la pena chiarire la struttura prima dell’elenco. Le sessioni girano sui computer dei tuoi sviluppatori, con le CLI dei provider che già hanno. Il relay trasporta i messaggi tra quei computer e i loro telefoni, browser e desktop. È l’unico pezzo che deve essere raggiungibile dall’esterno, ed è il pezzo che ti si chiede di ospitare.

Tutto ciò che segue è configurazione del server: variabili d’ambiente su quel container, applicate da quel container, senza alcun servizio gestito da Happier nel percorso. La postura predefinita di un server appena installato è archiviazione crittografata end-to-end e registrazione aperta, nel presupposto che la maggior parte delle persone lo metta dietro Tailscale. Se stai leggendo questa pagina, quasi certamente vuoi l’opposto della seconda metà di quella frase.

Cosa significhi sotto il cofano quel default crittografato — quale chiave viene generata dove, cosa resta in mano al tuo relay e quali colonne può leggere senza una chiave — è l’architettura di crittografia, scritta per lo sviluppatore anziché per te. È la pagina da mandare a chiunque chieda cosa possa vedere il server; questa resta su ciò che puoi imporre tu.

SSO: organizzazioni GitHub, gruppi OIDC e certificati client

L’identità è delegata a qualunque cosa tu già gestisca. Il compito di Happier è imporla su ogni richiesta anziché solo alla registrazione, e continuare a chiedere.

Richiedi un identity provider, ricontrollato a ogni richiesta: La registrazione anonima è attiva per impostazione predefinita perché la maggior parte di chi fa self-hosting mette il relay dietro Tailscale e ha finito. Disattivala e richiedi invece un identity provider: l’idoneità viene verificata su ogni rotta HTTP autenticata e sull’handshake realtime — non solo alla porta d’ingresso. Una richiesta da parte di qualcuno che non è più idoneo viene rifiutata, non declassata.
Accesso con GitHub, limitato alle tue organizzazioni: Consenti login specifici, oppure richiedi l’appartenenza a una o più organizzazioni GitHub, verificando che corrispondano ad almeno una o a tutte. Il percorso consigliato verifica l’appartenenza tramite una GitHub App anziché tramite il token OAuth dell’utente, così l’accesso non sopravvive alla revoca del consenso da parte di uno sviluppatore — e non si rompe quando questo accade.
Single sign-on OIDC, con regole di autorizzazione per provider: Okta, Entra ID, Auth0, Keycloak, qualunque cosa abbia un documento di discovery. Ogni provider ha le proprie regole di autorizzazione: una allowlist di login, i domini email consentiti, i gruppi di cui l’utente deve far parte per almeno uno, i gruppi di cui deve far parte per tutti. Se il tuo IdP omette i gruppi dal token e restituisce invece un puntatore di overage, Happier tratta l’utente come non idoneo anziché come privo di gruppi.
Certificati client mTLS dal tuo MDM: Termina mTLS sul tuo reverse proxy e inoltra un’identità verificata a Happier. Mappala dall’email SAN o dall’UPN SAN del certificato, così un dispositivo che ruota il proprio certificato resta la stessa persona, e vincolala con allowlist di emittenti e di domini email. I certificati sconosciuti vengono rifiutati a meno che tu non abbia deliberatamente abilitato il provisioning automatico.
Offboarding: appartenenza ricontrollata all’intervallo che imposti: L’appartenenza viene ricontrollata a un intervallo che imposti tu — giornaliero per impostazione predefinita, fino a un minuto — e il risultato viene messo in cache sul record di identità. L’impostazione interessante è cosa succede quando il tuo IdP non è raggiungibile: permissiva per impostazione predefinita, oppure strict, dove il server fallisce in chiusura anziché lasciare che un controllo di idoneità obsoleto sostituisca uno reale.

Policy di archiviazione, conservazione e il database che ospiti tu

I controlli di cui un auditor chiede per secondi, una volta che ha finito con l’autenticazione.

Tre policy di archiviazione, e quella predefinita è la più severa: Solo end-to-end encrypted, che rifiuta le scritture in chiaro ed è ciò che fa un server appena installato. Opzionale, dove decide un account o una sessione. Oppure solo testo in chiaro, per le organizzazioni che gestiscono la crittografia a livello di infrastruttura e vogliono l’indicizzazione lato server — un compromesso reale, detto chiaramente: con quell’impostazione il server può leggere i contenuti memorizzati.
Finestre di conservazione che imposti tu, applicate senza leggere una trascrizione: Disattivata per impostazione predefinita: non imposti nulla e il server conserva le sessioni per sempre. Attivala e la regola sulle sessioni è volutamente conservativa — un albero di sessione viene eliminato solo quando è inattivo secondo il flag persistito, più vecchio della soglia su due timestamp distinti e non osservato come attivo in memoria, con la soglia ricontrollata dentro la transazione di eliminazione. Non ha mai bisogno di decrittare una trascrizione per decidere.
Disattiva funzioni per tutti in una volta sola: Voce, social, upload delle segnalazioni di bug, allegati, terminale integrato, handoff di sessione, servizi connessi, indicatori di quota — ciascuno è una variabile d’ambiente sul server, comunicata ai client a runtime. I client si adattano a ciò che il server dichiara disponibile, così una capacità disattivata è assente dall’interfaccia anziché presente e non funzionante.
Rate limit e un endpoint di diagnostica che controlli tu: Un limitatore globale più limiti per rotta, ciascuno con la propria finestra e una strategia di chiave che scegli tu — per IP, oppure per utente con ripiego sull’IP, che è quello che serve quando cento sviluppatori condividono un unico indirizzo di uscita VPN. Lo snapshot di diagnostica del server è disattivato finché non lo abiliti, e riservato all’owner quando lo fai.
Un’immagine Docker, con SQLite o Postgres dietro: L’immagine relay-server pubblicata gira come utente non root con l’interfaccia web integrata, usa per impostazione predefinita SQLite su un singolo volume montato, e accetta un override Postgres documentato. Funziona anche MySQL, da un’immagine compilata dai sorgenti — quella precompilata lascia deliberatamente fuori quel client. Fissa un tag immutabile; l’immagine non si aggiorna da sola.

Se la tua organizzazione ha la zero data retention

Se stai leggendo questa pagina potresti aver già incontrato il muro dall’altra direzione. La documentazione di Remote Control di Anthropic è esplicita: le organizzazioni con requisiti di conformità come la Zero Data Retention non possono abilitarlo. In quello stato l’interruttore nella console di amministrazione di Claude Code è disattivato, quindi non è qualcosa che un Owner possa decidere diversamente. Non è disponibile nemmeno su Amazon Bedrock, sull’Agent Platform di Google Cloud e su Microsoft Foundry, ed è disabilitato quando il traffico è puntato su un gateway LLM anziché su api.anthropic.com.

Niente di tutto questo è una critica. Remote Control tiene la trascrizione della sessione sui server Anthropic per poterla sincronizzare tra i tuoi dispositivi, e un’organizzazione che ha contrattualizzato la conservazione zero lo ha, correttamente, escluso. È semplicemente una risposta diversa a una domanda diversa, e se la tua organizzazione si trova in quella posizione, un relay che gestisci tu è la forma di risposta che resta.

Cosa ottiene l’approvvigionamento: una licenza MIT e un’immagine container

MIT. Non source-available, non open-core con lo stack di autenticazione dietro un livello commerciale, non AGPL. Tutto ciò che è su questa pagina si trova nello stesso repository del client, sotto la stessa licenza, e niente di tutto ciò è vincolato a un contratto con noi. Se la policy della tua organizzazione è che il copyleft non entra in azienda, quella policy non si ferma qui.

Nessuno dei controlli qui sopra è dietro un acquisto: non c’è un tier enterprise da comprare né un numero di postazioni da negoziare per nessuno di essi. A seconda del tuo processo di approvvigionamento questa è la parte rassicurante o quella preoccupante della pagina. Quello che ottieni invece è il sorgente, una licenza MIT e un’immagine container.

Metti su un relay di prova e verifica cosa impone

L’ordine onesto è: metti su il relay su un host usa e getta, puntaci uno sviluppatore, e leggi GET /v1/features per vedere esattamente cosa quel server sta dichiarando ai suoi client. Quella risposta è il contratto, ed è il modo più veloce per confermare che una policy che imposti è una policy che i client rispetteranno davvero.

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

La guida al deployment con Docker copre l’immagine, il volume e l’override Postgres. Il riferimento sull’autenticazione del server copre ogni variabile citata sopra, comprese le ricette per un server pubblico che richiede GitHub o un provider OIDC.