My Lovable app is running – how do I get it into production safely?

Lovable makes it easy to turn an idea into a web app in a short time. The result is usually a React frontend; data and sign-in often run through Supabase. It works – in the browser, with real data, often with real users already.

What easily gets lost: "it runs" doesn't mean "it's operated". At the latest when customers, colleagues or revenue depend on the app, you need more than a working prototype.

1. Clarify who owns the app

The first question isn't a technical one: who owns the code, the database and the domain? If the person who "prompted" everything leaves, the app must not leave with them.

• Connect the project to a GitHub repository that belongs to your company – not to one person's private account.
• Create the Supabase project in an organization owned by the company and give at least two people admin rights.
• Register the domain and payment methods in the company's name.

2. Check the access rules

In Supabase, Row Level Security (RLS) decides who may read and change which records. The public key (anon key) is necessarily in the frontend – anyone can see it in the browser. Without suitable rules, it allows more than you think.

• Is RLS enabled for every table?
• Does every table have policies that match your permission concept?
• Test with a second user account: does it see data it shouldn't?
• The service_role key bypasses all rules. It never belongs in the frontend.

3. Get secret keys out of the frontend

API keys for OpenAI, Stripe or email services have no place in the frontend: anything that ends up in the browser can be read by anyone. Secret keys belong in server functions – such as Supabase Edge Functions – and there in the stored secrets.

If a key has already ended up in the code or in the Git history, deleting it isn't enough. How to do it properly is explained in the guide How do I remove passwords and API keys from the Git history?

4. Check backups – and practice the restore

• Check in the Supabase dashboard whether and how often backups are made and how long they are kept. Point-in-time recovery is available as an add-on, depending on your plan.
• Also set up your own regular export to a second location, for example a database dump.
• Don't forget the files: uploads in Storage are not part of the database dump.
• Restore a backup into a test project once. A backup that has never been restored is a hope, not a plan.

5. Make errors visible

Without monitoring, you hear about outages from your users. It doesn't have to be that way:

• An external uptime check calls the app regularly and raises the alarm if it doesn't respond.
• Error tracking in the frontend, for example with Sentry, shows you crashes before anyone calls.
• Keep a regular eye on the logs of your server functions.

6. Roll out changes in a controlled way

With AI, the next change is just one prompt away – and quickly lands directly in the live system.

• Separate testing and production: a separate Supabase project for testing, check changes there first.
• Version database changes as migrations in the repository instead of just clicking them together in the dashboard.
• Set up an automatic test pipeline that tests every change before it goes live. More on that: What is CI/CD and why do I need it for vibe coding?

7. Domain, data protection and responsibility

• Run the app under your own domain with HTTPS.
• Clarify where the data is stored. With Supabase, you choose the region when you create the project, for example Frankfurt.
• Conclude a data processing agreement (DPA) with every provider that processes personal data, and update your privacy policy.
• Decide who is responsible when something fails – by name, not "someone on the team".

The checklist to tick off

• Code lives in a company-owned repository
• Supabase project in a company organization, at least two admins
• RLS active on all tables and tested with a second account
• No secret keys in the frontend
• Backup checked, restore practiced once, Storage backed up too
• Uptime check and error tracking active
• Separate test environment, migrations in the repository
• Responsible person named