[GCP] CloudRun costs optimization

Questions
1

Hi guys!

We are running a few n8n instances on CloudRun. Every single instance rise general GCP costs. I am trying to find a way to optimize those costs.
My current configuration is:

  • 2 CPUs + 4Gi memory (always-on billing, cpu_idle = false)
  • Single instance (min_instance_count = 1, max_instance_count = 1)
  • PostgreSQL database backend
  • Execution environment: Second Generation
  • Startup CPU Boost: true

Since we serve that for other users and embed n8n in our page the instance has to be available without any downtime.

I am looking forward for your recommendations.

Thank you!

2

@rgrzesk

I’d start by changing the billing model, because with cpu_idle = false and min_instance_count = 1 you are paying for that full instance all the time, even when usage is low. If you still need one warm instance for availability, I’d keep the main instance small and move executions to queue mode with workers, then right-size CPU and memory based on actual Cloud Monitoring usage. That is usually where the biggest savings come from.

3

Hey @tamy.santos thank you for your answer.
Initially I wanted to keep it like that, but it turned out that the instance is not warm and it brings startup errors by displaying: Cannot GET or Database not ready which is not acceptable.
Would liveness_probe keep the instance up and running as well? I cannot accept warm up of the instance of 1 minute.

4

happy to help :smiley:

I’d keep min_instance_count = 1, add a proper startup probe, and stop expecting liveness to keep the instance warm. Liveness only restarts unhealthy containers, while the startup probe is what prevents traffic from reaching n8n before the app and database are actually ready. If boot still takes close to a minute, I’d focus on reducing n8n startup time and database readiness.

5

That’s what I had before, at some point instances were being disconnected and the only way to get them up was redeployment. I created a thread about it Connection aborted - error reading from instance, CloudRun vs CloudSQL

Taking the advice I added liveness probe, since that time the instances are running all the time without any problem (yes, I guess they are restarting because of that). Do you have other opinion about that?

6

personally, I’d see liveness as a practical workaround, not the real root fix. If adding it stopped the instances from getting stuck, then I think it was absolutely worth doing, but if it is also causing silent restarts in the background, that tells me something deeper is still unstable. So I’d keep it for stability, but I’d still want to understand why the instance reaches that broken state in the first place, especially around readiness and Cloud SQL connectivity.

7

Exactly, that’s how I would envision that as well. It works well, but it’s not a remedy. Unfortunately I have no more responses in the other topic.
That’s why I am a bit worried of making cpu_idle=true to not have more of these restarts.
@tamy.santos are you using such configuration with luck?

8

@rgrzesk
I haven’t personally had good results relying on cpu_idle=true in cases where the service was already showing instability. It can help reduce costs, but in my experience it also makes cold starts and readiness issues more noticeable. If liveness is what is keeping your service stable today, I’d be careful with that change and test it gradually.