Appwrite has repositioned. Its README now calls it “an MCP and agent-first, open-source platform for building and scaling apps,” and the headline is “The open-source cloud for agents & devs.” That is a notable shift for a project that spent years being described as an open-source Firebase alternative, and it tells you where backend platforms think the demand is going.
The service list is broad: auth, databases (Appwrite’s own, or managed PostgreSQL and MySQL), storage, functions, Sites for static/SSR/CSR frontends, messaging across email, SMS and push, a firewall, realtime, and an MCP endpoint for agent connectivity. Avatars and Locale round it out. It is BSD-3-Clause licensed.
What “agent-first” actually buys you
The concrete part is the MCP support. On Appwrite Cloud it is included with nothing to install; self-hosted deployments point at a local MCP server instead.
That matters for the same reason it does in InsForge: an agent writing code against a backend it cannot introspect will invent column names. One that can query the actual schema through a tool call writes code that compiles. Whether you need a whole platform for that is the real question — but the capability is not marketing, it is an endpoint.
Installing it yourself
The documented Docker route, reproduced as the README gives it:
docker run -it --rm \
--publish 127.0.0.1:20080:20080 \
--volume /var/run/docker.sock:/var/run/docker.sock \
--volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \
--entrypoint="install" \
appwrite/appwrite:2.4.0Two details in that command are worth reading rather than copying.
It pins a version tag, 2.4.0, not latest. Good practice for a platform that needs a migration tool to upgrade — but it also means the command in the docs ages, so check what the current tag is before running it.
The publish address is 127.0.0.1, deliberately. The setup wizard is only published on localhost, and for a remote server the README’s instruction is to “SSH-tunnel to 127.0.0.1:20080” rather than exposing the port. That is the correct design and the step most likely to be skipped by someone installing on a VPS in a hurry. Do not open 20080 to the internet to finish a wizard.
The mounted Docker socket deserves the same attention: Appwrite orchestrates containers, so it needs it, but a socket mount is effectively root on the host.
Client coverage
This is where Appwrite is genuinely strong. Client SDKs cover Web, Flutter, Apple, Android and React Native; server SDKs cover Node.js, Python, Dart, PHP, Ruby, .NET, Go, Swift, Kotlin and Rust. If you are building a mobile app and want one backend for auth, storage and push without assembling three services, that breadth is the argument.
Operational notes from the README
The project documents its own rough edges, which is more than most platforms of this size manage:
- On non-Linux hosts, “the server might take a few minutes to start after completing the installation” — so a seemingly dead install may just be slow.
- Install or upgrade can fail on a Docker API version mismatch, fixed by setting
DOCKER_API_VERSIONor upgrading the host engine. - Upgrading from an older release requires the Appwrite migration tool. Plan upgrades; do not treat them as a tag bump.
Where it fits
Appwrite suits a team that wants one self-hostable backend behind a mobile or web app and would rather configure than assemble. The SDK breadth and the single-command install are real advantages over stitching together auth, storage and a queue yourself.
It is a heavier commitment than a single-file backend like PocketBase, and it wants a server you are willing to operate — see the self-hosting archive for the deployment side of that decision. The cloud free plan exists precisely so you can decide which half of that trade you want before standing up infrastructure.
Start on Cloud if you are evaluating the product, and self-host once you know you want it. Just read the SSH-tunnel line before you install on anything with a public IP.
