How to deploy an AI built web app for the first time: hosting, environment variables and a production checklist

Why does the first deploy go wrong more often for AI-built apps?

The app works on your machine because your machine has things the host does not: a .env file full of keys, a local database, and you clicking through the happy path. The first deploy is where those assumptions meet the internet, and the most expensive one to get wrong is where the keys live.

GitGuardian's State of Secrets Sprawl 2026 counted 28.65 million new hardcoded secrets added to public GitHub commits in 2025, a 34 percent increase on the year before. It also found that "Claude Code-assisted commits showed a 3.2% secret-leak rate, versus a 1.5% baseline across all public GitHub commits." GitGuardian is careful about what that comparison means: "That gap is meaningful, but it should not be read as a simple tool failure," and "The leak still happens through a human workflow." The figure covers public commits only, and it measures how people work with an assistant rather than the assistant on its own. What it still shows is that a builder who accepts generated code quickly is the person who has to decide where every key goes.

So the job for a first deploy is three decisions made in order: what kind of app you built, where its secrets live, and how you will know it works for someone who is not you.

What kind of app have you actually built?

Most AI-built web apps fall into one of three shapes, and the shape decides the host far more than any feature comparison. If you are not sure which you have, ask the agent that built it:

Explain in plain language: does this app have any code that runs on a server rather than in the browser? List every environment variable it reads, the file that reads it, and whether that file runs in the browser or on a server.

Shape	How to recognise it	Where a secret can live	Hosts that fit (examples)
Front end plus a hosted backend	Every file runs in the browser; data goes straight to a service such as Supabase	Nowhere in the app. Only keys designed to be public	Netlify, Vercel, Render static sites, Replit Static Deployment
Front end plus server functions	Some files are API routes, route handlers or functions	In the host's environment settings, read only by the server code	Vercel, Netlify
A running server	A server process (Express, Flask) that stays up, holds connections or runs background work	In the host's environment or secrets settings	Render web services, Replit Autoscale or Reserved VM

The first row is where AI-built apps most often leak. Build tools copy any variable with a public prefix into the JavaScript every visitor downloads. The Vite docs say it directly: "VITE_* variables should not contain sensitive information such as API keys. The values of these variables are bundled into your source code at build time." Next.js does the same with NEXT_PUBLIC_: the value is "inlined into any JavaScript sent to the browser." If an agent named your AI provider key VITE_AI_KEY or NEXT_PUBLIC_AI_KEY so the browser could call the model, the key is public the moment you deploy.

The fix is a change of shape: move that call into a server function, so the app becomes the second row. That is also why a static host is the wrong choice for anything that needs a secret. Replit's documentation makes the same point from the host's side: "Secrets are available for all deployment types except Static Deployments" (Replit Secrets).

For a running server, two host details matter on a first deploy. Render spins down a free web service "that goes 15 minutes without receiving any inbound traffic", and starting again "takes about one minute", so your first tester may wait; a free Render Postgres database expires 30 days after creation (Render free tier). If you built in Replit, its deployment types cover the same ground: Static for sites that "don't change based on user input", Autoscale that "automatically adjusts resources based on your app's usage", and Reserved VM for an app that needs "to run continuously".

How do you move secrets into the host's environment settings?

Do this before the first deploy, in this order.

1. Inventory. Use the prompt above to list every variable. Mark each one public (a Supabase URL, a publishable key, an analytics ID) or secret (anything that costs money, grants admin access or reads other people's data).
2. Fix the shape. Any secret read in browser code moves into server code, and loses its VITE_ or NEXT_PUBLIC_ prefix. Ask the agent for exactly that change and nothing else.
3. Check git. Open .gitignore and confirm .env and *.local are listed. If .env was ever committed, the ignore rule does nothing on its own: per GitHub's docs, "If you want to ignore a file that is already checked in, you must untrack the file before you add a rule to ignore it," with git rm --cached.
4. Rotate anything that leaked. If a secret was ever committed, pasted into browser code or shown on a screen share, create a new one and revoke the old one. GitHub's guidance on removing sensitive data puts this first: "as a first step you need to revoke and/or rotate that secret."
5. Add each variable in the host. On Vercel you choose Production, Preview or Development for each one. On Netlify you can set a value per deploy context, and Netlify recommends the UI, CLI or API "to avoid storing sensitive values in your repository" rather than its config file. On Render you add them under Environment. In Replit, published apps read them from Production app secrets in the publishing settings.
6. Redeploy, then confirm. Vercel's docs state that changes "are not applied to previous deployments, they only apply to new deployments." Render offers "Save, rebuild, and deploy", "Save and deploy" and "Save only", and the last one leaves the running service on the old values. Public variables are baked in at build time, so they always need a fresh build.

Supabase deserves its own line because so many AI-built apps use it. Its API keys documentation splits keys into publishable (called anon in older projects), which are "Safe to expose online", and secret (service_role in older projects): "Never put one in a browser, a shipped application, or source control." The publishable key is only safe under one condition: "Row Level Security decides what this client can reach, so enable it on every table before you deploy."

Which five checks should pass before you share the link?

Run each against the live URL, not your local copy. Each one maps to a failure a real user would otherwise find for you.

Check	How to test it	What failure looks like
1. Auth holds for a second account	Sign up as user B in a private window. Try to see user A's records, including by changing an ID in the address bar	B sees A's data, or an empty page that should have been a "not allowed" message
2. Data survives a refresh and a redeploy	Create a record, refresh, redeploy, look again	The record is gone, because it was held in the browser rather than a database
3. Errors are visible	Trigger a known error (submit an empty form) and find it in the host's logs	Nothing in the logs, so the first real error will reach you as a user's screenshot
4. Paid APIs have a limit	Set a spending limit in each paid provider's billing settings where one exists, and a per-user or per-day cap in the app	One script, or one excited user, can run up a bill overnight
5. A rollback exists	Roll back to the previous version once, on purpose, then return to the current one	You learn how rollback works during an outage

Check 1 is the one AI-built apps fail most, because the agent built and tested everything while logged in as you. With Supabase it is almost always a table with Row Level Security off, or a policy that allows any logged-in user to read every row.

Check 3 has a time limit on some plans. Vercel's runtime logs are kept for 1 hour on the Hobby plan, so look right after the test, not the next morning. Server-side console.error output appears there marked as an error. Replit's monitoring for published apps shows logs, and Replit "emails you if it goes down."

Check 5 differs by host, and each has one surprise worth knowing before you need it:

• Vercel: Instant Rollback points your domain at an earlier production deployment; on Hobby, "you can roll back to the previous deployment." Environment variables are not rolled back, and after a rollback new pushes do not go live until you choose Undo Rollback.
• Netlify: publish an earlier deploy from its detail page; per the deploy docs, "Rollbacks are instantaneous," but with Git auto publishing on, the next Git-triggered production deploy replaces the rolled-back version.
• Replit: publishing "creates a snapshot of your app's files and dependencies," so the live app only changes when you publish. Roll the workspace back to a checkpoint and publish again; "By default, rollbacks do not change your database."

What does a worked first deploy look like?

Here is one start to finish. The app is a class waitlist for a small pottery studio, built with an AI coding agent: a Next.js front end, Supabase for logins and data, and one feature that asks an AI model to draft an email when a spot opens.

Inventory. The agent's answer listed four variables: NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY, NEXT_PUBLIC_AI_KEY and SUPABASE_SECRET_KEY. The first two are public by design. The third was a problem: the email draft was generated in a browser component, so the AI key would have shipped to every visitor.

Shape. One prompt: "Move the email draft generation into a route handler under app/api. The browser calls that route. Rename the key to AI_KEY. Change nothing else." The app was now a front end plus server functions, which pointed to Vercel or Netlify; the builder picked Vercel.

Git. .gitignore listed .env.local, but the very first commit, made before the agent created the ignore file, contained .env. The builder ran git rm --cached .env, added .env to .gitignore, and rotated both the AI key and the Supabase secret key, since both had sat in history.

Host settings. The four variables went into Vercel with Production scope, and a second AI key with a lower provider limit went into Preview. Then a fresh deploy, because the old build carried none of them.

Five checks.

Check	Result	Fix
1. Second account	Failed: student B could read student A's waitlist entry by changing the class ID in the URL	Enabled Row Level Security on the waitlist table with a policy: students read their own rows, the studio owner reads all
2. Refresh and redeploy	Passed	None
3. Errors visible	Passed: an empty sign-up showed as an error in Logs within a minute	None
4. Paid API limit	Partly: no cap in the app	Limited drafts to one per opened spot and 20 per day, and set a monthly limit in the provider's billing settings
5. Rollback	Passed after one practice run	Noted that Undo Rollback is needed afterwards

The failing check took one prompt and one retest to fix, and it is the one that would have exposed customers' email addresses to each other. Only after all five passed did the link go to the studio's first five students.

When should you not deploy it yourself?

The strongest objection to this whole guide is that a non-developer should not be deploying production software at all. It is right for a specific set of apps: anything that takes payments, stores health, financial or children's data, or lets strangers create accounts at scale. Those need someone who can read the code to review it before real users arrive, and when not to use an AI coding agent sets out where that line sits.

For everything below that line, an internal tool, a waitlist, a prototype you want ten people to try, deploying it yourself is how you learn what the app actually does. The five checks are the minimum, not a security review. If a check fails and you cannot explain why, stop and use the loop in how to debug AI-generated code before you share anything.

Where does deployment sit in the build loop?

Deploying comes after scoping and building, and before learning from real users. If you built in Replit, how to build an MVP with Replit covers the build steps that come before this, and vibe coding mistakes to avoid covers the habits, such as checkpoints and billing limits, that make a first deploy less risky. Once the link works, collecting feedback on an MVP from first users is the next step.

Zero to Shipped with Vibe Coding is a 1 week Builders Camp bootcamp in the Vibe Coding Expert Track, with 2 live sessions and 11 self-paced microlessons, built around going from idea to a working MVP with AI-assisted building tools; the tools it names include Cursor, Supabase, Replit and Stripe. Using AI to Build Your First Product covers the same ground over 2 weeks, with shipping and launch basics (deploy, test, release) in its syllabus.

See the Zero to Shipped with Vibe Coding bootcamp

Before your next deploy, run the inventory prompt and read the answer line by line. If any variable with a public prefix holds something you would not paste into a public chat, you have found your first fix.