Google Antigravity: how to deploy your app to production

Google Antigravity can write an app, run it, and test it on your machine. But it does not host it. Production hosting for an Antigravity app is a separate thing you have to handle yourself: a frontend, a backend, a database, a domain.

On Lizard (lizard.build) that is two prompts pasted into the Antigravity: one that installs the Lizard Skill, and one that says "Deploy this app on Lizard". This article covers what Antigravity does and does not give you, what production actually needs, and how to hand the deploy to the agent so it ships without you typing a command.

Updated 18 August 2026. Checked against Antigravity 2.0 as announced at Google I/O in May 2026, and against Lizard prices and CLI behaviour on the same day.

What Antigravity does not do

Antigravity writes your app, runs it, and clicks through it in a browser. It does not host it. Nothing in the 2.0 release changed that — not the desktop app, not the CLI, not the SDK.

Managed Agents is the part people misread. It hands an agent session an isolated Linux box, and when the session ends, so does the box. It runs the agent, not your product.

So you have a working app on localhost:3000. Close the laptop and it is gone. No URL, no certificate, no database that survives a restart, no logs from anyone but you, and nothing to start it again when it crashes. Fixing that is the rest of this article.

Deploy an Antigravity app to production without typing a command

Two prompts, both pasted into the Antigravity chat you already have open. The first installs the Lizard Skill:

Install as a skill if I have npm: npx skills add lizard-build/skill -g

The second is the deploy, in plain language:

Deploy this app on Lizard

The agent does the rest. It detects the stack, builds on Lizard's build nodes, runs the app in its own container on our Kubernetes cluster, and comes back with a live *.onlizard.com URL that already has TLS. You watch it happen in the dashboard. No Dockerfile, no YAML, no Docker running locally, and nothing typed into a terminal.

lizardpack handles the detection: Go, Node, Python, Rust, Ruby, PHP, Java, and static sites. Whatever Antigravity chose to build in, it is on that list. If the agent already wrote a Dockerfile with a real build step, that one is used as is.

Try it free, no card →

Why the skill, rather than pasting commands

The Lizard Skill is a bootstrap. It loads the full usage guide out of the installed Lizard CLI with lizard skills get core --json, so the instructions the agent follows always match the CLI version on the machine. There is no copy of the docs to go stale, which is the usual reason an agent confidently runs a flag that was removed two releases ago.

Antigravity 2.x reads skills and MCP servers from a shared config under ~/.gemini/config/, so installing once covers the desktop app and the Antigravity CLI. See Google's MCP docs for the current file layout. The skill format is Agent Skills, so the same install works in any agent that reads it — we wrote up the Claude Code version of this loop separately.

If you would rather wire nothing at all, tell the agent to run lizard --help --json. Every command takes --json, and the root help returns the whole command tree, options and exit codes, so an agent can discover the surface at runtime.

Antigravity can deploy to Cloud Run. That is not the same as hosting your app.

Cloud Run runs one container that answers HTTP requests. It does that well. It is not a home for an application, and the gap between those two things is where the afternoon goes.

The deploy itself is real and it works: install the Cloud Run MCP server, type "Deploy this folder as Cloud Run service in the project my-project in us-west1 region", and the container is live. Google has a codelab for it. Now count what the app around that container still needs, and which product each one is:

That is seven products, several IAM bindings and a billing account before the first request, against one CLI. Google's own quickstart for connecting Cloud Run to Postgres is a document, not a command.

The first request after a quiet spell waits. Cloud Run drops a revision to zero instances, and only an incoming request brings it back, so somebody pays for the cold start with their page load. You can hold a warm instance, but a warm instance bills like an ordinary server, which is the thing scale-to-zero was meant to save you from. A Lizard service is a process that stays up, so there is no first-request penalty to design around.

Scale-to-zero stops being free at the database. Cloud Run's free tier is real and generous — two million requests and 180,000 vCPU-seconds a month, permanently — and for a pure HTTP app with no database and light traffic it is genuinely hard to beat. Say that out loud, then look at the next line of the bill. Cloud SQL does not scale to zero and has no free tier. The cheapest shared-core Postgres runs around $9 a month, rising fast with size, and bills every hour whether anyone shows up or not. Your idle app has a floor, and a different product set it.

Background work is somebody else's product. A queue consumer, a poller, a scheduler, a warm in-memory cache — none of it fits a container that disappears between requests. On request-based billing you get no CPU outside a request at all, so the work simply cannot run. Switch to instance-based billing and you are paying for an instance around the clock. Otherwise you rebuild the job as Cloud Tasks or Pub/Sub. WebSocket connections end at the 60-minute request timeout in every case.

What you get in exchange, and whether you need it. This is a fair trade, not a trap. Assembling those products buys you things we do not sell: quotas into the thousands of instances, GPUs, Cloud Run Jobs and Worker Pools, private VPC networking, audit logging, the compliance paperwork an enterprise buyer asks for, and around thirty regions against our two. If you need any of that, Cloud Run is the right answer and you should stop reading here. The question is whether the app Antigravity wrote you last night needs a VPC and an audit trail, or a database and a URL.

For the app Antigravity just built you, the honest comparison set is Railway, Render, Fly and us — platforms where a database is a command instead of a product. We think we win that comparison, and the next section makes the case.

Where to deploy an app your AI IDE built

Pick the platform by whether the app is a process or a request handler. Antigravity, Claude Code, Cursor, and Codex all produce the same shape of thing — a repo with a backend, a frontend, a database, and usually a worker — and that shape rules some platforms in and some out.

A serverless platform cannot run a process that stays up, so an agent that wrote a scheduler, a poller, or a queue consumer has nothing to deploy it to. Agents write those because they are the obvious way to solve the problem. When none of them fit, the agent rewrites working code into whatever the platform allows — a Workflow, a cron entry, a third-party queue — and you end up debugging a design you never chose. On Lizard the process runs as written.

The loop the agent runs when a deploy fails

A failed deploy is six commands, and an agent can run all six without a human. This is the loop that decides whether it finishes the job alone.

lizard logs --build --json      # why the build failed
lizard events --json            # deploy history and replica status
lizard logs --restart latest    # the log tail from the most recent crash
lizard metrics --json --cost    # CPU, memory, and spend
lizard ssh --service web -- env # look inside the running container
lizard redeploy                 # try again

Structured output on every one, so the agent parses a result instead of scraping a terminal. Exit codes are typed, which means the agent knows what kind of failure it hit before it reads a single log line:

Failing safely matters as much as failing readably. A build that fails never reaches the deploy, so it costs you nothing but the build and the running version carries on untouched. Once a build succeeds, the new version replaces the old one in place: the old container stops, the new one starts, and the platform waits up to 30 seconds for it to answer on its port. There is a short gap on every deploy, and if the new version never answers, the app stays down until the agent fixes it and redeploys, which is what the loop above is for.

lizard ssh is the one that ends most debugging sessions. When the deployed app behaves differently from the local one, the agent opens a shell in the live container and looks, rather than reasoning from log lines.

The rest of the stack a SaaS needs

A database, a cache, and file storage are one command between them, provisioned in under a minute in the same region as the app. An app built in an afternoon needs all three, plus somewhere to run background jobs.

lizard add postgres redis s3

Then bind them on the service that consumes them:

lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service web
lizard secrets set REDIS_URL='${{redis.REDIS_URL}}' --service web

Those references resolve at deploy time and are stored by ID, so renaming an addon or rotating its credentials does not break the consumer. Managed Postgres, Managed Redis, and Managed Object Storage are first-party — one vendor, one region, one bill, no second account to sign up for mid-session.

Background work is a service with no HTTP port:

lizard add -s worker
lizard port 0 --service worker

Port 0 is worker mode: no port check, no load balancer route, no false "unhealthy" status for a process that was never meant to listen. Queue consumers, schedulers, and Telegram bots run as ordinary long-lived processes with no time limit.

Then the domain:

lizard domain yourapp.com --service web
lizard domain verify yourapp.com

The first command prints the DNS records to add. The second activates the domain once they resolve, and the certificate is issued for you.

From vibe-coded prototype to a SaaS people pay for

Seven steps turn a vibe-coded Antigravity build into something you can charge for: deploy on day one, move off SQLite, get the secrets out of the repo, split the worker out, attach a real domain, watch the bill, and give staging its own project. An agent can work through most of them if you name the items.

1. Get it deployed on day one. A live URL changes what you can test. lizard up before the app is finished, not after.
2. Move the database off SQLite. lizard add postgres, point DATABASE_URL at it, run the migration. Do this before you have data worth losing.
3. Get the secrets out of the repo. lizard secrets set per service. Ask the agent to grep the diff for keys before every push — models paste credentials into source more often than anyone admits.
4. Split the worker out. Anything slow — email, exports, webhooks, model calls — belongs in a second service in worker mode, not in the request.
5. Put a real domain on it. Nobody pays for something on a subdomain of a platform they have never heard of.
6. Watch the bill while it runs. lizard metrics --json --cost returns accruing cost per service, so the agent can read it mid-session instead of finding out at the end of the month.
7. Give staging its own project. Billing only for active resources means a staging copy costs what staging actually uses. Nobody hits it overnight, so its Idle App Cost is close to nothing.

What it costs

Building with Antigravity costs whatever your Google AI plan costs. Hosting the result is separate, and it is small.

• Free plan: $5 in credits for your first month, no card, up to 5 apps. One replica, 1 vCPU and 512 MB of memory per app: fine for an API or a small site, tight for a Next.js build.
• Hobby: $5 a month, which covers a typical side project.
• Pro: $29 a month, with $29 of credit.

Underneath, everything is metered per second on measured use: $0.0278 per vCPU-hour, $0.0139 per GB-hour of memory, $0.05 per GB of egress, $0.015 per GB-month of object storage. Seats are free; build time bills as ordinary compute. Memory is billed on what the app is measurably holding, not on the size you asked for, so the headroom an agent leaves itself costs nothing.

This is where an agent-built app differs from anything a platform team would size. The agent asks for headroom it never uses, and on measured billing that headroom is free. A prototype nobody has found yet costs cents a month — its idle app cost is the memory the process holds and nothing else.

Ship what Antigravity built

Your whole stack from one CLI, and an agent that can drive it.

Get started free →

No credit card required.

FAQ

Can Google Antigravity deploy my app to production? No. Antigravity writes, runs, and tests code on your machine, and its Managed Agents tier gives each agent session an isolated Linux environment for the agent's own execution. Neither hosts the app it built. You need a deployment platform. The shortest path is two prompts in the Antigravity chat: Install as a skill if I have npm: npx skills add lizard-build/skill -g, then Deploy this app on Lizard. The agent detects the stack, builds it, and returns a live URL with TLS.

Where do I host an app built in Antigravity? Anywhere that runs a long-lived process with a managed database attached. Lizard fits agent-built apps because the whole platform is one CLI with --json on every command, so the agent deploys, reads the failure, and redeploys without a dashboard. Railway and Render also take a repo and return a URL. Frontend-first serverless platforms fit only if the app is a frontend or a short-lived API.

How do I connect Lizard to Antigravity? Install the Lizard Skill with npx skills add lizard-build/skill -g. It is a bootstrap that loads the full usage guide out of the installed CLI, so the guidance always matches the CLI version. Antigravity 2.x reads skills and MCP servers from a shared config under ~/.gemini/config/, covering both the desktop app and the Antigravity CLI. If you skip the setup entirely, lizard --help --json returns the whole command tree for an agent to discover at runtime.

Should I deploy my Antigravity app to Cloud Run or somewhere else? Cloud Run runs a container that answers HTTP. Everything else your app needs is a separate Google Cloud product: Cloud SQL for the database, a VPC connector to reach it, Secret Manager for secrets, Cloud Load Balancing for a custom domain, Cloud Tasks or Pub/Sub for background work, each with its own IAM. Its free tier is generous — two million requests a month — but Cloud SQL has none, does not scale to zero, and costs from about $9 a month on its own. Cloud Run is the right answer when you are already on Google Cloud and need its ceiling: GPUs, private networking, audit logs, thirty regions. For an app an agent wrote you last night, compare Railway, Render, Fly and Lizard instead, where the database is a command rather than a product.

Can I deploy straight from local Antigravity output, without a GitHub repo? Yes. lizard up uploads the current directory as a tarball, respecting your .gitignore, and returns a live URL. Connect a repo later with lizard add -r you/your-repo if you want git push to deploy.

What is the difference between Antigravity Managed Agents and app hosting? Managed Agents runs the agent. App hosting runs the product the agent wrote. Managed Agents gives an agent session an isolated Linux environment with state that persists across turns, which is useful for long agent tasks and useless as a home for your SaaS — the environment belongs to the session, not to your users.

Do I need a Dockerfile to deploy an app Antigravity built? No. lizardpack detects Go, Node, Python, Rust, Ruby, PHP, Java, and static sites, then writes a multi-stage Dockerfile on the build node. If the agent already wrote a Dockerfile with a real build step, that one is used unchanged. You do not need Docker installed locally either — builds run on Lizard's build nodes.

What is the easiest way to deploy a web app to the cloud? One command from the project directory: lizard up. It uploads the code, detects the stack, builds it, runs it in a container, and returns a URL with TLS. Add a database with lizard add postgres and a custom domain with lizard domain yourapp.com. There is no config file to write and nothing to install beyond the CLI.

Can an AI agent deploy and debug on its own? Yes, if the platform answers in a format it can parse. Every Lizard command takes --json, exit codes are typed, lizard logs --build --json returns the failing build's output, and lizard ssh opens a shell inside the running container. That is the whole loop an agent needs: deploy, read the error, look inside, fix, redeploy. A build that fails never reaches the deploy, so the running version is left alone.

How much does it cost to host an app built with an AI IDE? Start free with $5 in credits for your first month and no card. After that Hobby is $5 a month and includes $5 of usage, which covers a typical side project outright; Pro is $29 with $29 of credit. Usage is metered per second on what the app measurably holds — $0.0278 per vCPU-hour, $0.0139 per GB-hour — not on the size you asked for, so the headroom an agent leaves itself costs nothing and an app nobody has found yet costs cents.

What happens if the agent ships a broken build? If the build fails, nothing changes: the deploy never starts, the running version keeps serving every request, and lizard logs --build --json tells the agent why the build failed. If the build succeeds but the app will not start, the answer is different. The new version replaces the old one in place, so the app is down until the agent fixes it and redeploys, and lizard logs --restart latest gives it the crash tail to work from.

Does the app keep running when I close Antigravity? Once it is deployed, yes — it runs as a long-lived process in its own container with no time limit, and it restarts on its own if it crashes. While it lives only on localhost, it stops when your machine does. This is the main reason to deploy on day one rather than at the end.

Useful sources

• Build with Google Antigravity
• Google I/O 2026 developer highlights
• Antigravity MCP documentation
• Google codelab: deploy to Cloud Run from Antigravity using the MCP server
• Cloud Run MCP server and Cloud Run request timeouts
• Lizard pricing
• Lizard documentation