Firebase Hosting Guide: Custom Domains, SSL, Rewrites, and Preview Channels

Overview

This article gives you a reusable checklist for the parts of Firebase Hosting that matter most in day-to-day deployment work. The goal is not to explain every setting in isolation, but to help you make clean decisions when shipping a web app, static site, admin panel, or frontend connected to Firebase services.

At a high level, Firebase Hosting is most useful when you want to serve fast static assets, deploy predictable frontend builds, add a managed custom domain, and keep routing logic versioned in your project configuration. It fits well for modern web apps, especially when your frontend also uses Firebase Authentication, Firestore, Cloud Functions, or other managed services.

The pieces developers usually come back to are:

• Custom domains: connecting your own domain or subdomain to a Firebase-hosted app
• SSL: making sure HTTPS is enabled and expected hostnames resolve correctly
• Rewrites: sending incoming routes to your SPA entry point, a backend function, or another target
• Redirects: forwarding old paths or canonicalizing hostnames
• Headers: controlling caching and response behavior for static assets
• Preview channels: reviewing changes before they reach production

If your app also depends on server-side logic, it helps to think of Hosting as the front door, not the entire system. Static files may live on Hosting while APIs or dynamic rendering are handled elsewhere. If you are evaluating backend execution choices, see Firebase Cloud Functions vs Cloud Run: When to Use Each.

A good Hosting setup usually answers five questions clearly:

1. Which domain serves production?
2. Which routes are static, rewritten, or redirected?
3. Which assets should be cached aggressively?
4. How are staging and review environments handled?
5. Who on the team can deploy, verify, and roll back?

Checklist by scenario

Use the checklist that matches your situation, then combine items if your app has more than one hosting pattern.

1. Launching a standard single-page app

This is the most common firebase deployment pattern for React, Vue, Angular, and similar frontend builds.

• Confirm the build output directory is correct and consistent across local and CI environments.
• Set your public directory in project configuration to the actual compiled output, not the source folder.
• Add a rewrite so non-file routes return your main HTML entry point.
• Exclude generated secrets, source maps, or local-only files if they should not be deployed.
• Set cache headers carefully: long cache for hashed static assets, shorter or no cache for HTML where you want fresh deploys reflected quickly.
• Test direct navigation to nested routes such as /dashboard or /settings/profile, not just in-app navigation.
• Verify that your app still loads if a user refreshes on a deep link.

This is where firebase hosting rewrites are often misconfigured. If your SPA returns 404 on refresh, the usual issue is that Hosting is trying to find a physical file instead of rewriting the request to your main entry document.

2. Connecting a custom domain

For many teams, production is not complete until the default Firebase subdomain is replaced by a branded hostname.

• Decide whether production should live at the apex domain, a www subdomain, or another subdomain such as app.example.com.
• Pick one canonical hostname and redirect the others to it.
• Add the custom domain in your Firebase project and follow the required DNS verification steps.
• Update your DNS records exactly as specified by the setup flow.
• Allow time for DNS propagation before troubleshooting aggressively.
• Verify that both HTTP and HTTPS requests behave as expected after setup completes.
• Check redirect behavior between www and non-www if both can be reached.

For a firebase hosting custom domain setup, the operational issue is usually not the initial attachment but the final cleanup. Teams often leave multiple hostnames active without deciding which one should be canonical. That can create inconsistent links, cookie behavior, or analytics splits.

3. Enabling and validating SSL

Managed certificates are one of the conveniences that make Firebase Hosting attractive, but they still deserve a launch checklist.

• Confirm the intended domain resolves to Firebase before assuming certificate issuance will complete.
• Use the final production hostname consistently in app configuration, OAuth callback settings, and third-party integrations.
• Test secure loading of scripts, images, and fonts to avoid mixed-content issues.
• Verify that any external resources also use HTTPS.
• Make sure redirects do not accidentally bounce users between HTTP and HTTPS variants.

In practice, firebase ssl problems are often secondary issues. The certificate may be managed correctly, but the domain itself, DNS records, or app-level callback URLs are not aligned.

4. Routing some paths to backend logic

Many apps need Hosting to serve static assets while forwarding specific routes to backend code.

• List exactly which paths should stay static and which should be rewritten to serverless handlers.
• Avoid broad rewrites until you know which static files must remain directly served.
• Test route order carefully, because matching behavior matters.
• Keep API paths explicit, such as /api/**, to avoid accidental overlap with frontend routes.
• Document which team owns each route group.

If your backend uses Firebase-managed execution, the frontend-hosting layer and serverless layer should be designed together. For a deeper backend decision framework, review Firebase Cloud Functions Pricing, Limits, and Cold Start Tradeoffs.

5. Using preview channels for review and QA

Firebase preview channels are one of the most practical features for teams that want safer review workflows.

• Create a convention for who generates previews and when.
• Use previews for pull requests, stakeholder review, and visual QA before merging to production.
• Test environment-specific configuration so a preview does not accidentally point to production-only services without intention.
• Share preview URLs in your code review process, not as a separate ad hoc step.
• Define expiration and cleanup expectations for temporary environments.
• Record what was approved so production deploys can be traced back to a reviewed preview.

The main value here is not just convenience. Preview channels reduce the pressure to deploy directly to production in order to validate route changes, asset references, and basic interaction flows.

6. Deploying from CI/CD instead of a local laptop

A mature deployment process should not depend on one developer remembering the right command sequence.

• Store configuration in version control.
• Use a consistent build command in CI.
• Separate staging and production deployment steps if your team uses more than one environment.
• Restrict production deploy authority to the right pipeline or maintainers.
• Keep environment variables and non-public configuration outside the frontend bundle unless they are intended to be public.
• Make deployment logs easy to review after each release.

If your wider app stack includes auth, database access, and rules changes, align your release workflow across those pieces. Hosting is often the visible change, but it may depend on Authentication or Firestore updates elsewhere. Helpful references include How to Use Firebase Authentication: Providers, Flows, and Setup Checklist and Firebase Security Rules Guide: Firestore, Storage, and Realtime Database Patterns.

What to double-check

Before each production deployment, review these items even if your configuration has worked before. Most hosting incidents come from assumptions that went unverified.

Domain and DNS

• Is the correct project serving the production hostname?
• Did you change DNS anywhere else recently, such as through a registrar or proxy service?
• Are both the canonical domain and fallback hostnames behaving the way you intended?

Route behavior

• Do static assets still resolve after the latest build changes?
• Do deep links load directly in a new browser tab?
• Do redirect rules send users to the right final destination in one step rather than a chain?
• Are API routes excluded from SPA catch-all rewrites?

Caching

• Are HTML files updated quickly after deploys?
• Are fingerprinted JS, CSS, and image assets allowed to cache longer?
• Did you accidentally apply long-lived cache headers to content that changes often?

Caching mistakes are easy to miss because they often appear only after a second deployment. The first deploy looks fine, but users then receive old HTML with new asset references or new HTML with stale assets.

Environment boundaries

• Is staging isolated from production enough for safe testing?
• Are preview builds calling the correct backend resources?
• Are analytics, auth redirects, and API base URLs environment-aware?

Team workflow

• Can someone other than the original setup owner perform a safe deploy?
• Is rollback or redeploy straightforward?
• Is the current configuration documented in the repository?

Common mistakes

These are the issues that repeatedly create friction in Firebase Hosting projects.

Treating all routes the same

A frontend app, static assets, API endpoints, and legacy URLs usually should not all share one broad rule. Overly generic rewrites make debugging harder and can hide routing bugs until production traffic hits unexpected paths.

Skipping hostname decisions

Many teams attach a domain successfully but never choose a canonical hostname. That leaves duplicate entry points live. Decide whether users should land on example.com, www.example.com, or an app subdomain, then redirect consistently.

Forgetting non-root pages

Testing the homepage is not enough. The most common routing failure only appears when a user refreshes on a nested route or opens a shared deep link directly.

Confusing frontend config with secrets

Developers new to Firebase sometimes assume every config value must be private. In frontend apps, some Firebase configuration is intentionally public, while true secrets belong outside the client bundle. Review your boundary carefully and avoid embedding anything sensitive in deployable static files.

Using previews without process

Preview channels are strongest when tied to pull requests, approvals, and clear ownership. Without a workflow, they become temporary links no one revisits and no one trusts.

Ignoring adjacent architecture choices

Hosting works best when the rest of the app architecture is also deliberate. If you are still deciding between backend and database patterns, related reading can help prevent rework later: Firestore vs Realtime Database: Which One Should You Choose?, Firestore Data Modeling Best Practices for Scalable Apps, and Firebase vs Supabase: Feature, Pricing, and Scaling Comparison.

When to revisit

Firebase Hosting configuration is not something you set once and forget. Revisit it whenever the inputs around your app change.

• Before a major launch or seasonal traffic spike: review caching, domain routing, and your deployment process.
• When adding a new app surface: such as an admin panel, docs site, or marketing subdomain.
• When introducing serverless routes: especially if rewrites now send some paths to backend execution.
• When changing authentication flows: callback URLs and authorized domains often need to stay in sync with hosting changes.
• When adopting CI/CD or preview workflows: process changes can matter as much as technical settings.
• When your team changes: undocumented hosting setups become fragile when the original owner leaves.

A useful habit is to keep a short pre-deploy checklist in your repository. Include the production domain, redirect expectations, cache rules, preview workflow, and the specific routes that must be tested manually. That turns Firebase Hosting from a one-time setup into a repeatable operational practice.

If you want one final action list before your next deploy, use this:

1. Confirm the correct project and target environment.
2. Build locally or in CI and verify the actual output directory.
3. Test homepage, deep links, redirects, and API paths.
4. Review custom domain and canonical hostname behavior.
5. Confirm HTTPS works cleanly across the site.
6. Check cache behavior for HTML and hashed assets.
7. Use a preview channel for review if production impact is meaningful.
8. Deploy, then verify the live site in a fresh browser session.

That short loop covers most of the mistakes teams make with firebase hosting. As your stack grows, Hosting will still be the layer users see first. Keeping domains, SSL, rewrites, and previews tidy is one of the simplest ways to make the rest of your Firebase app development workflow feel more reliable.