Deploying Your Vibe Coded App

The Gap Between "Working" and "Live"

You have built something. It runs in Claude's Artifact preview, or in Bolt's browser panel, or as an HTML file on your desktop. You open it, click around, everything works. So why can't you just send someone a link?

Because right now, your app exists only on your computer — or inside the platform where you built it. There is no address on the internet for it yet. When you share a link, there needs to be a computer somewhere running your app and serving it to whoever visits. That computer is called a server.

The good news: you do not need to set up a server yourself. Hosted services can publish a static project from a folder, and app builders offer publish flows that give you a real URL to share. Check the provider's current plan and usage limits before relying on it.

Which Path Applies to You

How you deploy depends on how you built the app. Here is a quick way to figure out your path:

• You have a saved .html file (exported from Claude, or downloaded from somewhere) — go to Path A.
• You built it in Bolt — go to Path B.
• You built it in Replit — go to Path C.
• You built it in Lovable — go to Path D.
• You built it in v0 — go to Path E.

If you are not sure, think about what you were using when you built the app. If you had a live preview inside the tool while you described what you wanted, you probably used one of the platforms above. If you copied and pasted code into a text file yourself, you have an HTML file.

Path A — You Have an HTML File

If you built your app in Claude and saved the code as a .html file, you are in the best situation for easy deployment. A single HTML file is the simplest possible thing to put online.

One simple option is Netlify Drop. Put your site files in a folder with an index.html entry page, then drag the folder into the Netlify Drop publisher. Netlify recommends signing in first, although an unclaimed deploy can be claimed after sign-up.

How to Deploy with Netlify Drop

That is it. Anyone with the link can now open your app.

Renaming the Random URL

The auto-generated URL (quirky-name-12345.netlify.app) is not very memorable. After you claim or manage the project in a Netlify account, use the site's domain settings to choose an available Netlify subdomain or connect a custom domain.

Updating Your App Later

To update the same managed project, open it in your Netlify dashboard and drag an updated project folder into its deploy area. If you deployed without signing in, claim the deployment first so you can manage later updates.

Path B — You Built in Bolt

Bolt has built-in hosting. For new projects, click Publish and Bolt publishes to a free .bolt.host address by default. You can choose Netlify instead before the first publish by connecting a Netlify account in Bolt settings.

Bolt handles the hosting setup and gives you a shareable URL. Custom domains are available through Bolt hosting on eligible paid plans.

To update after making changes, publish the project again from Bolt. Projects originally published through Netlify may continue there or be switched according to Bolt's hosting settings.

Path C — You Built in Replit

While you build in Replit, the preview uses a development URL ending in .replit.dev. It is for testing, is only live while you actively work on the app, and can change when you reopen it. Do not treat it as your published link.

To share an app reliably, use Publish. Replit publishes a snapshot to a public .replit.app URL and offers different deployment types, including Static for browser-rendered sites, Autoscale for web apps whose resource usage varies, and Reserved VM for processes that must stay running.

Path D — You Built in Lovable

Lovable has a Publish button. Find it in the top right of the Lovable editor and click it. Your app gets a URL ending in .lovable.app that is immediately shareable.

Publishing deploys the current snapshot; later editor changes do not go live until you select Publish and update the deployment. Lovable also supports custom domains on paid plans.

Path E — You Built in v0

v0 integrates with Vercel deployments. Use its publish or deploy action to create a production deployment on Vercel and receive a Vercel URL; the exact build time depends on your project.

The connected Vercel project is where you manage domains, environment variables, deployments, and any enabled analytics or monitoring features.

Getting Your Own Domain (Optional)

A custom domain such as mywatchlist.com can make your app easier to remember. It is optional; platform-provided addresses such as .netlify.app, .bolt.host, .lovable.app, .replit.app, or .vercel.app may be enough for a prototype. Check plan limits and domain pricing before committing.

When a custom domain is worth it:

• You are sharing it professionally or showing it in a portfolio
• You expect people to remember and return to it
• The app serves a real purpose for others, not just yourself

How to Get a Domain

Buy a domain from a registrar, then connect it to wherever your app is hosted. Pricing, renewal costs, and supported domain features vary by registrar and top-level domain.

Hosting dashboards provide the DNS records required for a custom domain. Follow the current instructions in your chosen hosting platform, then allow time for DNS verification and propagation.

Your Data After Deployment

This is the part that surprises most people. When you deploy, your app goes live — but your data does not go with it.

If your app saves data in the browser (the most common approach for vibe-coded apps), that data is stored on your browser on your computer. When someone else visits your deployed app, their browser starts empty. And when you visit the deployed URL, your browser is also empty — because the deployed version is different from the version you tested locally.

This matters depending on what kind of app you built:

• Personal tools that only you use (habit tracker, shopping list, budget calculator) — Browser-stored data is fine. You will always visit from the same browser, so your data is always there.
• Apps you share with others who each keep their own data — Also fine. Each person's browser stores their own data independently.
• Apps where multiple people share the same data (a shared to-do list, a team board, anything with user accounts) — Browser storage does not work here. Everyone needs to access the same data, which means you need a database.

Adding a Database (If You Need One)

If your app needs shared data, one option is Supabase, which provides a hosted Postgres database and client libraries. A browser app can use its Data API, but you must enable Row Level Security, write appropriate access policies, and expose only a publishable key. Never put a secret or service-role key in browser code.

Ask AI to help: "My app currently saves data in localStorage. I want to move to a real database so any device can access it. I'm using Supabase. Walk me through the changes."

This is a bigger step — it adds complexity to your app. Only take it if you genuinely need shared data. Most vibe-coded apps do not.

What Surprises People After Going Live

Even when everything works locally, going live often reveals new issues. These are normal and fixable.

"It looks different on my friend's phone"

Different browsers and screen sizes render things differently. What looked perfect on your laptop may have overlapping text on a phone, or different fonts on Safari vs. Chrome. If you asked AI for a mobile-friendly design, test it on an actual phone before sharing widely.

"My friends immediately found bugs I never noticed"

When you test your own app, you use it exactly as you designed it — in the order that works, with data that makes sense. Real users do unexpected things. They click buttons in the wrong order, leave fields blank, type unusual characters, and use the app backwards from how you imagined.

This is good. These are genuine bugs and real feedback. Describe what your friend found and ask AI to fix it.

"Anyone on the internet can see it"

Your deployed URL is public. Anyone who has it — or finds it — can open your app. This is usually what you want. But if your app contains personal information, private data, or anything you would not want a stranger to see, do not deploy it to a public URL without adding some form of protection.

A password prompt implemented only in browser code is not protection because visitors can inspect or bypass it. For private content, use access controls provided by the hosting platform or implement authenticated access with server-side authorization before publishing.

"I updated the file but the live site still shows the old version"

Browsers cache (remember) old versions of websites to load them faster. After redeploying, the live site may show the old version for a few minutes. Try opening the URL in a private/incognito window, or hold Shift and press Refresh to force a fresh load.

Related Guides