The laptop-lid problem that started this
Anyone who has shopped for cheap hosting has had some version of this question. Someone has a bot or a scraper or now an AI agent running on their laptop, it works fine, and then they close the lid and it stops. They want the cheapest thing that keeps it alive. Until this week the standard answer was always the same: rent a small KVM box, and accept that you are paying for 24 hours of CPU to use about twenty minutes of it.
Google shipped Cloud Run instances on August 28, 2026, currently in preview: singleton container runtimes on Cloud Run that run exactly one copy, keep a stable HTTPS URL, and cost $5.70 a month for 1 vCPU and 1 GiB according to the announcement post (opens in new tab).
That number is not an accident. $5.70 sits directly under the $5 to $6 entry tier that almost every VPS provider advertises. Whoever set the price knew the market and landed one cent under the line that has anchored cheap-instance pricing for years.
So the question I want to answer here is the one anyone weighing the two options would ask. Is this actually cheaper than a VPS, or is it cheaper on the sticker and more expensive once the bill arrives? The numbers below are my best effort at a real comparison, and I will flag the gaps in what is publicly known rather than guess past them.
A quick note on framing before we go further. This is a preview product. There is no SLA behind it, the CLI command still has beta in it, and flags in preview products move around. I am not treating it as something you migrate a paying customer onto this month. I am treating it as something worth testing on a workload you would not cry about losing.
Background: why Cloud Run services never fit a long-lived agent
Cloud Run has been excellent at one specific shape of workload for years: stateless HTTP handlers that scale up under traffic and scale to zero when nobody is knocking. Scale-to-zero is the headline feature and it is also precisely what makes it wrong for a personal agent.
An agent like OpenClaw does not want zero copies. It also does not want four. It wants exactly one process, running continuously, holding its own session state, listening for messages from Telegram or WhatsApp whenever you feel like sending one. Put that on a normal Cloud Run service and you get either a container that gets shut down between requests or, under a burst, several agents all convinced they are the only one, which is a fun class of bug to debug at midnight.
So people did the sensible thing and bought a VM. That is where the chores start. You patch the OS, or you do not and eventually you get a surprise. You open the right ports and no others. You get an HTTPS endpoint working, which in practice means Caddy or nginx plus certbot plus a cron entry plus remembering, months later, why the cert stopped renewing. None of this is hard. All of it is unpaid work that accumulates across every box you own.
Where does cheap shared hosting fit? Mostly it does not. cPanel-style shared hosting is built around PHP request handling and a process manager that reaps long-running processes, and most hosts explicitly forbid keeping a persistent Node daemon and a websocket listener running on a shared account. It is not a policy invented to annoy you. One customer’s runaway agent on a shared box degrades everyone else on that box.
A cheap KVM VPS is the real comparison point. Root, a fixed CPU slice, a real disk, and about four hours of setup work per box if you are honest about hardening. That is the thing $5.70 is competing with.
What Cloud Run instances actually give you
Four attributes from the announcement, and they matter in this order:
- One instance, no autoscaling. The whole point. Your agent is a singleton and the platform now agrees.
- Up to 7 days of continuous runtime, with an automatic restart policy on by default.
- A stable HTTPS URL that survives updates and restarts.
- Stop and resume on demand, so an agent you only use on weekdays does not have to bill for weekends.
The pricing model is the interesting part. It is shared vCPU with a burst budget, not a dedicated slice. Google’s argument is that a personal agent idles most of the day and spikes when you ask it to do something, which fits burst accounting well. I think that argument is correct for the workload they are targeting and I will come back to where it stops being correct.
Deployment is one command:
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}"
Two things to notice. The bucket mount carries uid=1000;gid=1000;file-mode=0700, which exists because the container runs as a non-root user and OpenClaw will refuse to touch a config directory with loose permissions. If you get the uid wrong you will find out through a permissions error on startup rather than anything descriptive.
Second, that example passes GEMINI_API_KEY and the gateway password as plain environment variables. Fine for a demo. For anything you keep, put them in Secret Manager and reference them instead, because env vars show up in deployment metadata and in the console for anyone with view access on the project.
The announcement quotes OffDeal saying Cloud Run instances cut their cold starts by 88%. I would not build a decision on that. It is one customer, in a launch post, with no baseline given, and their previous setup could have been anything.
Are Cloud Run instances cheaper than a VPS?
Direct answer: the sticker price is competitive and the total is probably a bit higher than $5.70 for most real deployments.
$5.70 covers the compute for 1 vCPU and 1 GiB for 30 days. It does not cover egress, and an agent that pushes media through WhatsApp will generate some. It does not cover the Cloud Storage bucket holding your mounted config, which is cents but is not zero. Most significantly it does not cover the API calls the agent actually makes. In the OpenClaw example, Gemini API usage is billed separately, and for a chatty agent that line will dwarf the $5.70 without much effort.
Here is the comparison in terms a site owner will recognise. Think of a $5 VPS as renting a small storage unit. Fixed rent, your key, your padlock, and you sweep it yourself. A Cloud Run instance is closer to a serviced locker where the building handles the door, the lock, and the lighting, and charges you a metered amount for how much you move in and out. If you mostly leave things sitting there, the locker wins. If you are running a business out of it, the storage unit is more predictable.
What you genuinely stop paying for is labour. No patching. No firewall rules. No cert renewal, which is the one that quietly costs me the most support time across my own fleet. And the URL not changing across restarts and redeploys removes a whole category of “my webhook broke” tickets.
Where a VPS still wins today:
- Root access, right now, without a signup form.
- Persistent local disk, at real disk latency, not a bucket mounted over the network.
- No 7-day runtime ceiling.
- Predictable CPU under sustained load, because a fixed slice does not have a budget to exhaust.
- No dependency on a preview product with no SLA.
If you already own the VPS and it is working, this is not a migration you need to do.
What it means in practice for the workloads I see
Good fits, based on the workload patterns most often compared against a $5 VPS:
- Single-user agents like OpenClaw or Hermes.
- Telegram and WhatsApp bots that idle all day and answer a dozen messages.
- Scheduled scrapers that wake up, work for ninety seconds, and go quiet.
- Small internal webhook receivers that need a stable HTTPS URL and nothing else.
Bad fits: anything that is a database, anything that needs a real block device, and anything doing sustained CPU work. That last one is my honest gap. I do not know how the burst budget behaves after a week of steady 60% CPU, whether you get throttled hard or gradually, and the public docs are thin on the accounting. Until I have run that test myself I would not put a video transcoder or a busy CI runner on this.
The 7-day restart deserves a paragraph on its own. It is not a defect, it is a documented policy with automatic restart configured by default, and it forces a design decision you should be making anyway: state lives in the mounted bucket, not in the container filesystem. If your agent writes its memory to /tmp, it will lose that memory on day seven and you will spend an afternoon confused. Test the restart deliberately rather than discovering it.
One instance also means no redundancy. A restart is downtime. For a personal agent, thirty seconds of downtime once a week is invisible. For the WhatsApp bot that takes your restaurant’s orders on a Friday night, decide in advance whether that is acceptable, because there is no second instance to catch the traffic.
What to expect next from Cloud Run instances
SSH access is announced as coming soon for both instances and services, currently behind a private access signup. That is the feature that closes most of the remaining gap with a VPS for me. Not for daily operations, but for the twenty minutes a month when something is wrong and you need to look at the process table rather than guess from logs.
My expectation, and I want to be clear this is a guess rather than anything Google has said: I think this pattern gets more attention than the launch post suggests, because the workload it targets is growing quickly and nobody has been serving it well. I would also expect the price to move at GA, in either direction, and I would not build a customer-facing cost model on $5.70 until that happens. Preview pricing is a marketing number as much as an engineering one.
Three things I would want answered before I recommended this for anything billable. How the burst budget behaves under sustained load. Which regions it lands in, because a preview limited to us-central1 rules it out for anyone who needs low latency from India or Southeast Asia. And whether the 7-day ceiling gets extended or stays as the fixed shape of the product.
So here is what to do this week. Upload your agent’s config to a Cloud Storage bucket, set a billing budget alert at something small like $15 so you find out fast if you have misjudged, then run the gcloud beta run instances create command from the announcement against a throwaway agent. Leave it running for a full seven days and watch what the restart does to your state. After 30 days, open the actual invoice and compare it to $5.70 instead of trusting the number in a blog post, mine included. If it comes out clean, move one real workload across and keep the VPS running until you are sure.