Guide
Cloud Run Instances for Long-Lived Agents: When a $5.70/Month Runtime Beats a VM
Google Cloud introduced Cloud Run instances in preview on August 27, 2026. The product targets a gap between autoscaling Cloud Run services and fully managed virtual machines: workloads that want exactly one long-lived container, stable state, a persistent HTTPS endpoint, and occasional CPU bursts. A Cloud Run instance has no autoscaling, runs one instance, can run continuously for up to seven days before restart, retains a stable HTTPS URL across updates and restarts, and can be stopped and resumed. Google’s published example prices a continuously running 1-vCPU, 1-GiB instance at about $5.70 for 30 days. The model fits personal agents and low-duty-cycle workers, but it is not a replacement for stateless autoscaling services, Kubernetes, or full VMs.
# Cloud Run Instances for Long-Lived Agents: When a $5.70/Month Runtime Beats a VM
## Article Summary
Google Cloud introduced Cloud Run instances in preview on August 27, 2026. The product targets a gap between autoscaling Cloud Run services and fully managed virtual machines: workloads that want exactly one long-lived container, stable state, a persistent HTTPS endpoint, and occasional CPU bursts. A Cloud Run instance has no autoscaling, runs one instance, can run continuously for up to seven days before restart, retains a stable HTTPS URL across updates and restarts, and can be stopped and resumed. Google’s published example prices a continuously running 1-vCPU, 1-GiB instance at about $5.70 for 30 days. The model fits personal agents and low-duty-cycle workers, but it is not a replacement for stateless autoscaling services, Kubernetes, or full VMs.
---
Personal agents have traditionally had awkward hosting choices.
### Local laptop
Cheap, but the agent disappears when the machine sleeps.
### Virtual machine
Always available, but you manage operating-system updates, networking, HTTPS, and host operations.
### Cloud Run service
Operationally simple, but designed around request-driven autoscaling and scale-to-zero behavior.
A personal agent often wants something else:
> exactly one process that stays around.
Cloud Run instances are designed for that shape.
## One instance is a feature here
Cloud Run services scale from zero to many instances.
Cloud Run instances run exactly one instance.
For a personal agent, automatic replication can actually be dangerous:
- duplicate messages;
- duplicate scheduled work;
- repeated API calls;
- state races.
Singleton execution can be the correct semantic model.
## Seven-day continuous runtime changes application design
Google says an instance can run continuously for up to seven days, with automatic restart behavior by default.
That means it is not an immortal VM.
The agent must be restart-safe.
Do not keep important state only in process memory.
Use persistent services for:
- memory;
- pending jobs;
- checkpoints;
- configuration.
## Stable HTTPS endpoint
Each instance receives an HTTPS URL that remains stable across updates and restarts.
That is useful for:
- messaging webhooks;
- control dashboards;
- callbacks;
- personal automation endpoints.
The platform handles the HTTPS endpoint rather than requiring a separate reverse proxy.
## Stop and resume
Not every agent needs to run 24×7.
A research or personal automation agent may be active only during work hours.
Stop/resume makes the runtime more natural than treating a VM as a permanently running server.
## Understanding the $5.70 figure
Google’s example is:
```text
1 vCPU
1 GiB memory
continuous 30-day runtime
≈ $5.70
```
This is a platform-compute example, not the total cost of an agent.
Real cost may also include:
- model APIs;
- storage;
- databases;
- network;
- logging.
For many agents, model inference will cost more than the runtime.
## Why this workload fits shared CPU
Long-lived personal agents often spend most of their time idle.
They wake up when a message arrives, perform a short burst of work, and wait again.
A shared-vCPU model with burst capacity fits that pattern well.
A continuously CPU-saturated workload may fit a different compute product better.
## Good use cases
- personal assistants;
- Telegram or WhatsApp bots;
- low-frequency background workers;
- research agents;
- lightweight schedulers;
- one-user automation runtimes.
The common properties are:
```text
single user
single runtime
long-lived state
mostly idle
stable endpoint
```
## When Cloud Run services are better
If the architecture is:
```text
many users
→ HTTP requests
→ stateless backend
```
a normal Cloud Run service is usually the better fit because autoscaling is the desired behavior.
## When a VM is better
Use a VM when you need:
- full operating-system control;
- custom kernel behavior;
- unusual network topology;
- continuously high CPU utilization;
- special accelerator environments;
- heavy local-disk state.
## When Kubernetes is better
Use GKE or Kubernetes when the system requires:
- many agent workloads;
- custom scheduling;
- sidecars;
- service mesh;
- complex network policy;
- GPU pools;
- multi-service orchestration.
Cloud Run instances simplify one long-lived container; they do not replace orchestration platforms.
## Recommended architecture
```text
Telegram / webhook
→ Cloud Run instance
├── agent runtime
├── scheduler
└── tool router
→ external APIs
```
Persistent state can live in Firestore, Cloud Storage, Cloud SQL, or another managed store.
Secrets should come from a secret-management system, not be baked into the image.
## Stable URL does not mean public-by-default is safe
A personal agent endpoint should still authenticate its callers.
Use signed webhooks, tokens, or identity-aware access depending on the integration.
The runtime being easy to expose does not remove application security requirements.
## Restart recovery workflow
A robust agent should start like this:
```text
boot
→ load configuration
→ restore state
→ rebuild connections
→ recover pending jobs
→ ready
```
Not as if every restart were a clean first launch.
## Idempotency matters
Suppose a scheduled email starts and the instance restarts before completion is recorded.
Without idempotency, the recovered agent may send it again.
Persist:
```text
job_id
status
idempotency_key
```
for any side-effecting work.
## Externalize logs
Do not depend on local files as the audit record.
Use Cloud Logging or another observability system so restarts do not erase the history needed for debugging.
## One agent per instance can be useful—at small scale
For dozens of valuable internal users, a per-user instance can provide clean state, secret, failure, and cost isolation.
For hundreds of thousands of users, that design becomes inefficient.
At large scale, a multi-tenant agent platform is a different architecture.
## Selection table
| Workload | Better fit |
|---|---|
| One long-lived personal agent | Cloud Run instances |
| Stateless HTTP API | Cloud Run services |
| Large multi-agent platform | GKE / Kubernetes |
| Full host control | VM |
| Low-frequency persistent bot | Cloud Run instances |
| Constant high CPU | VM / GKE |
## Conclusion
Cloud Run instances are not simply smaller VMs.
They are a managed shape for:
```text
one long-lived container
+ mostly idle compute
+ stable URL
+ low operations
```
That aligns closely with many personal-agent workloads.
The selection question is therefore not whether the feature is new.
It is:
> is this agent fundamentally a long-lived singleton process, or an autoscaling service?
For more agent-deployment, Cloud Run, and AI infrastructure guidance, visit **Zyentor Picks**: https://www.zyentorpicks.com/.