How to connect your own Supabase instead of Lovable Cloud
Yes, Lovable lets you connect an external Supabase project instead of using Lovable Cloud. You provide your Supabase project URL and anon key in Lovable's Supabase settings, and your app talks to your own Postgres, auth, and storage from that point on.
Last updated
Yes, Lovable lets you connect an external Supabase project instead of using Lovable Cloud. You provide your Supabase project URL and anon key in Lovable's Supabase settings, and your app talks to your own Postgres, auth, and storage from that point on. Lovable Cloud is a managed backend that Lovable hosts for you. Supabase is the same kind of stack, self-hosted or in Supabase's own cloud, that you own and control.
Can you still connect Supabase to Lovable?
Yes, and you could from early on. Lovable's Supabase integration is a first-class feature, not a workaround. In your Lovable project, there is a Supabase settings panel where you paste your Supabase project URL and your anon public key. Once connected, Lovable's generated code uses those credentials to talk to your Supabase project for auth, database queries, and storage.
The exact location of that settings panel has moved between versions of Lovable's editor, so if you cannot find it, look in the project-level settings or integrations section rather than in the chat. Lovable's own documentation is the authority on where the panel sits in the current editor version, and that is one place this page will not pretend to know better than the source.
If the connection fails, the most common causes are straightforward. The Supabase project URL must be the full https://<project-ref>.supabase.co form, not just the project reference. The anon key is the public anon key from your Supabase project's API settings, not the service role key. If you have Row Level Security enabled on your tables, you need policies in place or the connection will succeed but queries will return empty results, which looks like a connection failure but is not one.
Does Lovable Cloud replace Supabase?
Functionally, Lovable Cloud gives you a managed Postgres database, authentication, and file storage, which is the same surface Supabase provides. The difference is where it runs and who controls it. Lovable Cloud runs on Lovable's infrastructure. You do not see the Postgres instance, you do not get a database password, and you cannot point another tool at it.
Supabase, whether you use Supabase's hosted cloud or self-host it, gives you a Postgres database with a direct connection string, a dashboard for managing tables and policies, and the ability to migrate or back up your data yourself. If you leave Lovable with Lovable Cloud as your backend, your data is in Lovable's system. If you leave Lovable with your own Supabase connected, your data is already in a project you own, and the move is just code. This is the same question people ask when their Lovable plan runs out, and the answer is the same: what you own is what leaves with you. If you are already thinking about that, /learn/what-happens-after-my-lovable-plan covers the full picture.
How to change from Lovable Cloud to Supabase?
If you started with Lovable Cloud and want to switch to your own Supabase, the practical path is to create a Supabase project, set up the same table structure your app expects, and then connect that Supabase project in Lovable's settings. Lovable Cloud does not have a one-click migration to an external Supabase project. You are creating the target and pointing the app at it.
The hard part is the data. If your app has been running on Lovable Cloud and has real user data, you need to export that data and import it into your Supabase project. Lovable Cloud's data export options are something to check in Lovable's current documentation, because what is available and how it works has changed. If there is no clean export, you may need to recreate the schema in Supabase and write a migration script. This is the moment where "I'll switch later" becomes expensive, which is why connecting Supabase from the start is the advice most people wish they had followed.
What comes with you when you leave Lovable?
Lovable exports your project as a GitHub repository. That repository contains your frontend source, your component code, your build configuration, and any Supabase integration code. That is real source code, not a proprietary format, and you can run it anywhere that runs a Node application.
What does NOT come with you: the Lovable Cloud database and its data, unless you already moved it to your own Supabase. The environment variables you set in Lovable's dashboard, which you will need to recreate wherever you deploy next. The preview and staging URLs Lovable generated for you, which are Lovable's domain and stop resolving when you leave. The build pipeline, which is Lovable's and not yours. And the AI chat context, which is the conversation that built your app and cannot be transferred to another tool.
Is it better to use Lovable Cloud or Supabase?
If you want to ship something fast and never think about a database, Lovable Cloud is less work. You click, it works, you do not manage anything. If you plan to grow the project, leave Lovable eventually, or need direct access to your Postgres for reporting, migrations, or another tool, connect your own Supabase from the first day. The cost of connecting Supabase early is twenty minutes of setup. The cost of migrating data out of Lovable Cloud later is unknown and depends on what export Lovable offers at that point.
Who should NOT move to a self-hosted setup?
If you want a landing page and never want to see infrastructure again, a hosted builder is the right answer and a self-hosted cluster is the wrong one. Owning the runtime means owning the maintenance. A Kubernetes cluster you control is freedom, but it is also a thing that needs updates, backups, and somebody awake when a node stops responding. If that sentence sounds like work you do not want, stay hosted. There is no shame in that, and pretending otherwise is how people end up with a cluster they cannot fix at 2am.
On my-app.engineer, an app lands in a K3s cluster you own, deployed as a Helm release, with a Postgres database if the app needs one. You describe the app in chat, agents build and deploy it, and the source is a real repository you could run anywhere Docker runs. If you already have a Supabase project, the agents wire the app to it the same way any code would, by reading the connection details from environment variables. The cluster is yours from the first deploy, which means leaving here is a helm uninstall and a repository you take with you, not a platform you escape from. If that ownership model is what you were looking for when you started asking about Supabase, /learn/ai-app-builder-self-hosted-kubernetes-tutorial walks through the full path.