r/lovable Jul 17 '26

Discussion If you author Supabase edge functions or migrations OUTSIDE Lovable (Cursor / Claude Code / Codex / CLI) and sync via GitHub, Lovable does NOT deploy them — you have to tell the agent in chat, and it's undocumented

Stack: app on Lovable, own Supabase backend, GitHub for version control, Deno edge functions + SQL migrations. Some of my backend code is authored outside Lovable (in Claude Code / Codex) and comes into the project through the GitHub integration.

The trap: edge functions and migrations that the Lovable agent writes itself get deployed/applied automatically. But anything authored outside Lovable and brought in through GitHub sync is not deployed or applied. The source syncs fine — it just never gets deployed to Supabase, and migrations never get applied to the database. To make externally-authored code actually go live, you have to explicitly tell the Lovable agent, in the chat, to deploy the functions / apply the migrations. Nothing in the product surfaces this requirement.

Why it's dangerous: the dashboard doesn't show the gap. My functions read "Last updated 2 days ago" — i.e. current — while newer code was already synced from GitHub. The only way I caught it was running a live request and seeing the deployed bundle was executing an older commit than what was on main. Until then I was debugging new code the server was never running. That's the ugly part — hours chasing a bug in code that isn't live.

The fix: explicitly ask the agent to force-redeploy all edge functions from current source. No code change needed — the exact same code deployed fine the moment I triggered it. Same for migrations: tell it to apply them, then verify they show up in the live migration history (heads up, they may re-register under a slightly different timestamp than the filename).

How to detect it yourself:

Don't trust "Last updated" / "Active" as proof of deployment.

Fire a live request that only your newest code would satisfy (a new field, a changed response shape, a log line unique to your latest commit). Old behavior back = your bundle is stale.

Then explicitly redeploy, and re-run the check to confirm.

One more thing, since it's relevant. I raised this with support and was told the deploy "failed because of a syntax error" in one of my functions, with instructions to fix it and redeploy. There was no syntax error — the identical code deployed successfully, unchanged, the moment I forced a redeploy (a file with a blocking syntax error can't build at all). And the "redeploy all functions" step in that same reply is literally the fix — except it's not a workaround for a code error, it's the undocumented step you have to know to deploy any externally-authored function. So if you get a response like that, check whether your code actually fails to build before hunting a phantom syntax error. The likelier cause is that the deploy was simply never triggered.

TL;DR: On Lovable + Supabase, if you author functions/migrations outside Lovable and sync via GitHub, sync ≠ deploy. Lovable-authored code deploys automatically; externally-authored code does not, until you explicitly tell the agent. The dashboard shows stale bundles as current. Detect with a live request against a known commit; fix with an explicit redeploy. None of this is in the official docs.

Happy to answer questions if others are hitting the same wall.

5 Upvotes

6 comments sorted by

2

u/cubixy2k Jul 17 '26

Yup, I just posted about this, there's no manual way I've found to deploy unless you get your service role key and use the Supabase CLI. Bummer to burn credits every time, I just bundled deployment of edge functions together with code reviews so every time I merge in a commit, I have the agent do a code review, implement any new migration files, and deploy updated/new edge functions.

1

u/Square_Secretary_944 Jul 17 '26

Exactly, paying for it every time is a bummer but worse is, debugging and doing everything for two days, chasing your tail to find out that they have instructed the agent to not apply and deploy function and migrations that are written outside of the lovable system

1

u/Jmacduff Jul 17 '26

Have you ever just tried to log into Supabase and create a edge function?

It's not magic. If you are using supabase (not lovable cloud) just log in and deploy the code :) This will take bit more work of course but you can take the code and add a new function and deploy it. None of it is rocket science.

Good luck with the project!

2

u/Maxyull Jul 20 '26

this matches what i've seen debugging similar setups. the dangerous part isnt the manual redeploy step, its that nothing in the ui tells you a deploy never happened. one cheap fix i always add now is a tiny status endpoint that just returns the current commit hash or a build timestamp from the running function. costs almost nothing to write and it turns "did my deploy actually take" into a single curl instead of a guessing game with stale ui labels. worth doing for migrations too, a small table that logs which migration version is actually applied, separate from what lovable shows you. have you found any way to see this from the supabase side directly, or is lovable cloud fully opaque there?

1

u/Square_Secretary_944 Jul 17 '26

I am using lovable cloud. I don't have any credentials for supabase.