What breaks when an ADK agent that worked under adk web is deployed to Cloud Run?

## What the deploy actually produces `adk deploy cloud_run` generates a container around your agent directory and deploys it as a Cloud Run service. Inside, it serves the same FastAPI application you exercised locally with `adk api_server` — the same `POST /run`, `POST /run_sse` and session endpoints. If you want to control the container yourself, you build your own image and construct the app with `get_fast_api_app()` from `google.adk.cli.fast_api`, which is what you do when the agent must live inside an existing service. Either way the agent code is unchanged, which is exactly why the failures that follow are surprising: nothing about the agent broke, everything about its environment did. ## Statelessness is the headline failure Locally, `adk web` ran one process. The default in-memory session service, artifact service and memory service all lived in that process's heap, and every request hit the same heap. Cloud Run is the opposite by design: instances start on demand, scale out under load, scale to zero when idle, and are replaced freely. Consequences, in the order users notice them: 1. A user sends turn two and the agent has no idea who they are, because turn one landed on a different instance. 2. Traffic dips, the service scales to zero, and every conversation in flight evaporates. 3. Artifacts a tool wrote are unreadable on the next request because they were held in another instance's memory. The fix is configuration, not code: at deploy time point the session service at a database URI (or a Vertex-managed backend) and the artifact service at durable storage, using the deploy command's corresponding URI options. This is the number-one thing to say in an interview, because it is the failure that gets shipped. ## Identity changes underneath your tools On your laptop, a tool calling a Google API picked up your application-default credentials — an account that probably has generous project access. In the container, calls run as the Cloud Run service's service account. Anything you never granted is denied, and the denial surfaces as a tool error the model then narrates apologetically to the user. Deploy checklists should include: which APIs do my tools touch, what roles does the runtime service account hold, and does the model endpoint itself (Vertex AI or an API-key provider) work under that identity. Non-Google API keys must move out of the local `.env` and into the service configuration or Secret Manager — the local `.env` is a development convenience, not a deployment mechanism. ## The surface you get is narrower than the dev UI The browser dev UI is not part of a deployment by default; `--with_ui` includes it, and you should think hard before enabling it on anything public, because it is an unauthenticated-by-design developer console over your agent. Cloud Run's own access control (authenticated invocations, IAM, or an identity-aware proxy in front) is what stands between the internet and `POST /run`. An ADK service deployed with unauthenticated access is a bill and a data-exfiltration path with a chat box on it. ## Observability has to be turned on The Trace tab you leaned on locally does not follow the agent to production. `--trace_to_cloud` sends spans to Cloud Trace so you can still see which LLM or tool call consumed a turn's latency. Without it, a slow agent in production is a black box, and you will be reduced to reading logs for tool names. ## Timing and shape mismatches Agent turns are long by web standards — several model round-trips plus tool latency. Cloud Run applies a request timeout, and a multi-step turn can bump it; streaming through `/run_sse` both improves perceived latency and keeps the connection productive. Cold starts add seconds to the first request after a scale-to-zero, which users experience as the agent being slow specifically when they have not used it recently. Concurrency settings matter too: an agent instance spends most of its time waiting on model and tool I/O, so a very low concurrency setting wastes instances while a very high one can starve the event loop. ## The checklist worth reciting Durable session and artifact backends; service-account roles for every tool's API; secrets out of `.env` and into the platform; ingress restricted and `--with_ui` deliberate; `--trace_to_cloud` on; streaming endpoint used; timeout and concurrency reviewed against real turn length. Everything on that list is environment, not agent code — which is the point of the question.