How to deploy a Lovable app when you outgrow Lovable hosting

Lovable is the fastest way to go from a sentence to a working app, and its built-in hosting means you never think about deployment — until the day you do. Maybe you need a background job. Maybe you want your own Postgres instead of the bundled stack. Maybe you just looked at the subscription tier required to keep your app online and did the math.

The good news: Lovable exports clean, portable code. This is the complete path from Lovable hosting to your own deployment, without giving up the Lovable editor.

What Lovable actually generates

Under the hood, a Lovable app is a Vite + React frontend, usually with Supabase for data and auth. That's a completely standard stack — nothing about it requires Lovable's hosting. (Our Vite + React deploy guide covers the stack in detail.)

The one thing to know before migrating: Vite environment variables (VITE_*) are baked in at build time, not read at runtime. Whatever host you move to needs those set before the build runs, not after.

Step 1: Export to GitHub

In Lovable, click GitHub → Connect and let it create a repository. This is a real two-way sync — you keep editing in Lovable, and every change lands as a commit.

This matters more than it sounds: you're not leaving Lovable, you're separating where you build from where you host.

Step 2: Deploy the repo

git clone https://github.com/you/your-lovable-app && cd your-lovable-app
npm i -g @launchmatic/cli
lm login
lm init
lm deploy

Launchmatic detects the Vite build automatically. One production note: vite preview isn't a production server. Add a static server with SPA fallback so deep links survive a refresh:

{
  "scripts": {
    "build": "vite build",
    "start": "serve -s dist -l $PORT"
  },
  "dependencies": { "serve": "^14" }
}

The free tier gives you a service, a 1 GB Postgres, and an SSL-secured *.launchmatic.app URL — no credit card. (Free services sleep after 30 idle minutes and wake on request; $9/mo keeps a site always-on.)

Step 3: Decide what to do about Supabase

You have two clean options, and mixing them is fine:

• Keep Supabase. Your VITE_SUPABASE_URL and anon key are build-time env vars. Set them (lm env set VITE_SUPABASE_URL=...) and redeploy. Auth, storage, and data keep working exactly as before. You've changed hosting, nothing else.
• Move to your own Postgres. lm db create app-db --service <serviceId> provisions a managed database and injects DATABASE_URL. This makes sense when you start adding server-side code that Supabase's client model doesn't fit.

Most people keep Supabase for auth and move compute. There's no penalty for the hybrid.

Step 4: The thing Lovable hosting can't do — add a backend

The usual reason people outgrow builder hosting isn't cost, it's the first feature that needs a server: a webhook receiver for Stripe, a scheduled job, an API that talks to a third party with a secret key. On Launchmatic that's just a second service in the same repo:

lm monorepo init   # binds web + api as separate services
lm up              # deploys both

Your Lovable frontend and your hand-written (or Claude Code-written) backend deploy side by side, each with its own URL and logs.

Step 5: Custom domain

lm domains add yourdomain.com

Add the DNS record it prints; a Let's Encrypt certificate issues automatically.

Keep the Lovable loop

Because the GitHub sync is two-way, the workflow after migration is:

1. Edit in Lovable → it commits to GitHub.
2. Launchmatic sees the push → redeploys automatically.
3. Branch pushes get preview URLs (Pro tier), so experiments never touch production.

You gave up nothing. You gained a backend, your own database options, and hosting whose pricing doesn't depend on your builder subscription.

For the bigger picture — how this fits the general playbook for shipping AI-built apps — see the vibe coding hosting guide, or jump straight to the Lovable deploy guide for the condensed version.