Lovable Hosting: What You Get, and When to Move the Site

The short answer

Lovable already hosts your project. Publishing gives it a public address on lovable.app, and that address is free on every plan, with no cap on visitors, requests, or bandwidth. For most people the right move is to stop reading here.

Two situations make another host worth the work: a finished static site you want to keep editing through your own AI agent rather than Lovable's editor, and a site you want to outlive the Lovable project it came from. If you have not committed to Lovable yet, the earlier question is whether you need a builder at all.

Even then, only part of a project can move. The frontend builds to ordinary static files. A Lovable Cloud backend does not move at all, and a project with routes has one more condition to meet, which the static-files test settles.

What Lovable's hosting includes

Publishing takes a snapshot. The live site does not follow your editor: changes reach visitors only when you open the Publish dialog again. Worth knowing before you hunt a bug that is an unpublished edit.

The free plan gives you a lovable.app address with a customizable label, served without a traffic limit. A custom domain requires a paid Lovable plan, and workspace-restricted access is Business and Enterprise only.

Cost works differently from most hosts, which is where the confusion in Lovable's community comes from. There is no separate hosting bill: Lovable uses one credit balance for building the app, hosting it, and running its built-in backend, and the same docs say publishing to a lovable.app URL is free on every plan. Both are the vendor's statements, and the practical reading is that a published project with no Cloud backend has nothing running to spend on. Check the current plans, because the numbers move.

Where a Lovable project actually runs

A Lovable project has two halves with different fates.

The frontend is standard: Lovable projects are Vite applications and build as static frontends, so npm run build produces a dist/ folder of HTML, CSS, JavaScript and assets. Nothing in it needs a server. Any static host can serve it, Birta included.

The other half is Lovable Cloud, if you turned it on: a managed backend built on Supabase's open-source foundation giving the project a database, sign-in, file storage, edge functions and AI calls. It runs on Lovable's infrastructure in a region you picked once, and it stays there no matter where the frontend is served from.

So "moving the site" and "moving the app" are different jobs. This page covers the first.

Can your project be hosted as static files?

Three tests. All three have to pass.

Test one: does it need Cloud to be useful? If removing the backend leaves a page that still does its job, you can move it. If the point of the project is the login, the saved records or the AI call, keep it on Lovable.

Test two: is every URL a real file? The one people miss.

Test three: is anything in the build a file type a static host will not serve? Almost always no. A Vite build is HTML, CSS, JavaScript, images and fonts, and Birta serves all of those. Video, audio and PDF files are the exception: they are dropped from the published package, so host them elsewhere and link out.

Getting the code out of Lovable

You own the code, and Lovable documents two routes out.

On a paid plan there is a download with no Git involved: everyone with edit access can click Download codebase at the bottom of the file panel to save the entire project as a .zip, and the same button sits in Project settings → Git. Individual file downloads work on any plan.

The other route is GitHub or GitLab sync, which goes both ways: edits in Lovable reach the repository, pushes to the active branch come back. The repository is private by default, it is yours, and it stays intact with its history if you disconnect. Lovable syncs one branch at a time.

Either way, Git is how you get a copy, not the deploy pipeline. Netlify and Vercel guides start by connecting the repository to the host, so every publication runs through a push and a build on their side. Birta never connects to a repository: the built folder goes to Birta's chat as an upload, or your agent sends it. If continuous deployment from a repo is what you want, those guides are the right ones.

Publish the built site to Birta

1. Step 1BuildRun the project's build locally and confirm the dist folder has index.html at its root.
2. Step 2Hand overUpload dist to Birta's chat, or set up Birta in a file-capable agent.
3. Step 3UploadHave the agent put the built folder into a draft of a new project.
4. Step 4PublishOpen the draft's own address, check it, then approve publication.

Step 1: Build the static site

Open the downloaded or cloned project and run its build. Lovable documents npm run build with an output directory of dist/, and this step happens on your machine, because Birta installs no dependencies and runs no builds.

If the project uses Cloud, the Supabase values have to be present when the build runs. Lovable bakes VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID into the bundle at build time, not at request time. Birta has no environment variables and strips .env files out of any package, so uploading them later does nothing.

Then look inside dist/: an index.html at its root is what makes the folder publishable.

Step 2: Choose the chat or a connected agent

The shortest route is Birta's chat: upload the dist folder, or a zip of it, and its agent takes it from there, with nothing to connect.

To work from your own agent, use one that can read files on your computer, such as Claude Code or Cursor. The connection guides cover each one, and there is a reference for any other tool that speaks the same protocol.

The in-browser chat connection writes files one at a time, which is fine for a hand-written page and wrong for a Vite build full of hashed asset filenames. The local connection uploads a whole folder in one go.

Step 3: Upload the built folder into a draft

Ask the agent to create a project and put dist in as the draft. With your own agent, name the folder explicitly:

Create a Birta project called <name>, then upload ./dist as the draft.
Do not publish yet. Give me the draft address.

The draft is stored and validated while the live site stays put. A typical Vite build sits well inside the free plan's space for one project.

Step 4: Check the draft, then publish

The draft has its own address. Open it and click through everything, especially any link that is not the home page, because that is where the routing problem shows up.

If something is wrong, leave a comment on the page itself and have the agent fix and re-upload into the same draft. Publish only when the draft is right. The site goes live at https://<project>.birta.link over HTTPS, and a bad publication rolls back to the previous version.

What to check after publishing

Deep links and refreshes

Open a second-level page directly in a new tab, then refresh it. A 404 here means the routing test in the qualification section was not passed: no host setting rewrites those paths on Birta. The build shapes that hold up are the two named in that section.

Assets and fonts

Check that images and fonts referenced by the build actually shipped inside the folder you uploaded. Anything that lived only in Lovable's preview, or at a temporary URL, will be missing.

The Supabase connection

If the project uses Cloud, the published page still calls the backend from the visitor's browser. Load it and watch whether the data actually arrives. If requests fail from the new address while the same page works on lovable.app, the backend is refusing the new origin, and that is settled on the backend side. Birta has nothing to configure there.

The Birta mark and your domain

Published sites carry a small "made with Birta" mark on the free plan; removing it is the Team plan. Your own domain works on the free plan. The custom-domain guide covers the DNS part, and the connect flow covers the rest.

Forms

If your Lovable page had a form backed by Cloud, that form stops working the moment you leave the backend behind. Birta has its own lead forms with no database to set up. They deliver to the project panel and an email digest every 15 minutes, and nowhere else: no Telegram, no Slack, no webhook.

When to keep it on Lovable

Lovable's own advice is to start there and move pieces only against a real constraint. Good advice, and this is where it applies.

Stay on Lovable when your project has any of the following:

• accounts, sign-in, or anything a visitor logs into;
• a database, saved records, or uploaded files;
• edge functions, scheduled jobs, or secrets used by server code;
• payments, which Birta does not collect on published sites;
• a multi-page route structure you do not want to rebuild;
• daily editing in Lovable, since publishing elsewhere means rebuilding after every change.

If what you want is a server you control, running the project with its backend intact, that is a VPS decision and Birta is the wrong tool.

Frequently asked questions