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 and keep it where it is.

Two situations make another host worth the work. The first is a finished static site you want to keep editing through your own AI agent instead of through Lovable's editor. The second is a site you want to outlive the Lovable project it came from. If you have not committed to Lovable in the first place, the earlier question is whether you need a builder at all.

Even then, only part of a Lovable 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 before Birta can serve it correctly. The section below on whether your project can be hosted as static files is the one that decides it.

What Lovable's hosting includes

Publishing in Lovable takes a snapshot. The live site does not follow your editor: changes only reach visitors when you open the Publish dialog again and publish the changes. That is worth knowing before you go looking for a bug that is really just an unpublished edit.

What you get on the free plan is a lovable.app address with a label you can customize, served without a traffic limit. A custom domain requires a paid Lovable plan, and workspace-restricted access is limited to the Business and Enterprise tiers.

Cost works differently from most hosts, and it is where the confusion in Lovable's own 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 statements are the vendor's own, and the practical reading is that a published project with no Cloud backend has nothing running to spend on. Check the current plans for the numbers, because they move.

Where a Lovable project actually runs

A Lovable project has two halves, and they have different fates.

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

The second half is Lovable Cloud, if you turned it on. Cloud is a managed backend built on Supabase's open-source foundation that gives 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 keeps running 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 one. The second is a backend migration, and it is not a hosting decision.

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? This is 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. Lovable says so plainly and documents two routes out.

On a paid Lovable plan there is a download with no Git involved at all. 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. Downloading individual files works on any plan.

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

Either way, Git is how you get a copy. It is not the deploy pipeline. Guides for Netlify and Vercel 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 at all: your agent uploads the built folder. If continuous deployment from a repo is what you actually want, those guides are the right ones to follow and this page is not.

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 2ConnectSet up Birta in a file-capable agent that can read the folder on your computer.
3. Step 3UploadHave the agent create a project and upload the built folder into a draft.
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/. Birta does not install dependencies or run builds for you, so this step happens on your machine.

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.

Before you go further, look inside dist/. There should be an index.html sitting at its root. That file is what makes the folder publishable at all.

Step 2: Connect Birta to a file-capable agent

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

The in-browser chat connection works differently: it 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, and that is what you want here.

Step 3: Upload the built folder into a draft

Ask the agent to create a Birta project and upload dist as the draft. A useful prompt is specific about which folder is the site:

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, and the live site does not move. On the free plan you get up to 50 projects, each up to 25 MB, which a typical Vite build sits well under. Individual files are capped at 25 MiB and a version at 2000 files, which a landing page will not come close to.

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, since 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 then goes live at https://<project>.birta.link over HTTPS, and if a later publication turns out badly you can roll 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, and no host setting will fix it on Birta.

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, and the free plan does not turn it off. A custom domain also needs a paid plan: Solo at $12 a month connects one, Pro at $39 connects up to five. 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. The free plan lets you read 10 submissions per project per month.

When to keep it on Lovable

Lovable's own advice is to start there and move pieces only against a real constraint, not a hypothetical one. That is good advice, and this list 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 and re-uploading after every change.

If what you want instead is a server you control, running the project with its backend intact, that is a VPS decision. Birta does not run servers and is the wrong tool for it.

Frequently asked questions