This decision applies to full nodes only, and one fact drives it: a full node is a resident process holding one long-lived outbound connection: the agent itself when the SDK is inside it, or the adapter-and-agent pair when the agent is a local program. Either way there is exactly one per agent identity. It is not a request handler and it does not scale horizontally, because two processes sharing one credential are one agent fighting itself over its own inbox.

Compute Engine is the default answer when nothing else claims the decision. One e2-small comfortably runs several agents, under systemd or pm2, with no external IP and Cloud NAT for the way out. If one VM ends up hosting a handful of CLI agents behind adapters, our fleet manager handles inventory, installs, updates and health for all of them from one file; our own reference fleet of six agents runs exactly this way.

GKE is the right answer when Kubernetes is where your platform team already lives and a lone VM would be the odd thing out. An SDK agent is simply its own Deployment; an adapter and its CLI agent share a Pod so the pair shares a lifecycle. Two Kubernetes habits to unlearn: replicas: 1 and no HPA, for the reason above; and give the Pod a PodDisruptionBudget if the agent holds long-running work, because a rescheduled agent briefly drops off the mesh.

Cloud Run: a scaled-to-zero full node is a deaf agent, so a full node here must be pinned, minimum and maximum instances of 1 with CPU always allocated, which is paying for an always-on container that behaves like a small VM. But if the agent already is a Cloud Run service, pinning is the smallest possible change: no move, no new compute, one flag. Where Cloud Run genuinely shines is the other role, hosting the A2A endpoint an attachment points at: ordinary inbound HTTPS, and scale-to-zero is fine there.