Appwrite 2.0 RC: A Self-Hosted Backend Bundle With a Docker-First Install

What Appwrite Actually Bundles

Appwrite is not a single service. It is a suite of backend products that run together inside a containerized environment. The README lists six core products: Auth, Databases, Storage, Functions, Messaging, and Sites. Auth covers email/password, SMS, OAuth, anonymous sessions, and magic links, plus session management and multi-factor authentication. Databases provide structured storage with tables, rows, querying, pagination, indexing, and relationships. Storage handles uploads, downloads, encryption, compression, and file transformations. Functions offer serverless compute across 15 runtimes. Messaging sends emails, SMS, and push notifications. Sites is an integrated hosting platform with custom domains and SSR support. The value proposition is that a team gets all of these from one codebase and one API surface, instead of integrating separate providers. That is a real convenience, but it also means you adopt all of them together. You cannot pick only the database or only the auth module without running the rest of the platform.

The Docker-First Install Path

The README is explicit that Appwrite is designed for a containerized environment. The recommended install is a single docker run command. On Unix, that command publishes port 20080, mounts the Docker socket, and mounts a local directory for Appwrite's code. The entrypoint is set to install. The same pattern applies on Windows CMD and PowerShell, with minor syntax differences. The install writes files to a local appwrite directory and then starts the server. After installation, you access the console at http://localhost. The README warns that on non-Linux native hosts, the server might take a few minutes to start. This is a one-command install, which is attractive for quick trials. But it also means Docker is a hard requirement. There is no bare-metal or native install path documented. If you are on a host where Docker is not available or not permitted, Appwrite is not the right tool.

A Known Failure Mode: Docker API Version Mismatch

The README documents a specific install failure. If you see an error like client version 1.52 is too new. Maximum supported API version is 1.42, it means the Docker CLI inside the Appwrite image is newer than your host Docker Engine. The workaround is to pass an environment variable DOCKER_API_VERSION set to the maximum API version from the error, for example 1.42. You must use the same flag with the upgrade entrypoint. This is a concrete limitation that can trip up anyone with an older Docker host. It also signals that Appwrite's install tooling is tightly coupled to the Docker API version. If you run a managed Docker environment that restricts API versions or hides the socket, this install will not work. The README offers no alternative for such cases beyond upgrading Docker on the host.

Upgrade and Migration Overhead

Upgrading from an older Appwrite version is not just a matter of pulling a new image. The README states that after upgrading, you should use the Appwrite migration tool. That tool is not described in detail in the README, but its existence implies that data structures or configuration change between versions. The current stable release is 1.9.6, and there is a 2.0.0-rc.1 release. That release gap suggests a major version change with potentially breaking changes. For a self-hosted deployment, you must plan for migration steps, not just a container swap. The README also points to public docker-compose.yml and .env files for advanced production setups, which means the default install is a convenience layer over a more configurable system. But that configurability comes with the cost of understanding the environment variables and compose file.

Architecture and Runtime Dependencies

The README mentions an Architecture section in the table of contents, but it does not include its content. Based on the repository layout and the install command, Appwrite runs as a set of Docker containers orchestrated by the Appwrite CLI inside the image. The install command creates a local directory and writes the compose configuration there. The server exposes port 20080, which is the console and API endpoint. The reliance on the Docker socket means Appwrite manages its own containers from within a container. That is a common pattern for self-hosted platforms, but it has security implications. The container that runs the install has access to the host's Docker daemon. Anyone who compromises that container could control the host's containers. The README does not address this directly, but it is a real consideration for production deployments.

Self-Hosting vs. Managed Cloud

Appwrite is available as a managed cloud platform at cloud.appwrite.io, and the README says the easiest way to get started is to sign up for Appwrite Cloud. During public beta, it is free and does not collect credit card information. For teams that do not want to manage infrastructure, that is the simpler path. Self-hosting is for those who need control over their data or want to avoid vendor lock-in. The README lists one-click setups on DigitalOcean and Akamai Compute, which suggests the project targets users who want a quick deployment without Docker on their local machine. The trade-off is clear: managed cloud removes the Docker API version problem and the migration overhead, but it puts your data on someone else's infrastructure. Self-hosting keeps data in your control but requires you to handle upgrades, migrations, and Docker compatibility yourself.

Licensing and Maintenance Considerations

Appwrite is licensed under BSD-3-Clause, a permissive open-source license. That means you can use, modify, and distribute the code with minimal restrictions, as long as you preserve the copyright notice. For commercial use, this is a favorable license compared to copyleft options. The repository is actively maintained, with the last push on 2026-08-27 and a 2.0.0-rc.1 release on the same day. The stable line is 1.9.x, with patch releases in July 2026. The presence of a release candidate for a major version suggests the project is in a transition period. Adopting the RC for production is risky. Sticking with 1.9.6 means you get a stable base but will eventually need to migrate to 2.x. The maintenance cost is not trivial: you must track releases, run migration tools, and handle Docker API changes. The README does not provide a detailed upgrade guide beyond pointing to the docs, so you should verify the migration steps for your specific version before upgrading.

Editorial conclusion

Adopt Appwrite if you want a single self-hosted platform that covers auth, databases, storage, functions, messaging, and hosting without stitching together separate services. Skip it if you need fine-grained control over each backend component or if you cannot run Docker reliably in your environment. Before committing, verify that the 2.0.0-rc.1 release meets your stability requirements, test the migration path from 1.9.x, and check the Docker API version on your host, since the README documents a known mismatch that can break installs.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes