Our article about deploying Next.js on Cloud Run is one of the most popular articles on our blog. Many readers have reached out to express how helpful they found it. However, some people also encountered various issues that I believe are worth addressing in a separate blog post.

Table of contents

1. Deploying on Cloud Run Vs Deploying on a virtual machine

2. How does Google make money from Cloud Run

3. Running frontends on Cloud Run

   1. Poor latency
   2. Cloud run is expensive !
   3. Better alternatives must be explored

4. Conclusion

Deploying on Cloud Run Vs Deploying on a virtual machine

When you create a VM, or Virtual Machine, you have a server allocated to you 24x7. It has a processor that sits idle, waiting for work, and memory that is ready to be used. Regardless of whether you utilize it or not, you pay for the entire thing 24x7. The costs of these machines can range from $5 to $5000 a month or even more.

However, it's not just the cost of the machine. You need to spend time setting it up, ensuring it's working, and occasionally adjusting resources yourself. What if you get more traffic and want to add more machines? You can do that too. But when traffic decreases, you have to reduce the number of machines. This process can be automated, and tools like Kubernetes exist for this purpose.

The real issue arises when you have a small site with around 100 users a day, and you don't want to waste your time on a fragile $5-a-month server that keeps going down or a $45 robust server that is expensive. Nor do you want to spend $500 a month on running a full-fledged cluster of machines.

What you want is something much cheaper and extremely simple, even if it's not as fast as you'd like it to be.

Google Cloud Run can be thought of as a Kubernetes cluster managed by Google, but you don't pay for the management. You simply deploy a site on the cluster, and that's it. Google allocates no resources to it, and you don't pay anything for that. When the first request arrives, Google promptly allocates resources for it, and you only pay for the time it took to handle the request. Google charges you based on the exact amount of CPU or memory your application used to handle that request.

This means if you receive no traffic for a month, you pay $0.

This is an appealing deal with one side effect. When the first request arrives, Google boots up your application, starts everything, and then serves the request. This process might take a few seconds, so the first request is always somewhat slow. Subsequent requests will be handled quickly, but once the requests stop, Google will eventually shut down that node.

Google Cloud Run is affordable and easy to use, but as mentioned earlier, it can be a bit slow for initial requests.

How does Google make money from Cloud Run

Cloud Run's pricing model seems quite friendly despite its drawbacks. But how does Google profit from this service? And why isn't everyone switching to Cloud Run?

With Cloud Run, Google doesn't guarantee that any node will be active at a given time. This means that if you want at least one node to be available, you have to pay for it 24x7! This can make it quite expensive.

Keep in mind that Google operates data centers with thousands of connected CPUs. Cloud Run is an excellent way for Google to generate revenue from idle hardware. If Google needs the resources for a higher-paying customer, they can simply take the node away.

So, even though your monthly costs for Cloud Run might be lower than renting a full VM, at around $100, you're actually better off using a full VM instead of Cloud Run. This is because the VM will be more capable and always available.

Running frontends on Cloud Run

While NextJS certainly runs on Cloud Run and performs quite well, it's important to keep in mind that the first request will be slower on Cloud Run. Compared to many other frameworks, such as Angular, Spring Boot, and Rails, NextJS has a much smaller footprint and boots up quickly. However, the difference in time is still noticeable.

Poor latency

Users expect pages to load quickly, and search engines have even higher expectations. Running things on Cloud Run affects one of the most important numbers for performance scores: Time to First Byte (TTFB). In my experiments, Cloud Run consistently performs poorly on this metric.

With custom domain names, certain regions are known to have high latency. This is a well-known issue in Cloud Run. Some regions, like Mumbai, do not support custom domains at all.

Cloud run is expensive !

While the overall cost of Cloud Run is quite affordable, if your site receives a large number of requests, Cloud Run's usage-based pricing model can become significantly more expensive. This is especially true depending on the type of site you are running.

For any site with decent traffic that keeps at least one node active 24x7, it is certainly more costly than running a VM with your container.

Better alternatives must be explored

If you have a website, you should consider whether it can be 100% static or if it needs dynamic page rendering for certain pages. If it can be made static, you might want to look into Github pages, Vercel, Netlify, Cloudflare Pages, and others. Google's Firebase is also a good platform, but it comes with vendor lock-in.

Conclusion

Cloud Run is an excellent service, but it may not be suitable for high-traffic websites unless you're willing to pay more. Keep in mind that you might be better off using static site hosting services wherever possible or opting for a dedicated virtual machine.