What I Learned About Cloud Run Instances

approx. 1100 words
5 min
minherz

Cloud Run is my primary deployment platform when I experiment with AI Workloads or build samples for conferences and codelabs. When I got early access to its new feature called Cloud Run instances, I was a bit confused. I mean, Cloud Run already offered three execution models: Services for transactions and request-response apps, Jobs for batch processing, and Worker Pools for background tasks. Why introduce a fourth option?

Initially I thought that my “aha” moment would come when I tried to build an AI agent that runs long-lived sessions and needs to persist the session’s temporary data locally. Then I tried to find a difference between using an Instance and deploying the agent as a Cloud Run Service. I mounted a storage volume to my service and instrumented the agent with a tool to read and write state data to that volume. I also added an ephemeral disk to store temporary data that the agent generated mid-execution. The agent managed long-lived sessions without a problem. It scaled to zero minimizing costs when left alone and resumed to the same session operation when called later. The known problems of mounting Cloud Storage buckets via FUSE such as high latency and lack of true POSIX locking were there. And my ephemeral disk reset each time the service scaled to zero. “Well,” I thought, “it would be nice to have storage that behaves like a persistent local disk.” However the same would be true for Cloud Run Instances too. This experience supported my initial confusion about Instances.

Then I spoke to my colleagues about the confusion and they pointed me to a different scenario for an AI agent. I was thinking about agent interactions in terms of request/response sessions. This pattern is a natural fit for Cloud Run Services. However, many agents that operate long-lived sessions communicate differently. They maintain a long-lived WebSocket connection to push continuous updates back to a user. When I tried to reproduce this scenario I saw my connections just dropped after an approximately 5-minute period. It happened because Cloud Run Services have a time period (defaulted to 5 minutes) during which the service should respond to a request. The maximum timeout that I can set for my agent is 60 minutes. Too short for a long-lived session that can run for days.

This is exactly the gap Cloud Run Instances fill. And while long-lived AI agents were my entry point, the practical use cases go further:

  • Always-On Personal Agent or Workflow Engine: If I’m running something like n8n for my personal automations, or an AI agent like OpenClaw, I don’t need it to scale to a thousand users. I just need it to stay awake, keep its state, and give me a permanent HTTPS URL that doesn’t drop connection after an hour of running. I was reading that companies like OffDeal are already using them as the primary infrastructure for long-lived agents, which reduced their cold starts by 88%.
  • The Instant Bastion Host: Suppose I need a secure jump-box to access a private Cloud SQL database. Usually, I’d have to provision a whole Compute Engine VM, figure out the networking, and manage SSH keys. Instead, I can just spin up a Cloud Run Instance in seconds. Some Google Cloud customers are actually doing exactly this, using Instances as bastion hosts to give developers access to internal databases without the headache of traditional VMs.
  • “Vibe-Coding” and Code Sandboxes: Instances serve as excellent “vibe-coding” environments or execution sandboxes where you just need a single, addressable compute resource to run things for a while. Combining Instances with Cloud Run Sandboxes allows you to establish this environment without needing to provision a GKE cluster.

Let’s be honest, you don’t need Cloud Run Instances to implement these ideas. You can build them on a VM or a GKE cluster. The key advantages of Instances are simplicity and lower cost. Compare maintaining a VM instance and managing agent versioning against Cloud Run Instance deployments, and you will see the difference.

If you are looking at using Instances, you also have to look at the downsides.

First, an Instance is literally a singleton instance. It has no autoscaling. If my app suddenly gets hammered with requests, it will exhaust its resources and upcoming requests will simply time out while waiting for a response. Cloud Run wouldn’t spin another Instance of my app. It means that Instances are susceptible to DoS attacks. If you ever expect more than two or three parallel requests, you would definitely need to go back to Cloud Run Services or use alternatives such as VM or GKE.

Second, you have to be careful with how you store data including the agent’s state. Even though Instances feel like a VM, they don’t have local persistent disks. If you write to /tmp, it consumes container RAM. If you mount a Cloud Storage bucket, you hit volume concurrency limits. While Cloud Run’s preview release of the ephemeral disk solves the local disk performance and memory issue, remember: it is still ephemeral. Because Instances face mandatory restarts every 1 to 2 weeks, any data stored in memory or on local ephemeral disk will be wiped out. You still need an external database or storage bucket for anything that must survive a restart.

Putting it all together

As my train of thought wrapped up, the deployment options and resource model for the whole Cloud Run family finally made sense to me.

  • If I need a web app that scales to zero and handles bursts of users, I use a Service.
  • If I have a 5-hour data processing script, I use a Job.
  • If I need to continuously pull messages from a queue in the background without a public URL, I use a Worker Pool.
  • But if I just need a cheap $5.70/month (for 1GiB memory), simple, serverless single-node environment with a permanent URL, I’m reaching for a Cloud Run Instance.

I forgot to mention one more thing. When you discuss Cloud Run Instances, be precise about what you mean. I found it confusing to discuss Cloud Run Instances alongside container instances of a Cloud Run Service that are spun up to scale a workload. Make sure that you speak about the same “instances” when you do.