How to take a Lovable app to production: the checklist we use

Taking a Lovable app to production means a person who is not you can create an account, see only their own data, and come back the next day with the service still up. Secrets stay off the browser. A backup has been restored once, on purpose. Publish puts a snapshot on the internet. The checklist is everything after that click.

We use this list before we treat an app as ready for a real customer. It is written for a founder in the US, Europe, Israel, or Latin America who already has the screen working, and for an internal team about to put customer data behind login. If you want that work done for you, the scope sits on Take your Lovable app to production.

What "production" means here

Preview is the screen you open while you build. Publish, in Lovable's docs, deploys a snapshot to its own URL with HTTPS. A lovable.app address is free on every plan. A custom domain is a paid-plan feature Source [1].

Production, on this checklist, is narrower. A second person signs up, finishes the main path, cannot open the next row by editing an id, and finds the app awake tomorrow. If money changes hands, it goes through a payment provider. The card number is not a column.

Lovable's guide for leaving the platform says most teams keep the default and never need that guide. Hosting, custom domain, HTTPS, the built-in backend, and preview all stay in one place Source [2]. Moving is a requirement, not a graduation ceremony.

What Lovable already handles

You own the code, subject to the open-source licenses of the pieces inside it. You can change it, sell with it, and host it where you want Source [1]. Git sync is on every plan and keeps a repository on GitHub, GitLab, or Bitbucket. A zip download of the codebase is a paid-plan feature Source [1] Source [2].

Lovable builds web apps. It does not generate React Native, so a native App Store or Play Store binary is not an export button. The documented paths are a Progressive Web App, or a wrapper such as Capacitor applied outside Lovable Source [1].

The stack depends on when the project was created. Apps created from 13 May 2026 (22 June 2026 for Enterprise workspaces) use TanStack Start and run server code. Older apps use React and Vite and build to static files. There is no framework picker and no database picker. The database is PostgreSQL, through the built-in Cloud backend or a Supabase project you connect Source [1].

Open package.json to see which one you have. A TanStack Start project lists @tanstack/react-start. A static host that only receives files will not run the server functions of a TanStack Start app Source [2].

Lovable states SOC 2 Type II, ISO 27001:2022, and AIUC-1. The same FAQ says Lovable is not HIPAA compliant and does not sign a Business Associate Agreement. Standard terms do not allow protected health information, payment card data, financial account numbers, government identifiers, or biometrics inside the app. Take payment through Lovable's built-in payments or your own Stripe account Source [1].

As of 9 September 2026, Free and Pro plans may use prompts, code, and project files to train models unless you opt out in account settings. End-user data inside your app is not used for training. Business and Enterprise workspace data is excluded by default Source [1].

What stays manual

A code export is not a product export. Git sync and the zip include source, config, and migration files. They do not include database rows or storage files Source [2]. The Cloud data export (More, Cloud, Overview, Advanced settings) also skips stored files, Edge Function code, and secrets Source [1].

When the destination is another Supabase project, Lovable's migration table splits the work like this Source [2]:

Moving Postgres alone does not move auth, storage, realtime, or Edge Functions. That sentence is in the external-hosting guide, and it is the failure mode behind "we took a dump and called it a migration" Source [2].

Variables prefixed with VITE_ are embedded at build time. Changing the database URL later means building again. A Cloud project needs VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY in the browser. A TanStack Start server also needs the same values without the VITE_ prefix. Function secrets are not in the repository Source [2].

The checklist

Do it in this order. Data access comes before a nicer domain. Each item is a 15-minute test with a second account, on an email that is not yours.

Authentication

1. Create a test user who is not the project owner. Walk through sign-up, sign-in, password reset, and sign-out.
2. Turn email confirmation on. Supabase's production checklist asks for email confirmation and for your own SMTP, ideally on the same domain as the app. Without custom SMTP, auth email is capped at 2 messages per hour, a limit in place since 3 September 2024. With custom SMTP, the default becomes 30 new users per hour. A public launch blows past both Source [3].
3. Set one-time password expiry to 3600 seconds or less. Supabase recommends that ceiling, and a longer code if you need more entropy Source [3].
4. If sign-in is Google or another OAuth provider, add the production URL, and the preview URL if anyone still uses it, to the allowed redirect list. A domain cutover without that breaks login on launch day Source [2].
5. Turn on MFA for the Supabase account that administers the project. The checklist also suggests more than one org owner, so a lost laptop is not an outage Source [3].
6. Corporate email scanners open links before the user does. Supabase notes that magic links and reset links are single-use, so the person then sees an error. The workaround is a button on a domain you control, and turning off click-tracking on the SMTP provider Source [3].

Secrets

1. Search the repository, the zip, and the browser bundle for anything that is a real secret: a Stripe secret key, a service-role key, a vendor token. The publishable key (VITE_SUPABASE_PUBLISHABLE_KEY) is allowed in the frontend. It is not a secret. A key that bypasses row policies must not ship in the browser Source [2] Source [3].
2. Edge Function secrets and server-function secrets live in the destination environment, not in Git. The export does not carry them Source [1].
3. If the frontend leaves Lovable, you own the pipeline, the variables, the cache, uptime, and logs. Lovable cannot monitor infrastructure it does not control Source [2].

RLS and data

Row Level Security is the rule that decides which row a user can read or write. Supabase's checklist is blunt: enable RLS on all tables. A table without RLS, and with grants, can be read and modified by any client that holds the key Source [3].

1. Open the table list and write down which tables have RLS off. A forgotten "draft" table leaks the same way the main table does.
2. With the second account, try to read and edit a row that is not theirs. Change the id in the URL and in the request. If the row comes back, the policy is missing or it lets everyone through.
3. Repeat for insert, update, and delete. A read policy does not stop a delete.
4. More than one company in the same database (the multi-tenant case) needs an owner column and a policy that uses it. "Users see their own rows" is the wrong shape when "their own" means the whole gym, not the person.
5. Enforce SSL on the database and turn on network restrictions if the plan allows it. Both are on the same checklist Source [3].
6. Index the query the screen runs all day. Supabase points you at Performance Advisor and at a load test, preferably on a staging project Source [3].

Do not store what Lovable's standard terms forbid: protected health information, card numbers, financial account numbers, government IDs, biometrics Source [1].

Files

1. List the buckets. The bucket structure moves with the migration. The file does not Source [2].
2. Open another user's file with the second account. Storage policy is separate from table policy. One can be right while the other is wrong.
3. Upload a file the size a customer actually sends, not the 40 KB PNG from the preview.

Environments

1. Keep preview and production apart. Lovable preview is where you experiment. The production database is not.
2. If you host the frontend elsewhere, the production build uses production variables. VITE_ values are baked in at build time. A build made against the preview URL and then served on the real domain points at the wrong database with no obvious banner Source [2].
3. On a Supabase Pro plan, the checklist suggests branching so a migration is tried before it hits production, and GitHub "Deploy to production" so schema changes do not depend on someone running db push from a laptop Source [3].
4. The official deploy examples use Node.js 22 Source [2].

Observability

1. Know where you look when the screen is white on a Monday. On a paid Lovable plan, human support replies by email within 24 hours, mainly on weekdays, after the support AI does not solve it Source [1]. Off Lovable, the log is yours Source [2].
2. Have a way to learn that login broke before a customer writes in. A scheduled run of the main path, with the test account, is enough at the start.
3. Write down the second Supabase org owner Source [3].

Cost and continuity

1. A Supabase project on the Free plan may be paused after 7 days of low activity. You can restore it from the dashboard. Pro is what Supabase names as the way to keep the project from being paused for inactivity. Free-plan backups are not available for download Source [3].
2. If the database is heading past 4 GB, the checklist says to enable Point in Time Recovery. Default disk durability is given as 99.8 to 99.9 percent. PITR is the path when a disk fails and you need a specific second back Source [3].
3. Lovable credits run out mid-month if the team keeps asking for large changes in chat. A paid plan includes a monthly pack. Top-ups exist on Pro and Business. That is a building cost, separate from the cost of keeping the app up Source [1].
4. Hide the "Edit with Lovable" badge only if a customer will care. The switch is on paid plans, per project, and it disappears immediately, with no republish Source [1].

Signs the app is not ready

• The second account sees the full list of customers, orders, or members.
• Sign-up works for you and fails for the third person that day, because confirmation email hit the 2-per-hour cap Source [3].
• The only backup is "Lovable still has the project." You have never downloaded an export or restored one into a copy.
• The Supabase project is on Free and sat idle for a week. It may wake up paused Source [3].
• A Stripe secret, a privileged database key, or a vendor token is in the bundle the browser downloads.
• The app stores a copy of an ID, a card, or a medical record. Standard terms do not cover that Source [1].
• Nobody but you can publish, and you are on a plane the week of launch.
• Production is still the preview URL, or the custom domain serves a build that was compiled with the other environment's variables Source [2].

One of these holds a launch. Three of them are the usual shape of an app that "works in the demo."

Mistakes we keep seeing

Treating preview as staging. Preview runs as you, on your test rows. The hole shows up with the second user.

Assuming RLS "came on by default" and never opening the table list. Lovable will help you write a policy. Supabase still puts the review on your checklist, not on theirs Source [3]. A missing policy and a policy that allows everyone fail the same way for the customer.

Exporting the zip and announcing that the product has moved. Rows, files, and secrets stayed behind Source [1] Source [2].

Publishing a TanStack Start app to a static file host. The server functions do not run. The guide splits the two project types for that reason Source [2].

Storing the card number "just for now" next to a Stripe integration. The accepted path is built-in payments or your own Stripe account Source [1].

What not to do

Do not turn off the source project on the day the destination comes up. Run both until the second account finishes the main path on the destination and a real file opens.

Do not put production data in the project where the Lovable chat is still changing the schema. Every table change during launch reopens the RLS question.

Do not rewrite the app in another framework because an older article still calls every Lovable app "React + Vite, full stop." The FAQ current as of October 2026 describes TanStack Start for new apps and React + Vite for older ones Source [1]. A rewrite is a different project from a hardening pass.

Do not use a Supabase Free project as production for a paying customer. The inactivity pause and the lack of a downloadable backup are written on the checklist Source [3].

When you can keep going alone

Keep going alone if every line below is true.

The app has one user, or a group that shares one account on purpose. There is no second company's data in the same database. You opened the dashboard, saw RLS on the tables that matter, and tested with a second account. You exported the database, restored it into a copy, and opened a row. The Supabase project is not on Free, or you accept waking it by hand and no customer depends on it. There is no card, medical record, or government ID in the database. You know which host serves the app and who hears about it if login fails.

In that shape, the checklist is an afternoon. Write down what you tested. You will not remember next month.

When to call someone

Call someone when the app already has a customer, or will next week, and you cannot answer "who can read this row?" without opening the code. The usual case is multi-tenant: each of your customers has their own users, files, and billing.

Also call when the app has to leave Lovable because of an outside rule (data residency, a company pipeline, a private network) and the external-hosting guide has become a task list rather than a paragraph Source [2]. Or when the people who built it in chat are not the people who will answer the incident.

An English-language studio, VeryCreatives, publishes its own price for this work: a typical Lovable hardening sprint takes 2 to 4 weeks and runs from US$5,000 to US$15,000, depending on app size and how much of the Supabase schema and the frontend they rebuild. That is their price, not a market average. Their page still describes Lovable as a React single-page app. Lovable's current FAQ describes a different stack for apps created from May 2026 Source [1] Source [4]. Use the range as a published vendor quote, then check package.json before you believe a stack diagram from a services page.

At samambai, the same kind of review starts as a two-week sprint at US$1,200. That sprint is not the US$5,000 to US$15,000 scope. A product with a separate environment, a domain, and payments fits a project from US$3,000, with a delivery each sprint, usually over four to eight weeks, scoped after we have looked at the app. The three ways to buy are on pricing. The first conversation is 30 minutes and does not commit you.

The studio is based in São Paulo and already works with clients in São Paulo, New York, Madrid, and Tel Aviv, in English and in Portuguese. The sequence is diagnosis, strategy, execution, evolution. During execution, AI agents help scan policies, diffs, and tests, and a person reviews before a change reaches the live app. Access is the minimum required. Data stays in your accounts. It is not used to train public models.

When not to hire samambai

Do not hire us if you do not have an app yet. Lovable is the tool for that first version. Arriving with a paragraph and asking for "production" skips the step.

Do not hire us if the deadline is under a week and the app has login plus customer data. You can publish in a week. You cannot review access, test with a second account, and leave a restorable backup in that window without skipping the test.

Do not hire us if you cannot share the project or the repository. Without that, the review is an opinion about a screenshot.

Do not hire us if the product must store cards, medical records, or government IDs inside the app. Lovable's standard terms do not allow it, and we will not route around the terms Source [1].

Do not hire us for a native store app. Lovable does not generate React Native Source [1].

Do not hire us for a full rewrite when the app needs policies, a domain, and a backup. The reverse is also true. If your company requires a full move off Lovable, say so on the first call. Hardening on Cloud is one scope. Changing houses is another.

One real case, no name

A multi-tenant B2B product for gyms started in Lovable, on a Supabase backend, and now runs in production with paying customers. Each gym has its own members. The row policy is what stops one location from opening another's list. The path was not a rewrite onto a different framework. It was treating schema, access, environment, and operations as production work, with the code remaining the product owner's.

The same question fits an internal portal or a single-customer app. The policy gets smaller. The question does not. Who can read this row?

If the honest answer is still "the preview works," start with the checklist, or with the service page at Lovable to production. If the next gap is connecting the live app to a CRM, a spreadsheet, or WhatsApp, that is a different job, described under n8n automation.