How to Deploy a Lovable App to Your Own Host (2026): Both Stacks, Supabase Keys, and the Day-2 Auth Fix

Lovable is a great place to build. It is a less great place to be locked in. Every Lovable project can push to a GitHub repository you own — and once it does, you can host it anywhere. This guide is the "anywhere" part, done properly: both Lovable stacks, the environment variables you must set before the first build, and the one Supabase setting that breaks login on every new host.

Before you start: a two-minute checklist

• Your Lovable project is connected to GitHub (Project settings → GitHub) and the repository shows recent commits from Lovable.
• You can open the Supabase dashboard for the project the app uses — you will need the Project URL and the publishable key.
• You know whether the app uses Google/GitHub sign-in (there is a provider step later if it does).
• A SnapDeploy account — free, no credit card — with GitHub connected once.

Step 0 — What Lovable actually put in the repo

It helps to know what you are deploying. A Lovable export is an ordinary Vite project: package.json with a build script, src/ with pages and shadcn/ui components, Tailwind config, and a supabase/ folder when the project has migrations or edge functions. There is no .env in the repo — Lovable injects the Supabase values at its own build time, which is exactly why they are the first thing you must supply on a new host. TanStack Start exports add server routes and a Nitro config; you will see @lovable.dev/vite-tanstack-config in the dependencies.

First, which Lovable stack do you have?

Lovable changed its default project template in 2026, and the two generations deploy very differently. Open your repo's package.json:

• Classic Lovable — you'll see lovable-tagger and a plain Vite + React setup. It builds to a static dist/ folder and is served like any single-page app.
• New Lovable (TanStack Start) — you'll see @lovable.dev/vite-tanstack-config. This is a server-rendered app built with Nitro. It is not a static site, and most hosts that treat it as one fail with a blank page or a missing-index error.

SnapDeploy detects which one you have and builds accordingly: classic apps go to Nginx with SPA routing (output folder detected automatically), TanStack apps are built with the node-server preset and run as a real Node server on port 3000. You don't configure any of it.

Step 1 — Connect Lovable to GitHub

In Lovable, open your project settings and connect GitHub. Lovable creates a repository under your account and pushes every edit to it. From now on, GitHub is the source of truth — Lovable writes to it, your host reads from it.

Step 2 — Connect GitHub to SnapDeploy and pick the repo

Sign in to SnapDeploy, connect GitHub once (it uses the standard repo scope), click Deploy and choose the Lovable repository. Leave the build settings alone — detection handles the stack.

Step 3 — Set your Supabase variables before the first build

This is where most first deploys die on other hosts: the app builds fine, then shows a blank page because VITE_SUPABASE_URL was never set. Vite bakes VITE_* variables into the bundle at build time, so setting them after the build changes nothing until you rebuild.

SnapDeploy scans the repo for import.meta.env usage and lists the exact names it needs — typically:

• VITE_SUPABASE_URL — Supabase dashboard → Project Settings → API → Project URL
• VITE_SUPABASE_PUBLISHABLE_KEY (older projects: VITE_SUPABASE_ANON_KEY) — same page, the public/anon key

Paste the values, deploy. The build takes a couple of minutes and you get a URL like https://your-app.containers.snapdeploy.app.

Step 4 — The day-2 auth fix (login breaks on every new host)

Your app loads, you click Sign in, and either nothing happens or you get bounced back to the old lovable.app domain. That is Supabase doing its job: it only redirects to URLs you have allow-listed. Fix it once:

1. Supabase → Authentication → URL Configuration. Set Site URL to your new URL.
2. Add https://your-app.containers.snapdeploy.app/** to Redirect URLs. Keep the old entry until you're fully moved.
3. Using Google or GitHub sign-in? The Supabase callback URL itself doesn't change, but check the provider console for any authorized origin that still names the old domain.
4. Send yourself a magic link or password reset — those emails use Site URL, so this confirms step 1 took.

Step 5 — Your own domain

Add the domain in SnapDeploy → Domains, create the DNS records it shows you, verify. SSL is automatic. Then repeat step 4 for the new domain. Lovable keeps pushing to GitHub; SnapDeploy keeps redeploying on push — you never leave the Lovable editor to ship.

Step 6 — Keep editing in Lovable; every push redeploys

Lovable's GitHub integration is two-way: edits in the editor are pushed to the repository, and commits made elsewhere sync back. SnapDeploy installs a webhook when you link the repository, so every push to the deploy branch starts a new build. The deployment history on the container page shows each push with its commit message, its duration and — if it failed — the error and the last lines of the build log. Nothing about your Lovable workflow changes; only where the app is served.

Two useful variations: link a second branch to a second container for a staging copy, and unlink the repository if you ever want to pause auto-deploys.

Troubleshooting the first hour

• Blank page; console says supabaseUrl is required. The VITE_SUPABASE_* variables were not set before the build. Set them, redeploy.
• Sign-in loops or lands on lovable.app. Step 4 above — Supabase Site URL and Redirect URLs.
• A route 404s on refresh. That is a static host without SPA fallback. SnapDeploy serves classic apps with SPA routing and TanStack apps server-side, so you should not see it here.
• Build fails with "Missing required environment variables". The scan found variables you skipped; add them on the container page and redeploy.
• First request after a quiet spell is slow. Free containers sleep after about 15 minutes idle and wake on the next request in around a minute. Always-On never sleeps; a $1 Sprint Pack keeps a free container awake for 24 hours for demo day.
• Realtime features. Supabase Realtime connects to Supabase, not to your container, so it is unaffected by sleep. Apps that serve their own WebSockets need Always-On.

Why bother moving at all?

Three reasons come up again and again. Your domain, your certificate — a product on lovable.app looks like a prototype. Operational visibility — runtime logs, deployment history, resource metrics, the ability to pin a Node version or add a Dockerfile when the app outgrows the template. No hosting lock-in — the repository is yours, the build is standard Vite or Nitro, and the same repo deploys anywhere; SnapDeploy just happens to get both Lovable stacks right on the first try and to ask for the Supabase keys before the build rather than after a blank page.

What it costs

The free tier covers up to 4 containers and 100 container-hours a month; free apps sleep after about 15 minutes idle and wake on the next visit. Always-On keeps an app running 24/7 from $12 a month per container; a $1 Sprint Pack keeps one awake for 24 hours when you're demoing. Managed Postgres, Redis and RabbitMQ add-ons and custom domains are available on every tier.

Prefer to do all this from chat?

SnapDeploy's MCP connector works in Claude Code, Cursor, Codex and Gemini CLI: "deploy my Lovable repo" gets you the same detection, the same env-var scan and a live URL in the reply. See Deploy from Claude Code or the MCP docs.

Frequently asked questions