What hosting a small business site on Firebase really costs

Firebase App Hosting has no fixed monthly price. Google bills for what your site uses; for most small business sites we estimate a few dollars a month or less, depending on traffic.

How App Hosting is billed

As of October 2026, Google's App Hosting cost page says App Hosting requires a project on the pay-as-you-go Blaze pricing plan, and that the project “incurs costs once you exceed the pay-as-you-go Blaze pricing plan no-cost allowances.” On Blaze, the project is linked to a Cloud Billing account, which holds the card Google charges. That account should be in your name; see who owns your website.

App Hosting itself charges for outgoing data, at a lower rate when it is served from the cache on Google's content delivery network, Cloud CDN. The same page says you also pay for the Google Cloud products underneath:

• Cloud Run, which runs the site's server code and answers any request the cache can't
• Cloud Build, which builds each new version
• Artifact Registry, which stores those versions
• Secret Manager, which holds keys and passwords
• Cloud Logging, which keeps logs
• Cloud Storage, used only for deploys from local files or an uploaded archive

What is free

As of October 2026, the cost page lists these no-cost limits each month:

• Outgoing data: 10 GiB, then $0.15 per GiB served from the cache and $0.20 per GiB uncached
• Cloud Run: 180,000 vCPU-seconds, 360,000 GiB-seconds of memory and 2 million requests
• Cloud Build: 2,500 build-minutes
• Artifact Registry: 0.5 GB of storage
• Secret Manager: 6 active secret versions and 10,000 access operations
• Cloud Logging: 50 GiB of log storage per project, kept 30 days at no cost

Google says this no-cost usage is “aggregated across projects by billing account and resets every month,” and Cloud Run's pricing page says the same of its free tier. If one billing account pays for several projects, they share one allowance. Log storage is the exception, at 50 GiB per project.

Firestore, the database, counts differently. As of October 2026, Google's Firestore pricing page lists a free quota of 1 GiB of stored data; 50,000 document reads, 20,000 writes and 20,000 deletes a day, reset around midnight Pacific time; and 10 GiB of outbound data a month. It applies per project, to one database. A contact form uses a handful of writes per inquiry, far inside that.

What drives the bill

• Data served. Pages, images, scripts and fonts. In Google's example below it is almost the whole bill at 1 million visits, and Google notes that a page rich with images will likely cost more to serve than a simple HTML file.
• Pages rendered on request. Anything the cache can't answer goes to Cloud Run, which bills processing time, memory and requests. Google says generating a page on the server is “typically pricier than serving a cached version from a CDN.”
• Builds. Each rollout runs Cloud Build. Google's example assumes 20 builds a month of 8 minutes each: 160 of the 2,500 free build-minutes.
• Database reads and writes. A store that reads Firestore on every page view uses far more than a site whose only database use is a contact form.

What usually doesn't: the number of pages, storing builds (App Hosting deletes old ones automatically), and quiet hours, covered below.

What a small site typically costs

Google's cost page has one worked example, for a dynamic web app. As of October 2026, it assumes about 10 billed requests per visit; an average response of 400 KiB taking 1,000 milliseconds; half of requests served from the cache; App Hosting's default server settings (1 vCPU, 512 MiB of memory, 80 requests at once per instance, 0 to 100 instances); 20 builds a month of 8 minutes each, deployed from GitHub; a 380 MB build image; fewer than 6 secret versions; and logs kept under 30 days.

Measured against the monthly no-cost limits, Google's sample bill comes to $0.01 at 10,000 visits and $69.58 at 1 million, a visit being “a request to your app initiated by a user.” Google sums it up: “At a level of 10k visits there are virtually no costs, with costs of any significance beginning to accrue at the 1M visit level.” At 1 million visits, nearly all of it is outgoing data ($39.00 uncached, $29.25 cached); Cloud Run's processing time and memory still cost $0.00. Google calls the examples “a general guide, but your actual costs may differ.”

Our estimate for a small business site is a few dollars a month or less, depending on traffic, page weight and how much is served from the cache. At thousands of visits a month rather than a million, Google's first figure is the closer comparison.

How to keep the bill predictable

Budget alerts

As of October 2026, Google's budget documentation says a new budget alerts by default at 50%, 90% and 100% of the amount, against actual spend, emailing the billing account's administrators and users. An alerts-only budget “doesn't automatically cap” usage or spending, and alerts lag behind spending; after a budget is created, the first can take several hours. Google's cost page strongly recommends budget alerts and spend caps.

Spend caps

Google's spend caps page lists App Hosting as eligible for a spend cap budget, in Preview as of October 2026. At 100% of the cap, Cloud Billing pauses App Hosting's underlying Cloud Run service for the rest of the month unless the cap is lifted. Google says these are not “hard caps”: enforcement can lag by several minutes, and spending in that time is billed as normal. A paused server can mean a site that stops working, so set any cap well above normal spending.

A maximum instance count

The maxInstances setting limits how many copies of the server run at once; App Hosting's default is 100. Cloud Run's documentation calls it a cost-safety limit: a higher maximum “prioritizes availability” but risks bills from unexpected traffic spikes or misconfigurations, and the limit can be exceeded briefly. It bounds server time, not data served from the cache.

Static pages and caching

Every request passes through Cloud CDN first, and anything already cached skips the server, according to Google's caching guide. Pages that are the same for every visitor can be rendered once at build time and cached; Next.js marks them cacheable. That saves server work and moves data to the cheaper cached rate. The App Hosting Usage tab in the Firebase console shows the cached and uncached split.

Scaling to zero, and cold starts

By default, App Hosting keeps no minimum number of servers running (minInstances is 0), and Cloud Run doesn't charge for idle ones, so quiet hours cost nothing in server time. The trade-off is a cold start: the first visit after a quiet period can be slower while a server starts. Google's Cloud Run docs describe keeping minimum instances “warm and ready to serve requests” to avoid slow container start times. Cached pages aren't affected. If the delay matters, we can keep one instance always warm; Google bills its idle time to your account at Cloud Run's lower idle rate, a steady monthly charge.

Small images

Data served is most of Google's example bill at high traffic. Resizing images to the size they are shown at, in modern formats such as WebP or AVIF, cuts what every visit sends.

How we set it up at Titus Apps

Your site runs in a Google Cloud project on your own billing account from day one, with us invited in as administrator. Google bills your card directly and the bill never passes through us, so there's no markup.

Every Hosting & Care plan includes Google Cloud budget alerts on your project, so you hear early if spending runs higher than expected. They warn you; they don't cap spending. See our Hosting & Care plans and how hosting and ownership work.