How to host a Lovable app outside Lovable in 2026

Why people leave Lovable hosting

Lovable is the easiest AI app builder for non-developers in 2026. The hosting bill is where the story gets interesting.

Three things tend to push Lovable users toward an alternative host.

Credits keep ticking even after the app is built. Lovable Pro is $25/month, which buys you 100 monthly credits plus 5 daily (150 total). Every AI generation — even a button color tweak — burns 0.5 credits. Users in the Lovable subreddit regularly post about burning 100+ credits fixing a single stubborn AI error. Once your app stops needing daily AI changes, you're paying $25/month for capacity you don't use.

Custom domain requires Pro. Free tier ships on the .lovable.app subdomain with Lovable branding. Custom domain unlocks at Pro. If your app is finished and you're not iterating, you're still paying $25/month just to keep your domain.

Lovable Cloud is "optimized for previews and prototypes," by their own docs. The phrase appears in Lovable's own documentation. For a finished product handling real traffic, the deploy story is meant to be "export and host elsewhere" — which is exactly what this guide walks through.

The complication: Lovable apps are tightly coupled to Supabase. The frontend is portable. The backend needs a plan. The rest of this guide is the plan.

The three paths off Lovable hosting

Same shape as the other AI builder migrations — three workflows, three trade-offs.

Path A: Keep Lovable for AI, move just the host

The most popular path for active builders. Keep Lovable Pro for AI iteration. Sync the project to GitHub via Lovable's bi-directional integration. Deploy the frontend on a cheaper host. Keep using Lovable's managed Supabase backend so the integration stays clean.

The result. AI iteration loop stays the same, but the production frontend lives on livemy.app or a similar host. Custom domain at $20/month flat instead of $25/month plus credit metering.

Trade-off. Still paying Lovable Pro while you're iterating. The savings kick in when iteration slows — you can drop Pro and keep the app running on the cheaper host indefinitely.

Path B: Export the ZIP, host both frontend and your own Supabase

The cleanest full ownership path. In Lovable, click Export, choose Download ZIP (or push to GitHub via the integration). Set up your own Supabase project (free tier is generous), migrate the schema and data over, update the connection strings in the exported code.

The result. You own the code, you own the database, your monthly bill is just the host plus Supabase (free for small apps, $25/month if you outgrow free tier).

Trade-off. One-way migration. Once you've moved off Lovable's managed Supabase to your own instance, Lovable can no longer sync changes back. Future AI iteration in Lovable becomes "generate code, manually merge into your repo" — a real workflow change.

Path C: Full self-host, including self-hosted Supabase

For builders who want every piece on their own infrastructure. Same as Path B for the frontend, but instead of Supabase Cloud you run Supabase on your own server (Docker, or via a host that supports Supabase self-hosting like Fly.io or Coolify).

The result. Complete stack ownership. Your code, your database, your infrastructure. Lowest possible monthly cost at scale.

Trade-off. Real DevOps work — you're managing Supabase upgrades, backups, security patches. Worth it for serious products at scale; overkill for a small app that just wants to be cheap.

For most non-developers, Path A is the right answer until iteration slows. Then graduate to Path B. Path C is for the small minority of apps that need full infrastructure control.

From Lovable to a live URL on livemy.app (about 3 minutes)

Whether you went Path A or Path B, the livemy.app flow is the same. Here it is end-to-end.

Step 1: Get your code out of Lovable

Two options. The fastest: in your Lovable project, click ••• menu → Export → Download ZIP. The cleaner long-term option: click the GitHub icon, connect your GitHub account, push the project to a new repo. GitHub is better if you'll keep iterating in Lovable (Path A); ZIP is fine for a one-shot migration.

Step 2: Decide on Supabase

Before you deploy, decide which Supabase instance the new host will talk to.

• Path A (keep Lovable's Supabase): grab the Supabase URL and anon key from your Lovable project's settings. You'll paste them as environment variables in step 4.

• Path B (your own Supabase): create a new Supabase project at supabase.com (free tier). Use Supabase's import tool to migrate the schema and data from your Lovable-managed instance. Grab the new URL and anon key.

• Path C (self-hosted Supabase): spin up Supabase on Docker or via your chosen self-host platform. Migrate schema + data. Use the self-hosted URL and keys.

Step 3: Sign up at livemy.app

Go to livemy.app, click Start free. No credit card. You land in my.livemy.app — the dashboard.

For testing the deploy, Free is enough. For production hosting with real visitors, pick Maker ($20/month) before going live. Free-tier projects sleep after 60 minutes of inactivity — fine for a demo, not for a real product.

Step 4: Upload the ZIP (or connect the GitHub repo) and set env vars

In the dashboard, click New project → Upload archive and drop the Lovable ZIP. livemy.app auto-detects Vite + React + TypeScript and configures the build. If you went GitHub, click Connect repo, authorize once, pick the repo.

Under Project Settings → Environment Variables, add the two variables every Lovable app needs:

• VITE_SUPABASE_URL — from step 2

• VITE_SUPABASE_ANON_KEY — from step 2

Plus anything else your Lovable app reads via import.meta.env — third-party API keys, auth provider tokens, Stripe keys.

Step 5: Deploy and check the live URL

livemy.app runs the Vite build, provisions a container, gives you a your-app.livemy.site URL. Typical time: 2 to 5 minutes for a Lovable-sized project. Build log streams live in the dashboard.

Open the URL. Sign up with the auth flow. Confirm the data reads and writes are working. If anything is broken, jump to Troubleshooting below.

Step 6: Point your own domain at it

Click Add custom domain, paste your domain, update one DNS record at your registrar. Cloudflare, Namecheap, GoDaddy — all support this in their DNS settings. Within 1–10 minutes the DNS propagates, automated SSL SSL fires automatically, your domain serves HTTPS.

That's the flow. Your Lovable app is now on livemy.app at $20/month flat, your domain works, your Supabase is wherever you chose, your bill is predictable.

Five things that quietly break Lovable apps in production

Lovable makes a lot of decisions for you while building. Those defaults travel out of Lovable Cloud in unhelpful ways.

1. Supabase migration is one-way

The single most important thing to understand about leaving Lovable's managed Supabase. Once you move to your own Supabase instance, Lovable can no longer sync changes back to your project. The bi-directional GitHub sync still works for code edits, but the database is now disconnected.

Implication. If you want to keep iterating in Lovable after the move, keep using Lovable's managed Supabase (Path A) and just move the frontend. If you've decided to fully own the stack, accept that future code changes happen in your IDE, not in Lovable.

2. Row Level Security (RLS) policies travel — but you have to test them

Lovable generates Row Level Security policies on your Supabase tables. When you migrate schema + data, the RLS policies come with it — but the policies were designed against Lovable's auth provider, and small differences in how your new auth setup issues tokens can silently break them.

Fix. After migration, log in as a real user and try every CRUD operation in the app. If reads or writes fail with permission errors, inspect the RLS policy on the affected table and verify the JWT claims your new auth provider issues match what the policy expects.

3. Generated code is verbose — don't "clean it up" before deploying

Lovable's AI generates code that is more verbose than what a human would write. Helper functions are duplicated, some utilities feel redundant, file organization follows Lovable conventions. The temptation when migrating is to refactor.

Resist the temptation on the first deploy. Get the verbose code working on the new host first. Then refactor incrementally with the safety of a deployed baseline. Migrating + refactoring at the same time is how you ship a broken app.

4. The auth flow is integrated late — retrofitting hurts on a new host

A common Lovable workflow is to build the UI first and add Supabase Auth toward the end. On Lovable Cloud, this is fine because the integration is wired automatically. On a new host, you may discover protected routes that don't check authentication, role logic that runs client-side only, or token refresh that wasn't tested.

Fix. Before going live on the new host, audit the auth flow end to end: sign-up, sign-in, protected routes, role checks, token refresh, sign-out. If any of those depended on Lovable Cloud's environment, fix them now.

5. Environment variables are loaded differently in Vite

Lovable apps use Vite. Vite-style env vars prefix with VITE_ for anything exposed to the browser. Anything without that prefix only exists at build time. Lovable handles this for you on its own host — on a new host, you have to add every VITE_-prefixed variable explicitly.

Fix. In Lovable, open the project's environment panel. Copy every variable name and value. Paste each one into Project Settings → Environment Variables on livemy.app (or your chosen host). Don't forget the non-public ones if your code uses them — they need to be there too, just without the VITE_ prefix where appropriate.

Cost: Lovable Cloud vs livemy.app for one production app

Honest bill comparison for a finished, custom-domain, modestly-used Lovable app.

Lovable Pro is $25/month and bundles AI generation (150 credits/month) plus hosting on Lovable Cloud (custom domain, no branding). For an actively iterating app, you're paying $25/month for both the AI capacity and the hosting.

livemy.app Maker (Path A): keep Lovable Pro at $25/month for iteration + livemy.app Maker at $20/month for the host. Total: $45/month while iterating, $20/month once iteration slows and you drop Lovable Pro.

livemy.app Maker + self-Supabase (Path B): $20/month livemy.app + Supabase free tier (or $25/month Supabase Pro if you outgrow free). Total: $20–45/month depending on Supabase usage, fully owned.

The math for most non-developers:

• If you iterate daily with Lovable AI: stay on Lovable for the AI, run frontend on livemy.app for the host. $45/month combined.

• If your app is finished and you've stopped iterating: drop Lovable Pro, just pay livemy.app $20/month. Keep using Lovable's Supabase (no migration required if you stayed on Path A) or move to your own Supabase free tier.

• If you're scaling up and credits are eating your budget: Path B (own Supabase) gives you predictable infrastructure costs that don't scale with AI iteration.

Troubleshooting: what to check first when the Lovable migration breaks

Four failure modes account for the bulk of "my Lovable app works in Lovable, doesn't work on the new host" tickets.

Build fails on missing VITE_SUPABASE_URL or VITE_SUPABASE_ANON_KEY. The environment variables aren't set on the new host. Open Lovable's project environment panel, copy each value, paste into Project Settings → Environment Variables on livemy.app.

App loads but every database call returns empty arrays. Almost always an RLS policy mismatch. Check the JWT your auth flow issues against the RLS policy's conditions. If the user's role or org_id claim doesn't match what the policy expects, the query returns zero rows with no error.

Sign-up succeeds but sign-in fails (or vice versa). Lovable's auth flow assumed certain Supabase Auth settings; your new Supabase instance may have different defaults. Check email confirmation requirements, redirect URLs, and JWT expiration settings on the new Supabase project.

Routes work in preview, 404 on deploy. Vite SPA fallback not configured. livemy.app auto-detects Vite and handles this. If you're on a different host, ensure SPA mode is enabled or a _redirects file with /* /index.html 200 exists in public/.

Got something else? Email hello@livemy.app with the build log and the failing endpoint. Replies inside one business day.

FAQ

Can I host a Lovable app outside Lovable Cloud?

Yes. Lovable apps export as standard React + Vite + TypeScript projects via the ••• menu → Export → Download ZIP, or via the GitHub integration. The exported code runs on any host that supports Node.js builds — livemy.app, Netlify, Cloudflare Pages, Render, Railway, Fly.io, or your own server.

What about Supabase — do I have to migrate it too?

Not necessarily. You have two options: keep Lovable's managed Supabase and just move the frontend (Path A above), or migrate to your own Supabase instance for full ownership (Path B). The first is faster and reversible; the second is permanent (Lovable can no longer sync back after you move off the managed Supabase).

Will I lose Lovable AI iteration if I move hosting?

Only if you move to your own Supabase. If you stay on Lovable's managed Supabase and just move the host (Path A), Lovable's bi-directional GitHub sync still works — you keep iterating in Lovable, the changes deploy to your new host. If you move off the managed Supabase, the database disconnects and future code changes happen in your IDE, not in Lovable.

What's the cheapest way to host a Lovable app with a custom domain?

For non-commercial side projects: Cloudflare Pages with a free Supabase tier and your own domain (around $10–15/year for the domain). For real production with predictable pricing and always-on uptime: livemy.app Maker at $20/month flat with custom domain and free SSL, plus Supabase free tier or $25/month Pro if you outgrow it.

Why does my Lovable bill keep going up?

Credit consumption. Lovable Pro includes 150 credits/month; every AI generation — even small changes — burns some. Users frequently report 100+ credits disappearing while debugging a single AI error. The fix is either to slow down iteration (and stop burning credits) or to move hosting off Lovable so you're paying only when the AI is actually adding value.

Is the Lovable export production-ready?

The code runs. Lovable's docs themselves describe Lovable Cloud as "optimized for previews and prototypes," which is honest. The exported code is verbose compared to hand-written React, but functional. For a production deploy: get it running on a real host first, then refactor incrementally if needed. Most non-developer apps don't need to refactor at all.

Move off Lovable hosting — about as long as a coffee

If you've already exported your Lovable project as ZIP or pushed to GitHub, you're one upload + two environment variables away from a live URL on your own domain, at $20/month flat — no credit metering, no Lovable branding, custom SSL.

→ Start free on livemy.app · No credit card · Free tier forever · Pay nothing until you're ready for production hosting.

Stuck on the Supabase migration step or hitting one of the RLS gotchas? Email hello@livemy.app with the build log and the failing endpoint. Replies inside one business day.

Read next

• Bolt vs Lovable vs v0: which AI app builder ships fastest in 2026

• How to deploy a Bolt.new app to production in 2026

• How to deploy a v0 app to production in 2026

• How to self-host n8n in 2026: the complete guide