# How to host a Lovable app on your own server

Published 2026-11-09 · Self-hosting

To host a Lovable app on your own server, connect the project to GitHub in Lovable, clone the repository on an Ubuntu server, run `npm run build` and serve the `dist` folder with nginx and HTTPS. The app can keep its Supabase backend. Lovable projects created since May 13, 2026 use TanStack Start and need a Node.js server instead.

## Key takeaways

- Lovable's GitHub sync is available on every plan and keeps working after you move the hosting.
- Older Lovable apps are React and Vite and build to static files; newer ones use TanStack Start and run server code.
- Only the frontend has to move. The app can keep using Lovable Cloud or its Supabase project.
- Before launch, turn on Row Level Security on every table and keep secret Supabase keys out of the build.

## Can you host a Lovable app outside Lovable?

Yes. Lovable's own [hosting and ownership page](https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership) says the apps you build can be hosted anywhere. The editor and AI agent stay on Lovable; the code they write is yours to run where you like.

Lovable's built-in hosting is the easiest option, and for a prototype it is often the right one. People move to their own server for other reasons: a server in a region they choose, one bill for several apps, control over headers and logs, or a custom domain without a paid Lovable plan. Lovable's [custom domain docs](https://docs.lovable.dev/features/custom-domain) say custom domains are available on paid plans.

|  | Lovable hosting | Your own server |
| --- | --- | --- |
| Setup | Publish from the editor | GitHub, a server, nginx and HTTPS |
| Custom domain | Paid Lovable plan | Any domain you own |
| Where it runs | Lovable's infrastructure | The provider and region you pick |
| Who keeps it updated | Lovable | You, or a panel that does it for you |
| Keep editing in Lovable | Yes | Yes, through GitHub sync |

## First, check which kind of Lovable app you have

This decides how the app is hosted. Lovable says projects created from May 13, 2026 use TanStack Start, which runs server code, while older projects use React and Vite and build to static files. Bolt projects come in both kinds too.

| Project | Build output | How to host it |
| --- | --- | --- |
| Lovable, React and Vite (before May 13, 2026) | Static files in `dist` | Any web server; this guide |
| Lovable, TanStack Start (since May 13, 2026) | A Node.js server | Like a Node app, behind a reverse proxy |
| Bolt, Vite and React template | Static files in `dist` | Any web server; this guide |
| Bolt, Next.js | A Node.js server | Like a Node app, behind a reverse proxy |

To tell them apart, open `package.json`. A Vite app has `vite build` as its build script and often lists `lovable-tagger`. A TanStack Start app depends on `@tanstack/react-start`. For server-rendered apps, the steps in [deploy Next.js or Nuxt on a VPS](https://nuvlo.dev/blog/deploy-nextjs-nuxt-on-a-vps) apply: Node.js, PM2, nginx and releases.

## Export your Lovable project to GitHub

GitHub sync is the export route, and Lovable's [GitHub docs](https://docs.lovable.dev/integrations/github) list it as available on all plans. A ZIP download also exists, but it is a one-time copy and needs a paid plan.

1. In Lovable, open **Project settings**, then **Git**, then **GitHub**.
2. Add a GitHub connection for your workspace if there is none, choose the account or organization, and allow access to all or selected repositories.
3. Click **Connect** next to that connection. Lovable creates a private repository and starts two-way sync.
4. Clone the repository on your machine and run `npm install` and `npm run build` once to see that it builds outside Lovable.

Sync works both ways. Changes made in Lovable are pushed to GitHub, and commits pushed to the synced branch come back into Lovable. Lovable works on one branch at a time, usually `main`. If the two sides diverge, Lovable pushes to a `lovable-sync` branch instead, so check for it when changes seem to go missing.

## Where your data lives: Lovable Cloud, Supabase or self-hosted

Moving the hosting does not have to move the data. A Vite app talks to its backend from the browser, so the frontend can live on your server while the database stays where it is. You have three choices:

- **Keep the current backend.** The app keeps using Lovable Cloud or the Supabase project it already has. This is the least work and nothing about your data changes.
- **Move to your own Supabase project.** Lovable Cloud is built on Supabase, but there is no one-step move. Lovable's [Cloud docs](https://docs.lovable.dev/integrations/cloud) describe exporting the database, restoring it into your project, moving storage files, and setting up authentication and secrets again.
- **Self-host Supabase.** Run Supabase on a server you control, then repeat the same migration. You also take over its backups and updates.

Moving only the Postgres database is not enough. Authentication users, storage files, realtime and Edge Functions each need their own step.

> **Warning:** Older Lovable projects write the Supabase address and key straight into `src/integrations/supabase/client.ts`. The app keeps using that project no matter what you set on the server, until you change the file to read `globalThis._importMeta_.env.VITE_SUPABASE_URL` and `globalThis._importMeta_.env.VITE_SUPABASE_PUBLISHABLE_KEY`.

## Build and serve a Lovable app on Ubuntu 24.04

For a Vite app you need Node.js only to build, and nginx to serve the result. Install Node.js 24, nginx and Certbot as in the [Next.js and Nuxt guide](https://nuvlo.dev/blog/deploy-nextjs-nuxt-on-a-vps), then build the app with its Supabase settings. Lovable usually commits a `.env` with `VITE_SUPABASE_URL`, `VITE_SUPABASE_PUBLISHABLE_KEY` and `VITE_SUPABASE_PROJECT_ID`.

```
sudo mkdir -p /var/www/lovable-app/releases
sudo chown -R $USER:$USER /var/www/lovable-app
RELEASE=/var/www/lovable-app/releases/$(date +%Y%m%d%H%M%S)

git clone --depth 1 git@github.com:you/your-lovable-app.git "$RELEASE"
cd "$RELEASE"
npm ci
npm run build
ln -sfn "$RELEASE/dist" /var/www/lovable-app/current
```

Every address in a single-page app must load `index.html`, or a reload on `/dashboard` returns a 404. The `try_files` line does that. Vite puts hashed files in `assets`, so they can be cached for a long time.

```
server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;
    root /var/www/lovable-app/current;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }

    location /assets/ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}
```

```
sudo ln -s /etc/nginx/sites-available/lovable-app /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d app.example.com
```

Point the domain's A record at the server before running Certbot. Then sign up, sign in and load a page that reads data to confirm the app still reaches its backend.

## Keep editing in Lovable after the move

Lovable keeps pushing your changes to GitHub, but your server won't rebuild on its own. Each change needs the build steps above run again: clone into a new release folder, build, then switch the `current` symlink. Because nginx only follows the symlink, visitors never see a half-built app, and a rollback is the same switch pointed at an older folder.

To automate it, run the build over SSH from a GitHub Actions workflow on every push to `main`, or call a small script from a webhook. Keep the last few release folders so a broken change from the AI is one command away from being undone.

## Security checks before you launch a Lovable app

AI-built apps tend to ship the same few mistakes. Check these before you share the address:

- **Row Level Security on every table.** The publishable key is meant to be public, so RLS is what decides what visitors can read. [Supabase's API key docs](https://supabase.com/docs/guides/api/api-keys) say to enable it on every table before you deploy.
- **No secret keys in the build.** Every `VITE_` variable is written into the JavaScript that visitors download. A `service_role` key or an `sb_secret_` key there gives anyone full access to your database.
- **Nothing private in the public folder.** Serve only `dist`, never the repository root, so `.env` and `.git` can't be downloaded.
- **A backup if you self-host the data.** Supabase cloud manages its own backups; a self-hosted Supabase needs a schedule you set up. See our [secure Ubuntu server checklist](https://nuvlo.dev/blog/secure-ubuntu-server-checklist) for the server side.

## How Nuvlo moves a Lovable app for you

[Nuvlo](https://nuvlo.dev/solutions/lovable-apps) automates the steps above on a server in your own cloud account, for example at [Hetzner](https://nuvlo.dev/providers/hetzner) in Germany or Finland. The provider bills the server directly; Nuvlo never hosts or resells it.

- **Import**: choose **Import from Lovable or Bolt**, pick the repository, and Nuvlo shows what it found: the builder, the build and how the app connects to Supabase. TanStack Start and Next.js projects are recognised and sent to the [Node.js app](https://nuvlo.dev/docs/deploy-an-application) path instead.
- **Data**: keep the current Supabase project, including a Lovable Cloud or Bolt Cloud backend, or connect a [self-hosted Supabase](https://nuvlo.dev/solutions/one-click-apps/supabase) installed as a 1-Click app. Nuvlo sets its address and public key as build variables; the service role key stays on that server.
- **Address**: the app goes online at a temporary address with HTTPS right away. [Move it to your own domain](https://nuvlo.dev/docs/change-site-domain) whenever you are ready.
- **Deploy on push**: every change that reaches GitHub from Lovable is built and goes live.
- **Checks**: a service role or `sb_secret_` key in a build variable is refused. After each deploy, the [launch check](https://nuvlo.dev/docs/launch-check) reads the tables the app queries with the public key and flags rows anyone can read, secret keys in the JavaScript, and a self-hosted Supabase without backups.

What it doesn't do: Nuvlo does not copy your database to a self-hosted Supabase. You run the migration files from `supabase/migrations` in its SQL editor, move the data yourself and deploy Edge Functions there. The full walkthrough is in [Move a Lovable or Bolt app](https://nuvlo.dev/docs/move-a-lovable-app). Your first server and site are free; see [pricing](https://nuvlo.dev/pricing).

## Frequently asked questions

### Can I export a Lovable project without GitHub?

Yes. Lovable offers a Download codebase option in the project settings, but it needs a paid plan and gives you a one-time copy. GitHub sync is available on every plan and keeps updating the repository as you keep working in Lovable, which is what you want when the app runs on your own server.

### Will my Lovable app keep working with Supabase after I move it?

Yes, if you only move the frontend. The built app calls Supabase from the browser with the same address and publishable key, so it keeps working from any domain. Add the new domain to the Site URL and Redirect URLs in the Supabase URL Configuration so sign-in links and OAuth return to the right place.

### Can I keep using Lovable after I self-host the app?

Yes. Lovable keeps syncing changes to GitHub, and commits pushed to the synced branch flow back into Lovable. Your server only needs to rebuild when the repository changes, either through a deploy script you trigger or a tool that deploys every push automatically.

### How do I host a Bolt.new app on my own server?

The same way. Connect the Bolt project to GitHub, then check its stack. A Bolt Vite and React project builds to static files that nginx can serve with a single-page app fallback. A Bolt project on Next.js runs a Node.js server and needs PM2 and a reverse proxy, like any Next.js app.

### Do I need a big server to host a Lovable app?

No. A Vite app is static files once it is built, so even the smallest VPS serves it well. The build itself needs some memory, so pick 2 GB if you build on the server. A self-hosted Supabase is the heavy part: it runs about ten services and needs a mid-size server or one of its own.

---
Source: https://nuvlo.dev/blog/host-lovable-app-on-your-own-server