Relay autoalojado

Autoaloja el relay de Happier: SSO, mTLS y tu propia base de datos

Happier tiene licencia MIT, y el relay por el que hablan todos los dispositivos es un contenedor que puedes ejecutar tú. Esta página es la lista de controles que vienen con él — qué impone el servidor, qué almacena y qué les entrega a tus clientes en tiempo de ejecución.

Conviene tener clara la forma antes de la lista. Las sesiones se ejecutan en los propios ordenadores de tus desarrolladores, contra las CLI de proveedor que ya tienen. El relay lleva los mensajes entre esos ordenadores y sus teléfonos, navegadores y escritorios. Es la única pieza que tiene que ser accesible desde fuera, y es la pieza que se te pide alojar.

Todo lo de abajo es configuración de servidor: variables de entorno en ese contenedor, aplicadas por ese contenedor, sin ningún servicio operado por Happier en el camino. La postura por defecto de un servidor recién instalado es almacenamiento cifrado de extremo a extremo y registro abierto, dando por hecho que la mayoría lo pone detrás de Tailscale. Si estás leyendo esta página, casi con seguridad quieres lo contrario de la segunda mitad de esa frase.

Lo que ese valor cifrado por defecto significa por debajo — qué clave se genera dónde, con qué se queda tu relay y qué columnas puede leer sin ninguna — es la arquitectura de cifrado, escrita para el desarrollador y no para ti. Es la página que hay que mandarle a quien pregunte qué puede ver el servidor; esta se queda en lo que puedes imponer tú.

SSO: organizaciones de GitHub, grupos de OIDC y certificados de cliente

La identidad se delega en lo que ya tengas en marcha. El trabajo de Happier es imponerla en cada petición y no solo en el registro, y seguir preguntando.

Exige un proveedor de identidad, comprobado en cada petición: El registro anónimo viene activado por defecto porque la mayoría de quienes autoalojan ponen el relay detrás de Tailscale y con eso les basta. Desactívalo y exige en su lugar un proveedor de identidad, y la elegibilidad se comprueba en cada ruta HTTP autenticada y en el handshake de tiempo real — no solo en la puerta de entrada. Una petición de alguien que ya no cumple se rechaza, no se degrada.
Inicio de sesión con GitHub, restringido a tus organizaciones: Permite logins concretos, o exige pertenencia a una o varias organizaciones de GitHub, cumpliendo cualquiera de ellas o todas. La vía recomendada verifica la pertenencia a través de una GitHub App en lugar del token de OAuth del propio usuario, de modo que el acceso no sobrevive a que un desarrollador revoque el consentimiento — y tampoco se rompe cuando lo hace.
Inicio de sesión único con OIDC, con reglas de permiso por proveedor: Okta, Entra ID, Auth0, Keycloak, cualquier cosa con un documento de descubrimiento. Cada proveedor tiene sus propias reglas de permiso: una lista de logins permitidos, dominios de correo autorizados, grupos a los que el usuario debe pertenecer a alguno, grupos a los que debe pertenecer a todos. Si tu IdP omite los grupos del token y devuelve en su lugar un puntero de desbordamiento, Happier trata al usuario como no elegible en vez de como sin grupos.
Certificados de cliente mTLS desde tu MDM: Termina el mTLS en tu proxy inverso y reenvía una identidad verificada a Happier. Mapéala desde el correo SAN o el SAN UPN del certificado para que un dispositivo que rota su certificado siga siendo la misma persona, y acótala con listas de emisores y de dominios de correo permitidos. Los certificados desconocidos se rechazan salvo que hayas habilitado deliberadamente el aprovisionamiento automático.
Bajas: la pertenencia se vuelve a comprobar con el intervalo que fijes: La pertenencia se vuelve a comprobar con un intervalo que fijas tú — a diario por defecto, hasta cada minuto — y el resultado se cachea en el registro de identidad. El ajuste interesante es qué pasa cuando tu IdP no está accesible: permisivo por defecto, o estricto, donde el servidor falla cerrando en vez de dejar que una comprobación de elegibilidad caducada sustituya a una en vivo.

Política de almacenamiento, retención y la base de datos que alojas tú

Los controles por los que un auditor pregunta en segundo lugar, cuando ha terminado con la autenticación.

Tres políticas de almacenamiento, y la de por defecto es la estricta: Solo cifrado de extremo a extremo, que rechaza las escrituras en claro y es lo que hace un servidor recién instalado. Opcional, donde decide una cuenta o una sesión. O solo en claro, para organizaciones que gestionan el cifrado en la capa de infraestructura y quieren indexación en el servidor — un intercambio real, dicho sin rodeos: con ese ajuste el servidor puede leer el contenido almacenado.
Ventanas de retención que fijas tú, aplicadas sin leer una transcripción: Desactivada por defecto: no configures nada y el servidor guarda las sesiones para siempre. Actívala y la regla de sesión es conservadora a propósito — un árbol de sesión se borra solo cuando está inactivo según la marca persistida, es más antiguo que el corte en dos marcas de tiempo distintas y no se observa vivo en memoria, con el corte vuelto a comprobar dentro de la transacción de borrado. Nunca necesita descifrar una transcripción para decidir.
Desactiva funciones para todo el mundo de una vez: Voz, social, subidas de informes de error, adjuntos, la terminal integrada, el traspaso de sesiones, los servicios conectados, los medidores de cuota — cada uno es una variable de entorno en el servidor, anunciada a los clientes en tiempo de ejecución. Los clientes se adaptan a lo que el servidor dice que hay disponible, así que una capacidad desactivada está ausente de la interfaz en vez de presente y fallando.
Límites de tasa y un endpoint de diagnóstico que controlas tú: Un limitador global más límites por ruta, cada uno con su propia ventana y una estrategia de clave que eliges tú — por IP, o por usuario recurriendo a la IP, que es lo que quieres cuando cien desarrolladores comparten una sola dirección de salida de VPN. La instantánea de diagnóstico del servidor está desactivada hasta que la habilitas, y solo para el propietario cuando lo haces.
Una imagen de Docker, con SQLite o Postgres por detrás: La imagen publicada del relay-server corre como usuario no root con la interfaz web incrustada, usa SQLite por defecto sobre un único volumen montado y admite una sustitución documentada por Postgres. MySQL también funciona, desde una imagen construida a partir del código — la precompilada deja fuera ese cliente a propósito. Fija una etiqueta inmutable; la imagen no se actualiza sola.

Si tu organización tiene retención cero de datos

Si estás leyendo esta página puede que ya te hayas topado con el muro desde el otro lado. La propia documentación de Remote Control de Anthropic es explícita: las organizaciones con requisitos de cumplimiento como Zero Data Retention no pueden activarlo. En ese estado el interruptor de la consola de administración de Claude Code aparece en gris, así que no es algo que un Owner pueda decidir de otra manera. Tampoco está disponible en Amazon Bedrock, en Agent Platform de Google Cloud ni en Microsoft Foundry, y se desactiva cuando el tráfico se apunta a un gateway de LLM en lugar de a api.anthropic.com.

Nada de eso es una crítica. Remote Control mantiene la transcripción de la sesión en servidores de Anthropic para poder sincronizarla entre tus dispositivos, y una organización que ha contratado retención cero ha descartado eso, correctamente. Es sencillamente una respuesta distinta a una pregunta distinta y, si tu organización está en esa situación, un relay que ejecutas tú es la forma de respuesta que queda.

Lo que obtiene el departamento de compras: una licencia MIT y una imagen de contenedor

MIT. Ni código disponible, ni open core con la pila de autenticación detrás de un nivel comercial, ni AGPL. Todo lo de esta página está en el mismo repositorio que el cliente, bajo la misma licencia, y nada de ello depende de un contrato con nosotros. Si la política de tu organización es que el copyleft no entra en el edificio, esa política no se detiene aquí.

Ninguno de los controles de arriba está detrás de una compra: no hay un nivel enterprise que comprar ni un recuento de asientos que negociar para ninguno de ellos. Según tu proceso de compras, esa es la parte tranquilizadora de esta página o la preocupante. Lo que obtienes a cambio es el código, una licencia MIT y una imagen de contenedor.

Levanta un relay de prueba y comprueba qué impone

El orden honesto es: levanta el relay en un host desechable, apunta a él a un desarrollador y lee GET /v1/features para ver exactamente qué está anunciando ese servidor a sus clientes. Esa respuesta es el contrato, y es la forma más rápida de confirmar que una política que has fijado es una política que los clientes van a respetar de verdad.

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

La guía de despliegue con Docker cubre la imagen, el volumen y la sustitución por Postgres. La referencia de autenticación del servidor cubre todas las variables nombradas arriba, incluidas las recetas para un servidor público que exija GitHub o un proveedor de OIDC.