Take your Lovable app to production

A Lovable app is in production when someone who is not you can create an account, see only their own data, and come back the next day to find the service still up. Clicking Publish puts the site on the internet. It does not decide who is allowed to read each row.

Who this is for

This page is for a founder, an agency, or an internal team that already has an app working in preview, or live on a lovable.app address, and now needs it to hold a real user. The usual moment is the one after the demo: login exists, customer data is about to land, and sometimes a card is about to be charged.

It also fits a team that wants to keep iterating in Lovable and still have a production environment with an owner. Lovable's docs describe that hybrid on purpose. The repository stays in sync, Lovable keeps editing and previewing, and another host serves the live app Source [1].

If you are still on the idea, this is the wrong page. Keep building in Lovable. That is what the product is for.

Buyers in the United States, Europe, Israel, and Latin America hit the same wall. The preview looks finished. The database policy does not. English-language agencies already sell the cleanup. VeryCreatives, on its own site, prices a typical hardening sprint at 2 to 4 weeks and US$ 5,000 to US$ 15,000, depending on the size of the app and how much of the schema and frontend has to be rebuilt. That figure is the vendor's price, not a market average Source [6].

What Lovable already handles

Lovable's recommended path, for most apps, is to leave preview and production on Lovable Source [1]. Publish gives the project a public URL with HTTPS. A lovable.app address is free on every plan. A custom domain is a paid-plan feature Source [3].

You own the code. You can change it, use it commercially, and host it where you choose, subject to the open-source licenses of the pieces inside it. The database, storage, and configuration are portable. Lovable says it does not rely on a proprietary data store Source [1].

Lovable states SOC 2 Type II, ISO 27001:2022, and AIUC-1. It also states, plainly, that it is not HIPAA-compliant and does not sign a Business Associate Agreement. The 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. Do not store the card in the database Source [3].

The Lovable editor itself cannot be installed inside a customer's network. The app you build can Source [1].

The stack changed in 2026. Apps created from 13 May 2026 (22 June 2026 on Enterprise workspaces) use TanStack Start, which runs 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 backend (Cloud) or a Supabase project you own Source [3].

What you get

The hardening sprint covers the work Lovable's own migration guide assigns to you once the backend leaves Lovable, and the same checks when the app stays on Lovable but starts holding someone else's data Source [1] Source [2].

• A security and data review. What the app stores, who can read it, and what should not be there.
• Row Level Security in Postgres. Supabase's warning is specific: a table in an exposed schema, without RLS, and with a grant, can be read and modified by any role that holds that grant. Turning RLS on, before any policy exists, blocks access through the publishable key. The secret key, the one that acts as service_role, bypasses RLS and does not belong in the browser Source [5].
• Secrets. API keys, Stripe tokens, and SMTP passwords live on the server or in the project vault. They do not live in the frontend bundle. Lovable marks secrets as a manual migration step. The export does not include them Source [2] Source [3].
• Authentication. The providers you already use, redirect URLs for the new domain, email confirmation, a one-time-code lifetime you can defend, and a second factor when the risk calls for it. Supabase's production checklist asks for email confirmation on, a one-time code expiry of one hour or less, and SMTP on your own domain. The default auth-email rate limit is too low for a public launch Source [4].
• Domain, HTTPS, and the release path. If the app stays on Lovable, that is a custom domain on a paid plan. If the frontend moves, you own the pipeline, rollbacks, and environment variables. An older React and Vite app must serve index.html for client-side routes. A TanStack Start app needs a host that runs a server, not a file CDN alone Source [2].
• Backups. On Supabase's Free plan, database backups are not available for download, and a quiet project can be paused after seven days of low activity. Pro is what stops that inactivity pause. Point-in-Time Recovery is the add-on when you need to restore to a chosen second Source [4].
• Monitoring. Auth logs, function errors, and an alert a person actually reads. Lovable cannot monitor infrastructure it does not control Source [2].
• CI/CD. Schema changes leave from Git, not from someone's laptop on a Friday. Supabase documents connecting the repository and deploying from the main branch Source [4].
• Performance. An index on every column an RLS policy filters, a look at the hot queries, and a pass on what a phone on a real network feels like.
• Documentation. What is in production, where the key is, how to restore, and who to call.

The long checklist, including what migrates on its own and what stays manual, is in How to take a Lovable app to production.

How it works

The studio process is diagnosis, strategy, execution, evolution. On an app that already exists, that becomes four moments.

1. Diagnosis. Read access to the project, or to the synced repository, and a list of what is exposed. The first call is 30 minutes and does not commit either side. If the fit is wrong, that is the written answer.
2. Hardening sprint. Two weeks, one focus. Data and RLS come first, because that is the hole the key already sitting in the frontend can walk through. Secrets, authentication, domain, backup, and the pipeline follow.
3. Delivery. The app on the agreed domain, policies tested with a user who should pass and a user who should fail, a backup restored at least once in a test environment, and a short operating note.
4. Follow-through. The period after delivery is part of the project. Continuous change sits on the monthly partnership.

The build uses AI agents inside the studio's own process: construction, tests, and a separate audit from the person who wrote the change. A human reviews before anything is called done. Client data stays in the client's accounts, with least-access credentials, under LGPD and GDPR practices, and is never used to train public models.

Work is delivered in English and Brazilian Portuguese. The studio is based in São Paulo and has already delivered for clients in São Paulo, New York, Madrid, and Tel Aviv.

Time and price

A sprint is US$ 1,200 for two weeks, and you can cancel when you want. A fixed project starts at US$ 3,000, with scope, timeline, and price closed, a delivery every sprint, and support after launch. A partnership starts at US$ 900 a month, with a continuous roadmap and a monthly check-in. The three shapes are on Pricing.

For this service, a closed hardening pass (RLS, secrets, authentication, domain, and backup) fits in one or two sprints. A multi-tenant product with billing and a separate production environment is usually a project, 4 to 8 weeks. Those are the same windows the studio publishes for a full project. They are not a promise about an app nobody has opened yet.

Set that next to the agency range above. VeryCreatives publishes US$ 5,000 to US$ 15,000 for a 2 to 4 week hardening sprint Source [6]. A US$ 1,200 sprint is not that scope. A project from US$ 3,000 is the shape that lines up with a full production pass, still well under the top of that published range, and only after the review says what the app actually needs.

What this engagement does not include

• A from-scratch rewrite, when the missing work is hardening what already runs.
• Taking over an app nobody will open. Without the project or the repository, there is no diagnosis.
• Storing card numbers in the database. Lovable's terms forbid it, and the payment path is the provider Source [3].
• Turning the web app into a store-native app inside this sprint. Lovable does not generate React Native projects. A PWA, or a wrapper outside Lovable, is a separate job Source [3].
• Installing the Lovable editor inside your VPC. Lovable says that is not available Source [1].
• A promise that Lovable will fit forever. Data residency, private networking, or an internal rule that demands an audited host are the cases where the official path is to move the piece that hits the constraint Source [1].

When you should not hire this

Stay on Lovable alone while the app is still a test, used by you and maybe one other person, with no customer personal data and no charges. Publish and keep iterating. That is the path the docs call recommended Source [1].

Hire a product team, not a hardening sprint, when the open decision is what to build. Hardening the wrong screen only makes the wrong screen harder to delete.

Ask a different supplier if you need a framework Lovable does not generate, or a HIPAA contract. The official FAQ is direct on both Source [3].

A real case, without the name

A multi-tenant B2B SaaS for gyms started in Lovable, on a Supabase backend, and now runs in production with paying customers. The company name is not public. The shape is what matters: many gyms in one app, each one seeing only its own records, with people paying to use it.

That shape is where a sloppy RLS policy leaks. "Any signed-in user can read the table" is not a policy. The row has to be tied to that login's gym, and the test has to prove the negative: a different gym, also signed in, cannot read the row. Supabase treats RLS as a rule inside the database, not as a filter that lives only in the screen Source [5].

If the job is a workflow rather than an app, the neighboring offer is n8n automation. If the question is price before scope, start at Pricing.