July 25, 2026·7 min read

Lovable Hosting: Export Your App's Code and Run It Anywhere

Miget Team

Lovable will host your app for you, and for a prototype that is the right default. People start looking elsewhere for three reasons: hosting draws down the same credit balance you want to spend on building, a growing app eventually wants real infrastructure (custom domains, predictable cost, your own database), and some teams simply need the code to live inside their own perimeter.

Here is the part many Lovable users do not realize: exporting does not mean leaving. Lovable's GitHub integration is a two-way sync - changes you make in the Lovable editor push to GitHub, and commits you push to the active branch sync back into Lovable. You can keep prompting in Lovable and host the result anywhere. And the code is unambiguously yours: Lovable's own FAQ says you can export it "and do whatever you'd like with it."

This guide walks through exporting and self-hosting a Lovable app, for both generations of the Lovable stack. Disclosure: we run Miget, a flat-rate hosting platform, and the deploy steps use it - but the export steps are universal, and the same repo will run on any host that can serve a Node process or static files.

Step 1: Know which stack you have

Lovable changed its generated stack on May 13, 2026:

Projects created after May 13, 2026 use TanStack Start with server-side rendering. These are Node applications - they need a server at runtime, not just a static file host.
Older projects use React + Vite - a classic single-page app that builds to static files.

Check package.json in your export: @tanstack/react-start in dependencies means SSR; vite with plain react means SPA. Both use Tailwind for styling, and the backend runs on Lovable Cloud (Supabase-based), a Supabase you connected, or third-party APIs.

Step 2: Export via GitHub

In Lovable: connect your GitHub account (workspace-level authorization), then link the project to a repository. From that moment the repo is the source of truth you can clone:

git clone git@github.com:you/your-lovable-app.git
cd your-lovable-app
npm install
npm run dev

If it runs locally, you are most of the way done. (A zip download from the code editor works too, but you lose the two-way sync - use GitHub.)

Step 3: One backend fact that saves you a migration

Your frontend host and your backend are independent. The exported app talks to Lovable Cloud or Supabase over HTTPS with a project URL and a publishable key - it does not care where the frontend is served from. Moving your hosting does not require moving your backend. Deploy the frontend anywhere, keep the backend exactly as it is, and everything works.

Owning the backend too is a separate, later decision. When you get there: Supabase is open source and self-hostable - we maintain a production Supabase guide plus ready compose stacks for both the full Supabase and a slimmed supabase-lite (db + auth + rest + kong in 2 GiB) for exactly this move. But do not couple the two migrations; the frontend hop is an afternoon, the backend move is a project.

Step 4a: Deploy a TanStack Start app (post-May 2026)

This is a Node server, so it deploys like any Node app. On Miget: create an app, connect the GitHub repo, and Migetpacks auto-detects Node - no Dockerfile needed. Two platform specifics to set:

Port: Miget routes ingress to port 5000. Set PORT=5000 in the app's environment (TanStack Start's server respects PORT).
Bind dual-stack: listen on :: (IPv6 + IPv4), not 0.0.0.0 - Miget networking is dual-stack.

Your build and start scripts from the export work as-is (npm run build, npm start). Every push to the active branch deploys - and because of the two-way sync, that includes changes you make by prompting in Lovable. Prompt in Lovable, Lovable commits to GitHub, GitHub push triggers your deploy: the editing workflow survives the hosting move untouched.

Step 4b: Deploy a React + Vite app (older projects)

The build output is static (dist/), but a SPA still needs two things from its server: a catch-all route to index.html (client-side routing breaks without it) and correct cache headers. The smallest production-honest setup is a static server with SPA fallback. Add to package.json:

{
  "scripts": {
    "start": "serve -s dist -l tcp://[::]:5000"
  },
  "dependencies": {
    "serve": "^14.2.0"
  }
}

-s is the SPA fallback flag. Push, and the Node buildpack runs npm run build then npm start.

One Vite-specific trap: environment variables prefixed VITE_ (like your Supabase URL and key) are baked in at build time, not read at runtime. Set them as build-time environment variables on the host and rebuild when they change - do not expect a restart to pick them up.

Step 5: Prove the build locally before you deploy

You do not have to guess whether the buildpack understands your export. Migetpacks - the same builder Miget runs - is a public Docker image you can point at your repo locally:

docker run --rm \
  -v /path/to/your-lovable-app:/workspace/source \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e OUTPUT_IMAGE=my-lovable-app:latest \
  miget/migetpacks:latest

It detects Node from your package.json (npm, yarn, and pnpm lockfiles all work), generates an optimized multi-stage Dockerfile internally, and outputs a finished image to your local Docker. Then run it:

docker run --rm -p 5000:5000 -e PORT=5000 my-lovable-app:latest

If that container serves your app on localhost:5000, the deploy on Miget will work - same builder, same result, and you never write a Dockerfile yourself. This is the fastest way to catch a build-script surprise before it happens in a deploy pipeline.

Step 6: Domain and TLS

Your app gets <your-app>.migetapp.com with TLS out of the box; add your own domain in the dashboard and point DNS at it. On a flat plan the app, a staging copy, preview environments, and any databases you add later all live inside the same fixed monthly price - the same "no meter" logic that made Lovable's unlimited-seats pricing feel right, applied to hosting.

Frequently asked questions

Can I host a Lovable app on my own infrastructure?

Yes. Export via GitHub (or zip), and the code is yours with no licensing restrictions - Lovable's FAQ states the creator owns all generated code. TanStack Start apps deploy as Node services; Vite apps deploy as static builds behind any server with SPA fallback.

Does exporting break editing in Lovable?

No - this is the key feature. GitHub sync is two-way: Lovable pushes its changes to the repo, and your pushes sync back into Lovable. You can keep building by prompt while hosting runs on your infrastructure. Lovable syncs one branch at a time, so keep the linked branch as the deploy branch.