How to Host a Lovable Site Without Lovable's Hosting

One thing Lovable gets right: it doesn't trap your work on its own hosting. Every project can sync to GitHub. If the project produces a static build, you can put that output on another host and add a password or custom domain there.

Why host outside Lovable

A few situations where this comes up:

• You want to password-protect a client preview before it's ready for the world.
• You want a custom domain without touching the rest of your stack.
• You want a link that stays put as you keep shipping updates.
• You're sending a one-off preview and don't want it living in your main Lovable workspace.

What you'll need

• A Lovable project with the GitHub integration turned on (or ready to turn on).
• Node.js and npm installed locally, to run the build.
• A project that can build to static files with an index.html entry point.

Step 1: Sync your project to GitHub

In your Lovable project, open the GitHub integration and connect or create a repository. Lovable keeps that repo in sync with your project automatically, so it's a one-time setup per project.

Step 2: Build the static output locally

Lovable's current external-hosting guide describes Lovable projects as standard Vite applications that build as static frontends. Run npm run build and expect the output in dist/; Node 22 is recommended, and variables beginning with VITE_ are embedded at build time. PreviewSend can host that static output, but it cannot run a project you have separately changed to require a server process.

For a Vite project, the usual build is:

git clone <your-repo-url>
cd <your-repo>
npm install
npm run build

Open the output folder after the command finishes. If it contains index.html plus compiled JavaScript, CSS, and assets, you have a static build. If the output expects a server process, stop here and use a host that supports that runtime.

Step 3: Zip the build output

For a Vite build, zip the contents of dist/, not the folder itself, so index.html lands at the root of the archive. PreviewSend can find the shallowest nested index.html, but root placement works across more hosts:

cd dist
zip -r ../site.zip .

Step 4: Upload and get a live link

1. Sign up for PreviewSend. Eligible first-time owners get a one-time 14-day Pro trial on their first workspace without entering a card. Afterward, Free limits apply: the most recently updated site stays live and excess sites are archived.
2. Create a project and upload site.zip (up to 100 MB compressed).
3. You get a live URL immediately.

From there:

• Add a password before launch. Passwords are available on the Free plan too.
• Point a custom domain at the project on a purchased Starter, Pro, or Agency plan; the Pro trial does not unlock custom domains.
• Let the client pin comments or request changes on the page without creating an account. New projects enable the review overlay by default. Export all comments as CSV or Markdown, or turn unresolved notes into an AI-ready revision plan for the next Lovable pass.
• Ship an update by uploading a new ZIP to the same project. The link stays the same, and earlier versions remain in version history within your plan's retention. The file-level version diff is available on Pro, Agency, and during the active Pro trial.
• Send a named, version-specific approver link for final handoff on Starter, Pro, Agency, or an active Pro trial. After authorized approval, Pro, Agency, and active Pro-trial workspaces can download a stamped sign-off PDF. It is an audit record, not an electronic signature.

What stays on Lovable

If your project uses Lovable Cloud for the database, auth, or server functions, you can leave that backend where it is and move only a compatible static frontend. Before npm run build, set VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY as described in Lovable's external-hosting guide. These are frontend configuration values. Do not expose a Supabase service-role key.

The zip-and-upload half of this is identical for any static output, whatever built it. The mechanics of turning a folder of files into a live URL cover the structure and the path gotchas in one place. For a different starting point, here's the same idea applied to a Claude artifact, or the export-and-build path from a Bolt.new project.