Релей, развёрнутый у себя

Разверните релей Happier у себя: SSO, mTLS и своя база данных

Happier под лицензией MIT, а релей, через который говорят все устройства, — это контейнер, который вы можете запустить сами. Эта страница — список механизмов контроля, которые идут вместе с ним: что сервер применяет, что он хранит и что он отдаёт вашим клиентам во время работы.

Форму стоит уяснить до списка. Сессии идут на собственных компьютерах ваших разработчиков, на тех CLI провайдеров, которые у них уже есть. Релей переносит сообщения между этими компьютерами и их телефонами, браузерами и десктопами. Это единственная часть, до которой обязательно нужен доступ снаружи, и это та часть, которую вам предлагается разместить у себя.

Всё ниже — это конфигурация сервера: переменные окружения на том контейнере, применяемые тем же контейнером, без единого сервиса под управлением Happier на этом пути. Исходная позиция свежего сервера — хранение со сквозным шифрованием и открытая регистрация, из предположения, что большинство ставит его за Tailscale. Если вы читаете эту страницу, вам почти наверняка нужно обратное от второй половины этого предложения.

Что этот шифрованный режим по умолчанию означает внутри — какой ключ где генерируется, что остаётся на руках у вашего релея и какие колонки он может прочитать без ключа — описано в архитектуре шифрования, написанной для разработчика, а не для вас. Именно эту страницу стоит отправлять всем, кто спрашивает, что видит сервер; эта же остаётся про то, что вы можете обеспечить сами.

SSO: организации GitHub, группы OIDC и клиентские сертификаты

Идентичность делегируется тому, что у вас уже работает. Задача Happier — проверять её на каждом запросе, а не только при регистрации, и продолжать спрашивать.

Требуйте провайдера идентичности, с перепроверкой на каждом запросе: Анонимная регистрация включена по умолчанию, потому что большинство тех, кто разворачивает релей у себя, ставят его за Tailscale и на этом заканчивают. Выключите её и потребуйте вместо неё провайдера идентичности — и право доступа будет проверяться на каждом аутентифицированном HTTP-маршруте и на рукопожатии реального времени, а не только на входной двери. Запрос от того, кто больше не проходит по правилам, отклоняется, а не понижается в правах.
Вход через GitHub, ограниченный вашими организациями: Разрешайте конкретные логины или требуйте членства в одной или нескольких организациях GitHub, с совпадением по любой из них или сразу по всем. Рекомендуемый путь проверяет членство через GitHub App, а не через собственный OAuth-токен пользователя, так что доступ не переживает отзыв согласия разработчиком — и не ломается, когда тот его отзывает.
Единый вход по OIDC, с правилами доступа для каждого провайдера: Okta, Entra ID, Auth0, Keycloak — всё, у чего есть discovery-документ. У каждого провайдера свои правила доступа: список разрешённых логинов, допустимые почтовые домены, группы, в любой из которых пользователь должен состоять, и группы, в которых он должен состоять во всех. Если ваш IdP не кладёт группы в токен, а возвращает вместо них указатель из-за превышения размера, Happier считает пользователя не имеющим права доступа, а не пользователем без групп.
Клиентские сертификаты mTLS из вашей MDM: Терминируйте mTLS на своём обратном прокси и передавайте в Happier проверенную идентичность. Сопоставляйте её с SAN email или SAN UPN из сертификата, чтобы устройство, сменившее сертификат, оставалось тем же человеком, и ограничивайте её списками разрешённых издателей и почтовых доменов. Неизвестные сертификаты отклоняются, если вы намеренно не включили автоматическое создание учётных записей.
Офбординг: членство перепроверяется с заданным вами интервалом: Членство перепроверяется с интервалом, который задаёте вы, — по умолчанию раз в сутки, вплоть до минуты, — а результат кэшируется в записи идентичности. Самая интересная настройка здесь — что происходит, когда ваш IdP недоступен: по умолчанию мягкий режим, либо строгий, в котором сервер закрывается, а не позволяет устаревшей проверке прав заменить собой живую.

Политика хранения, срок хранения и база данных, которую держите вы

Те механизмы контроля, о которых аудитор спрашивает вторым делом, закончив с аутентификацией.

Три политики хранения, и по умолчанию действует строгая: Только сквозное шифрование — этот режим отклоняет запись открытым текстом, и именно он у свежего сервера. Опционально — решает аккаунт или сессия. Или только открытый текст — для организаций, которые управляют шифрованием на уровне инфраструктуры и хотят индексацию на стороне сервера; это настоящий размен, и сказано о нём прямо: на этой настройке сервер может читать сохранённое содержимое.
Окна хранения задаёте вы, а применяются они без чтения транскрипта: По умолчанию выключено: не задавайте ничего — и сервер хранит сессии вечно. Включите — и правило для сессии окажется намеренно консервативным: дерево сессии удаляется, только если она неактивна по сохранённому признаку, старше отсечки по двум отдельным меткам времени и не наблюдается живой в памяти, причём отсечка перепроверяется внутри транзакции удаления. Расшифровывать транскрипт, чтобы это решить, ему никогда не нужно.
Выключайте функции сразу для всех: Голос, социальные функции, загрузка отчётов об ошибках, вложения, встроенный терминал, передача сессий, подключённые сервисы, счётчики квот — каждая из этих функций управляется переменной окружения на сервере и объявляется клиентам во время работы. Клиенты подстраиваются под то, что сервер объявил доступным, так что выключенная возможность отсутствует в интерфейсе, а не присутствует и падает.
Ограничения частоты запросов и диагностический эндпоинт под вашим контролем: Глобальный ограничитель плюс ограничения на каждый маршрут, у каждого своё окно и выбранная вами стратегия ключа — по IP или по пользователю с откатом на IP, а это как раз то, что нужно, когда сотня разработчиков делит один выходной адрес VPN. Снимок серверной диагностики выключен, пока вы его не включите, и доступен только владельцу.
Docker-образ, за которым SQLite или Postgres: Публикуемый образ relay-server работает от непривилегированного пользователя, со встроенным веб-интерфейсом, по умолчанию использует SQLite на одном примонтированном томе и принимает задокументированное переопределение на Postgres. MySQL тоже работает — из образа, собранного из исходников: в готовом образе этот клиент намеренно не оставлен. Закрепляйте неизменяемый тег; образ сам себя не обновляет.

Если у вашей организации нулевое хранение данных

Если вы читаете эту страницу, возможно, вы уже упёрлись в ту же стену с другой стороны. Собственная документация Anthropic по Remote Control говорит прямо: организации с требованиями соответствия вроде Zero Data Retention включить его не могут. В таком состоянии переключатель в админ-консоли Claude Code неактивен, так что решить иначе Owner не может. Он также недоступен на Amazon Bedrock, на Agent Platform в Google Cloud и на Microsoft Foundry и отключается, когда трафик направлен на LLM-шлюз вместо api.anthropic.com.

Ничто из этого не критика. Remote Control держит транскрипт сессии на серверах Anthropic, чтобы синхронизировать его между вашими устройствами, а организация, которая договорилась о нулевом хранении данных, совершенно правильно это исключила. Это просто другой ответ на другой вопрос, и если ваша организация в таком положении, релей, который вы держите сами, — та форма ответа, которая остаётся.

Что получает отдел закупок: лицензия MIT и образ контейнера

MIT. Не source-available, не open-core с аутентификацией за коммерческим тарифом, не AGPL. Всё на этой странице лежит в том же репозитории, что и клиент, под той же лицензией, и ничто из этого не закрыто договором с нами. Если политика вашей организации в том, что копилефт внутрь не заносят, эта политика здесь не спотыкается.

Ни один из механизмов контроля выше не спрятан за покупкой: нет ни корпоративного тарифа, который надо купить, ни числа мест, о котором надо договариваться. В зависимости от вашего процесса закупок это либо самая успокаивающая часть этой страницы, либо самая тревожная. Взамен вы получаете исходный код, лицензию MIT и образ контейнера.

Поднимите тестовый релей и проверьте, что он применяет

Честный порядок такой: поднимите релей на одноразовом хосте, направьте на него одного разработчика и прочитайте GET /v1/features, чтобы увидеть ровно то, что этот сервер объявляет своим клиентам. Этот ответ и есть контракт, и это самый быстрый способ убедиться, что политика, которую вы задали, — это политика, которую клиенты действительно соблюдут.

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

Руководство по развёртыванию в Docker описывает образ, том и переопределение на Postgres. Справочник по аутентификации на сервере описывает каждую переменную, названную выше, включая рецепты для публичного сервера, который требует GitHub или OIDC-провайдера.