TL;DR
Appwrite is an open-source backend with client SDKs for web, mobile, and games, and it now hosts sites and offers managed Postgres. Its core model is clients reading and writing data directly under permissions. If your agent is building a web app for a known group of people, floo is the alternative: one floo.app.toml declares the app, Postgres, storage, schedules, and invite-only sign-in at the gateway, and the browser never holds database credentials.
- Data access: Appwrite's client SDKs write rows directly, and permissions on every table and row are the guard. On floo,
DATABASE_URLis injected only into your server's container. - Sign-in: Appwrite Auth is a set of APIs your app's own screens call. floo's gateway signs invited people in before any request reaches your code.
- Agents: Appwrite API keys are scoped by Appwrite service. floo keys are scoped to your app's own routes, per named consumer.
- Where Appwrite leads: open source and self-hosting, mobile SDKs, realtime, Messaging, image transforms, and a wide auth provider list.
Facts about Appwrite come from its own documentation and blog, read on November 3, 2026. Sources are listed at the end.
How do they compare?
| Appwrite | floo | |
|---|---|---|
| Web app hosting | Sites: static, plus server rendering for frameworks such as Next.js, Nuxt, and SvelteKit | Any service with a Dockerfile, plus workers, deployed from GitHub |
| Server logic | Functions, each in its own container, in many runtimes | Your own long-running services and workers |
| Database | TablesDB, DocumentsDB, VectorsDB; or managed Postgres or MySQL without the permissions layer | Managed Postgres, DATABASE_URL injected |
| Who guards the data | Table and row permissions on every client request | Your server code; the browser has no database credentials |
| Sign-in | Auth APIs with many methods; Teams with email invites | access_mode = "accounts": invite-only sign-in at the gateway, no auth code |
| Agent credential | API keys scoped by Appwrite service, optional expiry | Key per named consumer, scoped to declared routes, rate-limited, with request history |
| Scheduled work | Cron schedules on Functions | [cron.<name>] runs a command in your app's container |
| Environments | A separate project per environment; previews per pull request for Sites only | Dev and prod in one app; pull request previews with their own managed resources and Postgres branch |
Who guards the data?
Appwrite's TablesDB, DocumentsDB, and VectorsDB come with Appwrite's permissions, queries, and realtime. The client SDKs carry Permission and Role classes, so a browser can create a row and set who may read it in the same call. Access is grant-only: nobody has access until a table or row grants it, and row permissions apply only after you turn on row security for that table. Roles include any, users, a team, a team role, and a label.
That is a clear model, and it puts a permission decision on every table your agent creates. An agent that grants any to get a page working has granted it to everyone.
Appwrite now also offers managed PostgreSQL and MySQL with direct connections, extensions, and point-in-time recovery. Its docs say those databases have no Appwrite permissions or SDK layer, which makes them the same shape as floo's: your server code connects, and your server code decides.
On floo that is the only shape. [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. 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, but there is no second permission system to keep in sync with it.
How does sign-in work?
Appwrite Auth supports email and password, phone, magic links, email codes, passkeys, anonymous sessions, MFA, and more than 30 OAuth providers. Teams let a team owner invite someone by email: Appwrite sends a link, and your app's page completes the membership. Appwrite's docs describe a user limit and per-method toggles, but no single invite-only switch.
On floo the whole app is invite-only by default once you set one line:
[app]
name = "orders"
access_mode = "accounts"
floo apps invite teammate@acme.com --role member sends the invitation, and the gateway handles the sign-in page, the session, and sign-out. Your code reads the person from X-Floo-User-Email and X-Floo-User-Role. See app sign-in.
How does an agent get access?
Appwrite serves agents that build the app well: a hosted MCP server at mcp.appwrite.io with OAuth sign-in, agent skills, and an AGENTS.md setup. For server access, an API key carries per-service scopes such as databases.read or databases.write, can expire, and, with the right scope, gets access whatever the permissions say. Appwrite's docs do not describe a key scoped to your own app's HTTP routes for one named consumer.
On floo, an agent operates the platform through the CLI, the HTTP API, or the hosted MCP server. For an agent that uses the app itself:
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 touches no other key. See app API keys.
What about environments and previews?
Appwrite's docs describe environments as separate projects, with a CLI config file for each. Sites creates a preview for each pull request, visible only to members of your Appwrite organization, and those previews do not branch the database. Managed Postgres can branch, but a branch expires after at most seven days and is not tied to Git or Site previews automatically; Appwrite's per-pull-request example is a GitHub Actions workflow you write.
On floo, one app has dev and prod. With preview_environments = true under [github], 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. See preview environments.
Where is Appwrite stronger?
- Open source and self-hosting. Run the same stack on Docker or Kubernetes. floo is a hosted service only.
- Mobile and games. Client SDKs for Flutter, Apple, Android, React Native, and Unity. floo has no mobile SDKs.
- Realtime and Messaging. WebSocket subscriptions that respect permissions, plus push, email, and SMS through many providers. floo proxies WebSocket requests to your app, but has no realtime product.
- Public sign-up. Passkeys, MFA, phone, and 30+ OAuth providers. floo's app sign-in is invite-only, and SAML or OIDC for app users is not available yet.
- Storage extras. Image transforms and file-level permissions.
Which should you choose?
Choose Appwrite when you want an open-source backend you can self-host, or a mobile or public app whose clients talk to the data 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 declared in one file in the repository, with your own server code as the only path to the data.
See the backend for apps your agent builds, start from a template, or compare floo vs Supabase.
Sources
- Appwrite: homepage, docs overview, Sites, Sites rendering, deploy from Git, Sites previews, Databases, TablesDB, PostgreSQL, PostgreSQL branches, database permissions, platform permissions, Auth, Teams, team invites, project policies, auth methods, API keys, Functions, function execution, runtimes, Storage, image transforms, Realtime, Messaging, SDKs, CLI, AI tooling, MCP servers, self-hosting
- floo: how floo works, app sign-in, app API keys, Postgres, Redis, managed services, networking, storage, cron jobs, preview environments, Dockerfiles, MCP
Frequently asked questions
How does Appwrite protect data that the browser reads?
With permissions. Appwrite's client SDKs, including the web SDK, read and write rows directly, and table-level or row-level permissions decide what each role can do. Access is grant-only, and row permissions apply only once row security is turned on for the table.
Does Appwrite have Postgres?
Yes. Alongside its TablesDB, DocumentsDB, and VectorsDB APIs, Appwrite now documents managed PostgreSQL and MySQL with direct connections. Those databases do not get Appwrite's permissions or SDK layer, so access goes through your own server code.
Can an Appwrite API key be scoped for an agent?
Yes, by Appwrite service: a key can carry scopes such as databases.read, and it can expire. A key with the right scope gets access regardless of row permissions. Appwrite's docs do not describe a key for a named consumer scoped to your own app's HTTP routes. On floo that is the app key: route-scoped, rate-limited, revocable, with a request log.
Does Appwrite host the web app?
Yes. Appwrite Sites hosts static sites and server-rendered frameworks such as Next.js, Nuxt, and SvelteKit, deploys from GitHub, and creates a private preview per pull request. Those previews do not branch the database.
When is Appwrite the better choice?
When you want to self-host an open-source backend, ship mobile or Flutter apps, use realtime subscriptions, send push, email, or SMS through Messaging, or offer public sign-up with passkeys, MFA, and many OAuth providers. floo is not self-hostable and has no mobile SDKs or self-serve sign-up for an app's users.