Taking a Lovable app to production starts with owning the code.

Lovable gives you real code, and that is a good start

Lovable is very good at turning an idea into a working application quickly. According to its documentation, apps created from May 13, 2026 use TanStack Start, which renders pages on the server, while older apps use React and Vite and render in the browser. The backend is either Lovable Cloud, which Lovable describes as built on Supabase's open-source foundation, or a Supabase project you connect yourself. Both use PostgreSQL.

Ownership is also clearer than on many builders. Lovable's FAQ states that the apps and code you create are yours, GitHub sync is available on all plans, and paid plans can download the codebase. The sync is two-way on one active branch, and Lovable creates the repository itself rather than connecting an existing one. This has a practical consequence: a direct push to the active branch flows back into the Lovable editor, so the team has to agree where changes are made.

The gap between a prototype and production is rarely the code itself. It is the practices around it: who reviews changes, how data is protected, how a bad release is rolled back and who notices when something breaks.

Security starts in the database

In a Supabase-based app, the browser talks to the database with a publishable key. Supabase's documentation is explicit that this key is safe to expose and that Row Level Security decides what each client can reach. If a table has no RLS policy, or a policy that is too broad, anyone holding the key can read or change data the interface never shows. Secret and service role keys bypass RLS entirely and must never reach the browser or the repository.

This is not a theoretical concern. CVE-2025-48757, published in May 2025, describes insufficient RLS policies in Lovable-generated sites through April 15, 2025. Lovable disputes the CVE on the grounds that each customer is responsible for protecting their application's data. Whatever your view of the dispute, the practical conclusion is the same: the responsibility sits with you. Lovable now scans at publish and offers a deeper scan, but its own documentation says these tools cannot guarantee complete security and recommends a professional review for sensitive data.

Review what lives in the project history as well. In April 2026, The Register reported a researcher's claim that any free Lovable account could read other users' source code, database credentials and AI chat histories on projects created before November 2025. Lovable said it had not suffered a data breach and that code in public projects was visible by design, later apologized for how it first handled the issue, and said a February permissions change had accidentally re-enabled access to chats on public projects, which it reverted. Treat any key that was ever pasted into a prompt or committed to code as exposed: rotate it and move it to server-side secrets.

• RLS enabled on every table, with policies tested from a second user account
• Authorization checks in server-side functions, not only in the interface
• Secrets only on the server, rotated after the review
• Dependencies checked for known vulnerabilities

Environments, releases and data changes

When you publish, Lovable deploys a snapshot of the project. That is convenient, but production needs a path where changes are tested before users see them. Lovable's documentation says the Test and Live split in Lovable Cloud was retired on October 5, 2026. Drafts let you preview app changes before publishing, but they do not provide a second database, and the docs warn against relying on publishing to migrate data. In practice, this means a separate staging backend, for example a second Supabase project, with its own data and keys.

Schema changes should live as migrations in the repository and run the same way in staging and production. Add a CI/CD pipeline that installs, builds and runs tests on every change, protect the main branch, and require review for anything that touches authentication, payments or data. Start testing with the flows that would hurt most if they broke, such as sign-up, permissions and billing.

Backups need the same care. Lovable Cloud keeps a daily database backup for roughly 14 days, a restore rolls back both schema and data and cannot be undone, and files in storage buckets are not included. Decide how much data loss the business can accept, add an independent export if needed, and rehearse a restore before you need one.

Operations, cost and the exit path

Production also needs visibility. Add error tracking for the frontend and server functions, structured logs, uptime checks and alerts that reach a person. Review slow queries and indexes as data grows, and watch costs: Lovable Cloud, AI features and managed connectors consume workspace credits, and any external hosting is billed separately.

Plan the exit path while things are calm. Git sync gives you the source and migrations, but not data or secrets. Lovable's documentation notes that moving the PostgreSQL database alone does not move authentication, storage, realtime or Edge Functions, that there is no one-click migration from Lovable Cloud to your own Supabase project, and that the Lovable editor itself cannot be self-hosted. Staying on Lovable can be the right choice. The point is to know what leaving would take.

Privacy and compliance belong here too: know where personal data is stored, which processors handle it and which agreements apply, and confirm the current answers with Lovable and Supabase.

A practical path: assess, secure, stabilize, then scale

The order matters. Every feature built on an unreviewed foundation makes later fixes more expensive.

• Assess: connect GitHub, run the app locally, map tables, policies, functions, secrets and integrations, and list what the business depends on.
• Secure: enable and test RLS on every table, move secrets to the server, rotate exposed keys and add server-side authorization checks.
• Stabilize: add staging, migrations, CI/CD, tests for critical flows, error tracking, backups and a written release process.
• Scale: improve performance and cost, refactor the parts that slow the team down and keep developing on the stable base.

Questions to ask before launch

If any answer is unclear, treat it as work to schedule before real users and real data arrive.

• Who owns the repository, and who can approve a production release?
• Can a logged-in user read or change another user's records through the API?
• Where are secrets stored, and were any of them ever pasted into a prompt?
• Can we test a change against staging data without touching production?
• How do we roll back a bad release, and when did we last restore a backup?
• Who is alerted when errors spike, and what does an hour of downtime cost?
• What would it take to move off Lovable Cloud if we had to?

How a dedicated engineering partner approaches it

UVISION has taken long-term responsibility for business-critical software since 2012, and we approach an AI-built application like any system we take over. We assess first: the code, the data model, the access rules, the release process and the business flows that depend on them. We keep what works, since much of what Lovable generates is a reasonable starting point, and fix the risky parts before adding scope.

Then we keep developing. Every project has at least one full-time developer who knows the system, working either as a dedicated developer inside your team or within a managed engineering engagement where we own delivery. We do not commit to timelines or outcomes before the assessment, because they depend on what the assessment finds.