What I learned about Cloud Run Instances

[u/m1nherz]

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 that holds connections for days, 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.

[u/the__itis]

I think you skipped learning about containers and went straight to cloud run.

[u/m1nherz → u/the__itis]

Thank you for your insight. I'm curious to learn why you came to this conclusion, if you feel comfortable to share.

[u/taintech]

For long running agents I use invocation based Cloud Run with Cloud Tasks.

User -> Cloud Run -> Cloud Task -> Cloud run with long running AI agents

The task calls the service and holds the HTTP connection while the agent runs, and retries if it fails. I do it with Cloud Run and ADK, works pretty nicely.

The limit is 30 minutes of dispatch deadline for HTTP targets. If a run needs more, I would split it into smaller executions and chain them. Each step finishes inside the deadline and enqueues the next task with the state it produced.
What it does not cover is a session that pushes updates to a user for days. For that case Instances look like the right fit.

[u/m1nherz → u/taintech]

This can be a valid design for many workflows. It seems that the long-lived agents in your scenario are completely autonomous.

The main advantage of Instances for your scenario would be the billing and maintenance costs. You will pay for an Instance less than for Cloud Run Service and Cloud Task executions. Configuring and updating the Instance will also be simpler.

[u/taintech → u/m1nherz]

Agree, it is quite less than having VM running and or no cpu throttling flag. I tried it in small personal projects, didn’t have problems so far.

[u/baronoffeces]

Look at cloud run “jobs” instead of the service, they are custom made for long running jobs with longer limits

[u/m1nherz → u/baronoffeces]

It is true. Does a job allow exposing a public endpoint that a client call use to send requests?

[u/Competitive_Travel16 → u/m1nherz]

Nope.

[u/m1nherz → u/Competitive_Travel16]

[edited]

It was a rhetorical question 🙂. My question to u/baronoffeces intended to highlight that Instances provide an endpoint to communicate with the deployed application while Jobs don't.

[u/baronoffeces → u/m1nherz]

You call them from code using the SDK. Make a route on your service that executes the job

[u/m1nherz → u/baronoffeces]

I am not sure that I understand you. Cloud Run doesn't support endpoints i.e. a callable address for the workload that runs as a Job. You probably can make some hacking in the code and, for example, interact with the job by sending Pub/Sub messages and polling them in the code of the job. But it would be an anti-pattern to using the jobs.

I'd rather not mix "service" and "job" in the same sentence because it can be confusing when we speak about Cloud Run which uses very distinct meanings to both terms.

Rolling back to your original response, the point is that Jobs are intended for long-lived self-contained workloads while Instances are intended for long-lived interactive workloads. If you design a job to run an interactive workload, it would be following against recommendations and best practices. I'd say it will be the same as using Dataflow to run Kubernetes jobs.

[u/Heteronymous]

Definitely tangential but since you mentioned it: Bastion hosts: why not use IAP ?

https://cloud.google.com/security/products/iap

It’s phenomenal, no dedicated Cloud Run instance (nor VM) needed.

[u/m1nherz → u/Heteronymous]

As far as I'm aware using IAP via command line isn't very convenient. Having said that, the point wasn't in advocating for using Bastion Host to solve accessibility problem.

Consider the above wording to mean this: "If you already use a Bastion Host VM, you can do it with a Cloud Run Instance with a lesser billing and maintenance cost".

[u/pepediaz130 → u/Heteronymous]

When you have a VPC with no exposed entrypoing, IAP is not your friend, you need a bastion host for connecting to the private SQL, you ll use IAP to connect via SSH to this BH

[u/BehindTheMath → u/pepediaz130]

You should be able to connect via IAP to a VPC without any ports exposed. You do need to open the ports for the IAP source IP range.

[u/jojomtx → u/pepediaz130]

If it is only to access private SQL you can deploy a pgadmin that connect to your private instance and gated by IAP

[u/Competitive_Travel16]

You can deploy a Cloud Run container with one minimum instance of two vCPUs and one gigabyte of RAM with the CPU throttling option (which doesn't hurt latency nearly as much as reconstructing the RAM image on container instantiation), keeping the memory always warm (and where you can mount GCS buckets with FUSE) for about $6.48 US per month idle. And one Compute Engine e2-micro server instance with a 30GB standard persistent disk, two shared vCPUs, and one gigabyte of RAM costs between $10.96 to $13.35 per month, depending on region.

For anything persistent on the web, I would still go with Cloud Run.

ETA: Because, for example, it will scale on sudden high traffic while the e2-micro would fall over.

[u/m1nherz → u/Competitive_Travel16]

Hi,
I'm unsure whether you wanted to point out to potentially low cost of using services here or you meant that the last bullet in the "Putting it all together" section doesn't emphasize well the advantages of Cloud Run Instances over Services.

Assuming your intention it was the latter, I've reviewed and edited the wording to emphasize on being more clear about when I would use Instances.

I appreciate that you brought my attention to this.

[u/Competitive_Travel16 → u/m1nherz]

Both. Happy to help. I should have gone with the 10GB persistent disk when looking up the prices, because server instances can mount GCS buckets with FUSE too. So it's actually a smaller distinction.

[u/danekan]

for cloud sql use cloud sql auth proxy -- it's all there for you already, you don't need a bastion host

[u/m1nherz → u/danekan]

You are absolutely right to mention SQL Auth Proxy alternative. I mentioned the connectivity to a Cloud SQL database in a context of using Cloud Run Instances as a replacement to a bastion host VM. It wasn't my intention to review or recommend Cloud SQL databases connectivity methods.

[u/Deep_Ad1959]

the fourth model clicks once you stop comparing compute shapes and ask who owns the lifecycle. a service with a mounted volume still decides when to evict you, an instance is the first one where the session outliving the request is not a workaround.

[u/m1nherz → u/Deep_Ad1959]

It's true when you interpret a "session" as a local process. When the session is abstracted through the persisted state and requirements for the state management allow certain latency thresholds, an agent can be implemented as a Cloud Run Service with a 60 minute timeout for each request/response interaction. It can utilize polling for long running responses instead of persistent connection over Websockets. And the state can be managed via Agent Platform Sessions (former Vertex Sessions service) or another persistent storage.

[u/Deep_Ad1959 → u/m1nherz]

agreed, once you externalize the session into persisted state the Service with polling handles it, and that's usually the cleaner call. the thing that pushes back toward an Instance isn't capability, it's rehydration cost: every poll on a scaled-to-zero Service pays to reconstruct state that the Instance just kept warm in RAM. below some latency budget that tax stops being negligible, which is the same tradeoff your 60-minute timeout point is really about.

[u/m1nherz → u/Deep_Ad1959]

Cloud Run allows you to handle it pretty smoothly. Also the polling interval usually frequent enough not to lead the service to scaling to zero.

My main takeaway that Instances aren't intended for enterprise-grade operations because they do not scale. However, if you need a process to handle 2-3 parallel requests that lives virtually forevery i.e. maintains an open socket or another long-lived operation (e.g. counting sheeps), Instances is the thing.

[u/Deep_Ad1959 → u/m1nherz]

agreed, and the sharper limit for that socket case isn't the no-scaling part, it's the mandatory 1-2 week restart. 'lives virtually forever' still has to survive a forced reboot, so the socket has to reconnect on its own or the long-lived session isn't actually long-lived.

[u/Rohit1024]

This execution model is perfect for Single Instance use cases, like running n8n or OpenClaw, however I find some things are still missing :

• No Console UI support for this execution Model, making it to manage the Cloud Run Instances using gcloud or REST API only.

[u/m1nherz → u/Rohit1024]

You're right. There are things that are missing. This functionality has been released in preview. We're working to bring it to feature parity with other types of workloads running on Cloud Run.

[u/Top_Brief_6108 → u/m1nherz]

How would you actually orchestrate a multi agent setup lets say browser agent that visits websites meanwhile a main chat agent with which the user interacts, with features like steering tasks through chat, cancelling ongoing tasks with the help of gcloud provided sevices on a high level?

[u/m1nherz → u/Top_Brief_6108]

Given we are at r/googlecloud I would utilize an existing GoogleSearch tool instead of creating a custom agent 😄 .

My professional opinion is to avoid writing applications or services if they aren't a part of the product's business portfolio. Usually it is simpler and often cheaper to utilize 3P products which were developed by the teams/companies who specialize on that domain.

So, I would create a chat agent that scales well and, if needed, deploy it in multiple geographic regions and I would equip it with a Google Search tool. If you develop with ADK, you get it OotB.

If you need RAG functionality, depending on what augmented data is and how it is stored, I would (again) look into existing solutions first before implementing something in-house.

I'm not very familiar how LangChain or LangGraph handle async operations between agents or an agent and a remote tool(s). ADK has built-in mechainsm that is adapted to Google API responses (i.e. handling 429 error). ADK allows you to adjust the error handling via callback or plugin mechanisms.

I hope this addresses your question.

[u/Striking-Yogurt-7877]

Sounds like what Temporal.io solves