Appwrite: Backend-Bausteine unter einem Dach, selbst gehostet oder als Cloud

Was Appwrite unter einem Dach zusammenfasst

Die Kurzbeschreibung des Repositorys appwrite/appwrite nennt eine vollständige Cloud-Infrastruktur für Web-, Mobile- und KI-Anwendungen und zählt Auth, Datenbanken, Speicher, Functions, Messaging, Hosting, Realtime und weiteres auf. Im README-Abschnitt Products werden sechs dieser Bausteine einzeln beschrieben.

Appwrite Auth deckt Anmeldungen per E-Mail und Passwort, SMS, OAuth, anonyme Sitzungen und Magic Links ab und nennt zusätzlich Sitzungsverwaltung, Multi-Faktor-Authentifizierung und Verifizierungsabläufe. Appwrite Databases arbeitet mit Datenbanken, Tabellen und Zeilen und bietet Abfragen, Paginierung, Indizes und Beziehungen. Appwrite Storage übernimmt Uploads, Downloads, Verschlüsselung, Komprimierung und Umwandlungen für Medien.

Dazu kommen Functions als Serverless-Umgebung mit eigenen Laufzeiten, ausgelöst durch Ereignisse oder Zeitpläne, Messaging für E-Mail, SMS und Push-Benachrichtigungen sowie Sites als Hosting mit eigenen Domains, serverseitigem Rendern und Git-Anbindung. Das ist ein breiter Zuschnitt: Wer mit Appwrite startet, ersetzt damit in der Regel mehrere Einzeldienste.

Der Installationsbefehl mit --entrypoint=install

Appwrite ist für Container gebaut. Der im README angegebene Weg für Unix-Systeme besteht aus einem einzigen docker-run-Aufruf gegen das Image appwrite/appwrite:1.9.6, der den Port 20080 veröffentlicht, den Docker-Socket und ein lokales Verzeichnis einbindet und als Einsprungpunkt install übergibt.

Nach Abschluss der Installation ist die Konsole unter http://localhost erreichbar. Das README weist darauf hin, dass der Server auf Nicht-Linux-Wirtsystemen nach der Installation einige Minuten zum Start brauchen kann. Für Windows werden Varianten für die Eingabeaufforderung und für PowerShell gezeigt, die sich nur in der Fortsetzungszeile und in der Schreibweise des Arbeitsverzeichnisses unterscheiden.

Wer eine Umgebung von Hand aufbauen will, findet unter appwrite.io/install/compose eine docker-compose.yml und unter appwrite.io/install/env eine .env-Datei. Die Umgebungsvariablen sind unter appwrite.io/docs/environment-variables dokumentiert.

DOCKER_API_VERSION=1.42 als häufigster Stolperstein

Eine Fehlermeldung wird im README ausdrücklich behandelt. Scheitert die Installation oder das Upgrade mit einem Hinweis der Art client version 1.52 is too new. Maximum supported API version is 1.42, ist die Docker-Kommandozeile im Appwrite-Image neuer als die Docker-Engine auf dem Wirt.

Der beschriebene Ausweg besteht darin, die Umgebungsvariable DOCKER_API_VERSION auf die aus der Fehlermeldung genannte Höchstversion zu setzen, also etwa --env DOCKER_API_VERSION=1.42. Alternativ kann die Docker-Installation auf dem Wirt aktualisiert werden. Dieselbe Variable wird beim Upgrade benötigt, dann mit --entrypoint="upgrade".

Dass dieser Fall überhaupt im README steht, sagt etwas über das Installationsmodell: Das Appwrite-Image spricht den Docker-Socket des Wirts an und startet die eigene Umgebung selbst. Diese Bauweise ist bequem, bindet den Betrieb aber eng an eine funktionierende Docker-Installation.

Von 1.9.6 auf 2.0.0-rc.1: Versionsstand und Migrationswerkzeug

Hier liegt die auffälligste Unstimmigkeit im Material. Der Installationsbefehl im README verweist auf das Image appwrite/appwrite:1.9.6, und 1.9.6 wurde am 22. Juli 2026 veröffentlicht. Die jüngste Veröffentlichung in der Release-Liste ist jedoch 2.0.0-rc.1 vom 27. August 2026, nach 1.9.5 vom 1. Juli 2026.

Ein Release-Kandidat ist kein stabiler Stand. Wer neu installiert, sollte bewusst entscheiden, ob das README-Image mit 1.9.6 oder der Kandidat der 2.0-Linie eingesetzt wird, und diese Entscheidung dokumentieren. Für ein Upgrade von einer älteren Version verweist das README auf ein eigenes Migrationswerkzeug von Appwrite, das nach Abschluss der Installation benutzt werden soll.

Die Release-Titel nennen keine Änderungen, sie wiederholen nur die Versionsnummer. Inhaltliches zu 2.0.0-rc.1 oder zu Brüchen zwischen 1.9 und 2.0 ist damit im Material nicht belegt und muss in den Release-Notes auf der Releases-Seite nachgelesen werden.

Fünfzehn Runtimes in Functions und die Grenze der Produktliste

Für Appwrite Functions nennt das README 15 unterstützte Laufzeiten. Welche Sprachen das im Einzelnen sind, geht aus dem Auszug nicht hervor; eine Liste findet sich in der Produktdokumentation unter appwrite.io/docs/products/functions. Genannt wird nur, dass eigene Backend-Logik in isolierten Laufzeiten läuft und durch Ereignisse oder geplante Aufträge ausgelöst wird.

Die Produktliste im README ist durchgehend beschreibend. Es fehlen Angaben zu Grenzwerten: keine maximale Dateigröße im Speicher, keine Laufzeitbegrenzung für Functions, keine Aussage zu Durchsatz oder zu Kontingenten in der selbst gehosteten Variante. Das ist für eine Evaluierung ein echter Mangel, weil sich Kapazitätsfragen damit erst durch eigenes Ausprobieren klären lassen.

Positiv fällt auf, dass jedes Produkt auf eine eigene Dokumentationsseite verweist. Wer ein einzelnes Feature prüfen will, findet unter appwrite.io/docs/products einen klaren Einstieg, statt im Repository-Code zu suchen.

BSD-3-Clause, Cloud und Selbsthosting im Vergleich

Das Repository steht unter BSD-3-Clause. Diese Lizenz erlaubt Nutzung, Veränderung und Weitergabe einschließlich kommerzieller Verwendung, verlangt die Nennung des Urhebers und schließt eine Verwendung des Projektnamens zur Bewerbung eigener Produkte ohne Erlaubnis aus. Für den internen Einsatz in Unternehmen ist das eine unkomplizierte Grundlage.

Als Alternative zum eigenen Betrieb nennt das README Appwrite Cloud unter cloud.appwrite.io. Dort entfällt der gesamte Container-Stack; im Gegenzug liegen die Daten beim Anbieter. Das README beschreibt die Cloud als öffentliche Beta, in der keine Kreditkartendaten erhoben werden. Für einen ersten Test ist dieser Weg schneller als jede lokale Installation.

Eine dritte Möglichkeit sind die One-Click-Setups über Marketplace-Angebote, im Material genannt werden DigitalOcean und Akamai Compute. Sie richten eine vorkonfigurierte Umgebung ein, ohne dass lokal Docker installiert sein muss. Der Unterschied zum Selbsthosting liegt im Wirt, nicht in der Software.

Wann ein eigener Stack die bessere Wahl bleibt

Die Alternative zu einer gebündelten Plattform ist der klassische Weg: eine relationale Datenbank, ein Objektspeicher, ein Identitätsdienst und eine eigene Anwendungsschicht, jeweils einzeln betrieben und miteinander verdrahtet. Der Unterschied liegt im Ort der Komplexität.

Appwrite nimmt die Verdrahtung ab und liefert fertige Schnittstellen, SDKs und eine Konsole dafür. Dafür gibt man die Freiheit auf, jedes Bauteil unabhängig zu wählen und zu versionieren. Ein Team, das bereits eine gepflegte Datenbank mit eigenen Migrationen, eigenen Rechten und eigener Beobachtbarkeit hat, gewinnt durch Appwrite wenig und verliert die direkte Kontrolle über Abfragen.

Umgekehrt zahlt sich die Plattform dort aus, wo mehrere Anwendungen dieselben Bausteine brauchen und die gleiche Authentifizierung überall gelten soll. Die Rechnung ist einfach zu prüfen: Wie viele der sechs genannten Produkte würden tatsächlich genutzt? Bei ein oder zwei Bausteinen trägt der Betrieb eines kompletten Container-Stacks nicht.

Redaktionelles Fazit

Geeignet ist Appwrite für Teams, die Authentifizierung, Datenhaltung, Dateiablage und Hintergrundlogik aus einer Hand wollen und die Bereitschaft haben, einen Container-Stack selbst zu betreiben; der Einstieg gelingt mit einem Befehl. Weniger geeignet ist es für Projekte, die relationale Abfragen über SQL oder eine etablierte Migrationstradition brauchen, und für Teams ohne Docker-Erfahrung. Vor einem Einsatz sollte geklärt werden, ob die eigene Datenbank zu den von Appwrite angebotenen Schnittstellen passt und wie ein Upgrade von 1.9.6 auf den Zweig 2.0 mit dem Migrationswerkzeug konkret abläuft.

Offizielle Quellen

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