AI Development Series · Free Guide · No Email Required

Getting Your AI-Built App Live

Hosting, exporting your code, what happens to the database, and the things that are usually broken by the time an AI-built app reaches real users.

You built something in Lovable, Replit or Bolt, it works, and now you want it in front of real people. This is the part nobody explains. It is not hard exactly, but “deploy” means four different things depending on what you built it with, and the answer you find on the forums is usually specific to someone else’s setup.

Here is what deploying actually involves for each of the main tools, what you will need, and — because we spend our days opening these apps up — what tends to be broken by the time it goes live.

The short version

Most AI builders generate ordinary code you can take elsewhere. Bubble is the significant exception — its apps only run on Bubble.
Your frontend and your database are separate problems. Solve them separately, and in that order.
Getting it live is usually an afternoon. Getting it safe to be live is the part people underestimate.
The builder’s own hosting is fine to start with. The reasons to move are cost, control, and not having your business depend on someone else’s plan.
Publishing the frontend does nothing to the database. If the permission rules were wrong yesterday, they are wrong today with an audience.

Where your app actually lives right now

Most of the confusion around deployment comes from one missing mental model. An application built with any of these tools is really three things, and the builder has been quietly handling all three for you.

There is your interface — what users actually see. HTML, CSS and JavaScript, almost always React. It is just files, and files are easy to move.

There is your data — a database somewhere, very often Supabase or another PostgreSQL. This is the part that is genuinely yours and genuinely hard to replace, and it is the part most deployment guides skip.

And there is the stuff in between — the API calls, the login, the server-side functions, the rules deciding who is allowed to see which record. This layer is invisible when it works and expensive when it does not.

“Deploying” means deciding who handles each of those three from now on. You can move one without moving the others, and most people should. Hold that model and the rest of this page makes sense.

What deploying actually means, tool by tool

These tools are genuinely impressive. What they produce is ordinary code and an ordinary database, generated very fast by something optimising for a working result rather than a durable one. The differences below are about portability, not quality.

Lovable

What it is hosting for you: A React and TypeScript frontend, published to a lovable.app address. If you enabled Lovable Cloud, it is also running your database, authentication, file storage and serverless functions.
Getting the code out: Straightforward. Lovable syncs to a GitHub repository you own, and the sync is two-way: changes in Lovable push to GitHub, and commits pushed to the connected branch come back into Lovable. GitHub sync is on every plan; downloading the code directly from Lovable needs a paid plan.
Where the data lives: If you connected your own Supabase project, the data is already yours and stays exactly where it is when you move the frontend. If you used Lovable Cloud, the backend is managed for you — built on Supabase’s open-source foundation, but in Lovable’s account rather than yours.
Hosting it yourself: The frontend is a static build, so Netlify, Vercel, Cloudflare Pages or your own server will all serve it happily. Point it at the same backend and nothing else has to change.

The gotcha: Lovable’s own documentation states there is no one-click migration from Lovable Cloud to your own Supabase project. Moving means exporting your data, connecting a Supabase project to a new Lovable project and rebuilding the schema there. Two further things worth knowing before you commit: the Cloud region is locked once enabled, and removing Cloud cannot be undone, so export your database and storage files first.

What we find in Lovable apps →

Replit

What it is hosting for you: Both the editor and the running app. Replit offers four deployment types: Autoscale for apps whose traffic varies, Reserved VM for something that must run continuously, Static for sites with no server, and Scheduled for jobs that run at set times. Picking the wrong one is a common and fixable source of cost surprises.
Getting the code out: It is ordinary code in an ordinary project — React, Next.js, Express, Flask or Django — and you can push it to GitHub and run it anywhere. The friction is rarely the code itself; it is how much of the app assumes Replit’s runtime, storage and secrets handling.
Where the data lives: Replit provides a fully managed PostgreSQL database. You can see the connection string under the Database tool’s Settings tab, which means standard tooling such as pg_dump works and the data can be moved to any Postgres host.
Hosting it yourself: Entirely possible, and a normal deployment once the Replit-specific assumptions are unpicked. Budget a little time for environment variables and anything that was writing to local disk.

The gotcha: Replit keeps development and production databases separate. The data you carefully entered while building is in the development one, and your deployment gets its own. This is the single most common “my app is live but it is empty” moment, and it is the system working as designed rather than a fault. Move the data across deliberately.

What we find in Replit apps →

Bolt

What it is hosting for you: A frontend, published from Bolt by default. In the Domains and Hosting settings you can switch the hosting provider to Netlify and publish there instead, which is the usual first step for anyone wanting more control.
Getting the code out: The easiest of the group. Export gives you either a .zip download or a push to a GitHub repository, and the GitHub connection syncs both ways afterwards.
Where the data lives: Bolt commonly wires up Supabase for the database, authentication and any edge functions. That project is yours, so the data does not move when the frontend does.
Hosting it yourself: Whatever framework Bolt chose — React, Vue, Svelte or Astro — deploys like any other project of that type. Confirm which one you actually have before choosing a host.

The gotcha: Bolt builds in a browser-based environment, which is not the environment the app eventually runs in. Code that wrote files to disk, held state in memory between requests or relied on a long-running process can behave differently once deployed to a static or serverless host. The symptom is an app that worked perfectly while you were building it and then loses sessions or data once live.

What we find in Bolt apps →

Bubble

What it is hosting for you: All of it. The interface, the logic, the database and the hosting are one product, which is exactly why Bubble can do what it does without you writing code.
Getting the code out: You cannot, and it is better to know that plainly. Bubble’s own documentation says its apps can only run on the Bubble platform and there is no way to export your application as code. Bubble is clear that you own your data and your design; it retains ownership of the underlying code that runs the app.
Where the data lives: In Bubble, and it does come out: automated CSV exports and the Bubble API will both give you your records. Data portability and application portability are different things, and here you have the first but not the second.
Hosting it yourself: Not an option in normal circumstances. Bubble has committed to releasing its source code under an open-source licence if it ever discontinues the platform, so that apps could be self-hosted — a reasonable insurance policy, but not something you can act on today.

The gotcha: none of this makes Bubble a bad choice — plenty of real businesses run on it and it is a mature platform. But leaving means rebuilding rather than moving, so the decision is worth making deliberately and early, while a rebuild is still small.

What we find in Bubble apps →

v0

What it is hosting for you: A Next.js frontend, deployed to Vercel in one click. v0 generates with Next.js, Tailwind and shadcn/ui, which is a mainstream, well-documented stack that any React developer can pick up.
Getting the code out: It integrates with GitHub, and you can open a pull request against a repository rather than only deploying straight to production.
Where the data lives: Wherever you put it. v0 is strongest at the interface and expects to connect to your own APIs and databases, so the backend is a decision you make rather than one it makes for you.
Hosting it yourself: A Next.js app runs on Vercel most easily, and on Netlify, Cloudflare or your own Node server with a little more configuration.

The gotcha: the polish of the interface is not evidence about the layer underneath. Because v0 leaves the backend to you, the checks below matter more here than anywhere else on this page — there is no platform default quietly doing them.

What we find in v0 apps →

Cursor, Windsurf and the other editors

These are editors rather than hosts. They produce a normal repository on your own machine, so deployment is an ordinary deployment: pick a host that suits the framework, set your environment variables and push. Nothing on this page about getting your code out applies — you already have it.

The five things that break on the way to production

These are the things we find most often when we open up an AI-built app. None of them is your fault: the builder wrote the code this way, and it produced something that works, which is what you asked for. They matter now because “works” and “safe with real users” are different standards.

Keys that were fine in a prototype and are not now

API keys, database passwords and service tokens end up committed to the repository or shipped to the browser inside the frontend bundle. While you were the only user this changed nothing. The moment the app is public, anything in the browser is readable by anyone using it, and anything in a public repository is readable by everyone.

How to check: search your repository for the words key, secret and password, and open your deployed site’s JavaScript in browser developer tools. What fixing involves: move them to environment variables on the host, then rotate every key that was exposed — moving a leaked key does not un-leak it.

The database will let anyone read anything

This is the big one, and it is worth more of your attention than everything else here combined. Supabase and similar databases are queried directly from the browser, so the only thing standing between a stranger and your data is a set of row-level security policies. Those have to be switched on and written correctly. In the apps we have reviewed they are commonly switched off, or switched on with a policy permissive enough that any signed-in user can read every row.

This is not a hypothetical. CVE-2025-48757 is exactly this failure in Lovable-generated apps: insufficient row-level security allowing remote, unauthenticated attackers to read from and write to database tables they should never have reached. It was scored 9.3 out of 10 and reported as affecting more than 170 applications.

How to check: open your database dashboard and confirm row-level security is enabled on every table holding real data, then read the policies rather than trusting that their existence is enough. What fixing involves: writing policies that match how the business actually works — usually a day or two, and cheap relative to the alternative.

The permission checks are in the wrong place

Generated apps tend to enforce permissions in the interface: this button is hidden unless you are an administrator, this list is filtered to your own records. That is a display rule, not a security rule. Anything that does not go through your interface — a direct API call, a modified request, browser developer tools — is not bound by it at all.

This is the clearest example of why an automated scanner will not save you. A scanner checks for known vulnerabilities in known places, and it sees an app that works correctly. It cannot tell you the lock is on the wrong side of the door, because that requires understanding what your app is supposed to do.

How to check: log in as one ordinary user, then try to fetch another user’s record directly by changing the identifier in the request. If it comes back, the check is in the wrong layer. What fixing involves: moving the rule down into the database or the API, so it applies however the data is requested.

Nothing is backed up and nobody would know if it broke

Prototypes do not need backups, error tracking or logging, so builders do not add them. Once there are customers, the absence is felt in a specific way: something fails at eight in the evening, nothing tells you, and you find out when a customer emails two days later. Recovering from a bad data change without a backup is often simply not possible.

How to check: ask yourself how you would restore yesterday’s data, and how you would learn that a payment stopped working. What fixing involves: turning on your database provider’s automatic backups and adding an error-tracking service. Usually an hour, and the cheapest item on this list.

A server-side function that bypasses every rule above it

Most of these apps have some server-side code — an edge function, a cloud function, a webhook handler. To do their job they are often given an administrative key that ignores row-level security entirely. That is sometimes legitimate. The problem is when such a function accepts input from the browser and acts on it without checking who is asking, at which point every carefully written policy is bypassed by one endpoint.

It is worth calling out because it is invisible from outside: the app behaves perfectly, the database rules look right, and the hole is a function nobody has read since it was generated.

How to check: list your server-side functions and, for each, ask what credentials it runs with and whether it verifies the caller. What fixing involves: adding the caller check, or narrowing the credentials so the function can only do its one job.

Two more that show up once you are live. File uploads generated without validation will accept whatever type and size they are given and put it somewhere readable — worth ten minutes if your app takes uploads at all. And apps that are comfortable at ten users can struggle badly at a thousand, almost always because the database has no indexes beyond its primary keys. Neither is urgent on launch day; both are worth knowing about before the day they matter.

Custom domains, email, and the boring bits

Not everything on the way to production is a security problem. Some of it is just admin, and it is genuinely straightforward.

Custom domains work the same way everywhere: buy the domain, add it in the platform’s settings, then add the DNS records it gives you at your registrar. Lovable asks for an A record pointing at its IP address plus a TXT record to prove you own the domain. Bubble handles the root and www together so visitors reach you either way. All of these platforms issue and renew HTTPS certificates automatically, and on Bubble encryption is always on and cannot be disabled. Custom domains are a paid-plan feature on both Lovable and Bubble. Expect minutes of work and up to a few hours for DNS to propagate.

Transactional email is the one people forget until it bites. Password resets, receipts and verification messages are not marketing email, and sending them reliably needs a proper provider — Postmark, SendGrid, Mailgun, Resend or similar — with your domain’s SPF and DKIM records configured. Without that, your password resets land in spam and you get support tickets from people who cannot get back into their accounts. Test this before launch with a real address at a big provider, not just your own inbox.

A place to make changes that is not live. Prototypes get edited in production because at the start there is nothing to protect. Once real people are using the app, you want somewhere to try a change first — a second copy of the app pointing at a second database. Every platform here supports some version of this, and adopting it the week before launch is much easier than adopting it after a bad afternoon.

A pre-launch checklist

Work through this before you let real users in. Nothing here needs an email address, a signup or us.

Row-level security is enabled on every table holding real data, and you have read the policies rather than assuming they are right.
You have tested cross-user access deliberately — logged in as one user and tried to fetch another user’s record by changing the identifier.
No keys, passwords or tokens appear in your repository or in the JavaScript your site sends to the browser.
Every key that was ever exposed has been rotated, not just moved.
Permission rules are enforced in the database or API, not only in the interface.
Every server-side function checks who is calling it, especially any running with administrative credentials.
Automatic database backups are switched on and you know how to restore one.
Error tracking is in place so a failure reaches you before it reaches a customer.
Your production database contains the data you expect — on Replit especially, check you are not looking at an empty deployment database.
Transactional email is sending from a real provider with SPF and DKIM set, and password resets arrive somewhere other than spam.
Your custom domain resolves over HTTPS, with both the root and www reaching the app.
File uploads validate type and size, if your app accepts uploads at all.
Your database has indexes on the columns you filter and sort by, not only primary keys.
You have somewhere to make changes that is not production, and a copy of the data to test against.
You know what you would do if the app went down tomorrow morning and you were the only person available.

When to get someone to look at it

Most of the list above is genuinely DIY-able, and if you work through it you will be in better shape than a lot of funded startups. We would rather say that than pretend otherwise.

The ones that are hard to do yourself are the ones where you cannot see the problem from the outside: whether the permission model is enforced in the right layer, whether the data model matches how your business actually works, whether a function is quietly bypassing your rules. In all of those the app appears to work correctly while being wrong, which is precisely why they survive to production. Automated scanners do not find them either — a scanner looks for known vulnerabilities in known places, and cannot tell you your permission logic is in the wrong layer. A person has to read the code.

The AI Code Audit

A developer reads your codebase and reports across four areas: security, database structure, scalability and maintainability. £495 + VAT, written report in five working days, findings ranked by severity with what each would take to fix. The fee is credited back in full if you have us fix what we find. We are a UK development team and we have been building and fixing other people’s software since 2008.

Not sure whether any of this applies to you? Twelve questions, two minutes.

Common questions

Yes. Lovable syncs your project to a GitHub repository you own, and the sync runs both ways — changes in Lovable push to GitHub, and changes pushed to the connected branch come back. GitHub sync is available on all plans, though downloading the code directly from Lovable requires a paid plan.

With the code generators — Lovable, Replit, Bolt, v0 — yes. What they produce is ordinary React, TypeScript, Node or Python in a repository you control, and you can take it elsewhere. Bubble is the exception: you own your data and your design, but the application itself only runs on Bubble.

The frontend is a static React build, so any modern static host will serve it — Netlify, Vercel, Cloudflare Pages, or your own server. Lovable’s own hosting is perfectly reasonable to start with. The decision that actually matters is what happens to the backend, which is a separate question from where the frontend lives.

Lovable Cloud is a managed backend built on Supabase’s open-source foundation, set up for you. Your own Supabase project is the same technology with you holding the account. The practical difference is portability: Lovable’s documentation is explicit that there is no one-click migration from Cloud to your own Supabase, so choosing Cloud is easier now and more work to unpick later.

Not as an application. Bubble states plainly that its apps can only run on the Bubble platform and that there is no way to export your application as code. You can export your data by CSV or through the API, and Bubble will help you export the design, but the logic would have to be rebuilt. Worth knowing before you build, rather than after.

Usually nothing — and that catches people out. The database is a separate service from the frontend, so publishing a new version of the interface does not move, copy or protect the data behind it. If the permission rules were wrong before you deployed, they are wrong afterwards, now with real users attached.

Because Replit keeps development and production databases separate. The data you added while building sits in the development database, and a deployment gets its own. It is doing what it is designed to do. You need to move the data across deliberately, which is what the connection string in the Database tool is for.

To get it live, usually not. Every builder here has a publish button, and connecting a domain is a couple of DNS records. Where people reasonably want help is the layer underneath — database permissions, secrets and backups — because those are hard to check when you cannot yet read the code.

Less than people expect. A static frontend is free or a few pounds a month on most hosts, and a small managed database is typically in the same range until you have real volume. The costs that surprise people are usage-based ones further down the line, where an inefficient query pattern is billed per read.

You can, and plenty do — but be deliberate about it rather than drifting. The problems worth fixing before real users arrive are the ones where data can leak, because you cannot un-leak it. Backups, monitoring and performance can genuinely wait a fortnight. Permission rules cannot.

On every builder here it is the same shape: buy the domain, add it in the platform’s settings, then add the DNS records it gives you at your registrar. HTTPS is issued automatically on all of them. It usually takes minutes, though DNS changes can take a few hours to propagate.

It depends where the app ends up. If you have moved the frontend to your own host and hold your own database, you can stop paying the builder and keep working on the code. If you are using the builder’s hosting or its managed backend, then it is your hosting provider and the subscription continues.

Last reviewed: August 2026. Every platform-specific detail on this page was checked against the vendors’ own current documentation. These tools change frequently — if you find something here that is out of date, tell us and we will correct it.