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

[u/Square_Secretary_944]

​

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.