Skip to main content
Stackbastion

Draft, not yet published

Exporting your Lovable app and self-hosting it: a real walkthrough

7 July 2026· 5 min read · by Stackbastion

Your Lovable app works, you have real users, and now you want off the platform’s hosting and onto infrastructure you control. Maybe it’s cost, maybe it’s a compliance requirement, maybe you just want your database somewhere you can back it up properly. The good news: Lovable doesn’t trap your code. The catch: exporting the frontend is the easy 20%, and the backend is the other 80% nobody warns you about.

Here’s the real walkthrough, both halves.

Why this happens on Lovable

Lovable is two things bolted together. There’s the frontend it generates, a normal Vite or Next.js app in a real Git repository, and there’s the backend it provisions for you, which is almost always a Supabase project handling your database, authentication, and any edge functions.

When people say “export my Lovable app,” they usually picture the frontend. That part is clean: Lovable syncs to GitHub, you clone the repo, and you have standard code you can host anywhere. But the frontend is useless without the backend it talks to. Your data, your auth users, your row-level security policies, and your edge functions all live in that Supabase project. Self-hosting properly means taking both, and the backend is where the actual work is.

Understanding that split is the whole game. Skip the backend and you’ve “exported” a shell that still depends on infrastructure you don’t control.

How to fix it

Step 1: get the frontend out via GitHub.

In Lovable, connect the project to GitHub if you haven’t, then push. Clone it locally:

git clone https://github.com/your-username/your-lovable-app.git
cd your-lovable-app
pnpm install
pnpm run build   # confirm it builds clean before you go further

If it builds, the frontend half is portable. Note every environment variable it reads, usually a Supabase URL and anon key. You’ll repoint these at your own backend later.

Step 2: decide what “self-host the backend” means for you.

You have two honest options. One, keep using Supabase’s hosted platform but as your own project you fully control, which is the low-effort path. Two, run Postgres and the auth layer yourself, which is real self-hosting and more work. This walkthrough covers the second, because that’s what people usually mean by getting off the platform.

Step 3: export the database.

Get a full logical dump of your existing Supabase database, schema and data together:

pg_dump "postgresql://postgres:[PASSWORD]@[HOST]:5432/postgres" \
  --no-owner --no-privileges \
  --format=custom \
  --file=lovable-db.dump

The --no-owner and --no-privileges flags matter: they strip Supabase-specific role ownership so the dump restores cleanly onto a Postgres instance with different roles.

Step 4: stand up your own Postgres.

On your own server, run Postgres 17 in Docker. A minimal compose service to get started:

services:
  db:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: app
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    ports:
      - "5432:5432"

Then restore your dump into it:

pg_restore --no-owner --no-privileges \
  --dbname="postgresql://postgres:${DB_PASSWORD}@localhost:5432/app" \
  lovable-db.dump

Step 5: handle the parts Postgres alone doesn’t cover.

This is the step that surprises people. Supabase isn’t just Postgres. Your app probably relies on Supabase Auth, the auto-generated REST API (PostgREST), and maybe Storage and edge functions. Plain Postgres gives you none of those. You have two realistic choices:

  • Run the Supabase stack yourself with their self-hosting Docker setup, which gives you GoTrue for auth, PostgREST for the API, and the rest, all pointed at your Postgres.
  • Replace those pieces with your own small backend, which is a bigger rewrite but removes the dependency entirely.

For most people leaving the platform but not the tooling, self-hosting the Supabase stack is the sane middle path. Your auth.users table came across in the dump, so accounts and password hashes are preserved when GoTrue points at the restored database.

Step 6: repoint the frontend and add backups.

Update the frontend’s environment variables to your new backend URL and anon key, rebuild, and deploy. Then, before you call it done, set up backups. This is the reason many people self-host in the first place, so don’t skip it. Continuous archiving with point-in-time recovery is covered in our backup and restore tutorial, and the restore test matters more than the backup.

Step 7: verify auth actually works.

Log in as a real user against the new backend. If existing accounts authenticate and RLS still restricts rows correctly, your migration held. If logins fail, it’s almost always the JWT secret: GoTrue needs the same signing secret your tokens were issued with, or every existing session breaks.

Or, we do it for you

Migrating the frontend is a weekend. Migrating the backend without losing an auth user or a row is where people lose a week and their nerve. Our Rescue service does the full lift: database, auth, edge functions, and tested backups, with a rollback plan if anything goes sideways.

FAQ

Can I just export the frontend and leave the database on Supabase?

Yes, and that’s a legitimate lighter option. Keep the Supabase project as your own, host the frontend on your infrastructure, and point it at the hosted backend. You get control of the frontend and the code without the harder backend migration. You just don’t get full independence, and your data still lives on someone else’s platform.

Will my users’ logins survive the migration?

They can, if you carry two things across: the auth.users table, which comes in your database dump, and the JWT signing secret. Existing password hashes restore fine. The common failure is a mismatched JWT secret, which invalidates every active session and can look like “auth is broken” when it’s really just a config value.

Do I lose my row-level security policies?

No. RLS policies live in the database, so they come across in the pg_dump. After restore, re-run an audit to confirm every policy transferred and still points at the right roles, because a migration is exactly the kind of change that quietly drops one.

Is self-hosting cheaper than staying on Lovable?

Sometimes, but not always, and cost is usually not the best reason on its own. A small Hetzner server plus your time can undercut platform pricing at scale, but you’re now the operations team. The stronger reasons are control, proper backups, and compliance requirements you can’t meet on shared platform hosting.

Related posts