Can You Actually Self-Host What an AI App Builder Gives You? (September 2026)

Quick answer (September 2026). Usually not on the first try, and the reason is almost never the code. Every mainstream AI app builder now hands you a repository, and on BuilderProof's published portability leaderboard four of the five commercial builders we track score 7 or 8 out of 10 on getting that code out. What the export does not hand you is the set of running services the app was quietly leaning on while you built it: a database somebody else operates, an auth service somebody else patches, object storage, scheduled jobs, and in several cases the AI provider account that pays for the app's own model calls. Self-hosting means supplying all of those yourself. This page answers the practical version of the question, using scores and levels BuilderProof has already published rather than new ones, and it names the specific reason the obvious test gives you a false pass.

The question people actually ask

The benchmark version of this question is "how portable is the output?" The version people actually type is closer to: if I cancel my subscription tomorrow, is the app I built still running on Friday?

Those are not the same question, and the gap between them is where buyers get hurt. Code export is the part of the answer that is easy to verify, easy to market, and largely settled. Almost every builder in this category now offers a ZIP download or a two-way Git sync, and the code that comes out is usually a recognisable standard project. If your test is "can I get the files", you will pass, and you will have learned very little about Friday.

The thing that decides Friday is not the files. It is how many running services the files expect to find, and whether you can stand each of them up yourself.

What our published numbers already establish, and what they do not

BuilderProof has two existing pages that bear on this, and it is worth being precise about what each one settles.

The code ownership and portability leaderboard (published July 2026, documentation-sourced) scores the five commercial builders we track on a 0 to 10 ownership-and-portability axis: v0 and Bolt at 8, Lovable and Replit at 7, Base44 at 4. Those numbers answer whether the code can leave, and they were derived by reading vendor documentation, not by running a hands-on harness.

The runtime lock-in and self-host depth axis (proposed August 2026) exists precisely because the first question does not settle the second. It sets out four levels: tethered, partial eject, standard-stack eject, and self-host by default. That axis is a pre-registered proposal, not a scored leaderboard, and it deliberately names the pattern rather than assigning builders to levels, because doing that properly requires the hands-on eject harness we have not yet run.

So, stated plainly: a high portability score is compatible with an application that will not start once the vendor is removed. Exporting every source file and remaining dependent on a vendor's hosted database, auth, runtime or storage are not in tension. They are routinely both true of the same project. We are not publishing new scores on this page, because we have not run new measurements, and a page that invented placements would break the only rule that makes the published ones worth anything.

What is actually still attached

Here is the part the export does not cover. This is a checklist, not a score. Read it as the set of things you have to supply before the exported repository becomes a running application.

The last row is the one people underestimate, and it is not our characterisation. It is the vendors' own.

Two vendors independently publish the same list

The most useful thing we found while writing this page is that you do not have to take a benchmark's word for the operational cost. Two unrelated vendors document it themselves, about their own products, and their lists converge.

Lovable's ownership documentation is unusually direct about both halves. It states the company is "intentionally built so that you are never locked in", that "all Lovable projects can be continuously synced to a Git repository at any time", and that applications "are standard Vite + React projects" with "no proprietary frameworks, no hidden dependencies". It then carries a section headed "What changes if you stop using Lovable", which lists eight things you become responsible for: development environments and debugging workflows, CI/CD pipelines and release processes, production infrastructure with SSL certificates, CDN configuration and scaling, databases, storage systems, backups and access controls, authentication and data isolation policies, OAuth flows, secrets and external API integrations, AI provider accounts, credentials, billing and rate limits, and security audits, monitoring and compliance posture. The doc closes that list with a sentence worth quoting exactly: "This is simply the operational boundary of moving off a fully managed platform." (Lovable documentation, deployment, hosting and ownership, retrieved 11 September 2026)

Supabase, which sits behind the backend of several builders in this category, publishes a seven-item version of the same list under the heading "Your responsibilities when self-hosting": server provisioning and maintenance, security hardening and keeping the OS and services updated, service configuration and management, Postgres database maintenance, high availability and scalability, backups and disaster recovery, and monitoring and uptime (Supabase self-hosting documentation, retrieved 11 September 2026).

Neither list was written by a critic. Both were written by the vendor, about its own product, in documentation aimed at customers who are asking exactly the question this page is about. That convergence is the strongest available evidence that the operational surface is real and roughly the size both of them say it is.

We cite Lovable's list at length because it is the clearest published statement of the boundary we could find, and we want to be explicit that publishing it is a point in that vendor's favour rather than against it. A builder that writes down what you inherit is doing the reader a service. Its absence elsewhere is not evidence of anything; we did not audit which other vendors publish an equivalent page, and that omission is deliberate, because assigning vendors to levels is what the harness is for.

The word doing the most work is "equivalent"

Here is the seam, and it is the reason the two lists above are not the whole story.

Lovable's own compatibility table says the backend can move to "managed Supabase, self-hosted Supabase, or other PostgreSQL-based backends with equivalent auth, storage, and edge services". That is an accurate description of the swap being available. It is a claim about the shape of the interface, not a claim about feature parity.

Supabase's documentation about self-hosted Supabase says something the builder's page has no reason to say. It records that, relative to the managed platform, "branching, advanced metrics beyond logs, managed backups and PITR, analytics and vector buckets, ETL, and the platform management API are unavailable", that self-hosted Supabase "runs as a single project which means that Studio doesn't support multiple organizations or projects", and that self-hosted Supabase "is community-supported". The Docker guide adds concrete floors: 4 GB of RAM minimum and 8 GB or more recommended, 2 CPU cores minimum and 4 or more recommended, and 40 GB of SSD minimum (Supabase self-hosting with Docker, retrieved 11 September 2026).

Put the two documents side by side and the resolution appears, and neither one states it alone: the swap is available and it is not free. The interface is genuinely portable. The operational guarantees attached to the managed version are not part of the interface, so they do not travel with it. A reader who takes "equivalent" at face value will plan a migration and discover the missing pieces after the cutover, which is the worst possible time.

There is a second-order version of this that deserves naming. Supabase's own page says self-hosting "is a good fit if you need full control over your data, have compliance requirements that prevent you from using managed services". The same page lists managed backups and point-in-time recovery among the things that become unavailable. Backups and recovery are frequently themselves compliance requirements. That is not a contradiction in the documentation; it is an honest description of a genuine trade, and it is exactly the kind of trade a portability score cannot express.

The still-signed-in illusion

Every cheap test of self-hostability is run while you are still a customer, and that is the whole problem.

Your subscription is live. Your API keys still work. Your DNS still points at the platform. The database the app talks to is the one the vendor is operating for you, and it answers, because you are paying for it. In that state, an application that stands alone and an application that is completely tethered behave identically. Every observation you can collect comes from a single actor, the vendor, still fully in the loop. We call this the still-signed-in illusion, and two documented mechanisms make it concrete.

The first is build-time configuration. Next.js documents that variables prefixed for browser exposure "will be inlined into the JavaScript bundle during next build" (Next.js self-hosting guide, last updated 25 August 2026, retrieved 11 September 2026). This is correct, intended behaviour, and it means that changing an environment variable on your own host does nothing to an already-built bundle. You can re-point every value in your configuration, deploy, watch the app work perfectly, and still be calling the vendor's hostname, because the old value is compiled into the JavaScript your users download. The app works. It works because it is still using the platform.

The second is the local stack. Supabase's documentation states plainly that its CLI "runs a local stack for development and testing" and that "that stack is not a self-hosted deployment: it is not hardened for production and must not be exposed to external traffic". Running the project locally and seeing green is not the test people think it is. It demonstrates that the code runs against a backend of that shape. It demonstrates nothing about whether you can operate one.

The same page is worth reading for what it does confirm. Self-hosted Supabase run via Docker Compose "does not phone home or collect any telemetry", which is a real and checkable property, and the sort of thing the hidden-platform-glue signal in our runtime lock-in axis is looking for.

Three tests that tell you nothing, and three that do

Tests that pass while you are still signed in, and therefore prove nothing about Friday:

1. Downloading the ZIP or cloning the synced repository. Confirms export, which was never in doubt.
2. Running npm install and a local dev server with your existing .env in place. Confirms the code compiles against the vendor's live services.
3. Deploying the frontend somewhere else while the backend stays where it is. Confirms half an app runs, which is the definition of the partial-eject level rather than evidence against it.

Tests that actually discriminate, all of which you can run today, before you commit:

1. Empty-backend start. Create a fresh, empty database you control, point a clean checkout at it, run the vendor's documented migration or schema path, and start the app. If there is no documented path from empty to working, you have found the answer.
2. Rebuilt-bundle grep. Change the public configuration to your own hostname, rebuild, and search the built output for the vendor's domain. If it is still there, your re-pointing did not happen.
3. Credential removal. Remove the vendor's keys from the environment entirely, rather than replacing them, and see which features fail. What breaks is your list of attached services, produced empirically rather than from a docs page.

None of these requires cancelling anything, and all three are reproducible, which is the only property we actually care about.

What this page does not claim

We have not run a hands-on eject across the builders, so this page assigns no builder to a self-host level and publishes no new score. The July portability numbers quoted above remain documentation-derived, and the four self-host levels remain a proposal. Converting that proposal into measured placements is the work, and it is open.

One further boundary, because it borders an existing axis. Whether a public configuration value leaks something it should not is a secrets question, and we score it separately in our secrets-handling proposal. The question here is the opposite direction: whether a value you deliberately changed actually reaches the running application. An app can have flawless secret hygiene and still be impossible to re-point without a rebuild, and an app that inlines a genuine secret has a security defect that says nothing at all about whether it self-hosts. They move independently.

A related boundary worth flagging for anyone who does complete the move: once authentication stops being the vendor's problem, the behaviour of the credentials it issues becomes yours. What ends a session, how soon, and whether anyone can end one early is a separate question we pre-registered in our session lifetime and revocation axis (September 2026). Self-hosting hands you that decision whether or not you noticed inheriting it.

How to contribute

BuilderProof pages are community-editable, and this one is more useful with real transcripts than with more reading. If you have taken an exported app off a builder, the most valuable thing you can send is what actually stopped: the vendor doc you followed with the date you read it, the exact commands, and the first thing that failed once the platform was out of the loop. Counter-evidence is as welcome as confirmation. Reports that a builder ejects cleanly are exactly as useful as reports that one does not, and they are what turn the proposed self-host levels into measured ones.

BuilderProof is an independent, methodology-first benchmark of AI app builders. We score from published rules, cover all five commercial builders, and keep every axis open to public revision.

BuilderProof editorial team. "Can You Actually Self-Host What an AI App Builder Gives You? (September 2026)". BuilderProof, September 2026. https://www.builderproof.org/benchmarks/can-you-actually-self-host-what-an-ai-app-builder-gives-you-september-2026.

@misc{builderproof-can-you-actually-self-host-what-an-ai-app-builder-gives-you-september-2026,
  title  = {{Can You Actually Self-Host What an AI App Builder Gives You? (September 2026)}},
  author = {{BuilderProof editorial team}},
  year   = {2026},
  month  = {sep},
  howpublished = {\url{https://www.builderproof.org/benchmarks/can-you-actually-self-host-what-an-ai-app-builder-gives-you-september-2026}},
  note   = {BuilderProof, builderproof.org}
}