Google Antigravity: how to deploy your app to production

To deploy an app built in Google Antigravity, choose a hosting target and give the agent a repeatable production workflow. The project needs a production build, a start command where applicable, configuration, durable data storage and live checks. An IDE preview shows that some code runs; it does not establish that those production requirements are met.

This guide uses Lizard as one deployment option and explains when another host may fit. We checked the linked product documentation and Lizard CLI on 9 September 2026.

What Antigravity contributes to deployment

Google describes Antigravity as an agentic development environment whose agents can work across the editor, terminal and browser. Those capabilities can help prepare and check a deployment. The production runtime still belongs to the host you choose. Google's Antigravity introduction.

Deployment integrations can change. Check Antigravity's current documentation and the hosting tool you intend to use. Avoid assuming that a feature in the IDE means every database, worker or deployment requirement is already configured.

The important choice is not which tool generated the files. It is what the resulting application needs to run.

Identify what your app contains

Ask the agent to inspect the repository and produce a short deployment inventory:

• Framework, runtime version and dependency lockfile.
• Build command, output directory and production start command.
• Web services, APIs, workers and scheduled tasks.
• Database engine and the variables used to connect to it.
• Uploaded files, local filesystem writes and required persistence.
• Login providers, callback URLs, payment webhooks and other external services.

This catches common prototype assumptions before you choose a host. A frontend may contain a hardcoded development API URL. A generated backend may keep data in a local file. A background task may only run while the development process is open.

Choose the host by the application

Lizard is an option for web services, workers and managed data services through the Lizard CLI. Vercel can fit a frontend-focused workflow; read our Vercel comparison for runtime and billing distinctions. Cloud Run offers Services, Jobs and worker pools with different purposes. Cloud Run overview.

If Google Cloud is already your target, Google's Cloud Run MCP codelab describes a tool-based deployment workflow. Choosing Lizard is a hosting choice, not a requirement imposed by Antigravity.

Give Antigravity a specific deployment request

A useful request names the destination, required checks and environment:

Inspect this repository and deploy a test copy to the existing Lizard project my-project. Read the current Lizard CLI guide first. Reuse the existing build setup. Identify the database and worker requirements, configure their connections, and test the live application. Report the URL, deployed revision and checks that passed or failed before changing production traffic.

Replace the target with your actual project. If you intend a production update, say which service and domain may change. A request to deploy should not leave the agent guessing which database holds real user data.

Install the Lizard Skill following its instructions for your agent environment. The global CLI provides the current operational guide:

npm install -g @lizard-build/cli
lizard skills get core --json
lizard status --json

Finish browser authentication if the CLI requests it. The agent should inspect the current project link before creating or updating resources.

Use the right source for deployment

If the project has an accessible GitHub repository, connect that repository and the intended branch to the service. This gives later commits a repeatable route to deployment. Check the root directory in a monorepo. Follow the GitHub integration guide.

For code that exists only locally, use the source-upload workflow. The agent should explicitly select or create the intended project and service before upload. It should not silently replace an existing Git deployment with an uploaded copy.

In both cases, keep generated files and secrets out of source control. A production build should use the repository's dependency lockfile and a runtime version compatible with the application.

Make data and configuration explicit

Provisioning Managed Postgres is only the first part of a database setup. Set the connection variable that the application reads and run its migrations in a controlled release step. Test a write and read using the intended database.

If the app uses a worker, run it as a separate service with its own command and relevant variables. For files, distinguish temporary work from data that must survive a restart or redeployment. Use suitable storage and test that lifecycle.

Frontend variables deserve special attention: values included in a browser bundle are public. Do not put database passwords or server API secrets into frontend build settings. Keep server-side secrets with the service that needs them.

Verify a real production flow

Open the deployed URL directly in a fresh browser session. Test routes without relying on a tab that still has development state. Then check the flows the app promises to users.

For payment integrations, use the provider's test mode before a live transaction. For email, verify a test delivery and the links it contains. Check logs and resource use after the test rather than treating a visually correct page as the final result.

Estimate hosting separately from coding

The development tool and production services have different costs. Include all web processes, workers, databases, storage and traffic in the hosting estimate. Check plan fees, credit and allowances in Lizard pricing or the chosen host's terms.

A low-traffic service may still use memory while waiting for work. A request-driven host may scale down compute but continue charging for retained data or other services. Use measured behaviour instead of assuming that a prototype will fit a free allowance indefinitely.

FAQ

Does Antigravity automatically host my app? The app needs a production target. Antigravity can help use deployment tools, but verify which service runs the app and what resources it created.

Can I deploy without manually typing every command? An agent with the required tools can run the workflow. You still need to establish the target, credentials and allowed changes, and inspect the reported result.

Why does the preview work while the deployed app fails? Common causes include development-only commands, missing variables, a wrong port, an inaccessible database or a callback URL that still points at localhost. Start with the build and runtime logs.

Can I keep my existing database? Yes, if the deployed service can securely reach it and the latency and transfer cost are acceptable. Test that path before moving the data as well.

What should happen after the first deployment? Keep the release process repeatable, monitor errors and usage, and test backups. The CLI configuration reference and support page provide the next steps for Lizard.