How to host a Lovable app outside Lovable

Publishing with Lovable and hosting outside Lovable are different things. You can move only the web app and keep Lovable Cloud, or move its data and services too. Before changing DNS, decide which parts you want to operate and who will handle updates, backups and security.

Lovable’s official external deployment guide describes both paths. This guide focuses on the hosting decisions and a safe order for testing the change without first taking down the version that works.

1. Get a copy of the code and run it locally

Connect the project to GitHub, GitLab or Bitbucket with Lovable Git sync. The repository stays synchronized with the project and lets you deploy a selected branch. For a one-time copy, Lovable also offers a code download subject to your plan.

Clone the repository, inspect package.json and run the app on your own computer before configuring a server. Check the branch, project directory and actual scripts. A monorepo may contain several apps; its root manifest does not always describe the build you intend to publish.

2. Check whether you need static files or a server

Lovable says new projects created since May 13, 2026 use TanStack Start; older React and Vite projects keep their original architecture. Check package.json before choosing a host.

Older Lovable apps built with React and Vite produce static output, usually in dist/. A static web server can serve it, but browser routes need a fallback to index.html. Test a nested route by opening it directly and refreshing it.

TanStack Start can render routes on the server (SSR), pre-render them as static files (SSG), or combine modes. Lovable’s external guide prepares a server for TanStack Start; you need one if the app uses request-time SSR, dynamic server functions or API routes. Static hosting works if the configuration generates every required route and no application server is needed for each request; the frontend can still call an external backend. Check package.json for @tanstack/react-start, nitro, @lovable.dev/vite-tanstack-config and the build configuration described in Lovable’s external deployment guide.

For a Node server you control, Lovable’s official guide shows this Node.js 22 flow with the node-server preset. If your app uses Lovable Cloud, set VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY before the build; configure SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY and any secrets your server needs in its runtime environment. VITE_* values reach the browser; never put private secrets there.

# If the repository includes package-lock.json
npm ci
NITRO_PRESET=node-server npm run build
node .output/server/index.mjs

The build produces the server under .output. Follow your repository’s scripts and lockfile; if you use another package manager or preset, adapt the steps and test the generated output. The NITRO_PRESET=... assignment uses POSIX shell syntax; in PowerShell, set $env:NITRO_PRESET="node-server" before npm run build. Do not publish only dist/ for an app that needs SSR or server functions.

Hostbrid Projects can deploy projects from a repository and run Node or Docker services. Compare your app’s requirements with the available configuration and plan. For a static export, set the build and output directory; for TanStack Start, verify the runtime and server entry point before ordering.

3. Decide what happens to Lovable Cloud

Moving the frontend does not automatically migrate its database, authentication, files, Edge Functions, connectors or AI features. You can keep using Lovable Cloud from a frontend hosted elsewhere. In that setup, your data stays in the existing backend and the project still depends on those services.

If you also want to leave Cloud, prepare a separate migration for data and services. Lovable’s official guide uses Supabase as its reference destination and explains what to copy and configure again. Check row-level security policies, users, login redirect URLs, stored files, functions and scheduled jobs before switching the frontend. Keep the original backend until you have validated the copy and a rollback plan.

VITE_* variables are bundled into JavaScript delivered to the browser. Treat them as public values; never put passwords, service keys or private tokens there. Configure server secrets in the runtime environment and review permissions for every table and API.

4. Deploy to a temporary URL and test the flows

Configure the build from the repository. Lovable’s current examples use npm run build and Node 22, but verify your project’s lockfile and runtime. Test on a temporary URL before changing production DNS.

Open a nested route directly and refresh it, sign in and out, submit forms, upload files and run the app’s key functions. For TanStack Start, also test a server-rendered page and a server function. A successful homepage does not prove that payments, authentication or database writes work.

After the checks pass, point the domain to the new host and verify HTTPS, login redirects and API requests. Keep the old version available while you confirm the switch. Lovable’s Publish button still publishes to Lovable; a change in your Git branch can trigger the external deployment, depending on the integration you configured.

To deploy your app outside Lovable with Hostbrid, explore Projects and current prices. External hosting gives you deployment control, and makes you responsible for operating and protecting every service you move.