Take your Lovable app from prototype to production

Everything starts here, because a repository you own is what makes the rest possible. Lovable connects to GitHub and pushes the project, which gives you the application code and the SQL migration files that define your database.

This is also the point where you find out what you actually have. The migrations tell us how your tables and access rules are set up, which is the first thing we read, and the commit history tells us how much of the app was generated in one pass versus patched by prompting afterwards.

Lovable Cloud gives you a managed backend without creating an account anywhere, which is excellent until credits run out or someone needs the data under their own billing. Moving to your own Supabase project is a documented path, but less travels with the code than people expect.

The schema and access policies are in the migration files, so they rebuild cleanly. Your table rows, uploaded files, signed-up users and API keys are not: those are carried across by hand, in an order that matters. Passwords are the part that decides your timing, because if they cannot be carried then every existing user needs a reset email, which is a different message to send to twenty testers than to two thousand customers.

Because Lovable apps talk to the database from the browser, the database is the only place access can actually be enforced. If the rules are missing, the app is protected by its screens, and changing an identifier in a request is enough to read someone else's record.

We see this most often where tables were added late by prompting, after the earlier ones had policies written. The app looks consistent and the protection is not. It is also the fastest thing to test: make two accounts and try to read one's data from the other.

The other half of the same problem is the key the app uses. One kind is safe in browser code; another is built to bypass every access rule you wrote, because server code sometimes needs to read anything. They look alike in a settings panel, and the second one reliably makes a stubborn query succeed, which is exactly why it ends up in client code.

A key can also be absent from your source and still reach your users, because build tools copy environment variables into the files the browser downloads. We check the built bundle rather than the repository, and anything already public gets rotated rather than moved.

There is a point where prompting stops being the fast option. The signal is not a feature you cannot build; it is fixes that undo each other, because nothing is testing the behaviour you already had.

The useful answer is rarely to stop using Lovable. It is to put tests around the flows that work, move the decisions that matter to a server, and keep prompting for the parts where speed still pays. That way a later prompt that breaks checkout fails a test instead of a customer.

A Lovable app is typically a single-page application: one HTML shell serves every route and the content is assembled in the browser. Anything that reads your pages without running scripts therefore sees an empty file, which is why a working site can be missing from search results and unknown to assistants at the same time.

For many products the fix is cheap, because only the public pages need to be readable. The signed-in application can stay exactly as it is; nobody needs your dashboard indexed.