Seven backend products sit behind one Appwrite project
Appwrite puts authentication, databases, storage, functions, messaging, realtime events, and Sites hosting behind one console and API surface. Client SDKs cover web, Flutter, Apple, Android, and React Native. Server SDKs include Node.js, Python, PHP, Go, Rust, and several other languages. For a product team, the attraction is consistent users, permissions, events, and project configuration across services that otherwise arrive from different vendors.
That convenience comes from a large system. Our checkout had 3,162 files, about 382,524 source lines, and occupied 107 MB. The architecture routes REST, Realtime, GraphQL, and S3-compatible traffic through a security layer into product services. Queues feed background workers; cache and databases carry state; an executor runs Functions and Sites workloads. Appwrite is closer to adopting a backend platform than adding a library.
What happened when we ran it
Our sandbox ran npm install at the repository root in 5 seconds. It added 1 package and used 10 MB on disk. The root package is private and declares Prettier for formatting Compose files. Npm audit found 0 known vulnerabilities in that installed package set, with 0 critical, high, moderate, or low findings. This is a narrow JavaScript tooling result.
No npm build script or target existed, so the build step was skipped. No npm test script or target existed, so tests were skipped too. The repository does contain a tests directory and 12 CI workflow files. Its server test command lives in Composer, and the contributor guide runs service-specific PHPUnit checks inside the Appwrite container. Our Node 22 probe did not install Composer dependencies, start Compose, or call an Appwrite API.
Self-hosting starts with Docker and expands into operations
The documented Unix installer runs Appwrite 1.9.6 as a container, publishes port 20080, mounts a local Appwrite directory, and mounts /var/run/docker.sock. The installer uses that access to create the deployment, after which the console is available through a browser. Windows commands are also supplied. A Docker API mismatch has its own documented workaround through DOCKER_API_VERSION.
The public Compose file names far more than 1 service. It includes Traefik, the API, console, realtime process, workers, schedulers, browser and assistant services, an Open Runtimes executor and orchestrator, Redis, ClickHouse, MariaDB, MongoDB, PostgreSQL, and an embedding service. Some roles can be combined, but operators still own persistent volumes, secret values, upgrades, TLS and domains, capacity, logs, backups, and recovery.
The managed cloud removes the stack, not the product choices
Appwrite Cloud is the shortest path because users create a project and connect an SDK instead of installing containers. That is appealing when a team wants Appwrite's APIs without managing the supporting services. Self-hosting becomes worthwhile when infrastructure control, data location, or internal integration matters enough to pay the operational cost. The product model remains the same either way, so SDK work is portable between the two deployment choices.
Migration deserves a trial before depending on that portability. Open issue 13397, filed August 28, 2026, reports that a Cloud Free project which had exhausted its database-read allowance could not complete the documented export to a fresh self-hosted 1.9.6 instance. The request returned HTTP 402 before a migration job was created. That is one reported case, but it is a serious walk-away reason for teams treating export as an emergency exit.
PHP 8.5 and containers are the contributor path
The main server is PHP 8.5 or newer with Swoole 6, despite GitHub labeling TypeScript as the repository's primary language and the root npm manifest being easy to spot first. Composer scripts run PHPUnit, Pint, PHPStan, benchmarks, and refactoring checks. The project instructions warn that whole-project static analysis is slow and recommend targeted checks while developing. Docker Compose builds and starts the services needed for end-to-end tests.
Our 5-second npm install therefore measures only the formatting corner of a 382,524-line repository. A useful contribution environment needs Composer packages, PHP extensions, databases, Redis, containers, and the service under test. The repository has a Dockerfile, a compose file, tests, and 12 workflows, which gives contributors visible machinery. It also means a change to functions, storage, auth, or databases can require different fixtures and containers.
Release 1.9.6 focused on safer self-hosted upgrades
Appwrite 1.9.6 was released on July 22, 2026. Its notes include idempotent migration batches, repair of missing Sites and Functions attributes during upgrades, a side-effect-free health check, waiting for a writable MongoDB primary, better doctor reporting, and more installer time for pulling images. Those are operational fixes, and their presence shows why self-hosted upgrades need version-specific instructions instead of a blind image replacement.
The repository was pushed on August 30, 2026, and GitHub showed 57,160 stars plus 1,022 combined issues and pull requests. Same-day work included an end-to-end test adjustment for Node 22 function cold starts, while other current pull requests covered transactions, storage previews, and worker errors. The queue is large because the platform is large; the recent push and issue activity show it is not dormant.
Appwrite pays off only when several products are useful
Appwrite makes sense when a team would otherwise buy or operate several backend services and wants one permission model, console, SDK family, and event system. Auth plus databases alone may justify a trial, but storage, functions, messaging, realtime, or Sites should also be on the roadmap before accepting the self-hosted stack. Managed Cloud is the more honest default for teams without platform operators.
A small application that needs users, records, and files can be easier to run on PocketBase. A team that thinks in PostgreSQL schemas and SQL policies should compare Supabase. Appwrite is the better choice when its product boundaries match the application and the team wants those services under one roof. Our lab did not validate that full stack, so the next evaluation step is a disposable Compose deployment with one real user flow and a tested backup and restore.