The short answer
Start with the tool that made the site. Bolt, Lovable, v0, and Claude each have a native way to publish. That is usually the shortest route when the result depends on that tool's database, authentication, server code, storage, or AI features.
Move the site to Birta only when it can run as static browser files and you have a real way to hand those files over. Claude and an eligible ChatGPT account or workspace can write a simple site into a connected Birta draft. Cursor can build and publish the project from your computer. Bolt, Lovable, and v0 can provide source through a download or Git sync, but a file-capable agent must build and verify the static output before Birta can publish it.
This page starts after the site exists. It does not rank AI website builders or offer to generate a replacement. Its job is to route an existing result to the right publishing path. If the site does not exist yet, these prompts produce one that publishes without a build step.
A preview can look complete while its database, server actions, environment variables, or platform services run behind the scenes. If those parts must keep running, use the tool's native Publish option or an application host. Birta publishes static commercial sites, not full-stack applications.
Check the static boundary once
The name of the AI tool does not decide compatibility. Bolt can make a static landing page or a database-backed app. The same is true of Lovable, v0, Claude, ChatGPT, and Cursor. If you have not committed to one of them yet, the question comes earlier than hosting: whether you need a builder at all, which is the subject of the alternatives pages for Lovable, Bolt.new, v0, Figma Make and Base44.
A Birta-compatible result has a finished directory with:
index.htmlat the site root;- CSS, browser JavaScript, images, fonts, and other public assets it refers to;
- no project-owned server process or API route that must stay running;
- no private key or secret placed in files sent to visitors.
Ask the file-capable agent holding the project one question:
After the production build finishes, can this run entirely from the generated browser files, without its own server, database, authentication service, or private environment variable?
If the answer is unclear, use the fuller site-versus-application test. If the output is already plain HTML and assets, the HTML hosting guide owns the exact root-file and path checks. This hub does not repeat either guide.
Choose the route for your tool
| Source tool | Fastest current route | Route to Birta | Stop and stay native or use an app host when… |
|---|---|---|---|
| Bolt | Use Bolt's Publish action for a bolt.host site. | Use Bolt's project download or GitHub sync, open the source in a file-capable agent, build it, and publish the verified static directory. | The project needs a Bolt database, server function, authentication, or private configuration. |
| Lovable | Use Lovable's native Publish flow for its hosted result. | Use code download or Git sync, then build and publish only the static frontend output from a local project; the Lovable hosting guide walks the qualification test and the build step in full. | The useful result depends on Lovable Cloud or another database, authentication, storage, edge function, or secret that is not being operated separately. |
| v0 | Use Publish to Production when its Vercel project is the intended home. | Move the source through v0's GitHub workflow or its documented export path, create a genuine static export, and publish that output from a local agent. | The project uses server actions, API routes, database connections, authentication, or runtime environment variables. |
| Claude | Use Anthropic's Artifact Publish action when a Claude link and its access model are enough. | For a suitable static Artifact still available in its source conversation, follow the same-conversation Claude Artifact guide. | The Artifact needs Claude-powered calls, persistent Artifact storage, connector behavior, or another Claude runtime feature. |
| ChatGPT | If custom connectors are available and enabled for the account or workspace, use the current ChatGPT-to-Birta setup for a simple site the conversation can express as ordinary browser files. | The connected ChatGPT workflow creates a draft, writes the already-built site file by file, returns its preview, and publishes after approval. It does not run a package build. | The connector is unavailable, or the output must install packages, run a build, serve an API, keep a database, or use private server credentials. Move build work to a file-capable tool first. |
| Cursor | Add Birta with the current Cursor connection setup, build the local project, and ask Cursor to publish the verified static directory. | Cursor already has the files and uses Birta's local connection; the shipped local operation validates, then publishes an accepted package directly live. Test the returned live URL and roll back if necessary. | The project still needs a server, database, private API key, scheduled work, or another application runtime after the build. |
The table is intentionally uneven. A native platform and a neutral static host do different jobs. “Can export code” also does not mean “the downloaded folder is ready to host.” Source files may still need dependencies installed, a production build, a static-export setting, and a review of everything the original preview was doing for them.
Three handoffs, not six tutorials
The six rows reduce to three transfer patterns. Knowing which pattern you have is more durable than memorizing every current menu label.
A connected draft for a browser conversation
Claude web and a ChatGPT account or workspace where custom connectors are available do not point Birta at a folder on your computer. With Birta enabled, the conversation creates a project and an unpublished draft, writes browser files into it, and returns a preview. You review that preview before a separate instruction makes it live.
This works for an already-built page the conversation can represent directly. It is not a remote package builder, and it does not fetch a public Artifact or builder URL. The Claude Artifact child guide shows the exact version of this workflow without turning the hub into another tutorial.
A local project for a file-capable agent
Cursor has the project source, can run its build command, and can identify both the project root and the directory the build produced. Birta validates and publishes that directory while keeping the source as the maintained project.
The local operation is draft-first: Cursor hands over the two folders, Birta validates them and puts an accepted package into the project's draft, and the live site does not move. You get the draft's own address, look at it, and mark anything you want changed straight on the page; Cursor fixes the files, uploads again into the same draft, and publishes only when you say it is right. If a later publication turns out wrong, Cursor can list versions and restore the last known-good one.
The same pattern is useful after another tool's source has been downloaded or
cloned. The important change is that a file-capable agent now owns the build and
can see whether the expected index.html and assets actually exist.
Exported source from a hosted builder
Bolt, Lovable, and v0 all document a way for project code to leave or sync with another workspace. Treat that as the beginning of the handoff, not the end:
- obtain authorized source through the tool's documented download or Git route;
- open it in a file-capable agent and identify every runtime dependency;
- produce and test a static build;
- publish only the finished browser directory.
Do not upload the source ZIP simply because it contains package.json, React
components, or a development preview. Those are ingredients. A static host needs
the result.
Stop when the preview needs a runtime
Keep the project on its native host, or move it to a proper application platform, when any of these must continue running:
- user accounts, sessions, permissions, or private records;
- a database owned by the project;
- API routes, server actions, webhooks, or background jobs;
- private keys or environment variables used by server code;
- builder-managed storage, AI calls, connectors, or edge functions.
Sometimes a site has a static frontend and calls a separately managed service. That can be valid, but it is an architecture decision rather than a file export. Confirm the service's allowed origins, authentication model, secrets, ownership, and failure behavior before moving the frontend. This page does not turn a backend migration into a checkbox.
The safe rule is simple: if removing the source platform breaks useful behavior, do not describe the files alone as the same site.
Fix the failures shared by every tool
You have source code, not the hosted result
Seeing src, package.json, or framework components means you probably have a
project that still needs a production build. Ask a file-capable agent to read its
scripts and documentation, run the intended build, and name the output directory.
Birta does not install dependencies or build exported source for you.
The start page is inside another folder
Birta needs index.html at the root of the directory being published. If the file
is dist/index.html or out/index.html, publish dist or out as the site, not
the folder above it. Keep asset paths relative to that same site root.
The source tool supplied invisible runtime help
A blank page, failed button, or missing data after export often means the preview was providing a server, variable, package, database, or platform API. Return to the compatibility check. Either create a real static alternative for that behavior or choose hosting that preserves the runtime.
Images, fonts, or links only worked in the preview
Look for temporary preview URLs, attachment paths, absolute paths from a local computer, and assets that never entered the project. Every public asset must be in the built directory or at a stable authorized URL. Test the public result in a private browser window, not only inside the source tool.
Continue with a focused guide
Use the hub to choose a route, then leave it before the details repeat:
- Claude Artifact: follow the no-download Artifact workflow.
- Lovable: read what Lovable's own hosting covers and when a project can leave it before you export anything.
- ChatGPT: use the current ChatGPT connection steps.
- Cursor: use the current connection setup, then follow the draft-first validation, review, publication, and rollback behavior described above.
- Plain HTML or a built folder: check the static package requirements.
- Material that is not a site yet: if all you have is notes, drafts, and images, see how to publish a folder of files, where the agent writes the pages before anything is uploaded.
- Still unsure whether it is a site or an app: return to the classification guide before choosing a host.
For Bolt, Lovable, or v0, use the first-party export or Git link in the matrix, then continue from a local file-capable tool. There is no verified direct builder-to-Birta import path in this guide.
Publish from the tool that has the finished site
Connect Claude, ChatGPT, Cursor, or another file-capable agent once the static boundary is clear, then check the returned live URL.