Самостоятельно размещаемые окружения

Самостоятельно размещаемое окружение выполняет сеансы Claude Code в облаке на инфраструктуре, которой управляет ваша организация. Облачный сеанс — это любой сеанс, который выполняется не на машине разработчика: разработчики запускают их из claude.ai, мобильных и настольных приложений, терминала с помощью claude --cloud и запланированных процедур, и по умолчанию они выполняются на инфраструктуре Anthropic. В самостоятельно размещаемом окружении эти же сеансы выполняются внутри вашей сети, а опыт разработчика остается прежним, за исключением различий в Доступности и ограничениях и известных проблемах на странице развертывания. Если ваша команда не использует облачные сеансы, здесь нечего настраивать: сеансы в терминале или IDE всегда выполняются на собственной машине разработчика. Если вы хотите запустить Claude Code на собственной постоянно работающей машине и управлять ею с других устройств, используйте Remote Control, который также доступен на планах Pro и Max. Когда вы будете готовы к настройке, переходите прямо к быстрому старту; чтобы сначала проверить позицию безопасности, начните с Развертывание в production. Остальная часть этой страницы объясняет, как работает самостоятельное размещение и когда его выбирать.

​

Как работают самостоятельно размещаемые окружения

Самостоятельное размещение состоит из трех частей:

• Environment: именованное место назначения, на которое можно отправлять облачные сеансы. Ваша организация создает окружения в параметрах администратора claude.ai, и каждое группирует набор runners.
• Runner: программа, работающая на хостах внутри вашей сети. Runners выполняют сеансы; идея такая же, как у self-hosted CI runner.
• Session: одна задача Claude Code, запущенная разработчиком.

Когда разработчик запускает облачный сеанс, интерфейс запуска сеанса показывает средство выбора окружения, в котором перечислены окружения, размещаемые Anthropic, наряду с любыми созданными вашей организацией. Если они выбирают ваше, плоскость управления Anthropic помещает сеанс в очередь вашего окружения, где runner требует его, клонирует репозиторий, выбранный разработчиком, и запускает процесс Claude Code на вашем хосте для его выполнения. Runner аутентифицируется на вашем git-хосте с учетными данными, которые вы настраиваете; Настройка git охватывает варианты. Сеансы достигают ваших внутренних сервисов изнутри вашей сети, и вашего git-хоста таким же образом, когда он внутренний; трафик к Anthropic, опрос очереди, поток событий сеанса и вывод модели — это исходящий HTTPS к api.anthropic.com, с коротким списком дополнительных хостов, которые сеансы могут достичь в Требования к сети. Anthropic никогда не подключается к вашей сети. Два поля Claude Code на диаграмме — это процессы сеанса: один runner, выполняющий два сеанса одновременно, до его настроенной емкости. Runner служит одному владельцу за раз и блокируется на этого владельца, когда требует свой первый сеанс, поэтому проверенный код никогда не смешивается между владельцами; Жизненный цикл runner охватывает правило. Вы можете запустить runners самостоятельно и держать их работающими, или запустить автомасштабирующийся оркестратор, второй процесс, который вы размещаете, который запускает runners по мере очереди сеансов; каждый runner выходит самостоятельно, когда его работа завершается. В любом случае вы настраиваете окружение один раз, и оно появляется в средстве выбора на каждой поддерживаемой поверхности.

​

Доступность и ограничения

Проверьте это перед планированием развертывания:

• Plans: публичная бета для организаций Team и Enterprise. Самостоятельно размещаемые окружения отключены по умолчанию; Owner включает Allow self-hosted environments на странице администратора Cloud environments, что требует Claude Code on the web для включения для организации.
• Zero Data Retention: недоступно для организаций с включенным Zero Data Retention.
• Model inference: сеансы используют Anthropic API, и вывод не может быть маршрутизирован через Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry или LLM gateway.
• Surfaces: сеансы, запущенные из Claude Code on the web, мобильных и настольных приложений, запланированных процедур и терминала с claude --cloud или --environment dispatch, могут работать в самостоятельно размещаемых окружениях. Сеансы Claude Tag могут работать в них тоже, но Claude не может использовать Access bundles в этих сеансах еще. Сеансы Claude Security и Code Review еще не маршрутизируются на них. Поддержка этих двух поверхностей следует отдельно.
• Repositories: сеансы проверяют репозитории из GitHub; смотрите Варианты аутентификации GitHub.
• Billing: сеансы в самостоятельно размещаемом окружении потребляют использование Claude Code вашей организации так же, как сеансы в окружениях, размещаемых Anthropic.

​

Почему самостоятельное размещение

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

• Network access: сеансы работают внутри вашей сети и могут достичь внутренних сервисов, баз данных и реестров без их раскрытия в общедоступный интернет
• Custom tooling: предварительно установите компиляторы, SDK и внутренние CLI в образ runner, чтобы каждый сеанс начинался готовым к сборке
• Compliance: проверки репозитория и артефакты сборки остаются на инфраструктуре, которой вы управляете. Содержимое сеанса все еще идет на api.anthropic.com для вывода модели.

​

Окружения, runners и сеансы

Окружения управляются на странице Cloud environments в параметрах администратора claude.ai; runners — это процессы, которые вы запускаете и управляете на собственной инфраструктуре.

​

Ключевые концепции

Эти термины появляются на всех страницах self-hosted: В полях API, утверждениях токенов и названиях метрик окружение отображается как pool, а ID окружения — это pool_id. Справка отображает два написания, включая устаревшие названия флагов pool. Runner служит одному владельцу за раз. Первый сеанс, который требует runner, блокирует runner на владельца этого сеанса, и runner затем запускает сеансы только для этого владельца, до настроенной емкости. Кто владелец, зависит от того, как был запущен сеанс:

• Сеансы, запущенные пользователем: владелец — это учетная запись этого пользователя.
• Сеансы канала Claude Tag: Claude запускает их без прикрепленной учетной записи пользователя, поэтому владелец — это агент Claude Tag, который запустил сеанс. Каждый сеанс канала, который запускает этот агент, имеет одного владельца, кто бы ни отправил сообщение Slack, поэтому runner, заблокированный на нем, служит сеансам, которые разные люди запустили, когда вы запускаете его с --capacity выше одного или с положительным --drain-grace-sec. Runner, заблокированный на пользователя, никогда не требует эти, и runner, заблокированный на агента Claude Tag, никогда не требует сеансы пользователя.

Минимальный размер флота — это количество владельцев, которых вы ожидаете быть активными одновременно, считая пользователей и агентов Claude Tag.

​

Жизненный цикл сеанса

Когда разработчик запускает сеанс и выбирает ваше окружение, плоскость управления Anthropic помещает сеанс в очередь окружения. Отсюда:

1. Runner со свободной емкостью требует сеанс и держит аренду на нем.
2. Runner клонирует репозиторий в свой рабочий каталог и порождает дочерний процесс Claude Code.
3. Дочерний процесс передает события обратно по HTTPS, пока runner продолжает опрашивать; каждый опрос обновляет аренду и служит сердцебиением.
4. Если runner перестает опрашивать примерно на 60 секунд, сервер повторно ставит сеанс в очередь для другого runner.

Runner дает каждому запросу опроса 10 секунд. Когда запрос истекает, теряется или получает ответ, который runner не может разобрать, runner продолжает служить своим активным сеансам и повторяет попытку через секунду или две вместо ожидания следующего запланированного опроса. Например, перехватывающий прокси, который отвечает на опрос своей собственной страницей, производит ответ, который runner не может разобрать. Каждый раз, когда другой запрос не удается одним из этих способов, runner удваивает промежуток перед следующей повторной попыткой, до 20 секунд, и сокращает промежуток, когда аренда близка к истечению.

​

Жизненный цикл runner

Первый сеанс, который требует runner, блокирует runner на владельца этого сеанса, и runner запускает до --capacity одновременных сеансов для этого владельца. Пока runner имеет активные сеансы и не получил сигнал завершения или не достиг времени выхода, runner продолжает требовать работу заблокированного владельца в очереди. Что происходит после их завершения, зависит от --drain-grace-sec:

• По умолчанию 0: runner выходит, как только его активные сеансы завершаются, без опроса дополнительно, поэтому оркестратор, под которым вы его развертываете, такой как Kubernetes, может перезапустить его со свежим диском, готовым служить любому владельцу.
• При положительном значении: runner продолжает опрашивать очередь заблокированного владельца в течение этого количества секунд перед выходом.

Этот жизненный цикл изолирует проверенный код каждого владельца без необходимости runner удалять состояние диска между владельцами. То, как ваша инфраструктура останавливает runner, решает, нужен ли вам --retire-at. Убийство, которое доставляет SIGTERM, не требует флага: runner дренирует как Timing shutdown описывает, или продолжает служить сеансам, которые он уже держит, когда вы устанавливаете --defer-shutdown-max-min. Если ваша инфраструктура вместо этого уничтожает хосты в известное время по стене без сигнала, или с периодом благодати слишком коротким для дренирования, такой как ограничение времени жизни песочницы или отзыв spot-instance, передайте --retire-at <epoch-seconds> установленный на несколько минут раньше этого времени. В момент выхода:

1. Runner перестает принимать новую работу.
2. Runner выпускает каждый активный сеанс через тот же путь выпуска, который использует флаг --release-idle-session-min, поэтому сеанс возобновляется на свежем runner, когда пользователь отправляет свое следующее сообщение. Когда runner выпускает каждый сеанс, зависит от его состояния:
   • Runner выпускает сеанс, который находится в середине хода, как только этот ход завершается.
   • Когда ход завершается и оставляет фоновые задачи работающими, runner ждет до 60 секунд для них, затем выпускает сеанс, даже если они все еще работают. Если задачи завершились, но последующий ход, который читает их результаты, еще не запустился, runner держит сеанс до завершения этого хода и ждет не дольше SELF_HOSTED_RUNNER_BG_RESULT_GRACE_MS для этого хода, чтобы начать.
3. Runner выходит 0 после выпуска всех его сеансов.

Ход, который переживает убийство, все еще потерян; Timing shutdown охватывает размер маржи. Без --retire-at, убийство хоста без сигнала неотличимо от краха: плоскость управления записывает потерянного worker вместо чистого выпуска, и сеанс повторно ставится в очередь другому runner.

​

Сетевые пути

Runner и его сеансы делают несколько видов исходящего соединения, и входящее соединение от Anthropic не требуется:

• Control plane: runner опрашивает api.anthropic.com для работы и публикует события прогресса установки и отказа, все исходящие HTTPS. Опрос служит сердцебиением runner.
• SCM connector: дополнительный оркестратор SCM connector туннель — это единственное соединение WebSocket.
• Git: runner клонирует из и отправляет на ваш git-хост по HTTPS или SSH, аутентифицированный с учетными данными, которые предоставляет ваше развертывание; Настройка git охватывает варианты, включая учетные данные, отчеканенные для каждого сеанса, и Anthropic git proxy, который маршрутизирует git через api.anthropic.com вместо этого.
• Session child: дочерний процесс Claude Code держит поток событий сеанса на api.anthropic.com и делает свои собственные исходящие вызовы для вывода модели и для команд git, запущенных во время сеанса. Смотрите Требования к сети для полного списка выхода. Диаграмма выше показывает эти пути, кроме дополнительного SCM connector.

Вывод модели использует Anthropic API. Плоскость управления доставляет конечную точку API каждому сеансу, и сеанс аутентифицируется с помощью выданного Anthropic, токена OAuth с областью сеанса, поэтому вывод не может быть маршрутизирован через Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry или LLM gateway в самостоятельно размещаемых окружениях. Корпоративные прокси выхода поддерживаются. Runner и дополнительный автомасштабирующийся оркестратор соблюдают прокси и переменные mTLS, описанные в Конфигурация сети, такие как HTTPS_PROXY и NO_PROXY; установите их в окружение каждого процесса. Переменные охватывают вызовы плоскости управления, WebSocket SCM connector оркестратора и встроенный клон для HTTPS remotes, и сеансы наследуют их от runner. Потоковая передача сеанса использует события, отправляемые сервером, по HTTPS, поэтому прокси в пути не должен буферизировать ответы. Если ваш прокси также требует заголовка Proxy-Authorization, runner может добавить его к каждому соединению, которое он открывает на прокси; смотрите Аутентификация на прокси выхода.

​

Что остается на вашей инфраструктуре

Проверки репозитория, артефакты сборки, секреты и любые файлы, которые сеанс создает или изменяет, остаются на машинах, которые вы предоставляете. Сама беседа, включая подсказки, ответы и результаты инструментов, идет на api.anthropic.com для вывода модели, и Anthropic хранит стенограмму сеанса, чтобы вы могли возобновить сеанс с другой поддерживаемой поверхности. Самостоятельно размещаемое окружение перемещает выполнение сеанса в вашу сеть. Плоскость управления остается размещаемой Anthropic: оркестрация сеанса, очередь и интерфейс claude.ai продолжают работать на инфраструктуре Anthropic.

​

Начало работы

Страницы самостоятельно размещаемых окружений организованы по тому, что вы делаете:

• Quickstart: установите Claude Code, создайте окружение, запустите runner и маршрутизируйте свой первый сеанс
• Deploy to production: усиление безопасности, сетевой выход, учетные данные git, рецепты Kubernetes и Compose, известные проблемы и устранение неполадок
• Customize sessions: скрипты-обертки для учетных данных для каждого сеанса, hooks жизненного цикла, runners по требованию, MCP servers и разрешения
• Test end to end: дымовой тест CI, который проверяет образ runner перед его продвижением
• Reference: каждый флаг CLI, переменная окружения, метрика и конечная точка здоровья
• Verify session identity: проверьте токен сеанса из ваших собственных сервисов перед предоставлением доступа