Firebase Cloud Functions Min Instances: What They Cost (2026)

Setting minInstances on a Firebase function removes most cold starts, and you pay for that warm instance whether or not anyone calls the function. That is a fair trade on a login or checkout call. It is a poor one on a nightly job or a webhook, and it is easy to forget which functions have it.

This post covers what the setting does, how to list every function that uses it, how to estimate the monthly cost from Google's own pricing page, and how to cut it without making your app feel slower. If you want someone else to do the whole bill, App369 offers a fixed-price Firebase Cost-Cut Audit. For the wider method, see How to Cut Your Firebase Bill.

What min instances actually do

2nd gen Cloud Functions run on Cloud Run, so each function is its own Cloud Run service. Firebase's function management docs describe the setting as a minimum number of container instances kept warm and ready to serve requests. The docs also note that instances above that minimum can still cold start when traffic spikes, so it lowers cold starts rather than eliminating them.

The billing part is stated plainly in both places. Firebase's docs say a minimum number of instances kept running incurs billing costs at idle rates. Cloud Run's minimum instances page says instances kept running with the minimum instances feature do incur billing costs.

What "idle rate" means

Cloud Run has two billing modes, and which one a service uses changes the math:

• Request-based billing: CPU is charged while a request is being processed, and you are billed at a lower rate when instances are idle and waiting for requests. With min instances at 0, idle time is not billed.
• Instance-based billing: you are billed the default rate for the entire instance lifecycle, idle or not.

So a warm instance is cheaper under request-based billing than under instance-based billing, but it is never free. A function with minInstances: 1 costs something every hour of the month. A function with minInstances: 5 costs roughly five times that.

Find which functions set it

Start in code. Search your functions source for minInstances (Node.js) or min_instances (Python), and for setGlobalOptions, which sets defaults for every function in a codebase. A single global minInstances can quietly apply to dozens of functions you never looked at.

Then check what is actually deployed. Each function is a Cloud Run service, and the minimum is stored as an annotation:

gcloud run services list --format=json \
| jq -r '.[] | [.metadata.name, (.spec.template.metadata.annotations["autoscaling.knative.dev/minScale"] // "0")] | @tsv' \
| awk '$2 > 0'

To inspect one service, run gcloud run services describe SERVICE --region REGION. The Cloud Console shows the same value on the service's Scaling settings. If code and deployed state disagree, the next deploy wins, so trust your source code and fix it there.

Also look at the Firebase CLI output when you deploy: the docs say it provides a cost estimate at deployment time for functions with reserved minimum instances.

Estimate the monthly cost yourself

I am not going to quote a per-second price here, because Cloud Run prices vary by region and tier and change. The method is what matters:

1. Open the Cloud Run pricing page and pick your region and billing mode.
2. Note the idle (or instance-based) price per vCPU-second and per GiB-second, plus any free tier.
3. For each service, take its configured CPU and memory, multiply by the number of minimum instances and by the seconds in a month (about 2.6 million).
4. Add vCPU cost and memory cost, subtract free-tier allowances that apply, and you have the list-price cost of keeping that service warm.

Do this in a spreadsheet with one row per service. For actual spend rather than estimates, turn on Cloud Billing export to BigQuery and compare. Estimates are list prices; your bill can differ because of discounts, committed use and free tiers. Firebase's docs give one worked example for a small 1st gen function, so use the live pricing page for anything you rely on.

Cut it without hurting users

Ask one question per function: is a person waiting on this response?

• Keep it on latency-critical callables such as sign-in, checkout or a screen's first load, if you have seen cold-start delay there.
• Remove it from scheduled jobs, Firestore triggers, webhooks that the sender retries, and anything running in the background. Nobody notices a cold start there.
• Production only. Staging and development projects rarely need warm instances. Read the value from an environment parameter so staging gets 0.
• Lower the number. minInstances: 5 is rarely needed. Check how many instances are actually busy at peak in Cloud Monitoring before choosing.

Reduce cold starts instead of paying to hide them

Google's function tips list cheaper fixes:

• Load fewer dependencies. The docs say module load time adds to invocation latency during a cold start, so remove libraries the function does not use.
• Lazy initialization. Create heavy clients only when a function needs them, not at the top of a file shared by all functions.
• Concurrency on 2nd gen. The default is 80 requests per instance and you can set 1 to 1000, which lets an instance absorb spikes without a new cold start. The docs note concurrency needs at least 1 full CPU, and your code must be safe for parallel requests.

Roll back safely

1. Change one group of functions at a time, starting with background work.
2. Change the value in code and deploy, so the setting is not overwritten later.
3. Watch p95 latency and error rate for a few days for the changed functions.
4. If a function got slower, set the old value back and redeploy. In an emergency, gcloud run services update SERVICE --min MIN-VALUE changes it immediately, and the docs say default clears the setting. Update your code afterwards so the two match.

Write the old value in your commit message so reverting is one line.

When to get help

If your bill has more than min instances in it, the work is pricing every service and ranking changes by dollars and risk. App369's Firebase Cost-Cut Audit is $750 fixed price, delivered 5 business days after read-only access. You get a report with the monthly bill by service and savings ranked by dollars a month, user-visible risk and rollback, a CSV, and the exact gcloud and firebase commands. You apply the changes yourself. No savings are promised. Simon builds and runs Workspace369, a production Flutter and Firebase SaaS, and uses the same method on it.

Frequently Asked Questions

Do Firebase min instances cost money when idle?

Yes. Firebase says a minimum number of instances kept running incurs billing costs at idle rates, and Cloud Run says the same about its minimum instances feature. The idle rate can be lower than the active rate under request-based billing.

How do I find which Cloud Functions have min instances?

Search your code for minInstances and setGlobalOptions, then list deployed Cloud Run services and read the autoscaling.knative.dev/minScale annotation with gcloud run services list or gcloud run services describe. The Cloud Console's Scaling tab shows it too.

How do I turn off min instances on a Firebase function?

Remove or set minInstances to 0 in the function options and redeploy. For an immediate change on the Cloud Run service, use gcloud run services update SERVICE --min default or set the value to 0. Keep the code in sync.

How much does one min instance cost per month?

It depends on region, CPU, memory and billing mode. Take the vCPU and GiB-second prices from the Cloud Run pricing page, multiply by the service's configuration and the seconds in a month, then subtract any free tier.

Do I need min instances to avoid cold starts?

Not always. Lazy imports, fewer dependencies and 2nd gen concurrency reduce cold-start impact. Use min instances only where a user waits and cold-start delay is actually visible.