How to Deploy a Google Antigravity App With Firebase Hosting

Open your app's folder in Antigravity. Save a copy or commit your current work before making changes.

In Settings → Customizations → Build with Google Plugins, enable the Firebase bundle when available. Google's bundle supplies guidance for services including Authentication, Firestore, and hosting. See Google's setup instructions.

Paste this prompt:

Inspect this app and prepare a deployment plan. Make no changes yet.

Identify the framework, package manager, build command, output folder,
Firebase services, and any code that needs a server. List the required
settings by name, without printing secret values.

Tell me whether Firebase Hosting fits this app. If it needs App Hosting
or another server, explain the reason and propose that route.

Check sign-in, database permissions, client-side secrets, and what could
break after deployment. Preserve existing records. Flag any migration
separately. Show the files and commands you propose changing.

Wait for approval before creating resources, changing billing, changing
live security rules, or deploying.

For the CRM example, expect React, Vite, TypeScript, Firebase Authentication, and Cloud Firestore. Vite normally builds into dist; confirm the folder in your project. Vite's deployment guide covers its build output.

Use a staging project for testing and a separate production project for the app people will use. Firebase recommends separate projects to protect live data during development. Read its testing guidance.

In the Firebase console, create or select the staging project, register a web app, and copy that app's Firebase configuration. Create a Firestore database with access denied by default. Then enable Email/Password under Authentication → Sign-in method for this example. Firebase documents web app registration, password sign-in, and locked-down starting rules.

Install the Firebase command-line tool, sign in, and list the projects you can access:

npm install -g firebase-tools
firebase login
firebase projects:list

Use a Node.js version supported by your app and the current Firebase CLI. Run these commands in the project's terminal. Firebase's CLI reference covers installation and project selection.

In later commands, replace STAGING_PROJECT_ID and PRODUCTION_PROJECT_ID with the exact IDs you intend to use. The --project flag selects the destination explicitly.

Keep the browser settings and deploy target aligned.

The kit includes .env.staging.example and .env.production.example. Fill them with the matching Firebase web configuration and save local copies as .env.staging.local and .env.production.local. Check that Git ignores the local files. Match the variable names to the ones your app reads.

Vite includes VITE_ values in the browser build. Use them only for public client settings. Keep service-account keys, payment secrets, and private AI API keys on a server. Vite explains environment variables and build modes.

Firebase's web configuration includes an API key designed for client use. Restrict it to the required Firebase APIs and enforce data access with Security Rules. Keep a separate secret key for a service such as the Gemini Developer API. Read Firebase's API-key guidance.

For this small internal CRM, use approved accounts with private records. Each approved account can manage its own companies, contacts, deals, and notes. A trusted administrator controls the list of approved accounts. Have the agent show you where that approval lives, then approve your test accounts through the Firebase console or a trusted admin tool.

Ask Antigravity to implement that policy in both the app's data paths and Firestore Security Rules. Include checks that reject invalid fields and prevent users from changing record ownership or approving themselves.

A rule that grants access to every signed-in user would allow much broader access. Check permissions at the database level. Firebase supports checks based on the signed-in user's ID and document data. See Firestore's access-control examples.

Use this prompt:

Test the CRM's access rules with the Firebase Local Emulator Suite.

An approved user must be able to manage their own CRM records.
A signed-out visitor, an unapproved account, and another approved user
must fail when reading or changing those records.

Also test attempts to change ownership, grant account approval, or save
invalid fields. Use client requests for these tests. Report each test
and its actual result. Keep existing data intact and show proposed rule
changes for review. Do not deploy them yet.

Firebase provides a rules-testing library and emulator workflow. Use client requests to test restrictions; server libraries using admin credentials bypass Firestore Security Rules and need their own access checks.

For a shared team CRM, define team membership and roles before allowing shared access. Have someone qualified review the rules before you add real customer data.

For a Vite-based build script, create the staging build:

npm run build -- --mode staging

This uses the staging mode's settings. Check that the build finishes and produces dist/index.html. Run the project's tests and type checks as well. Vite documents staging modes.

Initialize Hosting when the project does not already have a Hosting configuration:

firebase init hosting --project STAGING_PROJECT_ID

Choose the existing staging project, set the public directory to dist, and select the single-page app option for this React app. Keep the app's generated index.html if the CLI asks to overwrite it. Review existing configuration before rerunning setup. See Firebase's initialization steps.

For this one-site example, the Hosting section of firebase.json should look like this:

{
  "hosting": {
    "public": "dist",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],
    "rewrites": [
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

Merge this section with your current file. Preserve any Firestore, emulator, function, or other settings. The rewrite sends routes such as /contacts to the React app when someone opens them directly. Apps with API rewrites need to preserve their routing order. Firebase documents Hosting configuration.

Firestore needs its own configuration and rules. If those files are missing, ask the agent to help run firebase init firestore --project STAGING_PROJECT_ID, then review the generated files. After the rules tests pass and you approve the changes, deploy them:

firebase deploy --only firestore:rules --project STAGING_PROJECT_ID

Review and deploy any required Firestore indexes separately. A Hosting deployment alone leaves your database rules unchanged in this static-app setup. Firebase documents rules deployments.

Publish the staging build to a temporary preview URL:

firebase hosting:channel:deploy crm-check --project STAGING_PROJECT_ID

Open the URL the command returns.

Preview URLs are public. They also use the backend configured in the app. Keep the staging build connected to your staging Firebase project and use fictional records. Firebase explains preview-channel behavior.

If sign-in fails on the preview, check the hostname and redirect settings required by your Auth provider.

Run this smoke test, a short check of the app's main functions:

Run the permission tests against the database as well as the interface. Hiding a record on screen alone cannot establish that access is blocked. Firebase's security checklist recommends automated rules tests.

Save the results. Fix any failed checks before sharing the app.

Set up the production project's web app, Authentication, Firestore, approved accounts, and reviewed rules. Use the production values in .env.production.local.

Changing --project changes the upload destination. It does not replace Firebase settings already built into JavaScript. Rebuild with production settings, and check the project ID the app will use. Firebase documents deploy targets, and Vite documents build-time settings.

Ask Antigravity for one final review:

Prepare this CRM for production deployment.

Show the Firebase destination project ID, the project ID used by the
browser build, the Hosting site, and the build output folder. List any
failed or unrun tests. Check for private keys, test endpoints, emulator
connections, and unrestricted database access.

List the exact commands and which services they change. Flag any
existing live site or database that those commands could affect.
Wait for my approval before deploying.

After review, run each command separately and stop if any command fails:

npm run build
firebase deploy --only firestore:rules --project PRODUCTION_PROJECT_ID
firebase deploy --only hosting --project PRODUCTION_PROJECT_ID

These commands assume you have reviewed the rules and configured this project for the single-site example. Deploy any required indexes before testing queries. Hosting returns your live site URL, usually on web.app. See the Hosting deployment steps.

Run the same smoke test on the live URL with dedicated test accounts and fictional records. Record the deploy time, source commit, and checks that passed. Remove your test records when you finish.

In the Firebase console, open Hosting, select the site, and choose Add custom domain. A subdomain such as crm.example.com lets you keep an existing website in place.

Follow the wizard's ownership check and add the exact DNS records it supplies at your domain provider. Wait for Firebase to show the domain as connected with an active HTTPS certificate. Preserve unrelated DNS records, including email records. Follow Firebase's custom-domain guide.

Check the new domain in Authentication → Settings → Authorized domains where your sign-in flow requires it. For Google sign-in or email links, verify the required domain and redirect settings. Test sign-in, sign-out, and password reset from the final address. Firebase covers Google sign-in domains and email-link domain requirements.

An authorized domain controls where supported sign-in flows can run. Your app's access rules still decide who can use the CRM.