# Appwrite self-hosting: install it locally and add a database row

> Appwrite bundles auth, databases, storage, functions, messaging and web hosting into one containerized platform. The install path is a single Docker command, and the trade-off is that you now operate the whole stack yourself.

**appwrite/appwrite** — Appwrite® - complete cloud infrastructure for your web, mobile and AI apps. Including Auth, Databases, Storage, Functions, Messaging, Hosting, Realtime and more

- Repository: https://github.com/appwrite/appwrite
- Website: https://appwrite.io
- Stars: 57,507 · Forks: 5,757
- Language: TypeScript
- License: BSD-3-Clause
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/appwrite-appwrite

## What Appwrite actually replaces

Appwrite is an open-source development platform that bundles backend infrastructure with web hosting. The README lists the products: Auth, Databases, Storage, Functions, Messaging, Realtime and Sites. Each one covers a job that a small team would otherwise wire together from separate services. Auth handles email and password, SMS, OAuth, anonymous sessions and magic links, plus session management, multi-factor authentication and verification flows. Databases stores structured data as databases, tables and rows, with querying, pagination, indexing and relationships. Storage covers uploads, downloads, encryption, compression and file transformations. Functions runs custom backend logic in isolated runtimes, triggered by events or scheduled jobs, and the README states 15 runtimes are supported. Messaging sends email, SMS and push. Sites deploys and scales web applications with custom domains, SSR, Git integration and previews.

The audience is a team building a web, mobile or AI application that does not want to assemble and operate those primitives separately. Appwrite is available as a managed cloud platform and can also be self-hosted on infrastructure you control. That choice is the first decision you make, and it changes everything about cost and operations.

## Traefik in front, one appwrite container behind

The repository's docker-compose.yml shows the shape of a deployment. Two services are visible in the file: traefik and appwrite. Traefik runs as traefik:3.6 with the container name appwrite-traefik, and it takes the host ports through ${_APP_HTTP_PORT:-80} and ${_APP_HTTPS_PORT:-443}. It is told to watch /storage/config for file-provider config and to read Docker labels, with exposedByDefault=false and a constraint that only services labelled traefik.constraint-label-stack=appwrite get routed. Two entrypoints are declared: appwrite_web on port 80 and appwrite_websecure on port 443.

The appwrite container uses image ${_APP_IMAGE:-appwrite/appwrite}:${_APP_VERSION:-latest} and joins the same appwrite network. Its healthcheck is a curl against http://localhost/v1/health/version with a Host header set from ${_APP_DOMAIN:-localhost}, on a 5 second interval, 5 second timeout, 12 retries and a 120 second start period. Traefik routes PathPrefix(`/`) to the service's port 80. The Dockerfile confirms the runtime: a composer build stage installs dependencies from composer.lock, then appwrite/base:2.0.5 is the base image, with the app, public, bin, src and dev directories copied into /usr/src/code. Persistent state lives in /storage subdirectories created at build time: uploads, imports, cache, config, certificates, functions and debug.

That layout tells you something the marketing copy does not. Appwrite is not a single process. It is a PHP application behind a reverse proxy, with MongoDB and other services implied by the repository's mongo-init.js, mongo-keyfile and mongo-entrypoint.sh files, and by docker-compose.separate.yml. Self-hosting means operating that set of containers.

## Installing Appwrite locally with one Docker command

The README says Docker must be installed first, then gives a single command for Unix. It publishes port 20080, mounts the Docker socket, writes a local appwrite directory, and uses the install entrypoint on a pinned image tag:

```bash
docker run -it --rm \
    --publish 20080:20080 \
    --volume /var/run/docker.sock:/var/run/docker.sock \
    --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \
    --entrypoint="install" \
    appwrite/appwrite:1.9.6
```

On Windows the README gives the same command in CMD and PowerShell forms, differing only in line continuation characters and the volume path syntax. After the installation completes, the README says to open http://localhost to reach the Appwrite console. It also warns that on non-Linux native hosts the server might take a few minutes to start after installation finishes. That warning matches the 120 second start period in the compose healthcheck.

If install or upgrade fails with an error like `client version 1.52 is too new. Maximum supported API version is 1.42`, the README explains that the Docker CLI inside the Appwrite image is newer than your host Docker Engine. The fix it gives is to pass DOCKER_API_VERSION set to the maximum version named in the error:

```bash
docker run -it --rm \
    --env DOCKER_API_VERSION=1.42 \
    --publish 20080:20080 \
    --volume /var/run/docker.sock:/var/run/docker.sock \
    --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \
    --entrypoint="install" \
    appwrite/appwrite:1.9.6
```

The README says to use the same `--env DOCKER_API_VERSION=...` flag with `--entrypoint="upgrade"` when upgrading. For production or custom installations it points to the Docker environment variables documentation, and to public docker-compose.yml and .env files for manual setup. The repository also carries docker-compose.yml, docker-compose.override.yml and docker-compose.separate.yml, and the package.json defines only two scripts, format:compose and lint:compose, both running Prettier against the compose files. There is no build script for the application itself in that file.

Once the console is reachable, the next step is an SDK. The README lists client and server SDKs, and the repository publishes docs/examples and app/config/specs through the package files array. A first real use is creating a database, a table and a row through the console or the SDK, then reading it back. The README does not include a worked SDK example in the section available here, so treat the console as the starting point and the SDK documentation as the place to confirm method names.

## Where self-hosting Appwrite gets expensive

The install command mounts /var/run/docker.sock into the installer container. That gives the container control over the host Docker daemon. It is how the installer can bring up the rest of the stack, and it is also the kind of mount that security reviewers flag. On a shared or multi-tenant host, that is a real consideration, not a theoretical one.

Upgrades are the second cost. The README says that if you are upgrading from an older version you should use the Appwrite migration tool once your setup is complete, and points to the Installation Docs for details. It does not document rollback. If a migration goes wrong, the README does not tell you how to return to the previous version, so a backup of the appwrite directory and of the database is on you, not on the tooling.

Version selection is the third. The most recent release listed is 2.0.0-rc.1 from 2026-08-27, which is a release candidate, while the stable line in the install examples is 1.9.6 from 2026-07-22. The README's install commands pin appwrite/appwrite:1.9.6, and the compose file defaults to `latest` when _APP_VERSION is unset. Those two defaults disagree. If you copy the compose file without setting _APP_VERSION, you are not running the version the README told you to install. The last push to the repository was on 2026-08-27, so the project is not abandoned, but the release candidate status of 2.0.0-rc.1 is something to weigh before putting it in front of production traffic.

## Appwrite versus Supabase and Firebase

The comparison people search for most is Appwrite versus Supabase, and the difference that matters is the data model. Supabase is built on PostgreSQL, so the data layer is a relational database with SQL, foreign keys and a migration story that comes from Postgres itself. Appwrite's Databases product, as the README describes it, stores structured data as databases, tables and rows with querying, pagination, indexing and relationships. That is a document-style model with relationship support, not SQL. If your application depends on complex joins, transactional guarantees across many tables, or an existing Postgres schema, Appwrite's data layer is the wrong shape and Supabase's is the right one. If you want the backend primitives to come from one vendor with one API surface and you do not need SQL, Appwrite's bundling is the point.

Against Firebase, the axis is hosting and control rather than features. Firebase is a Google-managed service; Appwrite can be self-hosted on infrastructure you control, which is the reason many teams look at it. The README states Appwrite is available as a managed cloud platform and can also be self-hosted, so you can start on Appwrite Cloud and move later. Note that the README describes Appwrite Cloud as being in public beta and says you can build with it completely free while that lasts, without collecting credit card information. Beta pricing language is not a long-term commitment, and the README does not promise one.

## Licence, upgrades and what maintenance costs you

The repository is BSD-3-Clause. That is a permissive licence: it allows use, modification and redistribution, including in closed-source products, provided the copyright notice and licence text are retained. It is not a copyleft licence, so it does not require you to publish your application's source. This is a description of the licence text, not legal advice; if your organisation has a policy on permissive licences or on redistributing modified versions, have counsel read the LICENSE file in the repository rather than relying on a summary.

The practical maintenance cost of self-hosting comes from the moving parts visible in the repository: Traefik, the appwrite container, MongoDB initialisation scripts, and the storage volumes. Upgrading means running the migration tool the README references, and the README does not describe a rollback procedure. Pinning _APP_VERSION in your .env rather than relying on the compose default of `latest` is the difference between a reproducible upgrade and a surprise. The repository's own package.json keeps only Prettier for the compose files, so there is no project-supplied upgrade automation beyond the upgrade entrypoint.

## Conclusion

Adopt Appwrite if you want auth, databases, storage, functions and hosting behind one API and you are willing to run Docker, or if you would rather let Appwrite Cloud carry that. Do not adopt it if you need a relational database with SQL joins and migrations, since the README describes structured storage built around databases, tables and rows rather than a SQL engine, and the repository does not document a migration path to one. Before committing, verify three things on your own deployment: that the Appwrite console answers at http://localhost after the installer finishes, that your host Docker Engine is new enough to avoid the client version mismatch the README documents, and that the 2.0.0-rc.1 line is stable enough for your workload, since the current release is a release candidate.

## FAQ

### What is Appwrite used for?

It is an open-source development platform for building web, mobile and AI applications, bundling authentication, databases, storage, functions, messaging, realtime and web hosting. Teams use it to avoid assembling those backend primitives from separate services.

### Is Appwrite completely free?

The README says that while Appwrite Cloud is in public beta you can build with Appwrite completely free and no credit card information is collected. Self-hosting is also an option, but the README does not state a permanent free tier for the cloud service.

### Is Appwrite SQL or NoSQL?

The README describes Appwrite Databases as scalable structured data storage supporting databases, tables and rows, with querying, pagination, indexing and relationships. It does not describe a SQL engine, so treat it as a document-style model with relationships rather than a relational database.

### How to install Appwrite locally?

Install Docker, then run the README's install command with `--entrypoint="install"` on the appwrite/appwrite:1.9.6 image, publishing port 20080 and mounting the Docker socket. When it finishes, the README says to open http://localhost for the Appwrite console.

### How to setup Appwrite?

The README gives two paths: sign up for Appwrite Cloud, or self-host with the Docker install command and then open the console at http://localhost. On non-Linux native hosts the README notes the server might take a few minutes to start after installation completes.

### Is Appwrite better than Firebase?

The README does not compare the two. The difference it does state is deployment control: Appwrite is available as a managed cloud platform and can also be self-hosted on infrastructure you control, while Firebase is a managed service.

## Sources

- [Official documentation](https://appwrite.io)
- [Official README](https://github.com/appwrite/appwrite#readme)
- [Project repository](https://github.com/appwrite/appwrite)
- [Release notes](https://github.com/appwrite/appwrite/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/appwrite-appwrite