The TanStack Backend Map: Where Your Lovable Backend Code Actually Runs Now

Two builders hit my support queue this week with the same confused face. One asked Lovable for a webhook and got a URL on his app's domain instead of his Supabase project URL. The other migrated off Lovable and watched his chatbot time out, because the endpoint he thought lived in Supabase never actually lived there.

Both were running into the same thing: since early August, in TanStack Start projects, the Lovable agent no longer creates Supabase edge functions. It creates server routes inside your app instead. Nothing in the changelog, no modal, no warning. Your backend code just started being born in a different place.

Neither of them was doing anything wrong. They just didn't have the map. So here it is.

The two places your backend code can live

Every Lovable project with a backend has two possible homes for server-side code, and they are very different animals. If you take one thing from this article, take this map.

New to these words? An edge function is a small piece of server code that Supabase hosts and runs for you, on its own URL, separate from your app. A server route is the same idea, a piece of server code, but it lives inside your app and runs wherever your app runs. Both exist for the same reason: sensitive work (API keys, payments, talking to other services) should happen on a server, never in the user's browser.

	Supabase edge function	TanStack server route
Runs on	Supabase's servers, independent from your app	Your app's SSR server, on Lovable hosting
Its URL	yourproject.supabase.co/functions/v1/hook	yourapp.lovable.app/api/hook
Lives in your repo	supabase/functions/	src/routes/api/
Lifecycle	Keeps running even if your Lovable app is paused	Lives and dies with your app
Portability	Goes wherever your Supabase goes	Deploys automatically with every publish

Both can hold secrets safely, because both run on a server, away from the browser. Both can talk to your database. The difference is not capability. The difference is whose lifecycle your endpoint is married to.

What changed in August

Around August 7, builders on TanStack Start projects started noticing that the Lovable agent refuses to create new files under supabase/functions/. Ask it for a webhook, an API endpoint, a background job, and it will build you a TanStack server route instead, and hand you a URL on your app's domain.

This is a platform-level policy, not the agent being moody. One builder confirmed it with a diagnostic prompt: the agent itself reports that the block is enforced by the platform, that there is no flag to bypass it, and that server routes are the supported path. A moderator is tracking it, and there is a feature request filed for an opt-in flag.

To be precise about what is and is not blocked:

Action	Still works?
Agent edits an existing edge function	Yes, unchanged
Agent creates a new edge function (TanStack)	No, it redirects to a server route
You create the file yourself, agent fills it in	Yes, this is the workaround
Supabase deploying and running edge functions	Yes, Supabase changed nothing

Edge functions are not dead. The agent just lost permission to give birth to them. A function created any other way is still a first-class citizen.

One honest caveat on scope: this is confirmed on TanStack Start projects connected to your own Supabase. I have not yet confirmed whether Classic (Vite) projects or Lovable Cloud projects behave the same way. If you have a specimen, my DMs are open.

How it actually affects you

1. Your URLs change. External services you configured against yourproject.supabase.co/functions/v1/... expect that URL to exist. The agent now only offers you yourapp.lovable.app/api/.... For a Stripe webhook, a CRM integration, or anything with an allowlist, that is not a cosmetic difference.

2. Your endpoint's lifespan is now your app's lifespan. A server route runs inside your app. If the app pauses, say your workspace hits zero credits, the endpoint goes down with it. An edge function in your own Supabase keeps answering no matter what is happening on the Lovable side.

3. Your backend stops being neutral, and yes, that is a notch more lock-in. An edge function travels with your Supabase: if you ever leave Lovable, it keeps running untouched, because Supabase is its home. A server route's code is still yours (TanStack is open source and your repo exports cleanly), but its running home is Lovable's hosting, so leaving now also means re-homing every endpoint. And if you ever want a mobile app or a second frontend calling the same API, that API now lives inside one specific web app instead of in an independent backend layer.

4. Version-controlled backend workflows break. If you treat supabase/functions/ as the source of truth and deploy with GitHub Actions, new functions simply stop being born there.

Should your endpoint be an edge function or a server route?

The short answer: if the endpoint only serves your web app and it is fine for it to sleep when the app sleeps, a server route is simpler and deploys itself. If anything external depends on it, payments, webhooks, another client, or it must survive your app being paused, it belongs in an edge function on Supabase.

Your situation	Use	Why
Internal API for your own app's UI	Server route	Same lifecycle as the app, zero extra infra
Payment or webhook receiver	Edge function	Must stay up independently of the app
API shared with a mobile app or another frontend	Edge function	Backend stays neutral, one API for all clients
Scheduled jobs, background processing	Edge function	Runs on Supabase (pg_cron + functions), app-independent
Quick server-side call with a secret key	Server route	Secrets stay server-side either way, this is the low-friction path

The scenario that decides it: your store's Stripe webhook lives in a server route. Your workspace runs out of credits on a Saturday and the app pauses. Stripe sends payment events to an endpoint that no longer answers. With an edge function on your own Supabase, those events land no matter what your credit balance is doing. If money flows through the endpoint, that is the whole decision.

The workaround: edge functions in TanStack, still possible

The block applies to creating files, not editing them. So you create the file outside Lovable, and the agent takes it from there. Confirmed working by the builder who first hit this:

1. Anywhere except Lovable (GitHub's web editor, Claude Code, Cursor, Codex, a Codespace), create the empty file at the path you need: supabase/functions/my-webhook/index.ts
2. Commit and push, and let it sync back into your Lovable project.
3. Now ask the Lovable agent to implement the function. Editing an existing file is allowed, so it fills it in normally.
4. Your function deploys to Supabase as always, with its functions/v1 URL.

And if you want the agent to confirm the situation from its own mouth before you touch anything, paste this. It costs one message and changes nothing:

Diagnostic only, change nothing. Is the block on creating files
under supabase/functions/ a platform policy? Is there a supported
way to create a new edge function through you? One short answer.

My honest take

For most builders, this change is genuinely good. One runtime, one mental model, endpoints that deploy with the app, secrets server-side without touching Supabase config. It also quietly kills an entire class of bugs I have documented for months, where backend code authored outside Lovable synced to the repo but never deployed. With server routes, what is in the repo is what runs.

For the smaller group that treats Supabase as an independent, version-controlled backend, it is a real regression, and they are exactly the users who know what they are doing.

The direction is defensible. Removing the choice without an escape hatch is the part I would push back on, and the community already is: the feature request for an opt-in flag exists because good defaults need escape hatches. Simple by default, powerful when asked. That is what mature platforms do.

Quick answers

Can Lovable still create Supabase edge functions? In TanStack Start projects, the agent no longer creates new edge function files. It still edits existing ones, and a file you create manually in the repo can be filled in and maintained by the agent normally.

Did Supabase change anything? No. This is a Lovable agent policy. Supabase deploys and runs edge functions exactly as before.

Are TanStack server routes less secure? No. They run on a server, so secrets stay out of the browser, same as an edge function. The differences are lifecycle, URL, and portability, not security.

Does this affect my existing edge functions? No. Everything already in supabase/functions/ keeps working and remains editable. Only the creation of new files there is blocked.

Is this more vendor lock-in? A notch, yes. Your code still exports (TanStack is open source), but new endpoints now run on Lovable's hosting instead of in your portable Supabase layer. The workaround above keeps new functions in the portable layer if that matters to you.