Firebase Hosting vs Cloud Run Cost

Firebase Hosting is a strong default for static sites, SPAs, marketing pages, docs, and cached assets because the main cost drivers are storage and outbound transfer. Cloud Run is a better comparison point when each request needs server rendering, custom API logic, authentication checks, database work, AI calls, or webhook handling.

For a realistic estimate, split traffic into static asset views, dynamic page requests, API calls, and file downloads. A site can use Firebase Hosting for the public shell and Cloud Run for dynamic routes, so the cheapest answer is often a mixed architecture rather than a single product choice.

Hosting and CDN behavior can change the cost shape more than the framework choice. Long-lived cache headers for versioned JavaScript, CSS, images, and fonts reduce repeated transfer. Shorter cache rules are still useful for HTML or pages that change often, but they should be intentional instead of inherited from a default deploy.

Cloud Run cost grows with request count, allocated CPU and memory, response time, concurrency, and any minimum instances kept warm. If a page can be pre-rendered or cached at the edge, avoid paying for a container on every visit. If every request must run personalized backend logic, estimate Cloud Run separately from static hosting bandwidth.

Use Firebase Hosting first when the product is mostly static, has predictable asset downloads, and needs fast setup with SSL and custom domains. Use Cloud Run when the hosting layer is really an application server: SSR, APIs, image generation, payment callbacks, AI workflows, or backend orchestration.

Before launch, run two calculator scenarios: normal qualified traffic and a spike case from bots, retries, social sharing, or a campaign. Watch which input changes first: outbound GB, Cloud Run request time, database reads, file downloads, or minimum instance hours. That signal should drive the architecture decision.