Built with Lovable? Own the hosting.

Deploy your Lovable app on SnapDeploy

Connect the GitHub repo Lovable already made for you. We detect the stack — the classic Vite app and the new TanStack Start server build — name the Supabase variables you need before the first build, and keep your app on your own domain.

Four steps

1 · Lovable → GitHub

In Lovable, connect the project to GitHub (Project settings → GitHub). Lovable pushes every edit to that repo.

2 · Connect + pick

In SnapDeploy, connect GitHub once, click Deploy, choose the repo.

3 · Paste your keys

The wizard has already scanned the code and lists the exact VITE_SUPABASE_* names, with where to find each value.

4 · Live

Build runs, URL appears. Push in Lovable again and it redeploys automatically.

Both Lovable stacks, detected automatically

Classic Lovable (Vite + React)

Built as a single-page app and served by Nginx with SPA routing. The output folder (dist) is detected — no configuration. This is the stack most hosts still document.

New Lovable (TanStack Start)

Projects on @lovable.dev/vite-tanstack-config are built with the Nitro node-server preset and run as a real server app on port 3000 — server routes and all. Most hosts treat these as static sites and fail.

Your Supabase keys, asked for before the build — not after a blank page

SnapDeploy scans the repo for import.meta.env usage and lists the variables it needs (typically VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY) with a note on where each lives in the Supabase dashboard. They are applied at build time, so the compiled app has them from the first deploy.

Never put the Supabase service-role key in a VITE_ variable — it would ship to every visitor's browser. SnapDeploy fails the build on purpose if a public-prefixed name looks like a secret.

Day-2 checklist: make login work on the new URL

The #1 thing that breaks after moving any Lovable app off lovable.app. Five minutes, once.

  1. Supabase dashboard → Authentication → URL Configuration: set Site URL to your SnapDeploy URL (or your custom domain).
  2. Same page → Redirect URLs: add https://your-app.containers.snapdeploy.app/** (and your custom domain). Keep the old one until you're done migrating.
  3. Using Google/GitHub sign-in? In that provider's console, make sure the authorized origins/redirects include the new site where the provider references your domain (the Supabase callback URL itself doesn't change).
  4. Emails (magic links, resets) use Site URL — send yourself one to confirm it lands on the new host.
  5. Moving to your own domain later? Add it in SnapDeploy → Domains, then repeat steps 1–2 for it.

What it costs

Free
Up to 4 containers · 100 hours/month · sleeps after ~15 min idle, wakes on the next visit · 10 deploys/day (5 per rolling 12 h)
Always-On from $12/month
Per container. Never sleeps, no hour cap, no deploy limit. Medium (2 GB) $25, Large (4 GB) $45.
$1 Sprint Pack
24 hours awake + unlimited deploys — demo day, launch day.

Managed Postgres, Redis and RabbitMQ add-ons and custom domains are available on every tier. India: UPI, cards, net banking. International: PayPal. Full pricing.

Which Lovable stack do you have? (30-second check)

Open package.json in the repository Lovable created for you and look at the dependencies:

You see lovable-tagger

Classic Lovable: Vite + React + TypeScript, Tailwind, shadcn/ui, usually a src/ folder with pages and components. It compiles to a static dist/ folder and is served like any single-page app.

You see @lovable.dev/vite-tanstack-config

New Lovable: TanStack Start, a server-rendered React framework built on Vite and Nitro. It has server routes and loaders, it produces a Node server, and it is not a static site — which is why hosts that assume "Vite = static" show a blank page or a missing-index error.

Either way you do nothing: SnapDeploy reads the same markers and picks the right build. If you have restructured the project by hand, the supported technologies page lists what the detector looks for.

What SnapDeploy does at build time, per stack

Classic (Vite SPA)TanStack Start
Buildvite build; the output folder (dist) is detectedBuilt with the Nitro node-server preset — a real server bundle, not an export
RuntimeNginx with single-page-app fallback, so deep links and browser refresh work on any routeNode process on port 3000; server routes, loaders and API handlers run server-side
Env varsVITE_* baked in at build timeVITE_* baked in for the client; server-only variables read at runtime
Node versionDetected from engines, .nvmrc or the lockfile (18, 20, 22…)
Typical buildOne to three minutes; the hard limit is sixty

Environment variables for a Lovable + Supabase app

VariableWhere to find itNotes
VITE_SUPABASE_URLSupabase → Project Settings → API → Project URLRequired; public
VITE_SUPABASE_PUBLISHABLE_KEYSame page — the publishable (anon) keyRequired; public by design (row-level security protects the data). Older exports call it VITE_SUPABASE_ANON_KEY — the scan tells you which name your code reads
VITE_SUPABASE_PROJECT_IDProject Settings → GeneralSome exports read it; set it if the scan lists it
service-role keyNever in a VITE_ variable: it would ship to every visitor's browser. SnapDeploy fails the build on purpose if a public-prefixed name looks like a secret

VITE_ variables are compiled into the bundle, so changing one later means a redeploy — one click on the container page, or "redeploy my-app" from an assistant. Details: environment variables.

Keep building in Lovable — every edit redeploys

Lovable's GitHub integration is two-way: edits in the Lovable editor are pushed to the repository, and commits made elsewhere sync back into Lovable. SnapDeploy installs a webhook on the repository when you link it, so every push to the deploy branch starts a new build automatically. You never leave the Lovable editor to ship, and the deployment history shows each push with its commit message.

Want a staging copy? Link a second branch to a second container. Want to stop auto-deploys temporarily? Unlink the repository on the container page; re-link when ready.

Your own domain, with the Supabase step people forget

  1. Container page → Domains → add app.yourdomain.com. SnapDeploy shows the DNS records to create.
  2. Create them at your registrar; verification is automatic and the certificate is issued for you — free SSL on every tier.
  3. Back in Supabase → Authentication → URL Configuration: set the Site URL to the new domain and add https://app.yourdomain.com/** to Redirect URLs. Skip this and sign-in still bounces to the old address.
  4. If you use Google or GitHub sign-in, check that the provider's console lists the new origin wherever it references your domain.

Guide: custom domains.

Troubleshooting a moved Lovable app

SymptomCauseFix
Blank page, console says supabaseUrl is requiredVITE_SUPABASE_* was not set before the buildSet the variables, redeploy (they are baked in at build time)
Sign-in returns to lovable.app, or the magic link opens the old siteSupabase only redirects to allow-listed URLsSite URL + Redirect URLs in Supabase → Authentication → URL Configuration
404 when refreshing a deep linkStatic hosts without SPA fallbackNot on SnapDeploy: classic apps are served with SPA routing; TanStack apps route server-side
Build fails with "Missing required environment variables"The scan found required variables you skippedAdd them on the container page and redeploy
App is slow the first time after a breakFree containers sleep after ~15 minutes idle and wake on the next request (about a minute)Expected on the free tier; Always-On ($12/month) never sleeps, a $1 Sprint Pack keeps it awake for a day
Realtime / WebSocket features drop on the free tierSleeping containers cannot hold open connectionsSupabase Realtime connects to Supabase, not your container, so it is unaffected; apps that serve their own WebSockets need Always-On

More: troubleshooting guide. If your project's backend is Lovable Cloud rather than a Supabase project you created, check Lovable's documentation for how to reach the underlying project's URL and keys before moving the front end.

Further reading

Frequently asked questions

How do I deploy a Lovable app to SnapDeploy?

In Lovable, connect your project to GitHub. In SnapDeploy, connect GitHub, pick the repository and deploy. SnapDeploy detects whether it is a classic Vite single-page app or the newer TanStack Start server build, builds it accordingly, and lists the VITE_SUPABASE_* variables it needs before the first build.

Does SnapDeploy support the new Lovable TanStack Start stack?

Yes. Projects using @lovable.dev/vite-tanstack-config are built with the Nitro node-server preset and run as a real server-side app on port 3000 — not a static export. Classic Lovable Vite apps are served as single-page apps with the output folder detected automatically.

Why does login break after moving my Lovable app to a new host?

Supabase only accepts auth redirects to URLs you have allow-listed. Add your SnapDeploy URL as the Site URL and to Redirect URLs under Supabase → Authentication → URL Configuration, and update any OAuth provider settings that still reference the old lovable.app domain.

What does hosting a Lovable app cost on SnapDeploy?

The free tier covers up to 4 containers, 10 deploys a day (5 per rolling 12 hours) and 100 hours a month, with auto-sleep after about 15 minutes idle. Always-On keeps an app running 24/7 from $12 per month per container; a $1 Sprint Pack keeps one awake for 24 hours.

Do I have to stop using Lovable?

No. Lovable keeps pushing every edit to the GitHub repository and SnapDeploy redeploys on each push, so you keep building in Lovable and only the hosting moves.

Does my Supabase database move too?

No. Supabase stays exactly where it is; the app keeps talking to it with the same URL and publishable key. Nothing is migrated — only the front end (and, for TanStack Start, its server) runs on SnapDeploy.

Can I deploy a private repository?

Yes. Connecting GitHub grants SnapDeploy the standard repo scope, so private repositories build like public ones.

Can I deploy from Claude Code or Cursor instead of the dashboard?

Yes. The SnapDeploy MCP connector runs the same detection and env-var scan from chat: "deploy my Lovable repo" returns a live URL. See Deploy from Claude Code and the MCP docs.

Prefer to deploy from chat?

SnapDeploy's MCP connector works in Claude Code, Cursor and Codex/Gemini CLI: "deploy my Lovable repo" → live URL, with the Supabase variable scan built in.

Keep building in Lovable. Host it where you own it.

First deploy free · no credit card

Deploy your Lovable app