TL;DR
InsForge is an open-source backend built for coding agents to operate: Postgres, auth, storage, functions, a model gateway, and an MCP server and CLI. Its data model is Supabase's: the browser queries tables through an API, and row-level security is the guard. If your agent is building a web app for a known group of people, floo is the alternative: it hosts the whole app behind a sign-in gateway, and only your server code holds the database credentials.
- Data access: InsForge exposes every table to the browser through PostgREST, with row-level security on each one. On floo,
DATABASE_URLis injected only into your server's container. - Agents: InsForge gives a project one admin key that bypasses row-level security. floo gives each agent a key scoped to declared routes.
- Hosting: InsForge Sites deploys the frontend to Vercel, and Compute runs other containers. floo runs the web app, workers, and cron jobs as one app from one config file.
- Where InsForge leads: open source and self-hosting, public sign-up, realtime, mobile SDKs, a model gateway, and payments.
Facts about InsForge come from its own documentation, website, and GitHub README, read on November 3, 2026. Sources are listed at the end.
How do they compare?
| InsForge | floo | |
|---|---|---|
| Web app hosting | Sites, deployed to Vercel; Compute runs Docker images for other services | Any service with a Dockerfile, deployed from GitHub on every push |
| Database | Postgres, every table exposed through PostgREST | Managed Postgres, DATABASE_URL injected into your service |
| Who guards the data | Row-level security policies on each table | Your server code; the browser has no database credentials |
| Sign-in | Email, magic links, OAuth providers, custom OIDC; an app's own sign-in screens | access_mode = "accounts": invite-only sign-in at the gateway, no auth code |
| Agent credential | One admin API key per project, bypassing row-level security | Key per named consumer, scoped to declared routes, rate-limited, with request history |
| Scheduled work | pg_cron calls an edge function's URL | [cron.<name>] runs a command in your app's container |
| Previews | Backend branches of the whole project, not tied to pull requests | Pull request previews with their own URL, managed resources, and Postgres branch |
| Config in the repo | insforge.toml; does not cover buckets, functions, secrets, or deploy variables | floo.app.toml for services, routes, access, Postgres, Redis, storage, cron, and previews |
Who guards the data?
InsForge puts PostgREST in front of Postgres, so every table becomes a typed REST and SDK endpoint. The browser connects with a public anon key and runs as the anon or authenticated role, and row-level security policies read the user's token for every read and write, for storage and realtime too. InsForge turns RLS on by default for new tables, and a table with no policies blocks browser access, which is a good default. Its diagnostics even flag permissive policies.
The model still makes a policy part of every table your agent creates. A policy that is too loose is open to anyone with the public anon key, which by design is every visitor.
floo has no client path to the database. [managed.default] with type = "postgres" provisions Postgres, floo injects DATABASE_URL into the service's container at deploy time, and the credentials never enter Git or floo.app.toml. Requests reach your app through floo's gateway, which runs sign-in first. Your code still decides which records a signed-in person may see, the same as in any server app, but there is no policy layer between the browser and the tables to get wrong.
How does an agent get access?
InsForge is designed for agents to run it. Its MCP server lets an agent read schemas, run SQL, create buckets and functions, and start deployments, and a CLI with agent skills does the same; InsForge lists a dozen tested agent clients. For write and admin actions, the local MCP server uses the project's admin API key. That key bypasses row-level security, and InsForge's docs describe no scopes or per-agent keys, so every agent with it can do everything.
floo splits the two jobs. An agent operates floo through the CLI, the HTTP API, or the hosted MCP server, signing in with OAuth or the device flow. An agent that uses the finished app gets its own key to the app's routes:
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. Revoking it leaves people and other agents signed in. See app API keys.
Who runs the app itself?
InsForge Sites deploys React, Vue, Svelte, Next.js, or static sites to Vercel, and server code inside those builds runs on Vercel too. Workers, queues, and long-running services go to Compute, which runs a Docker image as one instance with no persistent volumes. InsForge's README labels Compute a private preview, and its docs do not describe a sign-in layer in front of Compute services.
On floo the web app, an API, a worker, and the cron jobs are services of one app, declared together:
[app]
name = "orders"
access_mode = "accounts"
[services.web]
type = "web"
path = "."
port = 3000
ingress = "public"
[managed.default]
type = "postgres"
[managed.files]
type = "storage"
[cron.daily-report]
schedule = "0 6 * * *"
command = "node scripts/report.js"
service = "web"
[github]
preview_environments = true
floo apps invite teammate@acme.com --role member sends an invitation, and your code reads the person from X-Floo-User-Email. See app sign-in.
What about previews?
InsForge's backend branching creates an isolated child project that copies the database, auth config, storage, functions, and schedules, and merges schema changes back with a three-way merge you can preview with a dry run. Its docs say Compute services and frontend deployments are not branched, and describe no link to Git branches or pull requests.
floo previews follow pull requests. With previews on, each pull request gets its own URL and its own managed resources, including a Postgres branch, and an agent can create one for a pushed branch with floo previews up. Closing the pull request tears it down, and dev and prod are untouched. See preview environments.
Where is InsForge stronger?
- Open source. Apache-2.0, self-hostable with Docker Compose, with guides for many clouds. floo is a hosted service only.
- Public sign-up. Google, GitHub, Apple, Microsoft, and other OAuth providers, plus custom OIDC. floo's app sign-in is invite-only, and SAML or OIDC for app users is not available yet.
- Realtime and mobile. WebSocket channels with presence, and Swift and Kotlin SDKs. floo proxies WebSocket requests to your app, but has no realtime product or mobile SDKs.
- Built-in extras. A model gateway with per-project rate limits and spend caps, payments, transactional email, and pgvector.
- Schema merges. Branches merge schema changes back with generated SQL.
Which should you choose?
Choose InsForge when you want an open-source backend you can self-host, or a public app whose browser clients query tables directly. Choose floo when your agent is building a web app for a known group of people, and some agents, and you want the app, Postgres, sign-in, schedules, storage, and previews from one file in the repository, with no row-level security policies standing between the browser and your data.
See the backend for apps your agent builds, start from a template, or read floo vs Supabase, which InsForge's data model follows.
Sources
- InsForge: homepage, GitHub README, introduction, products, alternatives, FAQ, MCP setup, database, migrations, authentication, REST auth, storage, realtime, functions, schedules, model gateway, Sites, Compute, CLI, config as code, branching, diagnostics, TypeScript SDK
- floo: how floo works, app sign-in, app API keys, Postgres, managed services, storage, cron jobs, preview environments, networking, MCP, agent setup
Frequently asked questions
How does InsForge protect data the browser reads?
With row-level security. InsForge exposes every table as a REST and SDK endpoint through PostgREST, and the browser uses a public anon key. Policies read the signed-in user's token on every read and write. RLS is on by default for new tables, and a table with no policies blocks browser access.
What key does an agent use on InsForge?
Each project has an admin API key for server code and the CLI, which bypasses row-level security, and a public anon key. InsForge's docs do not describe scoped or per-agent keys. On floo, each agent gets its own key, limited to the app routes you declare, rate-limited and revocable without touching any other key.
Does InsForge host the frontend?
Yes, through Sites, which deploys React, Vue, Svelte, Next.js, or static sites to Vercel. Workers and long-running services go to Compute, which runs Docker images; InsForge's README labels Compute a private preview. floo runs the web app, workers, and cron jobs as services of one app.
Does InsForge have preview environments?
It has backend branching: an isolated copy of the project's database, auth, storage, and functions, with a three-way schema merge you can dry-run. Its docs say Compute services and frontend deployments are not branched and do not describe a link to pull requests. floo creates a preview per pull request with its own URL, managed resources, and Postgres branch.
When is InsForge the better choice?
When you want an open-source backend you can self-host, a public app with sign-up through many OAuth providers, realtime channels, native Swift and Kotlin SDKs, a built-in model gateway, or payments and email built in. floo is hosted only, has no mobile SDKs, and its app sign-in is invite-only.