Hey There,
I am running N8N 2.8.3 on cloud run, I have set up minScale and maxScale at 1, and was just wondering what everyone else has this set on?
I guess, I set this up as minScale = 1 so that it was not cold starting (and maxScale so it doesnt cost heaps), but wondered if that is required. N8N instances mainly catches webhooks but also does some cronjobs as well.
Thanks
Chris
Hi @Chris_Bradley!
I would keep minScale = 1 as i want no delay in my webhooks and as i have seen some delays and slow response time when mineScale = 0 , like that scale is your cold start threshold 0 means it would give some delay and would start but in 1 it means rapid response i donno much about the down side of it. It is better for when we have custom Cron triggers.
Look here for more information about that.
thanks,
I think its really a question around the cost to not cold start vs how suitability it is to run n8n with a minScale of say 1.
will n8n and the cronjobs run if minScale = 0 ?
@Chris_Bradley Not like very sure but i guess if minScale is 0 then n8n will be cold started for webhooks and the cron triggers would not be triggered as they do when minScale is 1, and the reason i have found in documentation is that when minScale is at 0 there is no active container running, so i which means if you are using more of cron triggered jobs into your workflow keeping minScale to 1 would be a better take.
Hey @Chris_Bradley,
Just curious, what have you actually noticed in your setup when setting minScale = 0? When you try to access the n8n dashboard (the UI) after it’s been idle, roughly how long does it take for it to load up?
From what I’ve seen regarding self-hosting n8n on Cloud Run, the pros and cons of minScale usually boil down to this:
Setting minScale = 0
Pros: Unbeatable cost. When n8n is idle, Cloud Run shuts it down, meaning you pay $0 for compute while you sleep.
Cons: Cold starts are the big trade-off. The UI can easily take 10 to 30+ seconds to load if the container is asleep. Webhooks will also be delayed by that same startup time. Most importantly, n8n’s internal Cron Trigger nodes won’t fire if the instance is scaled to zero, because there’s no active server running to keep track of the schedule.
Setting minScale = 1
Pros: Always ready. The UI loads instantly, webhooks are processed with zero delay, and your Cron jobs run exactly when they are supposed to because the container never goes to sleep.
Cons: You pay for a constantly running instance. Even with Cloud Run’s efficient pricing, keeping an instance warm 24/7 means it’s no longer totally free.
Would love to hear if your cron jobs are actually surviving the 0 setting, or if you ended up having to switch to 1!
Thanks for your reply, interesting view that isn’t really documented (same as mine really)
I have set up a sandbox instance on cloud run with minScale=0 and a cronjob that sends a webhook to my prod n8n every 30 mins. Will check tomorrow or next day once billing is in and seeing what change in costing and if the cronjob is actually firing.
from my view - cronjobs are really the issue and webhooks taking their time (less so), I don’t have any running (as it is purely a test n8n instance), but I will test it out with a cronjob and minScale=0
UPDATE
So Cronjob doesn’t work (obviously) when the n8n if offline, spinning it online via a cronjob in run is possible, but the instance will linger for 15mins after its likely that it wont be worth it with webhooks and cronjobs.
just back onto this, I have ended up shifting from cloud run + cloud sql deployment.
It actually works pretty godd, the issue is the lignering 15min on cloud run and then the cost compared to running a ubuntu on digital ocean.