A Firebase alternative for apps your agent builds

TL;DR

Firebase is built for apps whose clients talk to the database directly: mobile apps, offline sync, public sign-up. If your agent is building a web app for a known group of people, floo is the alternative: it hosts the app, its Postgres, storage, and schedules from one floo.app.toml, and signs people in at the gateway before any request reaches your code.

Data access: Firebase clients read and write Firestore directly, and Security Rules are the guard. On floo the database connection string is injected only into your server's container, so the browser talks to your code and your code talks to Postgres.
Sign-in: Firebase Authentication is open sign-up by default. floo apps in accounts mode are invite-only, with no auth code.
Agents: Firebase's server credential is a service account with full admin privileges. floo gives each agent a key scoped to declared routes.
Where Firebase leads: realtime sync, offline persistence, mobile and game SDKs, public sign-up with many providers, and mobile tools like Crashlytics and Cloud Messaging.

Facts about Firebase come from its own documentation, read on November 3, 2026. Sources are listed at the end.

What does each one give an app your agent builds?

	Firebase	floo
Web app hosting	Hosting for static and single-page apps; App Hosting for server-rendered Next.js and Angular from GitHub	Any service with a Dockerfile, deployed from GitHub on every push
Database	Firestore (NoSQL documents), Realtime Database, or SQL Connect (Postgres on Cloud SQL)	Managed Postgres, `DATABASE_URL` injected into your service
Who guards the data	Security Rules on every client request; `@auth` levels on SQL Connect operations	Your server code; the browser has no database credentials
Sign-in	Firebase Authentication, open sign-up by default; restricting it needs Identity Platform's sign-up setting or its blocking functions	`access_mode = "accounts"`: invite-only sign-in at the gateway
Agent credential	Admin SDK service account with full admin privileges	Key per named consumer, scoped to declared routes, rate-limited, with request history
Scheduled work	Scheduled Cloud Functions on Cloud Scheduler	`[cron.<name>]` runs a command in your app's container
Files	Cloud Storage, accessed from clients under Security Rules	Private S3-compatible buckets, per environment
Previews	Hosting preview channels per pull request, using your real backend; a separate project per environment	Pull request previews with their own managed resources and a Postgres branch

Who guards the data?

Firebase's client SDKs connect straight to Firestore and Realtime Database from the browser or phone. Firebase's docs say each request is evaluated against your Security Rules before it reads or writes anything, and call the rules the only safeguard against malicious users. When you create a database you pick locked mode or test mode, and test mode lets anyone read and write. Server code using the Admin SDK bypasses the rules entirely.

That model is what makes Firebase fast for mobile apps. It also means every collection your agent adds needs a correct rule, and an agent that opens a rule to get a screen working has opened it for everyone.

On floo there is no client SDK for the database. [managed.default] with type = "postgres" provisions Postgres, and floo injects DATABASE_URL into the service's container at deploy time. The credentials never enter Git or floo.app.toml. Requests reach your app through floo's gateway, which runs sign-in first, so a browser's only path to the data is your own server code. That code still decides which records a signed-in person may see, the same as in any server-rendered app, but there is no second rules language to keep in sync with it.

How does sign-in work?

Firebase Authentication supports email, phone, anonymous, and many social providers, and sign-up is on by default. To stop strangers creating accounts, you upgrade to Identity Platform, then either turn off user sign-up or write a blocking function that rejects registrations. There is no built-in invite: the Admin SDK can generate an email sign-in link, and your own email service delivers it.

On floo, sign-in happens before the request reaches your app:

[app]
name = "orders"
access_mode = "accounts"

floo apps invite teammate@acme.com --role member sends the invitation. Your code reads the signed-in person from X-Floo-User-Email, and removing someone revokes their sessions. See app sign-in.

How does an agent get access?

Firebase has two kinds of credential. API keys restricted to Firebase services only identify the project and do not need to be kept secret; Security Rules and App Check do the protecting. The Admin SDK authenticates with a service account and has full admin privileges. App Check confirms a request comes from your genuine app, not which caller sent it. Firebase's docs do not describe a key scoped to one caller for your app's own routes.

Firebase does serve agents that build the app: its MCP server lets an agent create projects, deploy, query Firestore, and read logs with the Firebase CLI's credentials.

floo covers both jobs. An agent operates floo through the CLI, the HTTP API, or the hosted MCP server. For an agent that uses the app, such as one that files orders every morning, you declare which routes accept a key and mint one for a named consumer:

floo apps consumers create order-agent
floo apps keys create order-agent --consumer order-agent --scope orders.write --rate-limit-rpm 60

The key works only on routes declared with that scope. floo strips it before your code sees the request, passes the consumer's identity instead, and lists every request by key ID. See app API keys.

What about schedules and previews?

A Firebase scheduled function uses onSchedule and runs on Cloud Scheduler. Its docs warn that a run can start while the previous one is still going. On floo, a [cron.<name>] block takes a cron expression and runs a command in one of your service images, with the same database and environment variables. See cron jobs.

Firebase Hosting can create a preview channel for each pull request through a GitHub Action, but its docs warn that previews use your real backend resources. For isolation, Firebase recommends a separate Firebase project per environment. floo previews are off until you set preview_environments = true under [github]; then each pull request gets its own URL and its own managed resources, including a Postgres branch, so an agent's migration never touches dev or prod. See preview environments.

What about Firebase Studio?

Firebase's migration guide says Firebase Studio stopped accepting new workspaces on June 22, 2026 and shuts down on March 22, 2027, and points users to Google Antigravity or Google AI Studio. Firestore, Authentication, App Hosting, and the other core products are not affected. If you built in Studio, the app's backend can stay on Firebase; the choice is where you build and host from here.

Where is Firebase stronger?

Realtime and offline. Firestore listeners push every change to the client, and offline persistence is on by default on Android and Apple. floo proxies WebSocket requests to your app, but has no realtime sync product.
Mobile and games. SDKs for Apple, Android, Flutter, Unity, and C++. floo has no mobile SDKs.
Public sign-up. Many providers, plus SAML and OIDC through Identity Platform. floo's app sign-in is invite-only, and SAML or OIDC for app users is not available yet.
Mobile operations. Crashlytics, Cloud Messaging, Remote Config, and Analytics.

Which should you choose?

Choose Firebase for a mobile app or a public consumer app whose clients sync data live and work offline. Choose floo when your agent is building a web app for a known group of people, and some agents, and you want hosting, Postgres, sign-in, schedules, storage, and previews in one file in the repository, with no rules file standing between the browser and your data.

See the backend for apps your agent builds, start from a template, or read floo vs Supabase for the Postgres-with-row-level-security version of this comparison.

Sources

Frequently asked questions

Why do Firebase apps depend on Security Rules?

Firebase's client SDKs read and write Firestore, Realtime Database, and Cloud Storage directly from the browser or phone. Firebase's docs say every such request is checked against your Security Rules, and that the rules are the only safeguard against malicious users. A test-mode database lets anyone read and write.

Can I make a Firebase app invite-only?

Partly. Sign-up is on by default. With the Identity Platform upgrade, its user actions setting can stop end users from creating accounts, and blocking functions can reject a sign-up. Firebase has no built-in invite email: the Admin SDK generates a sign-in link and you send it yourself. On floo, access_mode = "accounts" makes the app invite-only and floo apps invite sends the invitation.

Does Firebase have Postgres?

Yes. Firebase SQL Connect, formerly Data Connect, is managed PostgreSQL on Cloud SQL with a GraphQL schema and an @auth level on every operation. Firestore, Firebase's main database, is a NoSQL document store.

How does an agent get a credential on Firebase?

Firebase API keys restricted to Firebase services only identify the project and do not need to be kept secret. Server access uses the Admin SDK with a service account, which has full admin privileges and bypasses Security Rules. Firebase's docs do not describe a scoped key per caller for your app's own routes. floo gives each agent its own key, limited to the routes you declare, rate-limited and revocable.

When is Firebase the better choice?

For mobile apps and public consumer apps: offline-first realtime sync, SDKs for Apple, Android, Flutter, Unity, and C++, public sign-up with many providers, and Crashlytics, Cloud Messaging, Remote Config, and Analytics. floo has no mobile SDKs, no realtime sync product, and no self-serve sign-up for an app's users.