Deploy a Firebase-Powered Website or Web App to Production

Review the Project Before Deploying

Identify which parts of the project run in the website itself and which parts depend on Firebase before deploying anything.

Production Deployment Review

Identifies the frontend framework, package manager, build/output settings and runtime version, catalogs every Firebase product, provider, and integration in use, classifies frontend hosting vs Firebase services vs external services vs production configuration, checks for exposed secrets, and finishes with the exact deployment settings and a pre-deployment checklist.

Review this project specifically for production deployment while keeping Firebase as its backend. Identify: - the frontend framework and project type - the package manager - the production build command - the build output directory - whether the frontend is static or requires a Node.js/server runtime - the required Node.js/runtime version, if applicable - every Firebase product used by the project - Firebase Authentication providers - Cloud Firestore collections and data relationships - Realtime Database usage, if any - Cloud Storage usage and upload flows - Cloud Functions or other server-side Firebase services - Firebase App Check, if configured - Firebase Analytics or other Firebase integrations - every environment variable used by the project — names only - Firebase client configuration used by the frontend - any service-account credentials or Firebase Admin SDK usage - any non-Firebase APIs or external services - OAuth redirect or callback URLs - CORS or allowed-origin configuration - webhooks - hard-coded localhost, preview, Firebase Hosting, or old production URLs - anything that depends on the final production domain Classify what you find into: 1. Frontend hosting — what will run on the new Hostinger deployment 2. Firebase services — what should continue running in Firebase 3. External services — anything hosted somewhere else 4. Production configuration — anything that must change when the project gets its live domain Check whether any private server credentials, service-account keys, or other secrets are exposed in frontend code. Do not expose secret values. Do not change or deploy anything yet. Finish with: - the recommended deployment type - the exact build command - the exact start command, if required - the build output directory - the required runtime version - the Firebase services that will remain unchanged - everything that must be configured before production deployment

NOTE

The Firebase web configuration object itself is designed to identify the Firebase project and is not what protects access to Firestore or Storage. Firebase relies on Security Rules, IAM where applicable, and App Check for access control and abuse protection; private service-account credentials and other true server secrets must still remain private.

Secure Firestore and Storage

Review any Firebase Security Rules that were created during development. Do not leave production data protected only by development or test rules.

Your rules should enforce the access model your application actually needs, such as: public data that anyone may read, authenticated-only data, user-owned private documents, admin-only operations, protected file uploads, user-owned files, and restricted write operations.

Open Firestore and Storage rules in Firebase and review them with your AI coding assistant.

Firestore Database Rules

Firestore rules

Storage Rules

Storage rules

Firebase Production Security Review

Reviews Firestore and Storage Security Rules, Authentication usage, UID-based ownership checks, admin-only data, public vs private collections and files, dangerous test-mode or blanket allow rules, Admin SDK/service-account usage, and App Check configuration, then verifies user isolation and finishes with a READY / NOT READY verdict.

Review this project's Firebase configuration for production security. Focus on: - Cloud Firestore Security Rules - Cloud Storage Security Rules - Firebase Authentication usage - ownership checks based on the authenticated user's UID - admin-only data or operations - public versus private collections - public versus private files - dangerous test-mode or blanket allow rules - Firebase Admin SDK usage - service-account credentials - App Check configuration, if used Verify that one authenticated user cannot read, update, or delete another user's private data unless the application explicitly requires it. Verify that unauthenticated users cannot access private data or files. Look for rules such as unrestricted read/write access that would be unsafe in production. Do not weaken existing security. Do not expose credential values. If changes are required, make the smallest necessary changes and explain why. Test the rules where practical before considering the Firebase backend production-ready. Finish with: Firebase security: READY / NOT READY If NOT READY, list exactly what remains unsafe or incomplete.

IMPORTANT

Firestore and Cloud Storage Security Rules are a critical production control. Firebase explicitly warns against permissive development rules such as unrestricted read/write access in a deployed application.

Check Authentication

If the project uses Firebase Authentication, verify the following before deploying.

Enabled sign-in providers

Authorized domains

Password reset flow

Email verification if used

OAuth providers such as Google

Any provider-specific callback settings

NOTE

Do not add the final production domain yet if it is not connected. We will do that after the deployment exists.

Check App Check

If the project already uses Firebase App Check, make sure the new production domain and deployment will work with its configuration.

If App Check is not currently used, do not add it automatically unless it makes sense for the project. Treat it as additional protection rather than a replacement for Security Rules.

NOTE

Firebase recommends monitoring App Check traffic before enforcement so legitimate production users are not accidentally blocked.

Push the Production Project to GitHub

If the project is not already connected to GitHub:

Create or choose a repository Push the production-ready project Make sure private .env files, service-account files, and other sensitive credentials are excluded

If the project already uses GitHub, use the existing repository when appropriate.

Get Hostinger Web App Hosting

This tutorial uses Hostinger to run the production website or web app.

Get Hostinger Web App Hosting

Deploy your Firebase-powered project from GitHub and keep future updates connected.

USED IN THIS TUTORIAL

https://www.hostg.xyz/SHJyP

Set Up Hostinger

Create a new website or Node.js web app in Hostinger based on the project type identified in Step 1. Connect the GitHub repository and review the detected settings.

Configure:

Framework/project type

Production branch

Node.js/runtime version if required

Build command

Start command if required

Output directory or entry file

Hostinger currently supports GitHub-based deployments for modern JavaScript applications and lets you review or adjust detected build settings before deployment.

Add the Production Environment Variables

Add the environment variables required by the frontend.

These may include Firebase configuration variables such as:

Firebase API key

Auth domain

Project ID

Storage bucket

Messaging sender ID

App ID

The exact names depend on the framework and existing project.

Also add any other client-safe production configuration required by the frontend.

IMPORTANT

Do not add private server credentials to client-exposed environment variables. In particular, keep things such as these private: service-account private keys, Firebase Admin credentials, third-party private API secrets, payment secrets, and email provider secrets.

Hostinger supports adding environment variables during deployment without storing them in the GitHub repository.

Production Configuration Check

Review the Hostinger deployment configuration before deploying.

Hostinger Deployment Configuration Check

Verifies the framework, package manager, build/start commands, output directory, runtime version, every required production environment variable name, which Firebase configuration values are client-safe, whether any true secret is exposed to client-side code, and that Firebase remains the backend rather than being moved into the frontend hosting environment. Finishes with a Ready to deploy verdict.

Review this project's Hostinger deployment configuration before I deploy it. Verify: - framework/project type - package manager - build command - start command, if required - build output directory or entry file - required runtime version - every required production environment variable name - which Firebase configuration values are safe for the frontend - whether any true private secret is accidentally exposed to client-side code - whether any Firebase Admin or server-only code requires a separate server runtime Also verify that Firebase itself remains the backend and that I am not accidentally trying to move Firestore, Authentication, Storage, or other Firebase services into the frontend hosting environment. Do not expose secret values. Do not deploy anything. Finish with: Ready to deploy: YES / NO If NO, list only what is missing or unsafe.

Deploy

Start the Hostinger deployment.

Keep the Firebase project unchanged and active.

Test the Temporary Deployment First

Before changing your domain, verify:

Pages and routes load

Firebase initializes correctly

Public Firestore reads work

Authenticated Firestore operations work

Storage files load

Uploads work if used

Authentication loads correctly

API requests work

There are no Firebase permission errors

There are no browser console or network errors

IMPORTANT

Do not switch the real domain until the new deployment works.

Connect Your Domain

Add the production domain to the Hostinger deployment and configure its DNS.

Then update Firebase and any other services that depend on the production URL.

Authentication Authorized Domains

If Firebase Authentication is used, add the production domain to the project's Authorized Domains where required.

Authentication Settings Authorized domains

NOTE

For newer Firebase projects, localhost is no longer automatically authorized, and Firebase recommends limiting authorized authentication domains to those actually required.

Update Production URLs

Use your AI coding assistant to find everything that needs the final domain.

Update Production URLs Review

Checks Firebase Authentication authorized domains, OAuth sign-in configuration, redirect URLs, site/app URL environment variables, CORS and allowed origins, API base URLs, Cloud Functions/external backend origins, App Check configuration, webhooks, payment callbacks, email confirmation and password-reset URLs, canonical/sitemap/Open Graph URLs, and any hard-coded old URLs, then returns a short checklist of what needs updating for the final domain.

The project is now deployed and I am connecting its final production domain. Review the project and Firebase configuration for anything that must be updated for the new domain. Check: - Firebase Authentication authorized domains - Google or other OAuth sign-in configuration - authentication redirect URLs - site/app URL environment variables - CORS and allowed origins - API base URLs - Cloud Functions or external backend origins - App Check configuration - webhooks - payment callbacks - email confirmation URLs - password-reset URLs - canonical URLs - sitemap URLs - Open Graph URLs - hard-coded localhost, preview, Firebase Hosting, or old production URLs Do not expose secrets. Do not change DNS. Give me a short checklist of exactly what needs to be updated for the final domain.

Apply only the settings relevant to your project. If environment variables change, apply the updated values to Hostinger and redeploy if required.

Final Production Test

Once the final domain is connected, test the entire application as a real production user. Check:

Homepage and important routes

Direct page refreshes

Account creation

Login and logout

Session persistence

Password reset

OAuth login if used

Firestore reads

Firestore writes

User-owned/private data

Storage downloads

File uploads

Firebase Functions if used

External APIs

Forms

Email

Payments and webhooks

Mobile behavior

HTTPS

Root domain and www

Browser console

Failed network requests

IMPORTANT

For applications with private data, explicitly test two different user accounts to make sure one user cannot access another user's protected data.

Run the Final Production Audit

Run a final production-readiness audit before calling the launch done.

Final Production-Readiness Audit

Verifies the site loads, Firebase initializes, Authentication and sessions work, password reset/OAuth work if used, Firestore and Storage Security Rules protect private data and block unauthenticated access, Cloud Functions work if used, Firebase Admin credentials stay server-only, external APIs/CORS/App Check are correct, HTTPS and the final domain work, and no leftover dev-only rules or temporary URLs remain. Finishes with a GO / NO-GO verdict.

Run a final production-readiness audit for this Firebase-powered application. Verify: - the production website loads correctly - Firebase initializes successfully - Firebase Authentication works - sessions persist correctly - password reset and OAuth work if used - Firestore Security Rules protect private data - one user cannot access another user's private records - unauthenticated users cannot access protected data - Cloud Storage rules protect private files - uploads and downloads work - Cloud Functions work if used - Firebase Admin credentials remain server-only - external APIs and integrations work - CORS and allowed origins are correct - App Check works correctly if enabled - HTTPS and the final domain work - no localhost, preview, old Firebase Hosting, or temporary deployment URLs remain where they should not - no development-only Firebase rules remain - there are no important console or network errors Do not weaken Firebase Security Rules to make a failing test pass. Do not expose secret values. Finish with: Production status: GO / NO-GO If NO-GO, list exactly what must be fixed before real users should use the application.

Once the project is live, the normal workflow is:

Make your changes Test locally Check whether Firebase rules, indexes, Functions, or configuration also changed Run the production build Push the frontend changes to GitHub Let Hostinger deploy the new version Apply Firebase-side changes separately when required Test the live application again

Pre-Update Production Check

Reviews the code changes, runs the production build, and checks whether frontend environment variables, Firestore or Storage rules, Firestore indexes, Firebase Functions, Authentication/authorized-domain configuration, or any external API/webhook/production URL changed — and that no private Firebase Admin or service-account credentials are exposed. Finishes with a Ready to update verdict.

I have updated this Firebase-powered project and want to publish the changes. Before I push the update: - review the code changes - run the production build - check whether frontend environment variables changed - check whether Firestore Security Rules changed - check whether Storage Rules changed - check whether Firestore indexes changed - check whether Firebase Functions changed - check whether Authentication or authorized-domain configuration changed - check whether any external API, webhook, or production URL changed - make sure no private Firebase Admin or service-account credentials are exposed Do not deploy anything automatically. Finish with: Ready to update: YES / NO If NO, tell me what must be completed first.