Why Firebase Hosting
Static sites with global CDN and zero config
The Problem
Static sites—SPAs, prerendered pages, documentation—need hosting that is fast, reliable, and simple. Setting up CDN, SSL, and deployment pipelines is undifferentiated work.
Complexity without value.
You can configure CloudFront distributions, manage SSL certificates, set up S3 buckets with the right permissions, create deployment scripts. Or you can run one command.
We needed hosting that:
- Deploys static assets globally with zero configuration
- Handles SSL automatically
- Integrates with CI/CD trivially
- Costs nothing for reasonable traffic
Current Options
| Option | Pros | Cons |
|---|---|---|
| VercelNext.js-optimized, excellent DX. |
|
|
| NetlifyJAMstack pioneer, feature-rich. |
|
|
| Firebase HostingGoogle CDN, simple deployment, generous free tier. |
|
|
Future Outlook
Static hosting is a commodity.
The differentiation is in ecosystem integration.
Firebase Hosting is simple on purpose. It does one thing: serve static files fast. If you need more—authentication, databases, functions—Firebase provides them. If you do not, you do not pay for them.
Edge compute is the next frontier.
Firebase is adding Cloud Run integration for server-side rendering and API routes. The static/dynamic line is blurring.
Our Decision
✓Why we chose this
- Zero configurationfirebase deploy and you are live. SSL, CDN, caching handled.
- Google CDNSame infrastructure as Google.com. Fast everywhere.
- Free tier10 GB storage, 360 MB/day transfer. Covers most projects.
- Atomic deploysAll files deploy together. No partial updates.
×Trade-offs we accept
- No build systemYou build locally or in CI. Firebase just hosts.
- Limited featuresNo preview deployments, no edge functions (without Cloud Run).
- Google dependencyPart of Firebase/Google Cloud ecosystem.
Motivation
Our marketing site, documentation, and internal tools are static or prerendered. They need global distribution, not server-side processing.
Firebase Hosting gives us Google's CDN without Google Cloud's complexity. One command deploys. SSL is automatic. Cache headers are sensible defaults.
We build in CI (GitHub Actions), deploy with firebase deploy. Total deployment config is ~10 lines. Time spent on hosting infrastructure: near zero.
Recommendation
Use Firebase Hosting for:
- Static sites and SPAs
- Prerendered pages
- Documentation sites
- Any purely static content
Build in CI, deploy to Firebase. Example workflow:
- Push to main triggers GitHub Action
- Action builds the site (Vite, Next export, whatever)
- Action runs firebase deploy
- Site is live globally
For dynamic features, add Cloud Run integration or use Firebase Functions. But start static—you can always add complexity later.
Examples
{
"hosting": {
"public": "dist",
"ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
"rewrites": [
{
"source": "**",
"destination": "/index.html"
}
],
"headers": [
{
"source": "**/*.@(js|css|woff2)",
"headers": [
{
"key": "Cache-Control",
"value": "public, max-age=31536000, immutable"
}
]
}
]
}
}Firebase config for an SPA. Rewrites handle client-side routing. Cache headers maximize CDN efficiency. Deploy with: firebase deploy --only hosting