AI & TechnologyFirebase Cloud Functions Min Instances: What They Cost (2026)

Setting minInstances on a Firebase function reduces 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 usually much cheaper under request-based billing than under instance-based billing, mostly because the idle CPU rate is far lower, 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 2nd gen function is a Cloud Run service, and the minimum is stored as an annotation, either on the revision template or on the service itself:

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

Prices vary by region and change, so check the page before you rely on any number. On 2026-10-21 the Cloud Run pricing page listed these default USD rates for Iowa (us-central1): request-based billing charges idle time for minimum instances at $0.0000025 per vCPU-second and $0.0000025 per GiB-second, and instance-based billing charges $0.000018 per vCPU-second and $0.000002 per GiB-second. 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 two rough figures for a function with the 1st gen default 256 MiB memory: about $3 a month with 1st gen style CPU and concurrency off, and about $8 a month with 1 CPU and concurrency on. As a check on the current price list, one vCPU and 512 MiB kept warm for a 30-day month (2,592,000 seconds) costs $6.48 for CPU (2,592,000 x $0.0000025) plus $3.24 for memory (1,296,000 GiB-seconds x $0.0000025), or $9.72 before any free tier, under request-based billing. The same instance under instance-based billing is $46.66 for CPU plus $2.59 for memory, or $49.25. These sums use the list prices above, recomputed from Google’s pricing page on 2026-10-21; 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. Firebase’s own example uses minInstances: 5, but that is an example, not a target. 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.

One catch before you redeploy: Google’s runtime schedule set October 30, 2026 as the decommission date for Node.js 20 on Cloud Functions, and after that you can’t update functions that still run on it. The free Cloud Functions Node.js 20 runtime checker reads your firebase.json and package.json to show which runtime you deploy.

When to get help

To put a number on your own setup, enter each function’s min instances, vCPU and memory in the free min instances cost calculator. It uses Google’s published us-central1 list prices.

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.