How to host a Lovable app on your own server

Can you host a Lovable app outside Lovable?

Yes. Lovable's own hosting and ownership page 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 say custom domains are available on paid plans.

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.

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 apply: Node.js, PM2, nginx and releases.

Export your Lovable project to GitHub

GitHub sync is the export route, and Lovable's GitHub docs 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 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.

ImportantOlder 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, 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 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 for the server side.

How Nuvlo moves a Lovable app for you

Nuvlo automates the steps above on a server in your own cloud account, for example at 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 path instead.
• Data: keep the current Supabase project, including a Lovable Cloud or Bolt Cloud backend, or connect a self-hosted 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 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 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. Your first server and site are free; see pricing.