DEV Community: Aakash

Lovable Cloud to Supabase Migration Checklist

Aakash — Sun, 04 Oct 2026 01:13:21 +0000

Most Lovable Cloud to Supabase migration guides stop at "dump the database, restore it, change two env vars." That part takes an afternoon. The bugs show up a week later, when a user taps "Continue with Google" and nothing happens.

So we built the checklist we wished existed, and then turned it into a free migration checker that reads your project's GitHub repo and tells you what your specific app needs. This post is the reasoning behind it.

What actually lives in a Lovable Cloud project

Lovable syncs your project to GitHub, and the backend is all there if you know where to look. supabase/migrations/ has every schema change as a timestamped SQL file. supabase/functions/ has your edge functions, one folder each, plus a _shared folder if Lovable got organized. supabase/config.toml has the project ref and, more importantly, any function that runs with verify_jwt = false. And src/integrations/supabase/types.ts is the generated type file, which doubles as a list of every public table even when the migrations are incomplete.

That last part matters more than it sounds. Migrations drift. If someone ever changed a column from the Cloud UI and Lovable didn't write a migration for it, your repo is lying to you about the schema. Before trusting the SQL files, compare them against a real pg_dump --schema-only of the Cloud database. It is the first thing we run on every migration.

The boring part (that still needs doing in order)

Extensions first. If a migration does create extension if not exists pg_trgm you're fine, but plenty of projects lean on pg_cron and pg_net that were switched on from a dashboard and never written down. Then the schema, then functions and triggers, then data, in that order. Triggers on auth.users deserve special attention: the classic handle_new_user that creates a profiles row has to exist before the first signup on the new project, or you get users with no profile and a frontend that crashes on null.

Copy the auth schema too. People forget that users don't live in public. Dump auth.users and auth.identities with their password hashes and your users log in with the same password on the new project. Skip it and every single user has to sign up again, which is a great way to lose half of them.

Storage is the annoying one. The Supabase dashboard can't move files between projects in bulk, so you either script it against the storage API or point rclone at both projects' S3 endpoints. Buckets have to be recreated with the same names and the same public or private setting, and the policies on storage.objects come along only if they were in a migration.

Three things that break after the switch

We ran the checker against three public Lovable Cloud repos while building it. All three call Lovable's AI gateway. Two of the three sign users in with Google through Lovable's own OAuth. That's the pattern.

Google sign-in goes through Lovable

Newer Lovable projects ship a file at src/integrations/lovable/index.ts that imports createLovableAuth from @lovable.dev/cloud-auth-js. The login button calls lovable.auth.signInWithOAuth("google"), Lovable's broker does the OAuth dance with Lovable's Google client, and then hands your app a Supabase session.

Move the database to your own project and that broker has nothing to hand tokens to. You need your own OAuth client in Google Cloud Console, the provider enabled under Authentication in Supabase, the callback URL set to your new project, and the frontend switched to plain supabase.auth.signInWithOAuth. It's maybe an hour of work. Finding out from a user that login is broken is worse.

The AI features go quiet

Edge functions that read LOVABLE_API_KEY and post to ai.gateway.lovable.dev only work inside Lovable Cloud. Off it, they fail on the first call. The fix is boring: pick a provider, get a key, set it with supabase secrets set, and change the URL and model name in the function. The trap is that nobody tests the "summarize this" button during a migration.

Signup emails never arrive

On a fresh Supabase project the built-in email service only sends to members of your own team. Everyone else gets Email address not authorized, and even for your team it's limited to a couple of emails an hour. Lovable Cloud hides this because it handles email for you. Set up custom SMTP before you switch traffic. We use Resend because the DNS setup takes ten minutes, but Postmark is just as good.

The cron job nobody remembers

One of the repos we tested was a personal finance app that syncs bank data every night. The sync runs from pg_cron, which calls an edge function over HTTP with net.http_post, and that function has verify_jwt = false and checks a shared secret header instead. Perfectly reasonable design. But the cron job has the old project's URL baked into the SQL. Restore it as-is on a new project and it keeps calling the old one every night, quietly, until the Cloud project is deleted and the sync just stops.

That's the kind of thing a checklist exists for. Grep your migrations for cron.schedule and supabase.co before you call it done.

How the checker works (and where it's dumb)

The migration checker runs in your browser. It pulls the file list from GitHub, downloads the migrations, functions and app code, and pattern-matches them. No database connection, no .env, nothing sent to us. It only works on public repos because it uses GitHub without logging in.

It parses SQL with regular expressions, not a real parser. That's a trade-off we'd make again: it's fast and has no dependencies, and Lovable's generated SQL is very regular. It can't see anything changed from the Cloud dashboard that never made it into a migration, and odd SQL formatting can slip past it. Treat its output as the checklist, not the audit.

If you'd rather hand the whole thing off, we do Lovable Cloud to Supabase migrations at a fixed price, and you keep building in Lovable afterwards.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Apple Rejected Your Lovable App Under 4.2. Now What?

Aakash — Sat, 03 Oct 2026 02:57:28 +0000

"Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience."

If you're reading this, you've probably got that sentence sitting in App Store Connect right now, under Guideline 4.2 - Design - Minimum Functionality. You wrapped your Lovable app in Capacitor or some "website to app" service, paid the $99 developer fee, waited two days, and Apple said no.

You're in good company. This is the single most common rejection we see on Lovable apps, and it's not random. The reviewer opened your app, saw your website with the browser chrome removed, and did exactly what the guideline tells them to do.

What the reviewer is actually checking

Apple doesn't ban WebViews. Plenty of approved apps render big chunks of their UI in one. What they reject is an app where the WebView is the product, and nothing about it uses the phone.

In practice the reviewer spends maybe two or three minutes in your app. A few things make it look like a website instantly:

a hamburger menu instead of a tab bar
a "Sign up" page that opens Safari for the magic link and never comes back
pull to refresh doing nothing, or worse, reloading the whole page with a white flash
the same cookie banner and footer links you have on the web

One founder we worked with had been rejected three times. Each time they changed something cosmetic, a new icon, a splash screen, a different app name. The fourth submission had the same WebView with the same footer that said "© 2026, view our website". Rejected in 40 minutes.

What gets an app through

You don't need to rebuild everything. You need enough native surface that the reviewer can tell it's an app. Usually that's three or four of these, done properly:

Push notifications that do something. Not "allow notifications?" on launch with nothing behind it. An actual notification when the thing the user cares about happens, which opens the right screen when tapped.

Native navigation. A real tab bar for the three to five main sections. This alone changes how the app feels more than anything else on this list.

Device features. Camera for uploads, Face ID sign-in, haptics on key actions, share sheet, offline handling. Pick the ones that fit your product. A habit tracker with a home screen widget reads as an app. A habit tracker in a WebView reads as a bookmark.

Auth that stays in the app. Magic links need Universal Links set up so they open your app, not Safari. And if you offer Google login, Apple will also want Sign in with Apple. That's a separate rejection (Guideline 4.8) but it tends to show up on the same submission.

When you resubmit, say what changed in the Review Notes. Short and specific: "Added native tab navigation, push notifications for new messages, camera upload, and Sign in with Apple." Reviewers read those notes. A vague "fixed issues" gets you the same reviewer making the same call.

The honest trade-off

Could you keep patching a wrapper until it passes? Sometimes, yes. We've gotten Capacitor apps approved by adding push, a native tab bar and a couple of plugins.

But we've also watched people spend a month fighting review on a wrapper and then hit the next wall: the app feels slow, scroll is janky on older Android phones, and the 1-star reviews say "it's just the website". At that point a proper Flutter or React Native build that talks to the same Supabase backend is often less work than the next round of patches. The backend, the database and the business logic you built in Lovable all stay. Only the screens get rebuilt.

Which way makes sense depends on what your app does and how much of it is really mobile. A booking tool people use twice a month? A good wrapper might be fine. Something people open daily on their phone? Build it native.

If your app is stuck in review right now, send us the rejection message and your Lovable link. We'll tell you whether it's a two-day fix or a rebuild, and if your backend still lives on Lovable Cloud, whether to move it to your own Supabase first.

Originally published on lovable2app.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Lovable Cloud vs Supabase: Which Should Your App Run On?

Aakash — Fri, 02 Oct 2026 15:45:28 +0000

Half the Reddit threads on Lovable Cloud vs Supabase are arguing about the wrong thing. People compare them like two databases. They're the same database. Lovable Cloud is a Supabase project that Lovable creates and runs for you, inside their account, billed through your Lovable balance. Your own Supabase is a Supabase project in your account, billed by Supabase.

Same Postgres. Same auth. Same storage buckets and edge functions. What changes is who holds the keys and who sends the invoice, and that turns out to matter a lot more than people expect in week one.

What you actually give up on Cloud

When a founder sends us a Cloud project to look at, the first thing we ask for is the database connection string. They go looking for it, and there isn't one. That's the whole comparison in a nutshell.

On Lovable Cloud you don't get:

the Supabase dashboard (no table editor outside Lovable, no logs explorer, no auth settings page you control)
the service_role key, which a lot of "how do I run a cron job" or "how do I connect Zapier" tutorials assume you have
a Postgres connection string, so no pgAdmin, no TablePlus, no pg_dump on a schedule
your own plan choice for compute, disk or point-in-time recovery

You do get a SQL editor inside Lovable, and the agent can create tables and write migrations for you. For building, that's honestly enough. For running a business on it, it gets thin fast.

Pricing, as far as anyone can tell

Supabase publishes a rate card. Free tier: 500 MB database, 1 GB file storage, 50,000 monthly active users, and the project pauses after a week of inactivity, which is fine for experiments and terrible for anything with customers. Pro is $25 a month per organization and includes an 8 GB database, 100 GB of storage and 100,000 MAU, with usage billed beyond that. You can open the usage page and see exactly which line is growing.

Lovable Cloud is usage-based and drawn from your Lovable balance. What Lovable doesn't give you is the same per-unit breakdown. You see the balance move. We've had two clients this year who were sure their AI features were eating their Cloud usage, and in both cases it was something boring (one was an edge function on a 1-minute schedule polling a third-party API that never changed, the other was image uploads at full resolution).

So "which is cheaper" depends on your app, and the honest answer for a small app is that nobody can tell you up front. For an app with real traffic, owning the Supabase project is almost always cheaper to reason about, which is what you actually want when you're the one paying.

When we'd tell you to stay on Cloud

Plenty of cases. If you're still validating the idea, if nobody else needs database access, if your data is small and you'd shrug at losing a day of it, stay. Cloud is genuinely faster to start with. One click and you have auth and a database, and you're not juggling two dashboards.

We'd also say stay if the only reason you want to move is a vague feeling that "real apps use Supabase". That's not a reason. Move when you hit a wall.

The walls people actually hit

These are the ones we see, roughly in order of how often:

A second developer needs access. A freelancer asks for the connection string or wants to run migrations from their own machine. On Cloud there's nothing to hand over.
Backups. Someone deletes a row they shouldn't have and asks "can we restore yesterday?" On your own Pro project you have daily backups, and point-in-time recovery is an add-on. On Cloud you're asking support.
Integrations that need the service role key. n8n, Make, a cron worker on Railway, a nightly export to Google Sheets. All of them want a key with admin rights.
The bill. Usually not the size of it, just not being able to explain it to a co-founder.
Compliance questions. A B2B customer sends a security questionnaire asking where data is hosted and who has access. "Inside Lovable's account" is an awkward answer.

If two of those are true for you, it's time.

How hard is the move, really

Not hard, but fiddly. Lovable now lets you export your Cloud data and switch the project to a Supabase project you own, from the Cloud settings, and you keep building in Lovable afterwards exactly like before. The schema and rows come across cleanly.

The fiddly part is everything around the rows. Storage files have to be moved separately. Secrets arrive as names with no values, so every Stripe key and API token gets pasted in again. Google and GitHub OAuth providers get set up from scratch, including the redirect URLs, which is where most DIY migrations stall for an evening. And user passwords. Depending on how the export is done, your users may need to reset them, so write that email before you start.

We did one last month for a booking app with 23 tables and about 4,000 users. The data moved in under an hour. The OAuth redirect for Google took longer than the data, because the client's custom domain was set up on a www subdomain in one place and the apex in another. That kind of thing.

If you want to see what the move involves for your app, the Cloud to Supabase migration page lists exactly what we move and what breaks, and how we work explains the access we need. Or skip the reading and book a call.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.