Hosting AI-built apps from Lovable, Bolt, v0 and Cursor

The tools stopped handing out single HTML files a while ago. Lovable gives you a React project. Bolt gives you a ZIP with a package.json in it. v0 gives you a Next.js app. Cursor and Claude Code give you whatever you asked for, already in a folder on your machine.

All of it runs on an ordinary hosting account, but "upload the folder" is no longer the answer: the folder is source code and what a browser needs is the build. Two questions come first. Which shape are you holding, and what did the tool keep. For the simpler case of a single page from a chat assistant, see how to host a website built with ChatGPT, Claude or Gemini; for how this fits the wider picture, AI and your website.

What each tool hands you (and what it keeps)

Lovable, Bolt, v0, Cursor and Claude Code hand over a project, not a page: a React or Next.js codebase that needs a build step and sometimes a server runtime. With a single HTML file the server hands out bytes. With a project, something compiles it first, and that something is your laptop or a build service, never a shared hosting account, which has no shell for npm.

The second question is what stayed behind. These tools run more than a code editor: Lovable can run your database, authentication and storage, and Bolt and v0 can host the result at their own URL. When you take the code, you take the code. The rest stays until you move or replace it, which is the decision most migration guides skip.

Coding tools give you everything because they never held anything. Builders give you the frontend, because the frontend was always yours. AI website builder vs AI coding tool: what you own works through that distinction and the ownership language in each vendor's terms.

Static, Node or Python: identify your project in two minutes

Open the project folder and look for three things.

A package.json with a build script? There is a build step, and what you upload is its output, not the folder you are looking at.

Anything that listens on a port or reads a secret? app.listen(...), an api/ directory with server handlers, process.env.SOMETHING_SECRET_KEY outside the browser: that is a server, and it needs a runtime.

A requirements.txt, or app = Flask(__name__)? A Python app, on a different path from Node.

Those answers sort every project into a lane:

A single HTML file, a Vite, React, Vue or Svelte build and a Next.js static export all run on a Flashcloud shared plan as plain static files, which covers most of what these tools produce. Node and Express servers run on Flashcloud shared hosting through cPanel's Setup Node.js App on Node 22 or 24, with NPM install and environment variables set from the panel. Flask, Django and FastAPI apps run through Setup Python App on Python 3.11.

If you cannot tell which lane you are in, ask the tool that built it: "does this project need a Node server at runtime, or can it be built as static files?" The answer is reliable, because the tool wrote the code.

Export paths per tool, dated

These move, so here is what the vendor pages said as of October 2026.

Lovable. Git sync is available on all plans, and the docs are explicit that "the codebase download as a .zip file requires a paid plan". The same page states your apps, code and content are yours, usable commercially, hostable wherever you choose. Git sync is the better path anyway, for a reason the GitHub section makes clear.

Bolt. The support docs say you can download your project as a zip file to work on it outside Bolt, using your own code editor, and GitHub sync is documented separately. Framework projects need npm install and a build after unzipping. We could not confirm Bolt's ownership terms from a direct source, so this guide makes no claim about them.

v0. Projects are Next.js, React, TypeScript, Tailwind CSS and shadcn/ui, per the v0 FAQ. The GitHub docs describe sync that moves code between v0 and GitHub, with generated changes committed and pushed to the working branch automatically, and there is a Download ZIP item in the project menu. One detail matters more than it sounds: images generated inside the preview live in temporary storage and are not in the download, so the site goes live with holes where the pictures were. Save them from the preview into public/ before you build.

Cursor and Claude Code. No export step. Claude Code's own docs describe it as an agentic coding tool that reads your codebase, edits files and runs commands, in your terminal and IDE. Cursor is a coding agent on the codebase you point it at. The files are yours from the first edit, so the hosting conversation starts at the build step.

Tool-by-tool walkthroughs are in progress. The product pages carry each tool's current steps: Lovable hosting, Bolt hosting and v0 hosting.

Build it, then upload the right folder

Run npm install, then npm run build. The output lands in dist/ for Vite, build/ for Create React App, or out/ for a Next.js static export. We ran exactly this on our own test account in October 2026: a Vite React build produced dist/index.html plus a hashed 164 KB bundle in dist/assets/.

Upload the contents of that folder, not the folder itself. It is the commonest mistake, and it shows as a file listing or a blank page rather than an error.

There are three ways to get files onto a Flashcloud account: push to GitHub and let cPanel Git Version Control pull the repository, upload with File Manager or FTP, or connect the AI assistant through the Flashcloud AI Connector and let it write the files. For a built bundle, FTP or a File Manager ZIP upload is the practical choice: the Flashcloud AI Connector writes files of up to 256 KB each, right for a single page or a config edit, wrong for a 2 MB bundle.

Two things we found doing it. A fresh cPanel document root is not empty: it already holds .htaccess with cPanel's own PHP directives, plus php.ini, .user.ini and .well-known/, so append to that file rather than replacing it. And for a subdomain the target is the folder cPanel created for it, next to public_html rather than inside it. On our test that was ~/vite. Upload to the wrong one and you get a 404 that looks like a DNS problem.

The step-by-step version, including the File Manager ZIP route, is in deploying a Vite or React build to shared hosting.

GitHub pull: the workflow that keeps the tool in the loop

If Lovable, Bolt or v0 pushes to GitHub, the hosting account can pull from the repository instead of waiting for an upload. cPanel's Git Version Control does this, with two edges worth knowing first.

It is pull-only on a shared plan. Shell access is off, so there is no clone URL to push to from your laptop, and the Git tool opens with a banner saying so. The account clones from GitHub, not the other way round. Public repositories clone in seconds; a private one needs SSH keys the account cannot hold without shell access.

It does not run your build either: whatever is committed is what gets deployed. So build locally, commit the output, and add a .cpanel.yml at the repository root that copies the built files into the document root.

---
deployment:
  tasks:
    - export DEPLOYPATH=/home/YOURUSER/public_html/
    - /bin/cp -R dist/* $DEPLOYPATH

Then in cPanel, open Git Version Control and create a repository from the HTTPS clone URL. One trap: the form auto-fills the path and display name as you type, so clear both fields first. After that, each change is Update from Remote, then Deploy HEAD Commit, which stays greyed out until a valid .cpanel.yml exists and the branch is clean.

This is the workflow worth the setup cost, because Lovable stays your editor: you keep prompting, Lovable keeps pushing, the site keeps updating on a domain you own. The mechanics are in deploying from GitHub with cPanel Git Version Control.

The backend question: Supabase, Lovable Cloud, Bolt Cloud

This is the part almost nobody writes about honestly. A project's backend does not move with the frontend export: it stays where it is, or it gets replaced. What that means depends on whose backend it is.

Your own Supabase project. Nothing to do. It is a separate service with its own URL and keys, and a frontend hosted anywhere points at it the same way.

Lovable Cloud. Lovable's own backend, built on Supabase's open-source foundation per their docs, and the case that catches people. As of October 2026 the Lovable documentation states plainly that there is no one-click migration from the built-in backend to your own Supabase project: you export your Cloud data, connect a Supabase project to a new Lovable project, and rebuild the schema there. The same page warns that removing Cloud permanently deletes the instance, so export the database and download storage files first. The frontend moves in an afternoon; the backend is a project of its own.

Bolt or v0 with a hosted service behind them. Same logic: a third-party service the code calls keeps working from anywhere; whatever the tool ran for you needs replacing.

So move the frontend first, point it at the backend where it lives, confirm the site works on your domain, and only then decide whether the backend should move too. A frontend on your own domain talking to a Supabase project is a stable arrangement, and plenty of sites stay that way. A full reference on what moves and what does not, tool by tool, is planned.

One habit while you are in here: keys in frontend code are public, because the browser downloads them. Fine for a Supabase anon key with row-level security behind it, a disaster for an OpenAI key. Secrets belong on a server.

Environment variables and the SPA rewrite

Two configuration steps turn a built project into a working site, and both get skipped.

The rewrite, for anything with client-side routing

Open the site after upload. The home page works. Click an internal link such as /menu, then reload. A 404 there is client-side routing meeting a web server that looks for a file called menu and does not find one. On our October 2026 test LiteSpeed returned 404 for /menu until the rule went in.

A client-side routed app on LiteSpeed needs the standard mod_rewrite fallback in .htaccess so routes like /menu return index.html instead of a 404. Append this to the existing file:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.html$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.html [L]
</IfModule>

Reload /menu and it serves index.html, where your router takes over. One side effect: unknown paths now return index.html with a 200 rather than a 404, which is normal single-page-app behaviour and what your router's not-found route handles.

Environment variables, for anything with a server

In Setup Node.js App, secrets go in the Environment variables table on the application's screen, not in the code the assistant wrote. Add Variable, Done, Save, Restart, and they arrive as process.env.WHATEVER on the next request. We set GREETING on the test app and read it back immediately. Setup Python App has the same table and reads through os.environ.

Two code details decide whether a Node app answers at all:

// 1. Never hard-code the port. The runtime assigns it.
const port = process.env.PORT || 3000;
app.listen(port);

// 2. cPanel's Node runner hands the app the FULL request path. With the
//    app at example.com/api, a route defined as /menu returns
//    "Cannot GET /api/menu". Mount on both, or use a subdomain.
app.use('/', router);
app.use('/api', router);

Three more things from the same test, each worth an hour. Setup Node.js App is not reachable from cPanel's Meridian theme, whose search returns nothing for "Node": switch to the classic theme, then search "Node" and it appears under Software. After uploading package.json, reload the page fully before expecting Run NPM Install, because the panel only detects configuration files on load. And when the app URL shows an error, read stderr.log in the application folder: before NPM Install has run it says Cannot find module 'express'. That log explains every startup crash.

Running an Express or Node.js app with Setup Node.js App has the walkthrough and Node.js environment variables the variables table. Guides on the Node path from an AI tool and on diagnosing a blank site after upload are planned.

Domain, SSL and the first visitor

The files are up and the routes work. Point the domain at the account, by changing nameservers at the registrar or setting an A record, and wait for DNS. Flashcloud issues the free SSL certificate once the domain's DNS resolves to the server; until then the server presents a self-signed certificate for the hostname, which is why a browser warning before DNS is normal rather than broken. The padlock appears after DNS, not before.

You do not have to wait blind. The Flashcloud preview link tool shows a site as a given server serves it before DNS points there, for anyone, free, with links that last 30 days, so you can check the rewrite rule and the images while the old site is still live. After the switch, the Flashcloud DNS propagation checker queries 25+ public resolvers on five continents plus the domain's own nameserver and gives each answer a verdict.

One warning: run NPM Install before DNS is pointed and you may see an availability error. The panel is fetching your Application URL by hostname and the hostname does not resolve yet. Ignore it; on a pointed domain the check passes.

When shared is not enough

Shared hosting runs more than people expect, and it does not run everything.

A shared plan is right when the shape is a static frontend, a static frontend plus a small API, or a WordPress site with an AI-written theme. That is most of what these tools produce, including most things people call an MVP. Flashcloud shared hosting starts at $2.79 a month on an annual term and every plan includes a free domain for life, free SSL, mailboxes, daily backups with 30-day retention and human support, so a bad deploy is a rollback rather than a lost evening.

Move up when one of these is true, not before:

• A process has to stay running and hold state: a websocket layer with real concurrency, a job queue, a long-lived worker.
• The build has to run on the server, because committing the output does not work for your team.
• You want to run and tune the database yourself.
• Resource graphs show you consistently against the CPU or entry-process ceiling, which is a measurement, not a feeling.

At that point it is a VPS, and sizing one is a conversation rather than a guess. The threshold version of this argument is planned, as is a decision matrix that starts from what you built. Running AI-powered apps and features on ordinary hosting goes deeper on runtimes and API keys once your app calls an AI service of its own.

If you would rather hand it over, Flashcloud moves an AI-built site onto your domain for free with every plan: you send the files, we set up the domain, SSL and email. The tool-by-tool deploy steps live on hosting for AI-built websites, and the project you vibe-coded this weekend can be on its own domain tonight.