Best backend for vibe-coded apps: what each one leaves you to check

Every claim about another product below comes from its own docs, read on November 3, 2026. Sources are at the end.

What changes when the app is vibe-coded?

You did not read the code. That is the point of building this way, and for a prototype it is fine. It becomes a problem at one moment: the first time you send the link to someone else. From then on, every table the builder created is reachable by whoever holds the link, unless something stops them.

So the useful question about a backend is not which has the most features. It is: if the generated code is wrong somewhere you did not look, what happens?

Where is your app's backend right now?

If it came from an app builder, probably in the builder's own cloud.

• Lovable turns on Lovable Cloud by default: database, auth, storage, realtime, and edge functions, built on Supabase's open-source foundation. You can connect your own Supabase project instead. Lovable's hosting guide lists the Supabase URL and publishable key as browser variables and says the app relies on row-level security. Its Supabase page warns that missing RLS policies commonly expose data.
• Bolt gives new projects a Bolt database. Its security docs say visitors can send requests straight to the database from the browser, and that for apps without sign-in, Bolt may write policies that let anyone read, change, or delete data.

Both builders scan for this. Lovable runs a quick scan on every publish that flags tables without RLS and rules that let everyone through, plus an on-demand deep scan of the code. Bolt checks every database for missing RLS and always-true policies, and paid plans add a project audit that checks whether one user can reach another's data. Use them. They are also the clearest evidence of where the risk sits.

What should you check on each backend before sharing?

Which backend should you pick?

Stay on your builder's backend if the app is a prototype you show on your own screen, or a public app you will keep building inside the builder. If only a few people should get in, Lovable lets you disable sign-up and add users by hand; Bolt's docs describe turning each sign-in method off, but invite-only access is not described in them. Fix every scan finding either way.

Supabase if the app is public, people sign themselves up, and you want Postgres with realtime. Its Security Advisor flags tables with RLS disabled; run it after every change your agent makes.

Firebase if it is a mobile or consumer app that needs offline sync and a CDN. Review the rules file like code.

Appwrite if you want an open-source backend you can self-host, with many sign-in providers and hosting through Sites.

Convex if the app is realtime at its core, such as a shared board or chat, and you are comfortable with TypeScript. Its docs describe every read and write going through functions, which is a safer default than direct table access, as long as each public function checks the caller.

PocketBase for a personal project on a server you run. Its docs say it is not yet at version 1.0 and not recommended for production-critical apps.

Neon if you only want Postgres and will bring your own host and server.

floo if the app is for you, your team, or a known group, which describes most vibe-coded software that sticks: the tracker that replaced a spreadsheet, the dashboard for the number everyone asks about, the queue someone used to manage by email. floo hosts the app, Postgres, sign-in, cron, storage, Redis, and API keys for agents from one config file in the repo.

Why does floo avoid the RLS problem?

Because it does not hand the browser a way to the database. Every request goes through floo's gateway, which shows invited people a sign-in page and tells your code who they are in request headers. Your server code, which the agent writes alongside the frontend, is the only thing holding DATABASE_URL.

[app]
name = "team-tracker"
access_mode = "accounts"

[managed.default]
type = "postgres"

That does not make permissions disappear. If members should see only their own rows, the server has to filter by the signed-in person. The difference is where the check lives: one WHERE owner_email = $1 in a route you can ask your agent to show you and test, instead of a policy on every table, where a missing policy fails open and nothing visible goes wrong.

How do you move a vibe-coded app to floo?

Both Lovable and Bolt sync your code to GitHub, and both docs say you can host it elsewhere from there. From the repo:

1. Ask your agent to add a small server, for example Next.js route handlers or an Express service, that queries Postgres with DATABASE_URL.
2. Point the frontend at those same-host routes and remove the database URL and key from the browser code.
3. Add floo.app.toml with access_mode = "accounts" and [managed.default], then deploy and invite your team.

The full walkthrough, with a prompt to paste, is in how to add a backend to an app your agent built. If you would rather start clean, the templates are working apps with sign-in, Postgres, and an agent API already wired up. The backend overview lists every part.

When is floo the wrong answer?

• Strangers sign up. floo admits only invited people. There is no self-signup or domain-based admission, and no SAML or OIDC for app users yet.
• Realtime sync. floo passes WebSockets through, but its docs describe no database subscriptions.
• A global audience. floo's docs describe no global CDN or multi-region serving.

For those, pick from the list above and run the pre-share checklist before you send the link. For the longer comparison, see the best backend for apps built with coding agents.

Sources

• Lovable: Lovable Cloud, Supabase integration, external hosting, security scans, authentication, GitHub
• Bolt: Supabase, database security, project security audit, authentication, Git
• Supabase: row-level security, securing your API, database advisors
• Firebase: Security Rules basics, insecure rules
• Appwrite: database permissions, API keys, Sites, self-hosting
• Convex: database, auth, internal functions
• PocketBase: introduction, API rules
• Neon: Data API
• floo: app sign-in, Postgres, networking, environment variables