# What "built-in backend" means on Lovable, Bolt, Replit, v0 and Base44, and what it leaves out

> Every builder now ships a backend: database, sign-in, storage, functions. What each includes, read from its own docs on 27 October 2026, what none covers, and when the built-in is the right call.

- Source: https://www.buildbase.app/blog/what-built-in-backend-means-on-lovable-bolt-replit-v0-and-base44
- Section: Blog
- Author: Dharmendra Jagodana
- Published: 2026-10-28

## In short

A built-in backend is the database, sign-in, storage and server functions a vibe-coding platform hosts for the apps built on it, so a prompt can add a table or a login. On 27 October 2026, Lovable, Bolt, Replit and Base44 ship one, v0 wires one from a marketplace, and none covers teams, roles, plan limits or credits.

A built-in backend is the database, sign-in, file storage and server
functions that a vibe-coding platform hosts for the apps built on it, so
that a prompt can add a table or a login without you opening an account
anywhere else. It is the reason a non-developer can get a working app in
an afternoon, and it is the reason the app stops at a very particular
place.

That place is the subject of this post. As of 27 October 2026, Lovable,
Bolt, Replit and Base44 each ship a built-in backend, and v0 wires one
together from Vercel's marketplace. Every one of them covers a database, a
login and, on paid plans, a way to take money. None of them documents
teams, roles, invitations, plan limits, seats or credits for the people
using your app. The gap is the same on all five, and it is worth seeing in
one place, because the vendor pages about these builders go stale within a
quarter and most of them still describe last year's builder.

Everything below was read from the builders' own documentation on 27
October 2026, and says so where a claim is a vendor's rather than a
builder's. If you are reading this months later, check the dates against
the changelogs before you lean on a row.

## Why built-in backends exist

They exist because the alternative is a terminal. A Hacker News commenter
put it in one sentence in August 2026, explaining why non-technical
builders pick Lovable over Claude Code: "With CC you still have to host it
somewhere. On Vercel, get a DB somewhere or tell it to use SQLite, which no
one knows what that is. You have to install it and use a terminal which no
one knows how to do."

The first generation of builders did not solve this. They generated a React
app in the browser and left the data to Supabase, which a builder had to
sign up for, configure and secure. Another commenter described the result
in December 2025: Lovable "uses Supabase by default and basically generates
React SPA's with no true backend. But random people won't understand this
distinction and will want to create full real apps." The 2025 scan that
became CVE-2025-48757 found 170 of 1,645 sampled Lovable apps with database
tables any visitor could read, which is what "no true backend" looks like
from outside.

So the builders absorbed the backend. Lovable launched Lovable Cloud in
September 2025, Bolt launched Bolt Cloud the same week, Replit already had
its database and added Replit Auth, Base44 was built around its own data
and identity layer from the start. The business reason sits beside the
product reason: a backend the builder hosts is usage the builder bills.
Lovable draws Cloud usage from the same credit balance as building, Replit
bills deployments and the production database by usage, and Base44's
founder told Calcalist in August 2026 the company expects gross margin to
move from near break-even to about 60% as that usage matures.

## What each one includes

The table is the summary; the paragraphs are what the docs actually say.
"End users" means the people who use your app, as distinct from you and
your collaborators inside the builder.

| Builder       | Database                                                | Sign-in for end users                                                                                                               | Payments                                                                                     | Functions and secrets                                                              | Not documented for end users                                                      |
| ------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| Lovable Cloud | Managed Postgres, storage, realtime                     | Email, phone, Google, Apple, Microsoft, Sign in with Lovable, SAML SSO, OIDC; up to 50 redirect URLs                                | Paddle (5.0% plus 50 cents) or your Stripe, Pro and up; one subscription per user by default | Edge functions; write-only secrets; jobs, logs, usage                              | Teams, roles, invitations, plan limits, seats, credits; email is a separate guide |
| Bolt Cloud    | Database (Supabase-backed per Supabase's post), storage | Email and Google                                                                                                                    | Stripe                                                                                       | Edge functions; a security scan on publish                                         | Teams, roles, plan limits, credits, email                                         |
| Replit        | Replit Database (Postgres), App Storage                 | Replit Auth (sign in with a Replit account) or Clerk Auth (a tenant per app, no organizations yet), own OAuth credentials           | Stripe connector                                                                             | Secrets tool as env vars; Autoscale, Reserved VM, Static and Scheduled deployments | Teams, roles, plan limits, credits                                                |
| v0            | Marketplace: Neon, Supabase, Upstash, Blob, AWS         | None of its own; Clerk and Auth0 one click since September 2026; Vercel owns Better Auth                                            | Stripe in the Marketplace                                                                    | Next.js route handlers; env vars in Vercel; previews run the full app              | Teams, roles, plan limits, credits                                                |
| Base44        | Entities as JSON schemas, managed in Base44             | Email and password, Google, Microsoft, Facebook, Apple, or SSO (Google, Microsoft, GitHub, Okta, custom), SSO exclusive with social | Base44 Payments by Wix, or Stripe                                                            | `functions/` as TypeScript files; project secrets                                  | Teams, roles, plan limits, credits; the function runtime                          |

**Lovable Cloud.** The docs describe "a managed PostgreSQL database,
login, and file storage", with realtime and functions, and say most
projects never need a separate Supabase account. The Users view is a
searchable list with sign-up and last sign-in times and the methods each
person used; the sign-in page mentions no roles, teams, workspaces or
invitations for end users. Secrets are write-only ("its value can never be
viewed again in Lovable, only replaced or deleted") and are injected into
edge functions and server-side integrations at runtime. Payments arrived
on 24 April 2026 through Paddle or your own Stripe, on Pro and up, with
one active subscription per user by default and one provider per project;
a project with payments on cannot be forked. Email is not listed as part
of Cloud; the docs point to a separate guide on sending from your own
domain. Two limits worth knowing before you commit: a database export is
allowed once every 24 hours, and removing Cloud "permanently deletes the
database, its backups, your app's user accounts, and the files in
storage". New apps since 13 May 2026 are TanStack Start apps rendered on
the server; older ones are React with Vite.

**Bolt Cloud.** Bolt's docs describe a database with email and Google
sign-in, storage, server functions and Stripe, a security audit you can
run from the Publish menu, and a Site URL plus a redirect allow list that
Bolt usually updates when you publish. Supabase's own post of 30
September 2025 says Bolt Cloud backends run on Supabase. Bolt hosting is
the default publish target; the Netlify alternative is for static sites,
and Bolt's own page says Netlify "can't host a database or a traditional
backend". Bolt's docs mention no roles, teams or permissions for end
users.

**Replit.** The strongest technical fit of the five, because a Replit
project is a real Linux workspace with a shell, so anything that installs
with npm installs. Replit Auth is "Replit-branded sign-in with zero setup":
your users sign in with a Replit account, through Replit's shared OAuth
apps, in a single environment. Clerk Auth is the other first-party option,
which the docs recommend for "branded apps, professional and commercial
products": a Clerk tenant of your app's own, separate development and
production environments, Google, GitHub, Apple and X with your own OAuth
credentials in production, and a Users tab. The same page lists what Clerk
Auth does not include today, and the first item is "Organization tenants,
Clerk's organization and team-membership features". Roles and permissions
for your users are not mentioned on either page. Secrets are set in the Tools pane and arrive as
environment variables, with production values set separately under
Publishing. After the July 2025 incident in which the agent deleted a
customer's production database during a code freeze, Replit rolled out
automatic separation of development and production databases.

**v0.** v0 generates Next.js with React, TypeScript, Tailwind and shadcn,
and has no backend of its own. Databases come from the Vercel Marketplace
inside the chat; one-click integrations for Clerk, Auth0, Resend and others
arrived in September 2026, and v0 loads a provider's published skills
automatically when its integration is installed, which is how it knows the
provider's patterns. Vercel bought Better Auth on 7 July 2026, so the
likeliest sign-in an agent on v0 reaches for is Vercel's own. Environment
variables live in the Vercel project and reach previews, which run the
full application. Publishing is one click to Vercel.

**Base44.** "Base44 apps are standard React apps built with Vite", with
`entities/` holding a JSON schema per entity and `functions/` holding one
TypeScript file per backend function. With the two-way GitHub integration,
entities are managed in Base44 and are not included in your local
repository. Sign-in is configured in `base44/auth/config.jsonc`: email and
password, Google, Microsoft, Facebook and Apple, or SSO through Google,
Microsoft, GitHub, Okta or a custom provider, with SSO and social login
mutually exclusive. No roles, teams or permissions for end users appear on
that page. In July 2025 Wiz found that Base44's registration and OTP
endpoints accepted requests without authentication, so anyone holding an
app's public id could create a verified account on a private app; Wix fixed
it within about a day and found no abuse.

**Google AI Studio's build mode**, for completeness: its agent provisions
Firebase Authentication and Firestore from the prompt, so it is a sixth
built-in backend in everything but name, with Firebase's rules model
underneath.

## The line every one of them stops at

Read the right-hand column again. Five builders, read on the same day, and
the same four absences: teams, roles, plan limits, credits. It is not an
oversight on one of them. It is where "an app" stops and "a product" begins,
and it is the line a built-in backend was never asked to cross.

Here is what the absence means in practice, in the order a stranger meets
it:

- **The second person from the same company.** The built-in backend gives
  every person an account. It does not give a company one. Two colleagues
  sign up separately, and nothing in the backend knows they belong
  together, so there is nothing for a prompt to build on when you ask for
  "teams". What the agent builds instead is a `teams` table and a `role`
  column checked on one page, which is the bug every audit of a vibe-coded
  app finds. [Teams, invites and admin versus
  member](/guides/teams-invites-and-roles-for-a-vibe-coded-app) is what the
  layer looks like when it exists.
- **The plan that has to change what the app does.** Lovable's built-in
  payments give a user one active subscription. Bolt's and Replit's Stripe
  connectors take a payment. None of them connects the payment to a
  feature, a seat count or a limit, so the connection is code the agent
  writes, usually in the browser, where a February 2026 audit found "a live
  marketplace with real Stripe payments where any logged-in user could
  grant themselves admin". [Paid plans that actually gate
  features](/guides/paid-plans-that-gate-features-vibe-coded-app) is the
  other half.
- **The email that arrives.** Every built-in sign-in sends confirmation and
  reset emails, and every one sends them from a development sender until
  you connect a domain. Supabase's default sender delivers only to your
  project's team, at two messages an hour, by its own docs.
- **The credit that runs out.** An AI feature needs a balance someone can
  spend down and a hard stop when it is gone. Nothing in the five backends
  holds one, which is why "development endpoints still in production that
  let anyone mark themselves as a paid user and give themselves unlimited
  credits" was a finding rather than a surprise.

> **Key takeaway:** A built-in backend answers "where does the data live" and "who is this
> person". It does not answer "which company do they belong to", "what did that
> company pay for" or "how much may they use". Those three questions are the
> product, and on every builder they are yours.

## Where the built-in backend wins

For a single-user app, a prototype, an internal tool or a weekend project,
the built-in backend is the right choice and nothing external comes close.
It is zero configuration inside the builder, it is paid for from the same
balance you are already paying, and the security checks (Lovable's Quick scan
runs on every publish; Bolt's audit is a free button in the Publish menu)
cost nothing extra. Replit Auth is "zero-setup" in the literal sense: ask the agent and
the login page exists.

There are specific things the built-ins have that BuildBase does not, or
has only with more setup. Lovable's sign-in ships SAML SSO and OIDC of its
own, where ours runs through your own WorkOS account on the Enterprise plan,
so an app whose buyer signs in with Okta and wants one vendor is better
served there. Lovable's Paddle option makes someone
else the merchant of record, which handles the tax side; our billing is
Stripe, bring your own, and the tax side is yours. Base44's entities are a
data model you never have to write a migration for. Replit's Clerk Auth
gives a commercial app a branded tenant with separate development and
production environments, provisioned without a Clerk account. If any of
those is the thing you need, the built-in is the pick, and this post is
not trying to talk you out of it.

## When the built-in backend is the wrong choice

The moment two people share an account, the moment a plan has to change
what the app does, and the moment you need to leave.

The first two are the gap above. The third is about the exits, which are
real but narrower than the pitch. Lovable Cloud exports once every 24
hours, removing Cloud deletes your app's user accounts with the database,
and the docs say moving to your own Supabase "isn't a one-step switch": you
export and restore the database, move storage files and code, and set up
auth, secrets and external services again. Base44's entity definitions
stay in Base44 even with GitHub sync on. Bolt's one-click alternative host
is static. Replit's data lives in Replit's database until you export it.
None of this is hidden, but it is the kind of thing people discover on the
day they want to leave, and a commenter on Hacker News in August 2026
described a client's Lovable backend as "completely inaccessible except
through the lovable interface" (Lovable's changelog has since added
exports and a way to create your own Supabase project, so check the
current docs before repeating that).

There is a fourth moment, quieter than the others: when the agent's own
tables go wrong. The built-in backend hosts the database; it does not write
your row rules. UpGuard's scan in September 2026 found 16,326 Supabase
databases with a publicly readable `users` table, and noted that tables
created through the API, which is how coding agents work, "do not enable
RLS by default". Lovable's Quick scan checks that rules exist, not that
they are right, which is the distinction the researcher behind
CVE-2025-48757 drew about Lovable's 2025 scan too. A built-in backend makes
the database easy to create and leaves its safety to the same prompt that
created it.

## Three questions to ask before you lean on one

The table above is what the docs say today. These three questions decide
whether a built-in backend is still the right call in a year, and each has
a different answer per builder, so ask them before the first stranger
signs up rather than on the day you want to move.

**Can I get the database out, and how often?** Lovable: an export once
every 24 hours, and a documented path to your own Supabase project that its
docs call "not a one-step switch". Base44: the code syncs to GitHub both
ways, the entity definitions do not; they are managed in Base44. Bolt and
Replit: the code is in GitHub as soon as you connect it (Bolt polls the
repository for changes about every 30 seconds; Replit's Git tool pushes),
and the data stays in the builder's database until you export it from
there. v0: nothing to export from v0, because the database was never v0's;
it is a Neon or Supabase project in your Vercel account.

**Do my app's users come with me?** This is the question nobody asks. On
Lovable, removing Cloud deletes "your app's user accounts" along with the
database, so the accounts live and die with the backend. On Base44 the
accounts belong to Base44's identity layer, which the GitHub sync does not
carry. On Bolt Cloud and Replit Auth the users are rows in the builder's
sign-in system; Replit's docs describe Replit Auth as Replit-branded with a
single environment, and Clerk as the white-label route, which is also the
portable one. If the people who signed up are the asset, where their
accounts live is the decision, and it is made on the day sign-in is
switched on.

**What does the security scan actually check?** Lovable's Quick scan runs
on every publish and checks that row rules exist; the researcher behind
CVE-2025-48757 drew the line between "a policy exists" and "the policy is
right" about Lovable's 2025 scan, and it still holds. Bolt's audit goes
wider than most: its help page lists checks on whether protected pages
require an account, whether a user can change a price or skip a step,
whether keys reach the browser, and a database review that flags "a
permission rule that allows anyone to read a table". On Replit the
database is reached from your own server code, so the equivalent question
is whether every route checks who is asking, and no scanner answers it.
None of them knows which workspace a row belongs to, so a rule that says
"any signed-in user can read every row" is a rule, and it passes.

The honest summary: the built-in backend is the easiest backend to start
and the hardest to leave, and nothing about that is hidden. It is simply
not on the pricing page.

## How BuildBase sits beside it

BuildBase is not a database, and the rule every agent gets is "do not use
BuildBase as the primary database; pair it with Supabase or Postgres". So
the shape, on every builder, is the same: the built-in backend keeps your
tables, your files and your functions, and BuildBase holds the parts in the
right-hand column (the workspace a customer belongs to, the role each
member has, the plan the workspace pays for, the credits it may spend, the
email that goes out when a card fails), reached through hooks in the app
and a server SDK in your functions.

Each builder has a guide for the join, with what was tested and what was
not: [Lovable](/guides/add-login-teams-and-paid-plans-to-a-lovable-app)
(new apps are TanStack Start, which can hold the sign-in routes; older ones
are Vite and need a server first),
[v0](/guides/add-sign-in-teams-and-paid-plans-to-a-v0-app) (Next.js, where
`npx buildbase init` writes the files), and the
[Claude Code and Cursor](/guides/vibe-coding-with-claude-code-or-cursor)
route for anyone with a terminal. One honest wrinkle applies wherever
Supabase holds the data: its row-level security cannot verify a BuildBase
session directly, so data either goes through server routes that check the
session, or your server mints a Supabase-shaped token; the Lovable guide
has both.

The explainer underneath all of this is [what a SaaS backend is, and
which half of it is your product](/blog/what-is-a-saas-backend): the
account model (who the user is, which customer they belong to, what they
may do, what they owe) is the half the built-in backends leave to you, and
[the launch checklist](/guides/vibe-coded-app-launch-checklist) is the
twenty-item version of what that half contains.
