AI Website Builders with Code Export: What You Can Actually Self-Host

The answer: code ownership is only the first part of an exit

Lovable, Bolt and v0 document ways to take editable code outside their builders. That does not move the database, sign-in system, uploaded files or paid APIs automatically. Choose a destination that can run your actual framework, then decide which services to retain and which to replace. A marketing page and a customer application have very different exit costs.

Framer needs a separate decision: its official help pages give contradictory answers about downloading the published site. They do not establish a native export of an editable Framer project. If an independently operable source repository is a firm requirement, resolve that gap before choosing it.

This guide compares portability conditions, not build quality, speed or the cheapest subscription. For overall tool selection, start with our AI website and app builder guide.

What can you take, and what stays a separate job?

“Third-party hosting” means another company runs the destination. “Fully self-hosted” means you operate the necessary runtime and services yourself. A frontend hosted elsewhere while still calling the original backend is a hybrid setup.

These are documented capabilities, not completed exports from our accounts. This review does not establish a free-plan entitlement wherever the source does not specify one.

Lovable: a source exit, with a choice of how much to move

Lovable's plan table explicitly includes Git sync on Free, Pro, Business and Enterprise; direct code download is paid-only. Its GitHub guide describes two-way sync of one active branch at a time. A ZIP is a snapshot; Git is the continuing development path.

Check package.json before choosing a host. The ownership guide distinguishes new TanStack Start apps from older React + Vite apps. Static files alone do not run a server-rendered application. Choose this route when you can own the build and maintenance work; avoid a “just upload the folder” assumption for an app with server features.

The external deployment guide separates source files from database records and storage. It documents backend migration to your own Supabase project and replacement of Lovable-mediated AI and connector calls when leaving that backend. Secrets must be configured at the destination. Restored user accounts still require authentication-provider setup, and active sessions do not transfer. Keeping Cloud while moving only the frontend is a valid hybrid, but is not complete independence.

For a developer handoff, ask for the repository, dependency lockfile, service inventory and a reproducible deployment. Source ownership does not supply the operational work. Lovable profile.

Bolt: ZIP or Git is a code handoff, not a database transfer

Bolt's project guide documents Export → Download as a ZIP to open in your own editor. The documented local workflow requires Node.js and dependency installation. A working development preview is useful, but production deployment still needs the project's actual build and server requirements.

The Git integration guide describes automatic commits and fetching external changes, plus deployment through Bolt, Netlify or another service. It also warns that near-simultaneous edits can overwrite the GitHub version with Bolt's changes. Coordinate editing and review the final commit; a sync connection is not a substitute for a backup.

Database advanced settings offers claiming a Bolt Database into Supabase, with a Pro or Teams requirement. It warns that connecting a different database replaces the connection and can cause data loss. Claiming a managed database is distinct from exporting and operating the entire backend yourself.

Use Bolt for a code-based prototype or client handoff when someone will maintain the resulting app. Before promising complete independence, inventory its database, authentication, file storage, server functions and external providers. Do not assume they are inside the ZIP. The export and Git docs reviewed here do not establish every account's plan-level entitlement; confirm your own workspace controls. Bolt profile.

v0: portable application code with a Vercel-centered workflow

The v0 FAQ expressly permits exporting code and deploying elsewhere. Its Git import documentation describes an existing repository workflow with isolated working branches. Git is optional; connecting it provides a path for review and continuing development, not a promise that every cloud resource travels with a commit.

For an ongoing handoff, use a repository you control and verify the branch and commit that contain the final app. The reviewed current documents confirm code export but do not establish a universal one-click ZIP button or its plan entitlement, so we do not promise that particular UI path.

v0's database documentation treats providers as integrations. Its AI integration guide describes Vercel AI Gateway as the default and supports provider-specific credentials. A new host must retain authorized access or use an intentionally configured replacement. Copying source does not copy credentials, provider accounts, usage balances or stored records.

This is a reasonable route for developers prepared to operate the chosen framework and integrations. It is less suitable for a client expecting a folder that runs every feature on any static host. Identify server routes, generated assets and remote storage before agreeing to a destination. v0 profile.

Framer: two official statements that remain in conflict

Both pages below display September 15, 2026 as their update date. We checked them on October 5. Neither date lets us dismiss the other statement as simply older.

• Can I export my website to HTML and self-host it? says Framer does not offer downloadable published HTML files or a static-site bundle, and explains dependencies on its hosted services.
• Porting your data from Framer says published HTML, CSS, JavaScript and assets can be downloaded and moved; it separately describes CMS export through plugins as CSV or JSON.

Published output is not the editable design project. Even making that distinction leaves a direct disagreement about the published files. We therefore cannot confirm a native whole-site download procedure from these pages alone. Ask Framer to identify the supported export path for your project and verify the actual result before buying on that basis.

A third-party exporter that captures or rebuilds a public site is a separate workflow. A CMS plugin moves content records, not necessarily design behavior, asset rights, forms or the hosted CMS itself. A reverse proxy still depending on Framer does not make the site independent.

Framer can fit a team that wants a hosted visual publishing workflow. If the contract requires editable source and operation without the platform, treat that requirement as unresolved rather than signing off on a generic portability claim. Framer profile.

What remains after you stop subscribing?

Keep two questions separate: what you already hold in your own repository or files, and which hosted services will keep running. Export and verify before cancelling or deleting an account. This review did not test any cancellation.

• Lovable: the ownership policy says your code and content are yours, subject to third-party rights. The subscription guide says cancellation moves the workspace to Free at period end. That preserves a distinction between owned copies and paid editor/hosting entitlements; it is not a promise of unlimited ongoing Cloud service.
• Bolt: its ownership statement says created code is yours. Cancellation becomes a Free-plan downgrade at the next period. Your exported code and separately controlled repository are the handoff assets; continued hosted capacity follows applicable service limits.
• v0: the FAQ says Vercel does not own generated code, with suitability and third-party-IP caveats. A copied repository is separate from v0 access and Vercel/provider billing. The reviewed pages do not establish a universal post-cancellation hosting or project-retention guarantee.
• Framer: the portability page describes reusable output and CMS data, but the conflicting export guidance remains. We have not confirmed what a particular cancelled site can still retrieve or serve. Obtain and validate permitted copies before relying on that exit.

For any builder, record asset and dependency licenses. Paying for an editor does not automatically license every font, stock image, package or user-uploaded file for your destination.

Two different migration plans

A static presentation site

1. List the routes, redirects, images, fonts and any remote scripts. Identify CMS-generated pages and form submissions.
2. Obtain permitted source or published assets through the documented route. Build the project and determine whether the output truly needs no server.
3. Put an isolated copy on a compatible staging host. Test direct visits to nested URLs, page refreshes, mobile navigation and asset loading.
4. Replace external form or CMS dependencies intentionally. Compare titles, canonical URLs, robots rules, redirects and sitemap before a later authorized traffic switch.

An application with accounts and data

1. Map each service: database and schema, auth provider, storage, background work, server functions, email, payments and AI calls.
2. Arrange a permitted backup and restore plan. Recreate access policies and secrets without committing private keys to the repository.
3. Configure the destination runtime, provider callbacks, allowed origins, storage URLs and webhook endpoints. Decide what remains managed elsewhere.
4. Test read/write permissions and complete user journeys with isolated data. Reconcile records and files, plan the final data sync and retain a rollback path before switching traffic.

These are proposed acceptance steps, not a claim that we performed a migration. A page loading successfully does not prove that registration, a form, a receipt email or a payment callback works.

Migration acceptance checklist you can give a developer

• Code: a known commit or dated archive, lockfile, build instructions and dependency licenses are available outside the builder.
• Runtime: the intended production build runs on the destination; server-rendered routes and functions are tested, not just the homepage.
• Content: CMS rows, relationships, media, slugs and redirects reconcile with the original inventory. A CSV alone is not a running CMS.
• Accounts: sign-in, sign-out, reset flow and permission boundaries work with the new callbacks and keys.
• Data and files: reads, writes, private-file access and backups work under the intended user roles.
• Business flows: forms, delivery email, payment webhooks and AI calls reach their intended services, using authorized test modes and budgets.
• Operations: logs, error reporting, HTTPS, environment variables, restore procedure and a named maintainer exist.
• Exit: document every remaining vendor dependency and bill. Only claim independence after removing or explicitly retaining each one.

Does code export make a project open source?

No. Export describes access to files. Open-source status depends on a license; third-party dependencies and assets have their own terms.

Have these builders been migrated in this review?

No. This is a first-party-documentation comparison. We did not connect accounts, export a sample, change DNS or databases, or measure deployment time and cost.

Next: choose a builder by deliverable, compare self-hosted AI tools, or browse coding and development tools.