Google Cloud Run Instances Target Long-Lived AI Agents
On August 28, 2026, Google announced the preview of Cloud Run instances, a new runtime for workloads that need one continuously available container rather than request-driven autoscaling. Google positions it primarily for personal AI agents, but the operating model is also relevant to lightweight bots, development tools, and small services that maintain an active process.
The name is important. This is not another scaling option for a Cloud Run service. A Cloud Run instance is a dedicated singleton runtime: it runs exactly one instance and does not autoscale.
What Cloud Run instances provide
According to Google, each instance has four defining properties:
- exactly one running instance, with no autoscaling;
- up to seven days of continuous runtime;
- automatic restart enabled by default;
- a stable HTTPS URL that remains unchanged across updates and restarts.
An operator can also stop an instance when it is not needed and resume it later. This closes part of the gap between a conventional VM and a request-oriented Cloud Run service. The platform supplies the container runtime and HTTPS endpoint, while the application gets a continuously running process with predictable cardinality.
Cloud Run services remain the better fit for stateless HTTP applications that should add instances under load or scale to zero when idle. Cloud Run instances instead target workloads where scaling to zero would stop background activity and scaling out would create unwanted duplicate workers.
Why singleton execution matters for agents
A personal agent often has a different traffic pattern from a web API. It may wait most of the time, then perform a burst of work after receiving a message. It may also maintain a scheduler, poll a queue, or hold an outbound connection while serving only one user.
Running multiple copies can be actively harmful if every copy consumes the same event or executes the same scheduled task. A singleton runtime removes autoscaling as a source of duplication. It does not, however, replace application-level safeguards. External events can still be delivered more than once, and a process can restart, so side effects should remain idempotent.
The seven-day continuous runtime limit also means that local process memory cannot be treated as durable state. Even with automatic restart enabled, applications should be able to reconstruct their state after startup.
Persistent data needs an external store
Google’s announcement demonstrates an OpenClaw deployment that mounts a Cloud Storage bucket at /home/node/.openclaw. That detail is more important than the specific agent: container-local state should not be the only copy of configuration, credentials, conversation data, or task checkpoints.
A practical design separates three kinds of state:
- Store secrets in environment variables backed by an appropriate secret-management workflow rather than in the container image.
- Put durable files or checkpoints in external storage.
- Treat caches, open connections, and in-memory queues as disposable and rebuild them after a restart.
The command shown by Google uses the beta CLI surface and combines a public endpoint, a Cloud Storage mount, and environment variables:
gcloud beta run instances create openclaw-instance \
--image ghcr.io/openclaw/openclaw:latest \
--port 18789 \
--public \
--add-volume mount-path=/home/node/.openclaw,type=cloud-storage,mount-options="uid=1000;gid=1000;file-mode=0700;dir-mode=0700",bucket=${BUCKET} \
--set-env-vars "OPENCLAW_GATEWAY_PASSWORD=${PASSWORD},GEMINI_API_KEY=${GEMINI_API_KEY}"Treat this as an announcement example, not a production template. In particular, decide whether the endpoint should be public, pin and scan the container image, restrict the runtime identity, and avoid exposing secret values in shell history or deployment logs.
The pricing model
Google states that an instance with 1 shared vCPU and 1 GiB of memory costs $5.70 for 30 days of continuous operation. The runtime uses shared vCPU capacity with burst budgets, which matches an agent that is mostly waiting and occasionally needs more CPU.
That figure should not be mistaken for the total application bill. Model inference, storage, network traffic, logging, and any other cloud services are separate concerns. A continuously CPU-intensive worker may also be a poor match for a shared-vCPU product designed around bursty work.
The stop and resume controls are useful when an agent is needed only during working hours or for a temporary project. They make the runtime cheaper operationally without requiring the workload to adopt request-based scale-to-zero behavior.
Operational limits to plan around
Cloud Run instances are in preview, so they should be evaluated with more caution than a generally available runtime. The announcement also says SSH access is coming soon and requires separate private-access registration; it is not presented as an available preview feature.
Before choosing the service, verify that the workload can tolerate:
- one instance rather than horizontal scaling or built-in redundancy;
- process restarts and a maximum seven-day continuous run;
- shared-vCPU performance with burst budgets;
- externalized durable state;
- preview-stage interfaces and operational behavior.
A singleton is not the same as high availability. Automatic restart can restore a failed process, but there is still only one runtime. Workloads with strict availability targets need a design that accounts for the restart window or should remain on a platform that supports multiple replicas.
Where the new runtime fits
Cloud Run instances are most compelling when all of the following are true:
- the application is already packaged as a container;
- exactly one copy should run;
- the process needs to remain active without incoming HTTP requests;
- CPU demand is intermittent;
- durable state can live outside the process;
- a managed HTTPS endpoint is useful.
They are less suitable for high-throughput APIs, horizontally scalable consumers, CPU-bound batch processing, or systems that cannot accept periodic restarts. For those workloads, Cloud Run services, batch platforms, or VMs retain clearer operating models.
The useful change is not simply that Cloud Run can stay active. It is that Google now offers an explicit singleton primitive with a stable URL and stop/resume lifecycle. That gives small long-lived agents a managed option between an autoscaled service and a fully administered VM, provided teams design for restarts and respect the limits of the preview.