O gateway de aplicativos Claude foi projetado para organizações que devem — ou preferem — rotear inferência através de seu próprio provedor de nuvem, por exemplo para atender aos requisitos de residência de dados. Se você não tem esse requisito e deseja acesso a outros recursos como provisionamento SCIM ou Claude Code na web e mobile, Claude Enterprise pode ser uma opção melhor. Consulte a página de disponibilidade de recursos para uma comparação completa de todos os métodos de implantação.
claude, então o mesmo executável que executa Claude Code em um laptop executa o servidor gateway com claude gateway --config gateway.yaml.
Esta página cobre:
- Por que Claude apps gateway, o que adiciona em relação a executar o seu próprio, e quando algo mais se encaixa melhor
- Um guia de início rápido com pré-requisitos que leva um gateway de zero a um desenvolvedor conectado
- Conectando desenvolvedores, incluindo definir a URL do gateway através de configurações gerenciadas
- Disponibilidade e limitações cobrindo quais recursos do Claude Code funcionam através do gateway e o que o servidor suporta
Por que Claude apps gateway
A visão geral do gateway cobre o que um gateway faz e por que você executaria um. Claude apps gateway é o próprio gateway da Anthropic, integrado ao binárioclaude e testado junto com cada lançamento do Claude Code, então encaminha os cabeçalhos e campos de solicitação que Claude Code envia sem operadores mantendo uma lista de permissões separada. Uma vez implantado, ele oferece:
- Credenciais: a chave de API upstream ou credencial de nuvem vive apenas em sua infraestrutura. Os desenvolvedores se autenticam com SSO corporativo e recebem tokens de portador de curta duração, então o offboarding acontece em seu IdP. Desprovisione um usuário e seu acesso ao gateway expira dentro do tempo de vida da sessão, uma hora por padrão.
- Controle de acesso: seus grupos IdP mapeiam para listas de permissões de modelos e políticas de configurações gerenciadas. O gateway aplica acesso a modelos no lado do servidor, rejeitando solicitações para modelos não concedidos, e seleciona a política de configurações gerenciadas de cada grupo, que a CLI aplica no nível de configurações gerenciadas. Diferentes equipes obtêm diferentes modelos, ferramentas e permissões, e um desenvolvedor não pode substituir o que sua política bloqueia.
- Entrega de configurações: o gateway entrega configurações gerenciadas para clientes conectados, assumindo o lugar das configurações gerenciadas pelo servidor do console administrativo claude.ai.
- Telemetria: cada destino configurado, como Datadog, Splunk ou ClickHouse, recebe métricas do OpenTelemetry Protocol (OTLP) com contagens de tokens, modelo, identidade do usuário e latência por padrão, com logs e rastreamentos como opt-ins por destino.
- Roteamento upstream: os clientes falam a API de Mensagens Anthropic para o gateway, e o gateway traduz para cada upstream, seja Amazon Bedrock, Claude Platform on AWS, Agent Platform do Google Cloud, Microsoft Foundry ou a API Anthropic, com failover entre eles. Você pode alterar regiões, provedores ou ordem de failover sem que os desenvolvedores notem ou reconfiguram.
O plano de dados do próprio gateway não envia nada para a infraestrutura Anthropic a menos que a API Anthropic seja um upstream configurado. Você controla para onde a telemetria, logs de auditoria, configurações gerenciadas e a identidade IdP dos seus desenvolvedores vão, e o gateway não envia nenhum deles para Anthropic. Para o tráfego restante que o processo CLI pode enviar e como fechá-lo, consulte Postura de conformidade.
Outras implementações de gateway
Se você já executa um gateway LLM ou gateway de API que atende às suas necessidades, continue usando-o; Outros gateways LLM cobre a configuração do Claude Code contra ele. A referência do protocolo de gateway documenta o contrato que Claude Code espera de qualquer gateway: os endpoints que chama, os cabeçalhos e campos de corpo para encaminhar, e o que para de funcionar quando são removidos. Um gateway de aplicativos Claude em execução serve um superconjunto desse contrato emGET /protocol, adicionando os endpoints específicos do gateway de aplicativos Claude para sign-in SSO, entrega de configurações gerenciadas e telemetria. Busque-o com curl https://claude-gateway.internal.example.com/protocol de qualquer gateway implantado, como o que o guia de início rápido abaixo produz.
Mudanças significativas no protocolo são anunciadas com antecedência, mas compatibilidade retroativa indefinida não é garantida.
Guia de início rápido
Este guia de início rápido percorre o caminho mínimo: registre um cliente OAuth em seu IdP, escreva umgateway.yaml, execute o gateway junto com Postgres usando Docker Compose, e verifique o sign-in de ponta a ponta. Usa um upstream Amazon Bedrock; Claude Platform on AWS, Agent Platform do Google Cloud, Microsoft Foundry e a API Anthropic são igualmente suportados trocando o bloco upstreams conforme mostrado na referência de configuração. No final você tem um gateway que um desenvolvedor pode fazer /login.
Implante em sua rede privada. Claude Code só se conecta a um gateway cujo endereço é privado. Esta é uma proteção de segurança, porque um gateway confiável pode enviar configurações que executam comandos em máquinas de desenvolvedores. Coloque o gateway atrás de um balanceador de carga interno ou VPN e dê a ele um nome de host que resolve apenas para IPs privados.Os endpoints de gateway público operados pela Anthropic são a exceção:
/login os aceita via https://. Estes são um pequeno conjunto fixo de gateways que a própria Anthropic opera; não são uma opção de implantação que você pode selecionar ou configurar. A lista é compilada no Claude Code, portanto nenhuma configuração pode adicionar um nome de host a ela e nenhum gateway que você hospeda se qualifica para a isenção. Antes da v2.1.206, /login rejeitava esses endpoints como qualquer outro endereço público.Pré-requisitos
Tenha estes em vigor antes de começar:
O servidor gateway requer o binário
claude nativo; baixe uma versão fixada conforme descrito em Instalar Claude Code. O servidor usa recursos de runtime que não estão disponíveis quando Claude Code é executado sob Node. Se você vir requires the native binary na inicialização, mude para um dos métodos de instalação autônomos.
Etapas
1
Registre um cliente OAuth em seu IdP
Decida o nome de host do gateway primeiro, porque o URI de redirecionamento deve corresponder a ele. Crie um novo aplicativo web OIDC e defina o URI de redirecionamento para
https://claude-gateway.<seu-domínio>/oauth/callback, onde o host é o mesmo valor que você define como listen.public_url na etapa 3. Anote o client_id e client_secret. As instruções por IdP estão em Configuração do provedor de identidade.2
Provisione um banco de dados PostgreSQL
Qualquer Postgres 14 ou posterior funciona, incluindo o menor nível gerenciado. O gateway executa suas próprias migrações de esquema na inicialização, então o usuário do banco de dados precisa de permissão
CREATE TABLE. Se sua política de segurança proíbe DDL de funções de aplicação, pré-crie o esquema em vez disso; consulte store.3
Escreva gateway.yaml
Os segredos são lidos via expansão Esta configuração é suficiente para um loop de sign-in funcionando com o catálogo de modelos Bedrock padrão. Uma vez em execução, adicione RBAC por grupo e configurações gerenciadas via
${ENV_VAR} para que o arquivo em si possa viver no controle de versão. Use um nome de host public_url que resolva para um IP privado em sua rede, porque /login rejeita endereços públicos. A configuração mínima tem cinco seções, e todos os outros campos têm um padrão:gateway.yaml
managed.policies, fan-out de telemetria via telemetry, e failover multi-upstream, ARNs de throughput provisionado ou regiões não-US via models.O upstream Bedrock precisa de um principal AWS com
bedrock:InvokeModel e bedrock:InvokeModelWithResponseStream nos ARNs inference-profile/us.anthropic.* e nos ARNs foundation-model/anthropic.* subjacentes, e acesso a modelos habilitado no console Bedrock para os modelos Claude que você deseja. Forneça a credencial com IRSA no EKS, uma função de tarefa ECS ou um perfil de instância EC2 em vez de chaves estáticas. A referência upstreams tem os detalhes completos do IAM, a matriz de credencial entre nuvens e os blocos auth para os outros provedores.4
Execute-o
Construa uma imagem de contêiner em torno do binário O gateway é um único binário Linux que lê a configuração, executa descoberta OIDC contra seu IdP, aplica suas migrações de esquema Postgres, constrói clientes upstream e começa a escutar. A inicialização é fail-closed para a configuração, a conexão Postgres com um tempo limite de 5 segundos, descoberta OIDC e construção de cliente upstream. Se qualquer um desses for inacessível ou mal configurado, o gateway sai com um erro em vez de servir tráfego em um estado degradado.Uma inicialização bem-sucedida não valida o caminho de inferência, porque credenciais de instância Bedrock e Agent Platform resolvem na primeira solicitação, não na inicialização.Observe stderr para a sequência de inicialização. As linhas de log usam o formato Se a inicialização sair antes da linha
claude que atenda aos requisitos de imagem, então execute-a junto com Postgres:docker-compose.yaml
[gateway] <timestamp> <level> <message>, eventos de auditoria são JSON de linha única com um campo evt, e um banner de inicialização, omitido abaixo, é impresso entre as linhas de migração e escuta. Você deve ver, em ordem:claude gateway listening on, a última linha de stderr nomeia o problema:- um Postgres inacessível
- uma função Postgres sem permissão DDL
- um documento de descoberta OIDC inacessível ou inválido
- uma violação de esquema de configuração com o caminho de campo ofensivo
claude gateway --config gateway.yaml. Defina public_url para a origem do ingress e vincule listen a um endereço loopback ou interno do cluster.5
Verifique a superfície de autenticação
Três verificações confirmam que o gateway pode autenticar um usuário real antes de entregá-lo a um desenvolvedor.Os exemplos usam a URL pública do gateway; para a configuração local do Compose sem um ingress, substitua A resposta inclui campos adicionais, como Terceiro, teste a perna do navegador abrindo
http://localhost:8080 nas duas primeiras verificações. A terceira verificação abre verification_uri_complete, que é construída a partir de public_url, então para Compose local defina public_url: http://localhost:8080 em gateway.yaml e adicione http://localhost:8080/oauth/callback como um segundo URI de redirecionamento no cliente OAuth da etapa 1, porque o gateway constrói o redirect_uri do IdP a partir de public_url. O link de verificação então abre em seu navegador local.No Windows PowerShell, execute curl.exe; o curl simples é um alias para Invoke-WebRequest e rejeita esses sinalizadores.Primeiro, busque o documento de descoberta, que confirma que o gateway está ativo, a configuração é válida e todas as verificações de inicialização passaram:response_types_supported e scopes_supported.Segundo, solicite uma autorização de dispositivo, que confirma que o fluxo de sign-in do dispositivo funciona e Postgres é acessível e gravável:verification_uri_complete em um navegador e confirmando o código. Você deve ser redirecionado para a página de sign-in do seu IdP e, após fazer login, voltar ao gateway com uma confirmação de sign-in.Use a primeira verificação que falha para localizar o problema:- Primeira verificação falha: a inicialização não foi concluída; verifique stderr
- Segunda verificação falha: Postgres não é acessível do gateway ou a função não pode escrever; verifique a string de conexão e as concessões
- Terceira verificação não alcança o IdP: verifique que o URI de redirecionamento do IdP corresponde exatamente a
https://<gateway>/oauth/callback - Terceira verificação alcança o IdP mas volta com um erro: leia o log de auditoria do gateway, que registra cada rejeição de autenticação com o motivo, como
email domain not allowed
6
Faça login de um desenvolvedor
Esta última etapa acontece em uma máquina de desenvolvedor, não no servidor. Defina
forceLoginMethod como "gateway" e forceLoginGatewayUrl como a public_url do seu gateway no arquivo de configurações gerenciadas dessa máquina, então execute /login, pressione Enter na tela Cloud gateway e conclua o sign-in do navegador. Defina a URL do gateway abaixo cobre a distribuição de ambas as chaves em escala.Conectar desenvolvedores
Os desenvolvedores se conectam de seus próprios laptops com um sign-in de navegador, usando sua conta de trabalho corporativa. Eles não precisam de uma conta claude.ai, uma chave de API ou uma assinatura, porque as solicitações para o modelo passam pelo gateway usando a credencial upstream da organização. A conexão é orientada pelas configurações gerenciadas no lado do cliente que você envia via MDM, então não há configuração manual no lado do desenvolvedor; esta seção cobre o que o administrador configura. A CLI coloca a impressão digital do certificado TLS folha do gateway na primeira conexão e a fixa por nome de host. Publique a impressão digital SHA-256 esperada junto com a URL do gateway para que os desenvolvedores tenham algo para comparar. Obtenha a impressão digital do arquivo de certificado comopenssl x509 -noout -fingerprint -sha256 -in cert.pem; o prompt /login mostra os primeiros 16 caracteres do resumo como hexadecimal minúsculo sem separadores.
Quando o certificado é rotacionado, cada desenvolvedor vê o prompt de confiança novamente, então trate rotações como um evento planejado e republique a impressão digital.
Uma vez conectado, o seletor de modelo mostra os modelos na lista de permissões availableModels do desenvolvedor, as configurações gerenciadas se aplicam na inicialização e atualizam a cada hora, e a telemetria é roteada para seu coletor. As sessões são atualizadas silenciosamente antes da expiração de ttl_hours, e uma atualização falhada após desprovisionamento de IdP solicita um novo login.
Defina a URL do gateway
Defina ambas as chaves no arquivo de configurações gerenciadas por SO que você implanta via MDM ou diretamente no disco, e/login abre diretamente na tela Cloud gateway com a URL preenchida:
forceLoginGatewayUrl é ignorado nos arquivos de configurações próprias de um desenvolvedor. forceLoginMethod sozinho, sem uma URL, deixa o desenvolvedor em uma mensagem “Entre em contato com seu administrador de TI”. Ambas as chaves pertencem ao arquivo que você envia para máquinas, não ao bloco managed.policies[].cli do gateway, que só alcança clientes que já estão conectados.
Pipelines de CI e máquinas remotas
Não há fluxo de token de serviço para pipelines não supervisionados. O sign-in do gateway sempre executa o fluxo de dispositivo do navegador, então um trabalho de CI sem um desenvolvedor para aprovar o sign-in não pode se autenticar; configure aqueles contra seu provedor diretamente. Uma vez que um desenvolvedor tenha feito login, cada invocação do Claude Code nessa máquina usa a sessão do gateway, incluindo execuções não interativasclaude -p e sessões iniciadas pelo Agent SDK, e a política do gateway se aplica a todas elas.
O fluxo de dispositivo separa a CLI de polling do navegador aprovador, então uma caixa de desenvolvimento remota sem exibição ainda funciona: o desenvolvedor executa /login via SSH na máquina remota e abre o link de verificação no navegador em seu laptop.
O que é aplicado aos desenvolvedores
Estas garantias se aplicam a cada sessão de gateway conectada.- Acesso a modelos: solicitações para modelos que a política não concede retornam 400, e o seletor
/modelé filtrado para a lista de permissõesavailableModelsda política. DefinaenforceAvailableModels: truena política para que a opção Padrão resolva para um modelo dentro deavailableModelsem vez de para o padrão integrado do Claude Code; sem isso, Padrão permanece selecionável e é rejeitado no tempo de solicitação se esse modelo não for concedido. - Destino de telemetria: quando encaminhamento de telemetria é configurado, o endpoint de exportação OTLP é fixado ao gateway, e a configuração enviada pelo gateway substitui variáveis
OTEL_*definidas localmente. - Credenciais: o token do gateway é a única credencial da sessão.
ANTHROPIC_AUTH_TOKEN,ANTHROPIC_API_KEY,apiKeyHelpere qualquer login anterior de claude.ai são ignorados enquanto conectado, então os desenvolvedores não precisam fazer logout de claude.ai primeiro. - Configurações gerenciadas: chaves bloqueadas não podem ser substituídas localmente. A CLI aplica a política na inicialização e em cada sondagem horária.
- Inicialização: sessões conectadas saem na inicialização com um erro após cerca de 10 segundos quando o gateway é inacessível, em vez de iniciar sem suas configurações.
- Desprovisionamento: uma sessão cujo usuário é desabilitado no IdP expira dentro de
ttl_hoursquando a próxima atualização falha.
O que a organização pode ver
A telemetria de uso carrega a identidade do desenvolvedor, contagens de tokens, modelo e latência para o coletor da organização. O gateway não registra ou armazena conteúdo de prompt ou conclusão. Se telemetria mais rica, como logs e rastreamentos, é coletada, que pode incluir comandos e caminhos de arquivo, é a escolha por destino da organização.Disponibilidade e limitações
A tabela cobre quais recursos do Claude Code funcionam quando os desenvolvedores se conectam através do gateway e o que o próprio servidor gateway suporta. Onde algo não é suportado, a coluna Notas fornece a alternativa. O gateway entrega os valoresanthropic-beta que a CLI envia para cada upstream, então operadores não mantêm uma lista de permissões beta. Para Amazon Bedrock, que ignora o cabeçalho, o gateway move os valores para o campo anthropic_beta do corpo da solicitação; os outros upstreams recebem o cabeçalho conforme enviado.
O conjunto beta de sessão de gateway da CLI omite betas apenas de primeira parte e a beta de ttl de cache estendido, é por isso que essas linhas abaixo mostram como não disponíveis.
Próximas etapas
O guia de início rápido deixa você com uma configuração mínima em execução sob Docker Compose. Para ir além:- Expanda
gateway.yamlalém da configuração mínima, por exemplo para adicionar RBAC por grupo, failover multi-upstream ou destinos de telemetria. A referência de configuração cobre todas as opções. - Mude do Compose para uma implantação de produção em Kubernetes ou Cloud Run, configure seu IdP adequadamente e revise o modelo de segurança. O guia de implantação e operações cobre configuração por IdP, requisitos de imagem de contêiner, sondas de saúde e solução de problemas.
- Coloque limites de gastos em desenvolvedores individuais ou grupos para que uma carga de trabalho descontrolada não possa consumir todo o seu compromisso. Limites de gastos cobre a API de administração e como a aplicação funciona.
- Para um exemplo completo trabalhado no Google Cloud, com Cloud Run, Cloud SQL e Secret Manager, consulte Implante no Google Cloud.