Take your Lovable app off the hosted plan and onto infrastructure you own
Lovable produces a real React application against a real Postgres database, which makes this the most tractable migration on this page.
- Typical timeline
- 2–4 weeks for a typical app
- Pricing
- Fixed quote after a free Production Check
- Rollback
- Written, rehearsed, and executed by you before handover
What staying on Lovable actually costs
Not a list of features you are missing. These are the four things that reliably turn into an incident, an invoice, or a lost deal.
- 01
One database has been serving three purposes
Development, staging, and production almost always point at the same Supabase project on a Lovable app.
- 02
The security model is one policy away from public
The anon key ships in the browser by design and identifies a Postgres role, not a person.
- 03
Editor-driven deploys have no history
Changes made in the builder go live without a commit, a review, or a diff.
- 04
Costs and limits arrive together
Hosted plans price per editor seat and per project. As the team and the number of environments grow, the seat cost grows faster than the infrastructure it replaces - while the platform limits you were not thinking about (row counts, function invocations, egress) become the reason a feature cannot ship.
The sentences we hear most, and what we do about each one
These are paraphrases of things founders have actually said on scoping calls. The left column is the experience; the right column is the work.
"I was told my app is secure because it has login"
Authentication and authorization get conflated constantly, and builders reinforce the confusion: there is a working login screen, so security feels handled.
How we helpWe enumerate every table, write the policy each one should have, and then prove it - a test suite that logs in as three different users and asserts that each sees only their own rows.
"Something changed and I cannot work out what"
With no version control, the state of the app is whatever the editor last wrote.
How we helpThe codebase moves into git with a real history from the first commit onward, and every subsequent change lands through a pull request with a preview environment. "What changed on Thursday" becomes a two-second answer.
"My app got slow and I do not know which part"
Lovable-generated data fetching is correct and unbounded - components select entire tables because at demo scale that is indistinguishable from correct.
How we helpWe profile against a production-sized dataset, add the indexes the query plans actually ask for, and introduce pagination on the paths that are unbounded.
"If I hire a developer, they will not want to touch this"
This fear is well founded and it is often what triggers the call.
How we helpHandover is a deliverable. Tests around the invariants that matter, a README that describes what the app does and how to run it, environments that exist, and a pipeline that stops a bad change before it ships.
Component by component, before and after
Every line is a decision we will walk you through, and every one of them is written down in the handover documentation.
| Today | becomes | After the migration | Why it matters |
|---|---|---|---|
| Lovable-hosted frontend | Your Vercel, Netlify, or container deployment from git | Same React application, deployed from a repository you own, with preview environments per branch. | |
| Shared Supabase project | Separate development, staging, and production projects | Or self-hosted Supabase where data residency or cost makes that the better answer. | |
| Generated row-level security policies | Policies written per table and covered by tests | Every policy asserted against at least two user identities, plus an anonymous one. | |
| Service-role key reachable from the client | Privileged work behind edge functions, keys rotated | The old key is revoked as part of cutover, not left to expire. | |
| Editor-driven deploys | GitHub Actions with migrations applied in order | Schema changes become reviewable files instead of invisible edits. | |
| No backups you have tested | Point-in-time recovery with a rehearsed restore | We restore into a scratch project during handover so you have seen it work. |
Four phases, each with something you can hold
Scope is fixed after phase one. Every phase ends in artefacts you keep, whether or not you continue to the next.
- 013–5 days
Production Check
The free audit comes first here, because on a Lovable app the security findings usually change the scope of everything else.
You receive
- Row-level security review, table by table
- Secret and key exposure scan, including git history
- Query plan and index review against real data volumes
- Prioritised remediation plan with effort estimates
- 023–5 days
Split the environments
Development, staging, and production become separate projects with separate data and separate credentials.
You receive
- Three environments with seeded, non-production data below production
- Migrations captured as ordered, reviewable files
- Per-environment secrets, with production readable by nobody but production
- 035–10 days
Close the security findings
Policies are rewritten table by table and covered by tests. Privileged calls move server-side.
You receive
- Policy test suite asserting cross-tenant isolation
- Privileged operations moved behind server-side functions
- All exposed credentials rotated and the old ones revoked
- 043–5 days, plus 30 days support
Deploy, instrument, hand off
The app ships from git to infrastructure you own, with monitoring, error tracking, and documentation.
You receive
- CI/CD with preview environments and one-command rollback
- Error tracking, uptime monitoring, structured logs
- Architecture documentation and runbook
- 30 days of post-launch support
What can go wrong, and what stops it
We would rather write these down than discover them together. Each one is a real failure mode from a real migration, with the control that prevents it.
Rotating keys breaking the running app
Rotation is sequenced: new credential issued, deployed, verified, then the old one revoked.
A new policy locking out legitimate users
Every policy change ships with tests that assert both denial and access.
Losing the ability to keep editing in the builder
Where keeping the builder as a design surface is realistic, we set that up and document the boundary.
Before you book the call
Often yes, as a design and prototyping surface, with production shipping from git.
No, and usually you should not. Supabase is an excellent production database when it is configured like one.
The honest answer is that most Lovable apps we audit have at least one table any visitor can read.
Related migrations
Bolt.new → production
Bolt gets a full-stack app running in an afternoon and it is genuinely good at that. The gap between "runs in the Bolt preview" and "runs in production for paying users" is remarkably consistent across projects, which is convenient: it means the work is known before we start.
Read the planBase44 → your own cloud
Base44 builds working internal tools and SaaS quickly, and the questions that follow are always about ownership: where the data lives, who can reach it, and what happens on the day the platform is no longer the right fit.
Read the planReplit → AWS
Replit is the fastest way to get from an idea to a running app, and a genuinely bad place to leave one once people depend on it.
Read the plan
Thinking about moving off Lovable?
The scoping call is free, and it ends with a straight answer about whether it is worth doing yet.