How to host an app built with AI: from Lovable or Bolt to your server

Where your app runs today

Lovable, Bolt and Replit publish the app on their own infrastructure, in one click. Here is what their documentation says, as consulted in October 2026:

v0 publishes to a Vercel project and generates a Next.js app (React, TypeScript, Tailwind CSS); the code can be exported, or synced with GitHub in both directions. Cursor is an editor and coding agent installed on your computer: the code is already there, and hosting is entirely your choice.

These built-in hosting options are designed to publish fast. At Lovable as at Replit, the live version is a snapshot, renewed with each publish, and the cost follows platform usage (at Lovable, credits cover backend activity and AI; at Replit, the Starter plan includes one published app, which expires after 30 days and can be republished). People move to their own server for a domain and data under their control, reserved resources, always-on background jobs or compliance requirements.

Getting your code and data back

The safest route is to connect the project to a GitHub repository: every change lands there as a commit, with the full history. At Lovable, sync works both ways: you keep building in Lovable while your server serves the app.

1. Lovable: connect the project to GitHub, GitLab or Bitbucket, or download the .zip archive of the code (paid plan).
2. Bolt: connect GitHub, or click the project title at the top left, then "Download".
3. Replit: the three-dot menu at the top of the file tree, then "Download as zip"; or the Git tool, connected to your GitHub account, with automatic sync.
4. v0: connect GitHub from the project menu ("Settings", then "GitHub"), or export the code.

The code contains neither the database contents nor the files your users uploaded. At Lovable, the database is exported from the project as a .backup file, to be restored with pg_restore, and storage files are downloaded separately. At Bolt, the database can be attached to your own Supabase account (Pro and Teams plans).

What your app is made of

Open the package.json file: it tells you what the app relies on, and therefore what your server needs to run.

With Vite, any variable whose name starts with VITE_ is built into the code sent to the browser, at build time: every visitor can read it, and changing its value takes a new build. That is intended for Supabase’s public key (sb_publishable_…, or the older anon key), designed for the browser and governed by row-level security (RLS) rules. The secret key (sb_secret_…, or the older service_role key) bypasses those rules: it stays on the server, with no VITE_ prefix.

VITE_SUPABASE_URL=https://xxxx.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=sb_publishable_xxxx
VITE_SUPABASE_PROJECT_ID=xxxx

Enable RLS on every table before going live: its rules are what protect your data while the public key travels in the browser.

Putting it on your own server, step by step

On a Linux VPS, going live always follows the same order. Lovable recommends Node.js 22 to build and run its apps.

1. The build: clone the repository on the server, then run npm install and npm run build. A Vite app produces static files in dist/; a TanStack Start app is built with NITRO_PRESET=node-server npm run build and starts with node .output/server/index.mjs, on port 3000; a Next.js app starts with npm run start.
2. The process: for an app with a server, a systemd service starts it with the machine and restarts it if it stops.
3. The web server: Nginx or Caddy receives visitors. For a Vite app, it returns index.html for any unknown address, otherwise a refreshed page answers 404; for an app with a server, it forwards requests to the Node.js process.
4. The domain name: a DNS A record (and AAAA for IPv6) points to the server.
5. HTTPS: a free Let’s Encrypt certificate. Caddy obtains and renews it on its own; with Nginx, Certbot takes care of it.
6. Secrets: in an environment file readable only by the app’s user, outside the Git repository.
7. The database: keep the backend with its provider, or install it on your server. Alongside its PostgreSQL database, a Supabase app needs authentication, storage, real-time and functions: self-hosted Supabase brings them all together.
8. Redirect URLs: add your domain to the allowed URLs for authentication, and at Google or GitHub if the backend changes address.
9. Backups: the database and files every night, copied off the server, and a test restore from time to time.

app.your-domain.com {
	reverse_proxy 127.0.0.1:3000
}

server {
    server_name app.your-domain.com;
    root /var/www/app/dist;

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

What it takes to keep it running well

An app that is online keeps evolving: its dependencies receive patches, its database grows, its traffic changes. What keeps it fast and secure fits into a routine:

This routine is a system administrator’s job, and it can be handed over. With a Managed VPS, the host keeps the server up to date, monitors it day and night and steps in without waiting for your call. It also proactively monitors your app (errors, slowdowns, expensive queries, disk space) and recommends the fix: you apply it with your own AI assistant, just as you built the app, and you stay in control of your code.