# Lovable hosting: your own link for a Lovable build

Lovable projects are Vite and React, they build with npm run build, and they write to dist. Lovable documents all three itself. What its docs do not cover is the setting a client-routed build needs on a static host, and that is the part this page exists for.

## What Lovable outputs

A Vite and React project. Lovable's own deployment documentation states that its projects are built with Vite and React, that the build command is npm run build, that the output directory is dist, and that Node 22 is recommended.

The same documentation says something more useful than any of those numbers: Lovable projects use client-side routing, with React Router and BrowserRouter. That single sentence predicts the most common complaint about hosting a Lovable build anywhere. The home page works, and every other route returns 404, because the routes are decided by JavaScript after the page loads and a static host answers the request before that happens. There is a free switch for it here and it is described further down.

One more line from those docs is worth reading before you build rather than after: environment variables prefixed with VITE_ are embedded at build time, not runtime. That means whatever value was set when you ran the build is now inside the JavaScript you are about to publish, readable by anyone who opens the page. It is why the deploy-time security check on this side reads what you published and names any key it finds.

## Which of the two paths you are on

For Lovable it is almost always the second. The first is here for the rare single-page export that has nothing around it.

### One file, no build

You have a single self-contained HTML page, or a single React component file that imports nothing but React.

- Drop the .html and it publishes exactly as written.
- A lone .jsx or .tsx is transformed in the visitor browser, with React served from our own edge.
- Any import of shadcn/ui, an icon set or a router closes this path.
- The single-file runtime in full, including what it declines to render.

### A project, one build first

The normal Lovable case. Sync the code out, install, build, and upload the dist folder.

- Run npm install, then npm run build. Node 22 is what Lovable recommends.
- Upload dist, as a folder or zipped with index.html at the top level.
- Turn on the Single-page app switch afterwards, or every route but the first will 404.
- Build details in the Vite deploy guide.

## Getting the code out of Lovable

Lovable documents Git sync as the way to hold your own copy of the code: a GitHub or GitLab repository kept in two-way sync with the project.

1. **Connect Git sync.** Lovable documents syncing a project with GitHub or GitLab, keeping the code in your own repository with automatic two-way sync. That repository is the copy you build from.
2. **Clone the repository locally.** Run git clone, then npm install inside the folder. Node 22 is the version Lovable's deployment documentation recommends.
3. **Set any VITE_ variables before building.** Lovable documents that VITE_ variables are embedded at build time, not runtime. Setting one after the build has no effect, and any value you do set becomes part of the published JavaScript.
4. **Run the build.** Run npm run build. The documented output directory is dist.
5. **Upload dist and turn on the SPA switch.** Drop the dist folder here, then open the site settings and enable Single-page app. That is what makes React Router's routes resolve instead of 404.

Source: Stack, build command, output directory, Node version, client-side routing and the VITE_ build-time behaviour are all from Lovable's own documentation at docs.lovable.dev, read 8 September 2026: the external deployment and hosting guide states the build command npm run build, output directory dist, Node 22 recommended, that Lovable projects use client-side routing with React Router and BrowserRouter, and that VITE_ variables are embedded at build time rather than runtime. Git sync behaviour is from its Git sync overview. Documentation can change.

## What breaks, and why

The first one below is close to universal for Lovable, because it follows directly from what Lovable documents about its own projects.

### A Supabase project the app cannot reach any more

Why: Lovable projects are commonly wired to Supabase, and the connection lives in build-time environment variables. Publish a build made with the wrong ones, or none, and the front end loads while every data call fails.

Fix: Set the VITE_ variables before running the build, not after, then rebuild. Remember that whatever you set is readable in the published JavaScript: use the anon key that is designed to be public, never a service role key.

### Every route except the home page returns a 404

Why: The app routes in the browser, so /about exists only once JavaScript has run. A static host asked for /about looks for a file at that path, does not find one, and answers 404 before your code loads.

Fix: Turn on the Single-page app switch in the site settings. Unknown paths are then served the root index.html and the client router takes over. Free on every plan, applied without a redeploy, and off by default because a multi-page site wants real 404s.

### The API keys the tool wrote into the code are now public

Why: AI tools fill in the value they can see, and a key in front-end code is readable by anyone who opens the page. No host can fix that: a published page is public by definition.

Fix: The deploy-time security check names the key it found. Rotate it, then move the call behind something that can hold a secret. Every plan, free included, and it never blocks the publish.

## What the free plan includes

Publishing a Lovable build costs nothing, including the switch that makes its routing work, which is the one thing a free plan elsewhere tends not to give you.

- 1 live site on a real free plan, not a trial of a paid one, with HTTPS and no card to start.
- Up to 25 MB per upload and 25 MB of storage across the account.
- 5,000 visits and 5 GB of traffic a month.
- Up to 25 publishes a day, which is the number that matters when you are regenerating.
- The Single-page app switch, so a client-routed build works without paying for anything.
- The deploy-time security check, which warns about a stray .env file, a .git folder, a private key or an API key left in your JavaScript.
- A small Droply badge in the corner of the page. Removing it starts on Starter.
- Free sites are served noindex, so search engines do not list them. Search visibility starts on Starter.

## How this compares with the other host built for AI output

Static.app has a Lovable page of its own. These rows are the ones its published pricing and documentation make checkable.

- **Client-side routing (React Router).** Droply: One free Single-page app switch, applied live with no redeploy. Static.app: Not documented as a per-site setting.
- **The dist folder.** Droply: Uploaded directly as a folder, no ZIP required. Static.app: Accepted as a ZIP of built output.
- **Custom domain.** Droply: From Pro, $15 a month. Static.app: Included in the $5 entry tier.
- **Password protection.** Droply: From Starter, enforced at the edge. Static.app: Not listed on any of its plans.
- **Loose .html file accepted.** Droply: Yes, dropped on its own with nothing around it. Static.app: No. Its Claude page states a loose .html file is not accepted and must be zipped.
- **Single .jsx or .tsx without a build.** Droply: Yes. It is transformed in the visitor browser at the published address. Static.app: No. Its Claude page says React-based artifacts need a self-contained HTML version first.
- **Free plan.** Droply: 1 site, 25 MB storage, no card, and a plan rather than a trial. Static.app: A 7-day trial with no credit card, then paid. 1 site and 50 MB during it.
- **Security check on every publish.** Droply: Every plan, free included: leaked keys, a stray .env, a committed .git folder. Static.app: Not offered.

Static.app figures checked 8 September 2026 on its own pricing page (free tier: 1 site, 50 MB, a 7-day trial with no credit card; Starter $5 a month or $60 a year for 2 sites and 500 MB with a custom domain; Medium $10; Large $15) and on its Claude hosting page, which states that a loose .html file is not accepted and must be zipped, that React-based artifacts need an extra step because you have to ask the model for a self-contained HTML version, and that Import from URL takes claude.ai and claude.site links. Product plans can change.

## When Droply is the wrong choice

A Lovable app is often a real application with a backend attached, and the half that talks to a database is not something any static host can serve.

- Your app depends on Supabase functions, server-side auth or anything that runs code. The front end publishes; that part does not.
- You want the site rebuilt automatically whenever you prompt Lovable again. There is no Git integration and no CI here: each version is a build you run and an upload you make.
- The generated app has a database, a login screen or server actions. Those need a runtime; only the static half of it can be published here.
- You want a build to run here, on upload or on every push. There is no build step and no Git integration: you build locally and bring the output.
- You are running WordPress or another PHP application. A static export of it can be hosted here, but the application itself cannot.

## Frequently asked questions

### How do I host a Lovable site outside Lovable?

Sync the project to GitHub or GitLab, clone it, run npm install and npm run build, then upload the dist folder here and turn on the Single-page app switch. Lovable documents the first three steps itself.

### What is the Lovable build command and output folder?

npm run build, writing to dist, with Node 22 recommended. Those are Lovable's own documented values, not an assumption about Vite projects in general.

### Why do my Lovable routes 404 after publishing?

Because Lovable projects use client-side routing with React Router and BrowserRouter, which its documentation states. A static host answers /about with a file or a 404 before your JavaScript runs. Turn on the Single-page app switch in the site settings and unknown paths are served the root index.html instead.

### Does the Single-page app switch cost anything?

No. It is available on every plan including free, it is applied to the live site without a redeploy, and it is off by default because a multi-page site should return real 404s.

### What happens to my Supabase connection?

Nothing about it changes, but the values have to be right at build time. Lovable documents that VITE_ variables are embedded at build time rather than runtime, so a build made without them ships without them.

### Is it safe to publish a build with my Supabase key in it?

Only the anon key, which is designed to be public and to be governed by your row level security rules. A service role key in front-end code is readable by anyone who opens the page, and the deploy-time security check will name it if it finds one.

### Can I use my own domain?

Yes, from Pro at $15 a month. The certificate is issued and renewed for you. On the free plan the site is served on a subdomain over HTTPS.

### Do I keep the same link when I rebuild?

Yes. The address belongs to the site, so republishing keeps it and any link you already sent shows the current version. From Pro you can restore an earlier build.

## Other AI tools

- [bolt.new hosting](https://droply.host/bolt-new-hosting)
- [v0 hosting](https://droply.host/v0-hosting)
- [Replit hosting](https://droply.host/replit-hosting)