This estimate misses the entire benefit of Cloud Run which is metered compute billing. Nobody in their right mind would run a serverless stack if they had 250K

This estimate misses the entire benefit of Cloud Run which is metered compute billing. Nobody in their right mind would run a serverless stack if they had 250K connections 24/7. It’s specifically documented that it isn’t for long-running processes, just for event-based apps. More realistically you’d get 250k requests, serve them with a total of ~5 container instances, and then the billing stops 5 seconds later. It’s cheap. It’s not for websocket apps. It’s perfect for MVPs and spiky traffic. It’s an easy path to move the hosting to K8s, App Engine, or normal VMs (GCP VMs can just run containers with minimal config), which are all far better choices if traffic is predictable. I think this is a far more valuable model than Function-as-a-service, where the runtime environment is strictly defined. Since “it’s just containers” you could write a web server in brainfvck if you felt like it, write a tiny dockerfile, then ‘git push origin/main’ and Cloud Run gives you a running endpoint. Okay, there is some devops work to set up that pipeline, but that is mostly boilerplate. It’s Heroku but it scales down to zero (ie free) and up to 1000+ instances of your server in ms.