How to Deploy a Vibe-Coded App: from preview to live

Your app works in the preview window. Now what? This guide explains, in plain English, how to get a vibe-coded app onto the real internet: the three main ways to deploy, what to check before you press Publish, how to handle secret keys and custom domains, and how to fix the errors that show up on launch day.

How to deploy a vibe-coded app, in one sentence: use your tool's built-in Publish button for the fastest route, or push the code to GitHub and connect it to a hosting service for more control, and in both cases check your secret keys and database permissions first. Deployment is simply the step that turns the app you built by chatting with an AI into a website or web app that other people can open with a link.

The good news is that deploying has never been easier. Most vibe coding app builders can put your project online in a couple of clicks. The bad news is that "online" also means "visible to strangers", and that's where many vibe-coded apps get into trouble. This guide walks you through both halves: the clicks, and the checks.

What does "deploy" mean?

If you're new to building software, "deploy" can sound like something only engineers do. It isn't. It just means putting a copy of your app on a computer that's always on and connected to the internet (a server), and giving it an address people can visit.

While you're building, you're looking at a preview: a temporary version that runs inside your tool, often only visible to you. When you deploy (many tools call it "publish"), the tool packages the current version and puts it on a host. The host gives you a URL, and you can later attach your own domain like yourbusiness.com.

Two more words you'll see a lot:

• Production is the live version real users see.
• Environment variables (or "secrets") are settings, such as API keys, that the app needs but that shouldn't be written into the code itself.

If the idea of vibe coding itself is still fuzzy, start with our complete guide to what vibe coding is, or the short version on the vibe coding meaning homepage.

The three ways to deploy a vibe-coded app

Almost every deployment falls into one of three paths. Which one is right depends on how you built the app and how much control you want.

Not sure which tools fall into which group? Our guide to the best vibe coding tools splits them into app builders, AI code editors and coding agents. As a rule of thumb, if you built in a browser app builder, start with Path 1. If you built with an AI code editor or a terminal agent on your own computer, Path 2 is the natural fit.

Before you deploy: the 10-minute safety check

This is the part most tutorials skip, and it's the part that matters most. A preview is private-ish. A deployed app is on the open internet, where anyone (and any automated scanner) can poke at it.

Why be careful? Because AI-written code is often not secure by default. Veracode's 2025 GenAI Code Security Report tested more than 100 AI models on 80 coding tasks and found that AI-generated code introduced security flaws in 45% of cases. And real incidents happen. In February 2026, The Register reported that security researcher Taimur Khan found 16 vulnerabilities, six of them critical, in a single app hosted on Lovable, exposing more than 18,000 user records. The worst bug was an AI-generated access check that was backwards: in Khan's words, the "guard blocks the people it should allow and allows the people it should block." Lovable said projects get a free security scan before publishing and that acting on its recommendations is up to the user, and noted the vulnerable database wasn't hosted by Lovable.

The lesson isn't "don't deploy". It's "check these things first":

1. No secret keys in front-end code. Payment keys, AI API keys and database admin keys must live on the server side or in your host's secrets settings, never in code that runs in the visitor's browser (more on this below).
2. Database access is locked down. If your app uses a database such as Supabase, every table that the app can reach should have access rules (Supabase calls this Row Level Security).
3. Logged-out test. Open the app in a private browser window without logging in. Try to reach admin pages, other users' data and any "secret" URL. If you can see it, so can anyone.
4. Two-account test. Create two test accounts and check that account A can't see or edit account B's data.
5. Forms reject junk. Submit empty forms, very long text and odd characters. The app should complain politely, not crash.
6. Error messages don't leak. Errors shouldn't show raw database messages, file paths or keys.
7. Test data is gone. Remove fake users, sample orders and placeholder text.
8. Mobile check. Open the preview on a phone. Most visitors will.
9. Run the tool's scanner. Many app builders now include a security scan in the publish flow; read the results instead of skipping them.
10. Ask the AI to review itself with the prompt below.

// Paste this into your vibe coding tool before publishing
"I'm about to deploy this app publicly. Act as a security
reviewer. List every place where: (1) a secret key or token
appears in code that runs in the browser, (2) a database
table can be read or written without the right login,
(3) an admin page or API route can be reached while logged
out, (4) user input is used without validation. For each
issue, explain it in plain English, rate it high/medium/low,
and fix the high ones first. Don't change anything else."

For the full list, use our vibe coding security checklist (16 checks). It takes longer than ten minutes, but it's worth doing before real customer data goes in.

Path 1: deploy with the built-in Publish button

If you built your app in a browser-based builder, this is the fastest way to go live. The exact buttons change over time, so always check your tool's own documentation, but here's how three popular builders describe it today.

Lovable

According to Lovable's documentation, you click Publish in the top-right of the editor, then Publish again in the dialog. Your app gets an address ending in lovable.app, based on your project's subdomain. A few details worth knowing:

• Only the current version is deployed. Later edits don't go live automatically; you open the dialog and click Publish changes to update the live site.
• Publishing from the dialog doesn't use credits, while asking the AI in chat to publish does.
• When the publish dialog opens, a quick security scan runs automatically, checking things like database access rules and dependencies. By default its findings don't block publishing, so read them.
• On Free and Pro plans you can choose "Public" (anyone with the link) or "Invite only". Connecting a custom domain is a paid-plan feature.

Bolt

Bolt's help center says it includes built-in hosting and that publishing is free at a bolt.host address. The first time you publish, Bolt picks a random name, which you can change in the Publish menu.

• Sites are public by default, so search engines can list them. Private sites are available on paid plans.
• Changes to your project "aren't automatically applied" to your published site. Click Update in the Publish menu to push them live.
• On paid plans you can run a security audit from the Publish menu before publishing, and on any plan you can check your Bolt database's security in its Security tab.
• Paid plans can attach a domain you own or buy one through Bolt.

Replit

Replit's docs describe publishing as saving a snapshot of your app to the cloud, where it runs separately from the version in your editor. You open Tools → Publishing, review the settings and select Publish (you may be asked to add a payment method). To update, you publish again to create a fresh snapshot. Replit also asks you to pick a deployment type:

One more Replit tip from its docs: don't rely on files written to a published app's filesystem. Use a proper database or storage option for anything you need to keep.

Path 2: deploy with GitHub and a host

If you built your app with an AI code editor or a coding agent, your code lives in a folder on your computer. The most common way to deploy it is to save it to GitHub (a site that stores code and its history) and connect that repository to a host. Many app builders can also sync or export to GitHub, so this path works for them too once you outgrow built-in hosting.

Here's how Vercel's documentation describes its GitHub integration, as one example:

• Every push deploys. Vercel for GitHub deploys every push by default, including pushes to branches and pull requests.
• Preview URLs. The latest push to any pull request gets its own unique preview URL, posted as a comment on the pull request, so you can test before going live.
• Production. Pushes and merges to the production branch (commonly "main") go live on your custom domain.
• Rollbacks. If you revert a commit that's already in production, the previous production deployment is made available at your domain instantly.

Other Git-based hosts work in a similar way. The general steps look like this:

1. Ask the AI to prepare the project. "Make sure this project builds for production. Tell me the build command, the output folder and every environment variable it needs."
2. Create a GitHub repository and push your code (your AI editor or agent can walk you through the commands, or do it for you).
3. Check that no secrets were committed. Ask: "Search the repository for API keys, passwords or tokens, and confirm the .env file is in .gitignore."
4. Import the repository into your host and confirm the build settings it detects.
5. Add environment variables in the host's project settings, not in the code.
6. Deploy, then test the live URL with the same checks as before.
7. Work on branches. Make changes on a branch, test the preview URL, then merge to main to go live.

// For AI code editors and coding agents
"Prepare this project for deployment to a Git-based host.
1. Confirm it builds with no errors and tell me the build
   command and output folder.
2. List every environment variable it needs and which ones
   are secret. Move any secrets out of browser code.
3. Make sure .env files are ignored by Git.
4. Write a short DEPLOY.md explaining how to deploy and
   update it, in plain English for a non-programmer."

Need more prompts like these? Our vibe coding prompts that actually work guide has copy-paste templates for every stage of a project.

Secrets and environment variables, explained simply

This is the single most important technical idea in deployment, so it's worth a few minutes.

A web app usually has two parts. The front end runs in the visitor's browser: buttons, pages, forms. Anyone can view that code with their browser's built-in tools. The back end runs on a server you control (or your tool's server). Visitors can't see its code.

Secret keys must only ever live in the back end. Here's how two common pieces of vibe coding stacks put it:

• Vite (a build tool many AI-generated apps use) says variables prefixed with VITE_ are exposed in client-side source code after bundling, and that they "should not contain sensitive information such as API keys". For real secrets it recommends a backend server or serverless/edge functions.
• Supabase (a popular database for vibe-coded apps) says to "enable RLS on every table in an exposed schema", warns never to use a secret key in the browser or expose it to customers, and notes that the service role key bypasses Row Level Security, so it must stay server-side.

In practice: a public "publishable" or "anon" key in the browser can be fine if your database rules are strict. A secret, admin or service key in the browser is a serious problem, because anyone who finds it can skip your rules entirely. If you're not sure which kind of key you have, ask your AI tool to explain each key in the project and where it's used.

Adding a custom domain

Your app's free address (on the tool's or host's domain) is fine for testing and sharing with friends. For a business, you'll usually want your own domain. The process is similar everywhere:

1. Buy a domain from a registrar, or through your tool if it offers that.
2. Add the domain in your app builder's or host's domain settings. On app builders such as Lovable and Bolt this is a paid-plan feature.
3. Copy the DNS records the host shows you (usually an A record or a CNAME record).
4. Paste them into your registrar's DNS settings. Changes can take a while to spread across the internet.
5. Wait for the secure padlock (HTTPS). Hosts generally set up the certificate for you once DNS is correct.
6. Test both versions of the address (with and without "www") and decide which one is the main one.

Tip: if you get stuck, paste the exact error message from the host's domain screen into your AI tool and ask, "What does this mean and what do I change at my registrar?"

Common deployment errors and how to fix them

Most launch-day problems fall into a handful of patterns. Here's what they usually mean and a prompt to fix each one.

When you ask for help, always include the exact error text, where it appears (build log, browser console, host dashboard) and what you changed last. Vague prompts like "it's broken" get vague fixes.

After you deploy: keep it healthy

Deployment isn't a one-time event. A live app needs a little regular care:

• Use a simple release routine. Make changes in the preview, test, then publish. Write one line in a notes file each time ("Oct 28: added booking reminders"). It makes rollbacks and debugging much easier.
• Know how to roll back. Find out now how your tool or host restores a previous version, before you need it.
• Back up your data. Check whether your database offers exports or backups, and test that you can actually restore one.
• Watch for errors. Check your host's logs after each release, and ask a couple of real users to tell you when something looks wrong.
• Re-run the security checks after big changes, especially anything touching logins, payments or the database.
• Keep dependencies updated. Every few months, ask your AI tool: "Which packages in this project are outdated or have known security issues? Update them safely and tell me what changed."
• Watch your plan limits. Hosting, databases and AI features can use credits or count toward plan limits as people use the app. Check your tool's current pricing pages rather than guessing.

If the app is for your business, our guide to vibe coding for small business covers what to build first and when buying software makes more sense than building it.

Which deployment path should you choose?

Still at the "what should I even build" stage? Spin the Vibe Machine idea generator for a random project idea, and follow our how to start vibe coding guide to build it. And if you'd rather have it built and deployed for you, you can hire a vibe coder to build, test and launch the app, then hand it over.

Is a deployed vibe-coded app "production ready"?

Not automatically. Being online and being ready for real users are different things. Developer Simon Willison made a useful distinction in March 2025: not all AI-assisted programming is vibe coding. If you've reviewed, tested and understood what the AI wrote, you're closer to AI-assisted engineering. If you shipped it because it seemed to work, that's vibe coding in the strict sense, which is fine for a personal toy and risky for an app holding other people's data.

A practical way to think about it: the more a mistake would hurt someone (lost money, leaked personal details, a broken booking system for a busy business), the more checking the app deserves before and after you deploy it. For a weekend game, publish and have fun. For a customer portal, test with a friend, run the checklists, and consider a review from someone who reads code.

Want to test your understanding of these ideas? Try the two-minute vibe coding challenge, or browse the vibe coding tools directory.

Frequently asked questions

Keep reading

Browse every guide on the vibe coding blog.

Sources

1. Lovable Docs, "Publish": docs.lovable.dev
2. Bolt Help Center, "Publish your site": support.bolt.new
3. Replit Docs, "About deployments": docs.replit.com
4. Replit Docs, "Deployment types": docs.replit.com
5. Vercel Docs, "Deploying GitHub Projects with Vercel" (updated Sept 2026): vercel.com
6. Vite Docs, "Env Variables and Modes": vite.dev
7. Supabase Docs, "Row Level Security": supabase.com
8. The Register, "Lovable-hosted app littered with basic flaws exposed 18K users, researcher claims", February 27, 2026: theregister.com
9. Veracode, 2025 GenAI Code Security Report press release, July 30, 2025: veracode.com
10. Simon Willison, "Not all AI-assisted programming is vibe coding (but vibe coding rocks)", March 19, 2025: simonwillison.net

VibeCodingMeaning.com is an independent educational site and isn't affiliated with any tool or platform mentioned. Tool features, plans and publishing steps change often; check each tool's documentation for current details. Some links may be affiliate links.