Get started with the Claude apps gateway for Google Cloud

But rolling it out across an organization forces you to deal with enterprise friction: you have to manage per-developer cloud credentials, push a managed-settings.json to every laptop over MDM, and not be verified with zero per-developer usage attribution or easily enforceable spend caps. The Claude apps gateway closes that gap. It is a self-hosted service, shipped with the same claude binary, that sits directly between your local Claude Code clients and Google Cloud.

This post breaks down exactly why you should run it and what a secure deployment looks like on Google Cloud. (Note: If you want to jump straight to the code, the full walkthrough lives in the Claude apps gateway on Google Cloud docs .) Why run the gateway Run the gateway to centralize the governance that developers and platform admins otherwise each carry alone such as identity, policy, cost, and routing.

Here's what that looks like in practice. The /login request routes through your identity provider (IdP ) - Google Workspace or any OIDC/OpenID Connect one - and the gateway swaps the token for a short-lived session. No sensitive information lands on the developer's laptop - such as service-account keys, API keys, or ANTHROPIC_VERTEX_PROJECT_ID .

Onboarding is as simple as adding a user to an IdP group; offboarding by removing them, and their next session refresh fails on the spot. Your RBAC (role-based access control) rules live once in gateway.yaml , resolved per group and enforced server-side. The gateway re-checks availableModels on every /v1/messages call, so editing local managed-settings.json changes nothing - and rule updates reach the whole fleet within the hour.

Every claude_code.token.usage metric carries the verified email and groups from the session JWT (signed session token), not the spoofable client-set OTEL_RESOURCE_ATTRIBUTES . The gateway ships them over OTLP/HTTP to a collector you run - Cloud Monitoring, Grafana, Datadog, whatever you use. Set daily, weekly, or monthly caps per user, group, or org via the admin API; the gateway meters tokens against a Cloud SQL ledger and returns a 429 at the cap.

Costs are at list price, so treat them as a runaway-usage guardrail, not a bill reconciliation (committed-use discounts and negotiated rates don't show up). Calls go out under a single Cloud Run service identity. Set region: global for Agent Platform's global endpoint, or add a second upstreams: entry to fail over on 5xx/429/timeout in list order.

Either way, inference stays in your GCP project - quota, Data Processing Agreement, and billing all unchanged. How it fits together A developer's local or deployed claude process sends inference traffic to the gateway over HTTPS. The gateway is a stateless container on Cloud Run as shown below.

The gateway validates its own session bearer - Google Workspace is only contacted at sign-in and token refresh - checks policy, and forwards the request to Agent Platform using the Cloud Run service account. Cloud SQL holds device-code sign-in state and the spend ledger; an OTLP collector receives the attributed metrics. Setting it up on Google Cloud The full walkthrough, every gcloud command and the complete gateway.yaml reference, is in the Claude apps gateway on Google Cloud docs .