I've been running small services on Cloud Run for about a year now. Not a big migration story, just the honest list of where it fits and where it doesn't.
What it's genuinely good at
Internal webhooks. We have a handful of integrations that get maybe a hundred requests a day, each spike is unpredictable, and the rest of the time nobody is calling them. Cloud Run scales to zero, so the bill is basically nothing and I don't have to think about a VM.
Scheduled jobs that used to be cron on a box. Cloud Scheduler hitting a Cloud Run service with a shared secret is boring and reliable, which is exactly what I want for a nightly job.
Small internal tools: a form that writes to a sheet, a service that reformats a file and drops it in a bucket. The kind of thing where the code is fifty lines and the deployment used to be a whole afternoon.
What I don't use it for
Anything with a long-running connection. WebSockets are possible but I'd rather not fight with the request timeout and eventual cold starts. If the service needs to hold a connection for minutes, I put it somewhere else.
Stateful things. Cloud Run gives you no guarantees about which instance handles the next request, so anything that needs a local cache or a local file needs to be designed around that from day one. I learned this the hard way with a SQLite experiment that worked perfectly on my laptop and fell apart the moment two instances existed.
GPU workloads. Not the right product, and pretending otherwise is how you end up debugging someone else's scheduler.
The part people skip: cold starts
For low-traffic internal tools, cold starts are the whole story. The first request after idle can take a few seconds, and for a user clicking a form that feels broken. Two fixes that actually helped: keep the container small (multi-stage build, scratch or distroless base), and set a minimum instance count of 1 for anything a human waits on. The second one costs money, but less than you'd think for a small instance.
What I'd tell someone starting
Start with one small service and no min instances. Watch the cold starts for a week, and only then decide what deserves a minimum instance. The default configuration is a reasonable starting point, and most of the tuning advice you read online is for traffic you don't have yet.
Top comments (3)
The hundred-requests-a-day webhook is exactly where scale-to-zero earns its keep.
The min-instances=1 point is the one I keep coming back to. We tried to be clever with a scheduled warm-up and it was more fragile than just paying for one instance.
The SQLite experiment line made me laugh — same mistake, same laptop, same surprise when the second instance appeared.