Appwrite

What Appwrite does

Appwrite puts the usual pieces of an app backend into one product, with one console and one set of SDKs. Auth, Databases, Storage, Functions, Messaging and Realtime are the core services, and Sites adds hosting for static, server-rendered and client-rendered frontends deployed from Git. The result covers more ground than most tools in this category: with Appwrite you can host the frontend, send push notifications and run scheduled jobs without adding other services.

Data is stored in tables with typed columns and relationships, in schemaless document collections, or in vector collections for similarity search. You reach it through Appwrite’s REST, GraphQL or WebSocket APIs rather than by writing SQL. Official client SDKs cover web, Flutter, Apple, Android, React Native and Unity, and there are server SDKs for ten languages. Recent releases describe Appwrite as “agent-first”: an MCP server lets coding assistants work on a live project.

Security and access control

Auth supports email and password (hashed with Argon2), SMS, magic links, email one-time codes, more than 30 OAuth2 providers, anonymous sessions, passkeys, custom tokens and multi-factor authentication. Users can be grouped into teams with roles, or tagged with labels.

Access is controlled per resource. You grant read, create, update or delete rights to everyone, guests, signed-in users, a single user, a team, a role within a team or a label, and you can switch on row-level security for a table. Resources created from a server SDK or the console start with no permissions, while server SDKs using an API key with the right scopes bypass permissions entirely, so keep those keys on the server.

Moving from Firebase

The console includes a migration wizard that connects to a Firebase project through a service account and copies Firebase Auth users and Firestore data. The documentation is open about its limits. Only Firestore is supported, not the Realtime Database. Only top-level documents are migrated, so nested data stays behind. Users who signed in with OAuth must sign in again, and Cloud Functions have to be rewritten. The same wizard can import from Supabase and Nhost.

Self-hosting Appwrite

A Docker command starts a web setup wizard that writes a Docker Compose stack. The stack includes the Appwrite API, workers, a function executor, Traefik and Redis, and you choose PostgreSQL (the default), MariaDB or MongoDB for storage. That choice cannot be changed later. The minimum is 2 CPU cores, 4 GB of RAM and 2 GB of swap. There is also an official Helm chart for Kubernetes, marketplace images for DigitalOcean, Akamai and AWS, and templates for Coolify and Dokploy.

The documentation says self-hosted instances can use the same features as Appwrite Cloud. In practice you supply your own SMTP and SMS providers, handle backups and run the migration tool on upgrades.

Hosted version

Appwrite Cloud has a Free plan and paid plans. A Free project that reaches a resource limit is frozen and its console becomes read-only. Appwrite’s own documentation recommends Cloud for teams without DevOps experience and notes that self-hosting often costs more once time is counted.

Limitations

The self-hosted stack runs many containers and needs a mid-sized server. Because data sits behind Appwrite’s API, you cannot run ad-hoc SQL against it the way you can with Supabase. The Firebase importer handles flat Firestore data and email-based users well, but nested data, OAuth sessions and functions still need manual work.

Who it suits

Appwrite suits teams building web and mobile apps who want one product for the whole backend, including hosting and notifications, under a permissive license and with a self-hosted edition that matches the cloud. Teams that want to work directly in SQL may prefer Supabase.