Deploy Antigravity App: 5 Steps to a Live URL (2026)

To deploy Antigravity app projects, you pick a host, let the agent prepare the build, review what it plans to run, and test the live URL. Antigravity writes the app, and you choose where the app lives.

I checked the three routes against Google's docs and the vendors' pricing pages. The routes are Firebase App Hosting, Cloud Run, and GitHub to Vercel. This guide shows how to choose one and the steps for each.

Deploy Antigravity app projects: which host to pick

Three routes fit the apps below, and the right one depends on what the app does. Our AI app deployment guide compares hosts in more depth.

Here is how each kind of app maps to a host:

If you're unsure, start with Firebase for a web app and Cloud Run for anything with a backend you want to control.

What you'll need before starting

Prerequisites:

• Antigravity installed in the form you use, such as the desktop app, the CLI, or an IDE extension, with an app that runs on your machine.
• For the Firebase route, Node.js 20 or higher and Firebase CLI 15.10.0 or higher, the versions Google's Antigravity guide lists.
• A Google Cloud or Firebase project for the Firebase and Cloud Run routes, or a GitHub account for the Vercel route.
• A list of the environment variables and secrets the app reads.
• Optionally, the Firebase or Google Cloud bundle for the Firebase and Cloud Run routes, which you enable under Settings > Customizations > Build with Google Plugins.

How to deploy an Antigravity app, step by step

Steps 1 to 3 are the same for every host. Step 4 splits into three paths, and Step 5 closes the loop.

🏃 Step 1: Run and test the app locally

Start the app the way you built it, and click through the main flow. Check that the pages load, the main feature works, and the console shows no errors.

Fix any bug you find before you deploy, because a live host makes the cause harder to trace.

Pro tip: Write down what a working app looks like. You'll compare the live version against it in Step 5.

🗺️ Step 2: Ask Antigravity to plan the deploy

Use the /plan command, which tells the agent to write an implementation plan before it executes anything. Then review the plan as an artifact before you let the agent continue.

Use a prompt like this:

/plan Prepare this project for deployment. Don't change any files yet.

Tell me the framework, build command, start command, and output folder.

Tell me whether the app is static or needs a server.

List every environment variable by name only, marked public or private.

Flag hardcoded localhost URLs, secrets in client-side code, and missing

build or start scripts.

Recommend Firebase, Cloud Run, or a Git-based host.

The answer on static or server code decides the host. Static apps fit Firebase Hosting, and apps with server code fit App Hosting or Cloud Run.

Read the plan before you approve it. You can comment on any part of the plan before the agent proceeds.

Pro tip: Ask for variable names only. A plan that prints secret values can leak them into a chat log or a commit.

🛠️ Step 3: Fix the deployment blockers

Fix these three blockers before you deploy, and leave everything else alone.

The three blockers:

1. Hardcoded localhost URLs: A call to localhost works on your machine and fails on a host. Replace it with a relative path or an environment variable.
2. Missing build or start scripts: Hosts read package.json to learn how to build and run the app. A server app also needs to read its port from the environment instead of a fixed number.
3. Secrets in client code: Anything in browser code is public. A private key belongs in server-side code, and a key that was ever committed needs rotating.

Ask the agent to fix only the blockers from the plan, without refactoring or adding features. Then review the diff before you accept it.

Then run the production build and open the result locally. Fix any build error now, because the host runs the same build command.

Pro tip: If the diff lists a long run of changed files, the prompt drifted past the blockers. Ask the agent to undo the extras.

🚀 Step 4: Deploy with your chosen path

Follow the section that matches your pick, whether that is Firebase App Hosting, Cloud Run, or GitHub to Vercel. Each section ends with a live URL.

✅ Step 5: Test the live URL and plan updates

Open the live address and test it the way a user would.

Check each of these:

• The page loads, and refreshing a deep route still works.
• The main feature works.
• Database and API connections work.
• Sign-in works, if the app has it.
• No private key appears in the page source or network tab.

Add the live URL to your auth provider's allowed redirects and your CORS list. Then pick how updates ship, whether through a Git push, a re-run of the reviewed script, or a prompt that tells the agent to publish.

For other first-deploy failures, see our guide to deploying vibe-coded apps.

Path A: Deploy to Firebase App Hosting

Google's Antigravity migration guide describes publishing to App Hosting with the prompt Publish my app. Firebase also ships agent skills for App Hosting (Next.js and Angular) and for Hosting (static sites, single-page apps, and simple microservices).

To deploy:

1. Install the Firebase CLI, sign in, and confirm the version is 15.10.0 or higher.
2. Upgrade your Firebase project to the Blaze plan, which App Hosting requires.
3. In the Antigravity chat, enter Publish my app.
4. Review the plan. When the agent asks to run firebase deploy, read the command and choose Yes.
5. App Hosting builds the app with Cloud Build, serves it on Cloud Run, and caches it in Cloud CDN.

For later updates, tell the agent to publish the app again. To deploy one backend, run firebase deploy --only apphosting:backendId and replace backendId with your backend's ID.

For a static app: Use Firebase Hosting instead. Firebase Hosting runs on the Spark plan, with 10 GB of storage and 360 MB of transfer a day, and needs no payment method.

Costs: App Hosting needs the Blaze plan and bills Cloud Run and Cloud Build usage. Firebase lists no-cost allowances of 10 GiB of bandwidth, 2 million requests, and 2,500 build-minutes a month.

Firebase strongly recommends budget alerts and a spend cap on Cloud Run.

Path B: Deploy to Google Cloud Run

Cloud Run suits an API, a Python service, or anything you package as a container. Google's Antigravity codelab builds a document pipeline that ends on Cloud Run, and it reviews each plan before execution.

To deploy, follow the codelab's order:

1. Plan the architecture: Describe the service, and the codelab's /grill-me prompt makes the agent ask follow-up questions before it writes an implementation plan.
2. Review the plan: Comment on any part of the implementation plan, especially names, the project ID, and the region. Then click Proceed.
3. Let it generate the files: The codelab produces the service code, a Dockerfile, deploy and setup scripts, and test scripts.
4. Run the script with your project and region: Set GCP_PROJECT and GCP_REGION, then run the deploy script. Read the script before you run it.
5. Verify in the Cloud Console: Check the Cloud Run service health and logs, then run the generated test against the live service.

Check whether the script makes the service publicly reachable before you run it. The codelab's service is unauthenticated, and its page limits are set for prototyping and quick testing.

Costs: Cloud Run's free tier covers 2 million requests, 180,000 vCPU-seconds, and 360,000 GiB-seconds a month for request-billed services, based on us-central1 pricing. Usage-based billing applies after that. See Cloud Run pricing.

Path C: Deploy from GitHub to Vercel or a similar host

This Git route works for any project that builds from a repository. The host builds from your repository, so every push can ship.

To deploy:

1. Add .env and node_modules to .gitignore, and run git status to confirm neither is tracked.
2. Commit the project and push it to GitHub.
3. In Vercel, click New Project, select the repository, and review the detected framework and build settings.
4. Compare the detected framework and build command against your Step 2 plan.
5. Add every environment variable by its exact name, with its production value.
6. Click Deploy, then open the URL and run the Step 5 checks.

Never rename a private key with a public prefix, such as NEXT_PUBLIC_, to make a build pass, because a public prefix exposes the key to every visitor.

Costs: Vercel Hobby is $0/month for personal, non-commercial use, and Pro is $20/developer/month. Render has a $0/month Hobby workspace plus compute, with a Free instance and the smallest paid instance at $7/month.

Connect a custom domain and HTTPS

Each host documents its own domain steps, including Firebase Hosting, App Hosting, Cloud Run, and Vercel.

Here is how each host handles a custom domain:

Certificate provisioning can lag behind DNS updates, so check the host's domain status before you assume a failure. Firebase says leftover A, CNAME, or AAAA records can block certificate provisioning.

Once the domain works, add it to your auth provider's allowed redirects and your CORS list.

Deployment errors and how to fix them

Fix these errors:

• Cloud Run service fails to start: The container must listen on 0.0.0.0 on the port in the PORT variable, which defaults to 8080, according to the container contract. Read the port from the environment instead of a fixed number.
• A single-page app fails on refresh: Add a rewrite that serves index.html for paths that don't exist, as in Firebase's rewrites example below.
• Vercel shows an old variable value: Redeploy the project after you change a variable, because environment variable changes apply only to new deployments.
• Vercel builds on the wrong Node.js version: Set engines.node in package.json to override the project setting. Vercel's Node.js versions page lists 24.x and 22.x as available.
• Sign-in fails on the live URL: Add the live URL to your auth provider's allowed redirects and your CORS list.

Firebase Hosting rewrite example:

"rewrites": [ {

  "source": "**",

  "destination": "/index.html"

} ]

How to keep control of agent-run deploys

An agent with terminal access can deploy, and it can also run a command you didn't intend. Let the agent deploy, within limits.

Apply these limits:

• Keep command review on: Set the permission preset to Request Review, which asks for approval on every command. The Default preset asks only before sensitive operations, and Turbo runs all commands without restrictions.
• Keep artifact review on: Set artifact review to Request review, the option Google marks as recommended. The agent then halts for your approval.
• Use allow and deny lists: Allow a command such as npm run build, and deny destructive ones such as rm -rf and sudo. Deny rules win over ask and allow rules.
• Limit access outside the project: Keep file access outside the project on its default prompt, and add deny rules for folders that hold credentials. Denying read access to a path also blocks writes to it.
• Keep production credentials out of reach: Put production keys in the host's secret store, and keep them out of files inside the project. Use a deploy account with the fewest permissions it needs.
• Deploy through Git or a reviewed script: Let the agent write the script or push the branch, and run the final deploy yourself or through CI.
• Read the final command: Check the project, region, and flags before you approve. A wrong project ID or an unintended public setting shows up in the final command.

Set budget alerts on the Google Cloud project as well. A runaway service then triggers an alert before it becomes a bill.

What moving from Firebase Studio means for your deploys

Google is shutting down Firebase Studio on March 22, 2027, according to the Firebase Studio sunset page. Google recommends Antigravity or Google AI Studio for projects you want to keep.

The sunset applies only to the Firebase Studio development environment. Core services such as App Hosting, Firestore, and Authentication keep working, and your databases and user data continue to function normally.

To move a project:

1. In Firebase Studio, click Move now, then click Zip and Download.
2. Extract the folder and open it in Antigravity, with Node.js 20 or higher and Firebase CLI 15.10.0 or higher.
3. Run the @fbs-to-agy-export prompt in the Agent pane for the automated migration.
4. Enter Publish my app, and choose Yes when the agent asks to run firebase deploy.

If you published to App Hosting before, the agent publishes to your existing URL. If not, the agent walks you through setup.

The export is optimized for Next.js, Flutter, and Angular workspaces. Other workspace types may not migrate fully.

Can you build a mobile app with Antigravity?

Yes. A freeCodeCamp tutorial builds a Flutter app with Antigravity and tests it on an Android emulator or a physical device.

Flutter's docs set up the Antigravity CLI, which runs as agy, with the Dart and Flutter MCP server and official Flutter skills.

A mobile app ships as a store package. You build an Android package or an iOS package and submit it to the stores. iOS builds need a Mac, Xcode, and an Apple Developer account.

A Flutter web build can go to Firebase Hosting like any other web app.

Can you run Antigravity from a phone?

Yes, through Remote Control. Google's Remote Control docs describe driving your Antigravity desktop sessions and CLI instances from a web browser on any device, including a phone.

The agent keeps running on your computer. You turn on Enable Remote Control in the desktop app, sign in with the same Google Account, and keep the computer online and awake.

The app you build also runs on a phone. A web app works through its live URL, and a Flutter app runs on a device through a debug build.

Can you deploy an Antigravity app for free?

Partly. Antigravity has a $0/month Individual plan with basic weekly rate limits, according to its pricing page. Google's plan changes list Google AI Pro at $20/month and Google AI Ultra at $100/month and $200/month.

For how Antigravity compares with another agent, see our Claude Code comparison.

For hosting, Firebase Hosting on the Spark plan is free for static apps. Cloud Run has a monthly no-cost allowance, and Vercel Hobby is $0/month for personal, non-commercial projects. Firebase App Hosting needs the pay-as-you-go Blaze plan.

Mistakes to avoid when you deploy an Antigravity app

Avoid these mistakes:

• Approving a command without reading it: The project ID, region, and access flags decide where the app lands and who can reach it.
• Running Turbo against production: The Turbo preset runs all commands without restrictions. Scratch projects can run it, and a live account faces real risk under it.
• Committing .env: A secret in Git history stays there after you delete the file. Rotate the secret.
• Putting a private key in a public variable: Renaming a key with a public prefix publishes it.
• Forgetting live-URL settings: Sign-in redirects, and CORS lists still point at localhost until you update them.

Taking Antigravity to production for work

Every route above puts an app on the public web. An internal tool that needs company data, sign-in, and an audit trail also needs governance.

Superblocks handles that work as the governed enterprise vibe coding platform. Superblocks supports federated building, where business teams build apps with Clark, its AI builder, inside guardrails that IT sets once.

To bring an Antigravity project into Superblocks:

1. Set up the databases and APIs the app needs as integrations in Superblocks.
2. Zip the project's root folder, excluding node_modules, .git, and build output.
3. Start an import in Superblocks, choose Other as the source, and upload the zip, as the Other app import guide describes.
4. Connect the integrations Clark asks for.

Clark rewrites the pieces that tie the app to your laptop. Database clients (pg, knex, Prisma, Supabase) become integrations to your databases, custom auth becomes platform authentication with RBAC, and hardcoded keys become platform-managed credentials.

Express routes become backend APIs, and the frontend becomes React pages hosted on the platform.

What you add after import:

• SSO and role-based access: RBAC controls who can use each app, and Enterprise workspaces can add SSO through your identity provider.
• Your own network: Hybrid keeps the data plane in your AWS, GCP, or Azure account, and Cloud-Prem runs the full platform, including inference, in your own cloud (AWS, GCP, or Azure).
• Audit logs: Enterprise adds audit logs for the access and changes your security team asks about.
• Git and pull requests: Each app connects to one Git repository of your own, and changes go through pull requests.

RBAC is on Teams, while SSO, audit logs, and VPC deployment are Enterprise features. Teams is a flat $125/month for up to 15 builders, and Enterprise pricing is custom.

Superblocks stopped running pre-publish Policy Agents for Git-connected apps on October 1, 2026, according to its release notes. Git-connected apps therefore need security and code checks in CI.

Our last mile guide explains why prototypes stall before production. Superblocks also imports apps from Claude, Replit, Lovable, and v0, plus custom code, according to its App Imports announcement.

To bring your first Antigravity project into Superblocks, start with the import guide.

Or book a demo to see Superblocks run your own apps.

Frequently asked questions

How do I deploy my app from Antigravity?

To deploy an app from Antigravity, run it locally, plan with the agent, fix the blockers, and pick Firebase, Cloud Run, or GitHub to Vercel. Read every command before you approve it, then test the live URL.

Does Antigravity deploy apps for you?

Antigravity can deploy apps for you, with your approval. Google's docs describe publishing to Firebase App Hosting by prompt, and the Cloud Run codelab generates deploy scripts. The Request Review preset asks for approval on every command.

Which is better for Antigravity: Firebase, Cloud Run, or Vercel?

Firebase, Cloud Run, and Vercel each suit a different kind of Antigravity app. Firebase Hosting fits static apps, App Hosting fits Next.js and Angular, Cloud Run fits containers and APIs, and Vercel fits Git-based workflows.

Is it safe to let Antigravity run deployments?

Letting Antigravity run deployments is safe when you set limits. Use the Request Review preset, add deny rules for credential folders, keep production credentials out of the project, and read the final command before you approve it.

Can Superblocks help me take an Antigravity app to production?

Superblocks can help you take an Antigravity app to production when the app is an internal tool. Import the project as a zip and connect company data, and Clark rewrites database clients, auth, and keys to platform equivalents.