Deploying a Claude Application on Cloud Run with Vertex AI

Claude models on Vertex AI are, in Google's words, fully managed and serverless models offered as APIs — there is no model infrastructure for you to provision. That makes Cloud Run, Google's managed container platform, a natural home for the application wrapped around those calls: a chat backend, a document-processing endpoint, an internal API. This article walks through the pattern; exact console clicks and flag names belong to Google's Cloud Run docs, which you should keep open alongside.

The container: nothing exotic

Your image is an ordinary web service that uses the AnthropicVertex client. Install the Vertex extra of the SDK (pip install -U google-cloud-aiplatform "anthropic[vertex]") and read configuration from environment variables, twelve-factor style:

import os
from anthropic import AnthropicVertex

client = AnthropicVertex(
    project_id=os.environ["GCP_PROJECT"],
    region=os.environ.get("VERTEX_REGION", "global"),
)

def handle(prompt: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}],
    )
    return msg.content[0].text

Note what is absent: no API key, no credentials file, no auth code. That is deliberate.

Credentials come from the service identity, not the image

Every Cloud Run service runs as a service account — its service identity. The AnthropicVertex client authenticates via Application Default Credentials, and inside Cloud Run, ADC automatically resolves to that service identity. This is the same keyless principle as Workload Identity on GKE: the platform injects short-lived credentials; you never handle a secret.

Two setup requirements on the Vertex side. First, an administrator must have enabled the Claude model on its Model Garden card (a one-time act requiring the Consumer Procurement Entitlement Manager role, roles/consumerprocurement.entitlementManager). Second, the Cloud Run service's runtime service account needs the Vertex AI User role (roles/aiplatform.user), which carries the aiplatform.endpoints.predict permission used for inference. Create a dedicated service account per service rather than using a project-wide default — it keeps IAM grants and audit logs attributable.

Concurrency, timeouts, and streaming

Claude calls are long compared with typical web requests — seconds to tens of seconds, longer with big contexts. Three Cloud Run settings deserve attention (set values per your workload; check current limits in Google's docs):

Request timeout. The default is tuned for quick requests. Raise it to comfortably exceed your slowest expected Claude response, including retries.
Concurrency per instance. A Claude-calling service spends most of its time waiting on the network, so an async server can safely handle many concurrent requests per instance. A synchronous worker-per-request server cannot — size concurrency to your server model, not to Cloud Run's maximum.
Streaming. Vertex serves streamed Claude responses as server-sent events via the :streamRawPredict endpoint (the SDK exposes client.messages.stream(...)). Streaming through to your client dramatically improves perceived latency and keeps intermediaries from timing out on long generations.

Rule of thumb: stream anything user-facing. A 30-second silent wait feels broken; a stream that starts in a second feels fast.

Scale to zero — and what it doesn't save

Cloud Run's signature feature is scaling to zero instances when idle, so a low-traffic internal tool costs nearly nothing to host. Two clarifications keep expectations honest. First, cold starts add latency to the first request after idleness; if that matters, configure a minimum instance count and accept the standing cost. Second, scale-to-zero saves application hosting cost only — your dominant cost is Claude token usage on Vertex, billed pay-as-you-go per million tokens regardless of where the caller runs. Quotas are likewise a Vertex-side concern: many concurrent Cloud Run instances can collectively hit your per-project token-per-minute quota, so read the quota guide before load-testing.

Finally, region choices are independent: your Cloud Run region and your Vertex endpoint (global, us/eu multi-region, or a specific region) don't have to match, but keeping them aligned helps latency and simplifies residency stories.

Where to go next

For event-driven rather than request-driven invocation, see Cloud Functions as Claude triggers. For the first end-to-end call before any deployment, start with your first Vertex API call.

Sources

← All articles