Self-host the Happier relay: SSO, mTLS and your own database
Happier is MIT-licensed, and the relay every device talks through is a container you can run yourself. This page is the list of controls that come with it — what the server enforces, what it stores, and what it hands your clients at runtime.
The shape is worth getting straight before the list. Sessions run on your developers’ own computers, against the provider CLIs they already have. The relay carries messages between those computers and their phones, browsers and desktops. It is the only piece that has to be reachable from outside, and it is the piece you are being asked to host.
Everything below is server configuration: environment variables on that container, enforced by that container, with no Happier-operated service in the path. The default posture of a fresh server is end-to-end encrypted storage and open signup, on the assumption that most people put it behind Tailscale. If you are reading this page you almost certainly want the opposite of the second half of that sentence.
What that encrypted default means underneath — which key is generated where, what your relay is left holding, and the columns it can read without one — is the encryption architecture, written for the developer rather than for you. It is the page to send anyone who asks what the server can see; this one stays on what you can enforce.
SSO: GitHub orgs, OIDC groups and client certificates
Identity is delegated to whatever you already run. Happier’s job is to enforce it on every request rather than only at signup, and to keep asking.
- Require an identity provider, re-checked on every request
- Anonymous signup is on by default because most self-hosters put the relay behind Tailscale and are done. Turn it off and require an identity provider instead, and eligibility is enforced on every authenticated HTTP route and on the realtime handshake — not only at the front door. A request from someone who no longer qualifies is refused, not downgraded.
- GitHub sign-in, restricted to your organisations
- Allow specific logins, or require membership of one or more GitHub organisations, matching any or all of them. The recommended path verifies membership through a GitHub App rather than the user’s own OAuth token, so access does not survive a developer revoking consent — and does not break when they do.
- OIDC single sign-on, with allow rules per provider
- Okta, Entra ID, Auth0, Keycloak, anything with a discovery document. Each provider gets its own allow rules: a login allowlist, permitted email domains, groups the user must be in any of, groups they must be in all of. If your IdP omits groups from the token and hands back an overage pointer instead, Happier treats the user as ineligible rather than as ungrouped.
- mTLS client certificates from your MDM
- Terminate mTLS at your reverse proxy and forward a verified identity to Happier. Map it from the certificate’s SAN email or SAN UPN so a device rotating its certificate is still the same person, and constrain it with issuer and email-domain allowlists. Unknown certificates are rejected unless you have deliberately enabled auto-provisioning.
- Offboarding: membership re-checked on the interval you set
- Membership is re-checked on an interval you set — daily by default, down to a minute — and the result is cached on the identity record. The interesting setting is what happens when your IdP is unreachable: permissive by default, or strict, where the server fails closed rather than letting a stale eligibility check stand in for a live one.
Storage policy, retention and the database you host
The controls an auditor asks about second, once they have finished with authentication.
- Three storage policies, and the default is the strict one
- End-to-end encrypted only, which rejects plaintext writes and is what a fresh server does. Optional, where an account or session decides. Or plaintext only, for organisations that manage encryption at the infrastructure layer and want server-side indexing — a real trade, stated plainly: on that setting the server can read stored content.
- Retention windows you set, enforced without reading a transcript
- Off by default: set nothing and the server keeps sessions forever. Turn it on and the session rule is conservative on purpose — a session tree is deleted only when it is inactive on the persisted flag, older than the cutoff on two separate timestamps, and not observed as live in memory, with the cutoff re-checked inside the delete transaction. It never needs to decrypt a transcript to decide.
- Turn features off for everyone at once
- Voice, social, bug-report uploads, attachments, the embedded terminal, session handoff, connected services, quota meters — each is an environment variable on the server, advertised to clients at runtime. Clients adapt to what the server says is available, so a disabled capability is absent from the UI rather than present and failing.
- Rate limits and a diagnostics endpoint you control
- A global limiter plus per-route limits, each with its own window and a key strategy you choose — by IP, or by user falling back to IP, which is what you want when a hundred developers share one VPN egress address. The server diagnostics snapshot is off until you enable it, and owner-only when you do.
- A Docker image, with SQLite or Postgres behind it
- The published relay-server image runs as a non-root user with the web UI embedded, defaults to SQLite under a single mounted volume, and takes a documented Postgres override. MySQL works too, from a source-built image — the prebuilt one deliberately leaves that client out. Pin an immutable tag; the image does not update itself.
If your organisation has zero data retention
If you are reading this page you may already have run into the wall from the other direction. Anthropic’s own Remote Control documentation is explicit: organisations with compliance requirements such as Zero Data Retention cannot enable it. In that state the toggle in the Claude Code admin console is greyed out, so it is not something an Owner can decide differently. It is also unavailable on Amazon Bedrock, Google Cloud’s Agent Platform and Microsoft Foundry, and disabled when traffic is pointed at an LLM gateway instead of api.anthropic.com.
None of that is a criticism. Remote Control keeps the session transcript on Anthropic servers so it can sync across your devices, and an organisation that has contracted for zero retention has, correctly, ruled that out. It is simply a different answer to a different question, and if your org is in that position, a relay you run yourself is the shape of answer that is left.
What procurement gets: an MIT licence and a container image
MIT. Not source-available, not open-core with the auth stack behind a commercial tier, not AGPL. Everything on this page is in the same repository as the client, under the same licence, and none of it is gated on a contract with us. If your organisation’s policy is that copyleft does not come inside the building, that policy does not stop here.
None of the controls above sits behind a purchase: there is no enterprise tier to buy and no seat count to negotiate for any of them. Depending on your procurement process that is either the reassuring part of this page or the concerning one. What you get instead is the source, an MIT licence and a container image.
Stand up a test relay and check what it enforces
The honest order is: stand the relay up on a throwaway host, point one developer at it, and read GET /v1/features to see exactly what that server is advertising to its clients. That response is the contract, and it is the fastest way to confirm a policy you set is a policy the clients will actually honour.
curl -fsSL https://happier.dev/install | bashThe Docker deployment guide covers the image, the volume and the Postgres override. The server auth reference covers every variable named above, including the recipes for a public server that requires GitHub or an OIDC provider.