Lovable App to Production: Host It on Your Own Server

To run a Lovable app in production on your own server, sync it to GitHub, review security, build it in CI and serve it with Nginx (static) or PM2 (SSR).

Lovable, Bolt and similar builders are great at getting a working product in front of people in days. The trouble starts when that product gets customers: you want your own domain and server, real backups, a review step before changes go live, and costs that don't jump with usage. The good news is that a Lovable app is a normal codebase you own. This guide moves it onto the same production setup this website runs on: GitHub, GitHub Actions, Nginx and PM2 on an Ubuntu VPS. You can keep editing in Lovable afterwards.

Key takeaways

• You own the code. Lovable syncs both ways with GitHub, so the repo becomes the source of truth.
• Check which stack you have. Lovable apps created from 13 May 2026 use TanStack Start with server-side rendering; older ones are React + Vite static apps. They deploy differently.
• Review security before moving anything. Missing Row Level Security on Supabase tables is the most common serious problem in AI-built apps.
• Deploy from CI, not from the editor. Every change to main runs checks, builds, and goes live only if the health check passes.
• The backend can stay on Supabase. Move the frontend first; moving the database is a separate project.

Step 1: Connect GitHub and get the code running locally

In Lovable, connect the project to GitHub. Changes in the editor push to the repo, and commits you push to the active branch sync back into Lovable. Clone it and run it:

git clone git@github.com:you/my-app.git && cd my-app
npm ci
cp .env.example .env    # or create it: VITE_SUPABASE_* values
npm run dev
npm run build           # must pass before anything else

Look at package.json to see which stack you have. If the build script is plain vite build and outputs a dist/ folder, it's a static single-page app. If it depends on @tanstack/react-start and has a start script, it's a server-rendered Node app.

Step 2: Do a security review first

Moving hosts doesn't fix security, and a migration is the right moment to look. The browser bundle contains your Supabase URL and public anon key by design. That's safe only if every table has Row Level Security policies. In 2025, CVE-2025-48757 documented Lovable apps whose tables were readable by anyone because those policies were missing.

At minimum: enable RLS on every table, confirm no service_role key is in the frontend, check that edge functions verify the user, and add rate limits to anything that calls a paid API. My vibe coding security checklist has the full list with test commands.

Step 3: Prepare the server

A 2 GB VPS is plenty for most Lovable frontends. Harden it first (SSH keys, firewall, automatic updates; see my Ubuntu 24.04 hardening checklist), then install Nginx and Node.js LTS. Use a release-folder layout so deploys are atomic and rollbacks take a second:

/srv/my-app/
├── releases/20261005-1430-e4f5a6b/
├── shared/.env            # build-time and runtime variables
└── current -> releases/20261005-1430-e4f5a6b

Step 4a: Serve a Vite (static) app with Nginx

A static build is just files. Nginx serves them and sends unknown paths to index.html so client-side routes work:

server {
    server_name app.example.com;
    root /srv/my-app/current/dist;

    location /assets/ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
    location / {
        try_files $uri $uri/ /index.html;
    }
}

Remember that VITE_* variables are baked in at build time. Changing them means rebuilding, not restarting.

Step 4b: Run a TanStack Start (SSR) app with PM2

A server-rendered app is a Node process. Build it, then run the start command from package.json under PM2 and proxy to it:

// /srv/my-app/ecosystem.config.js
module.exports = { apps: [{
  name: "my-app",
  cwd: "/srv/my-app/current",
  script: "npm", args: "run start",
  env: { NODE_ENV: "production", PORT: 3000 },
}]};

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Then pm2 start ecosystem.config.js && pm2 save, and add HTTPS with certbot --nginx. Server rendering has a side benefit: crawlers and AI search bots see real HTML, which helps you get cited by ChatGPT and AI Overviews.

Step 5: Deploy from GitHub Actions

Push-to-deploy with checks is what turns a prototype into a product. On every push to main:

1. Install and run the type check and build in CI. A broken build never reaches the server.
2. SSH to the server with a deploy-only key and build the commit into a new release folder.
3. Swap the current symlink, reload Nginx or PM2, and hit a health URL.
4. If the health check fails, swap back to the previous release automatically.

I've written up the full workflow, including the forced-command SSH key and the rollback script, in GitHub Actions CI/CD to a VPS with automatic rollback.

Step 6: Decide what to do with the backend

Lovable's backend is built on Supabase, and Lovable's docs describe moving it to managed Supabase or self-hosted Supabase. For most teams the right order is:

• Now: keep the database where it is, with RLS reviewed, backups enabled and a separate staging project.
• Later, if needed: move to your own Supabase project or self-host Supabase with Docker on a server you control.
• Only with a real reason: rewrite onto plain PostgreSQL and your own API. Auth, storage, realtime and edge functions all need replacing, so treat it as a rebuild, not a migration.

Step 7: Production basics people skip

• Error tracking (Sentry or similar) for the frontend and functions.
• Uptime checks on the homepage and one API call.
• Database backups you have actually restored once.
• A staging copy on a subdomain, deployed from a staging branch.
• Branch rules: AI edits go to a branch and merge through a pull request, so nothing reaches production unreviewed.

Frequently asked questions

Can I host a Lovable app outside Lovable?

Yes. The code syncs to your GitHub repo and is a standard React project, either a Vite static app or a TanStack Start SSR app depending on when it was created. Any server or host that supports that stack can run it.

Will I lose the ability to edit in Lovable?

No. GitHub sync works both ways, so you can keep using Lovable while CI deploys main to your server. Use branches and pull requests so editor changes are reviewed before they go live.

Is Lovable production-ready?

The generated code can be, after a review. The common gaps are security rules, error handling, testing and deployment process, not the framework. Those are exactly what this guide adds.

What server do I need for a Lovable app?

A static Vite app runs on almost anything, even a 1 GB VPS. An SSR app needs a Node process; 2 GB of RAM is a comfortable start, and more if you build on the server.

Does this work for Bolt, v0 or Replit apps too?

Yes. The steps are the same once the code is in GitHub: identify the stack, review security, build in CI and serve it with Nginx or a Node process manager.

Want your prototype running like a real product?

I take AI-built apps to production: security review, CI/CD, server setup, monitoring and backups, with a handover document your team can follow. See my DevOps services or send me your repo.