Appwrite mit Docker installieren: Vollständige Open-Source-BaaS-Plattform

Wer ein vollständiges Backend für Web- und Mobile-Apps benötigt, greift heute oft zu Firebase oder Supabase und ist damit sofort im Cloud-Vendor-Lock-in. Appwrite ist die quelloffene Alternative: rund 57.000 GitHub-Stars, aktiv gepflegt und mit einem offiziellen Installer auf jedem Linux-Host oder jeder VM in Betrieb. Der Stack liefert Authentifizierung (OAuth, JWT, MFA), Datenbanken (seit Version 2.0 standardmäßig auf PostgreSQL), File Storage, Realtime-WebSockets, Serverless Functions und Sites sowie Messaging, alles hinter einem Traefik-Reverse-Proxy. Diese Anleitung zeigt Appwrite 2.3 und richtet sich an Entwicklerteams und Admins, die ein Backend ohne Cloud-Abhängigkeit selbst betreiben wollen. Wer noch Appwrite 1.9 betreibt, findet in Schritt 7 den Weg auf 2.3.

Voraussetzungen

1. Docker Engine 24.0+ und Docker Compose Plugin v2+. Docker Desktop reicht für lokale Tests; für Produktion einen Linux-Host (Ubuntu 22.04/24.04 LTS oder Debian 12) verwenden. Wie Sie Docker auf Linux installieren, erklärt die Anleitung Docker und Docker Compose auf Linux installieren.
2. Mindestressourcen laut Hersteller: 2 CPU-Kerne, 4 GB RAM, 2 GB Swap, dazu mindestens 20 GB freier Speicher. Für Produktion mit Functions und Sites sind 4 Kerne und 8 GB RAM sinnvoll. x86-64 und ARM64 werden unterstützt.
3. Öffentliche IP und Domain mit DNS-A-Record (nur für automatisches HTTPS per Let's Encrypt). Für lokale Tests reicht localhost.
4. Freie Ports 80 und 443, seit 2.3 zusätzlich 8883 und 8084 für MQTT (umstellbar). Für den Web-Assistenten wird während der Installation Port 20080 benötigt.
5. openssl für die Schlüsselerzeugung (auf fast allen Linux-Systemen vorinstalliert).
6. Optional: SMTP-Zugangsdaten für E-Mail-Funktionen (Passwort-Reset, Einladungen).

Schritt 1: Projektordner anlegen und Secrets generieren

Seit Version 2.0 ist der Stack deutlich gewachsen (Console als eigener Container, ClickHouse für Nutzungsdaten und Ausführungslogs, MQTT, Orchestrator, Geo- und Bilddienste). Eine von Hand gepflegte compose.yaml veraltet damit bei jedem Release. Diese Anleitung nutzt deshalb den offiziellen Installer: Er erzeugt docker-compose.yml und .env passend zur gewählten Version und generiert dabei die Secrets. Legen Sie einen übergeordneten Ordner an; der Installer legt darin den Unterordner appwrite an, der später auch den Docker-Projektnamen bestimmt. Ändern Sie diesen Namen danach nicht mehr, sonst legt Docker neue, leere Volumes an.

sudo mkdir -p /opt/appwrite-install
cd /opt/appwrite-install

# Variante A: Web-Assistent (Browser unter http://SERVER-IP:20080)
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:2.3.0

# Variante B: ohne Rückfragen, nur Dateien erzeugen
docker run --rm \
  --volume /var/run/docker.sock:/var/run/docker.sock \
  --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \
  --entrypoint="install" \
  appwrite/appwrite:2.3.0 \
  --interactive=N --no-start=true --database=postgresql \
  --http-port=80 --https-port=443 --domain=localhost

Der Web-Assistent fragt Hostname, Datenbank (PostgreSQL ist Standard, MariaDB und MongoDB sind wählbar), HTTPS und das erste Konto ab und zeigt den Verschlüsselungsschlüssel einmalig an. Für einen Server ohne Browserzugang auf Port 20080 eignet sich Variante B. Für --domain tragen Sie später Ihre echte Domain ein; zum Ausprobieren reicht localhost.

Verifizieren:

ls /opt/appwrite-install/appwrite
# Erwartete Ausgabe: .env  docker-compose.yml
grep -E "^_APP_(VERSION|DB_ADAPTER)=" /opt/appwrite-install/appwrite/.env
# Erwartete Ausgabe: _APP_DB_ADAPTER="postgresql" und _APP_VERSION="2.3.0"

Variante B meldet am Ende Installation files created. Run "docker compose up -d" to start Appwrite.

Schritt 2: .env-Datei anlegen

Die .env legt der Installer an, Sie passen sie nur noch an. Im Web-Assistenten (Variante A) erzeugt er den Verschlüsselungsschlüssel selbst. Bei Variante B lässt er dagegen die Beispielwerte stehen: Im Test enthielt die .env danach _APP_OPENSSL_KEY_V1="your-secret-key", _APP_DB_PASS="password" und _APP_DB_ROOT_PASS="rootsecretpassword". Ersetzen Sie diese Werte vor dem ersten Start, denn PostgreSQL übernimmt Passwörter nur beim Anlegen des Volumes, und ein später geänderter Schlüssel macht verschlüsselte Daten unlesbar.

cd /opt/appwrite-install/appwrite
for k in _APP_OPENSSL_KEY_V1 _APP_EXECUTOR_SECRET _APP_DB_PASS _APP_DB_ROOT_PASS _APP_USAGE_PASS; do
  sed -i "s|^$k=.*|$k=\"$(openssl rand -hex 32)\"|" .env
done
chmod 600 .env
cp .env /sicherer/ort/appwrite.env.$(date +%Y%m%d)

Drei weitere Werte sollten Sie ansehen:

• _APP_OPENSSL_KEY_V1: verschlüsselt Sessions, Webhook-Secrets, Provider-Zugangsdaten und Dateien. Geht er verloren, sind diese Daten nicht wiederherstellbar. Legen Sie ihn zusätzlich im Passwortmanager ab.
• _APP_DOMAIN und _APP_DOMAIN_TARGET: der Hostname, unter dem Console und API erreichbar sind.
• _APP_SYSTEM_EMAIL_ADDRESS, _APP_EMAIL_CERTIFICATES und die _APP_SMTP_*-Werte: Absender, Kontaktadresse für Zertifikate und Mailserver für Passwort-Reset und Einladungen. Ohne SMTP läuft Appwrite, verschickt aber keine Mails.

Verifizieren:

ls -l .env
# Erwartete Ausgabe: -rw------- ... .env
grep -E "^_APP_(OPENSSL_KEY_V1|EXECUTOR_SECRET|DB_PASS|DB_ROOT_PASS|USAGE_PASS)=" .env | grep -cE "your-secret-key|=\"?(password|rootsecretpassword|appwrite)\"?$"
# Erwartete Ausgabe: 0

Schritt 3: compose.yaml einspielen

Eine eigene compose.yaml müssen Sie nicht mehr einspielen: Der Installer hat sie als docker-compose.yml erzeugt und alle Images darin festgeschrieben. In der Standardinstallation (Topologie „combined“, PostgreSQL) liefen im Test 17 Container:

Wichtige Volumes: appwrite-postgresql (Datenbank), appwrite-uploads (Dateien), appwrite-functions, appwrite-sites, appwrite-builds, appwrite-certificates und appwrite-clickhouse. Der Embedding-Dienst für Vektorsuche ist ressourcenhungrig und standardmäßig aus; er startet nur mit COMPOSE_PROFILES=embedding. Bearbeiten Sie die Datei möglichst nicht von Hand: Beim nächsten upgrade schreibt der Installer sie neu und legt eine Sicherungskopie daneben.

Verifizieren:

cd /opt/appwrite-install/appwrite
docker compose config --quiet && echo "YAML valide"
grep -E "^\s+image:" docker-compose.yml | sort | uniq -c

Schritt 4: Stack starten

Beim ersten Start zieht Docker alle Images, das sind mehrere Gigabyte. Im Test dauerte der erste Start mit Image-Download bis zum Status healthy des API-Containers rund zehn Minuten, ein Start mit bereits geladenen Images unter einer Minute.

cd /opt/appwrite-install/appwrite
docker compose up -d

# Logs verfolgen (Strg+C beendet nur die Anzeige)
docker compose logs -f appwrite

Verifizieren:

docker compose ps --format "{{.Name}}\t{{.Status}}"
# Erwartet: appwrite, appwrite-console, appwrite-postgresql, appwrite-redis,
# clickhouse und exc1 mit (healthy), die übrigen mit Up

curl -s http://localhost/v1/health/version
# Erwartete Ausgabe: {"version":"2.3.0"}

Im Test auf einem Debian-Host mit 2 Kernen und 3 GB RAM belegte der Stack nach dem Start rund 1,8 GB, davon ClickHouse knapp 400 MB. Die Vorgabe von 4 GB RAM plus Swap ist also kein Puffer, sondern die Untergrenze.

Schritt 5: Erstes Admin-Konto anlegen

Öffnen Sie http://localhost im Browser (bei eigener Domain: https://ihre-domain.de). Haben Sie im Web-Assistenten bereits ein Konto angelegt, melden Sie sich damit an. Sonst zeigt die Console das Registrierungsformular; das erste Konto erhält die Rechte für die Instanz. Seit 2.0 erscheint die neue Console mit überarbeiteter Navigation, eingebautem Terminal (Appwrite CLI) und API-Explorer.

Nach dem Login legen Sie über „Create project“ Ihr erstes Projekt an. Darin finden Sie Auth, Databases, Storage, Functions, Sites, Messaging und Realtime, jeweils mit API-Keys und SDK-Beispielen für Web, Flutter, React Native, Python, Node.js, Go, PHP und weitere Plattformen.

Möchten Sie den Zugang zur Console auf bestimmte E-Mail-Adressen oder IP-Adressen beschränken, nutzen Sie _APP_CONSOLE_WHITELIST_EMAILS bzw. _APP_CONSOLE_WHITELIST_IPS in der .env und starten den Stack danach mit docker compose up -d neu.

Verifizieren:

# HTTP-Antwort der Console prüfen
curl -s -o /dev/null -w "%{http_code}\n" http://localhost/
# Erwartete Ausgabe: 200

# Im Browser: http://localhost zeigt Login bzw. Registrierung der Console

Schritt 6: HTTPS mit eigener Domain (Produktion)

Für den produktiven Betrieb mit Let's-Encrypt-Zertifikat tragen Sie Ihre Domain in die .env ein und erstellen den Stack neu:

cd /opt/appwrite-install/appwrite

# .env anpassen:
# _APP_DOMAIN=appwrite.example.com
# _APP_DOMAIN_TARGET=appwrite.example.com
# _APP_EMAIL_CERTIFICATES=admin@example.com
# _APP_OPTIONS_FORCE_HTTPS=enabled

docker compose up -d --force-recreate

Appwrite stellt die Zertifikate selbst über die HTTP-01-Challenge aus und legt sie im Volume appwrite-certificates ab; Traefik liest sie von dort. Der DNS-A-Record muss vorher auf die öffentliche IP zeigen und Port 80 muss von außen erreichbar sein. Läuft die Console auf einem anderen Hostnamen als die API, setzen Sie seit 2.3 zusätzlich _APP_CONSOLE_URL (zum Beispiel https://console.example.com); daraus baut Appwrite alle Links in Mails, OAuth-Rückleitungen und VCS-Kommentaren. Für Reverse-Proxy-Grundlagen hilft die Anleitung Traefik als Docker-Reverse-Proxy mit automatischem HTTPS.

Verifizieren: Die Abfrage über HTTPS liefert die Version, das Worker-Log zeigt die Zertifikatsausstellung.

curl -s https://appwrite.example.com/v1/health/version
# Erwartete Ausgabe: {"version":"2.3.0"}

docker compose logs appwrite-worker | grep -i certificate

Schritt 7: Updates und Backup

Appwrite wird nicht per docker compose pull aktualisiert, sondern mit dem upgrade-Befehl des Installers. Er liest Ihre bestehende docker-compose.yml und .env, übernimmt die Werte, legt Sicherungskopien an (docker-compose.yml.ZEITSTEMPEL.backup, .env.ZEITSTEMPEL.backup) und schreibt die Dateien der neuen Version. Danach führen Sie die Datenmigration aus. Führen Sie den Befehl im übergeordneten Ordner aus, in dem der Ordner appwrite liegt.

cd /opt/appwrite-install

# 1. Backup anlegen (siehe unten)
# 2. Upgrade auf die gewünschte Version
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="upgrade" \
  appwrite/appwrite:2.3.0

# 3. Datenmigration ausführen und auf das Ende warten
cd appwrite
docker compose exec appwrite migrate

Migration von Appwrite 1.9 auf 2.3

Appwrite 2.0 ist eine neue Hauptversion mit neuer Console und erweitertem Stack. Laut offiziellem Upgrade-Leitfaden gelangt eine Installation ab 1.9.6 in einem Schritt auf 2.3.0. Für eine Installation auf 1.9.0 aus der früheren Fassung dieser Anleitung heißt das:

1. Vollständiges Backup von .env, Datenbank und Volumes anlegen (siehe unten). Ein Rückweg ist nur über dieses Backup möglich.
2. Zuerst auf 1.9.6: upgrade mit dem Image appwrite/appwrite:1.9.6 ausführen, danach docker compose exec appwrite migrate.
3. Dann auf 2.3.0: upgrade mit appwrite/appwrite:2.3.0, danach erneut migrate. Die Laufzeit wächst mit der Zahl der Projekte.
4. Datenbank bleibt: PostgreSQL ist nur für Neuinstallationen Standard. Eine MongoDB- oder MariaDB-Installation bleibt beim Upgrade auf ihrem Datenbanksystem; einen Wechsel des Datenbanksystems führt der Installer nicht durch. Dafür ist eine Neuinstallation nötig, in die Sie die Projekte über die Migrations-Funktion der Console (Quelle „Self hosted“) übertragen.
5. Hand gepflegte Compose-Dateien: Haben Sie die compose.yaml aus der früheren Fassung dieser Anleitung von Hand angelegt, erkennt der Installer sie nicht, denn er erwartet appwrite/docker-compose.yml und appwrite/.env. Erzeugen Sie dann mit dem Installer neue Dateien in einem Ordner namens appwrite, übernehmen Sie _APP_OPENSSL_KEY_V1, _APP_DB_ADAPTER=mongodb sowie Datenbank-Benutzer und -Passwörter aus Ihrer alten .env und gleichen Sie Volume-Namen und Projektnamen mit dem Bestand ab, bevor Sie upgrade und migrate ausführen. Prüfen Sie dabei mit docker inspect appwrite-mongo, wo die Daten wirklich liegen: Die frühere Fassung band das Volume unter /var/lib/mongodb/data ein, das MongoDB-Image speichert standardmäßig unter /data/db.
6. Geänderte Variablen: _APP_CONSOLE_URL_SCHEME entfällt (stattdessen _APP_CONSOLE_URL), ebenso _APP_LOGGING_PROVIDER, _APP_LOGGING_CONFIG_REALTIME und _APP_EXECUTIONS_DUAL_WRITE. Fehlerberichte gehen nur noch an Sentry über _APP_LOGGING_CONFIG. Neu sind die MQTT-Ports 8883 und 8084.
7. Geändertes Verhalten: Dev Keys sind seit 2.3 vollständig entfernt, migrate löscht sie. Ausführungslogs von Functions und Sites liegen seit 2.2 nur noch in ClickHouse; Ausführungen, die nur in der Projektdatenbank existierten, werden nicht mehr angezeigt. Die Ausführungsdauer enthält seit 2.3 den Kaltstart.

Im Test haben wir Appwrite 2.3.0 mit Variante B und den Secrets aus Schritt 2 neu installiert (PostgreSQL, Topologie „combined“), ein Konto über die API angelegt und migrate auf der frischen Instanz ausgeführt. Testen Sie den Upgrade-Weg von 1.9.0 über 1.9.6 auf 2.3.0 mit Bestandsdaten vor dem Produktivsystem auf einer Kopie, wie es auch der Hersteller empfiehlt.

Backup

Sichern Sie mindestens die .env (vor allem _APP_OPENSSL_KEY_V1), die Datenbank und die Volumes mit Benutzerdaten:

cd /opt/appwrite-install/appwrite
cp .env /sicherer/ort/appwrite.env.$(date +%Y%m%d)

# PostgreSQL (Standard seit 2.0)
docker compose exec -T postgresql sh -c 'pg_dumpall -U "$POSTGRES_USER"' > appwrite-$(date +%Y%m%d).sql

# MongoDB-Installation (z. B. von 1.9 übernommen)
docker compose exec -T mongodb sh -c 'exec mongodump --username=root --password="$MONGO_INITDB_ROOT_PASSWORD" --authenticationDatabase=admin --archive' > appwrite-$(date +%Y%m%d).archive

# Uploads-Volume bei gestopptem Stack als Archiv sichern
docker compose stop
docker run --rm -v appwrite_appwrite-uploads:/data -v "$(pwd)":/backup alpine tar czf /backup/uploads-$(date +%Y%m%d).tar.gz -C /data .
docker compose start

Weitere Volumes wie appwrite-functions, appwrite-sites und appwrite-builds sichern Sie auf dieselbe Weise. Benachrichtigungen über neue Images liefern Diun oder WUD; das Update selbst führen Sie bei Appwrite immer manuell mit upgrade und migrate aus.

Verifizieren:

cd /opt/appwrite-install/appwrite
docker compose ps --format "{{.Name}}\t{{.Status}}"
curl -s http://localhost/v1/health/version
# Erwartete Ausgabe nach dem Upgrade: {"version":"2.3.0"}
ls -lh appwrite-*.sql
# Dump vorhanden und nicht leer

Troubleshooting / Typische Fehler

1. Installer meldet „Appwrite installation not found“ beim Upgrade: Der Befehl lief im falschen Ordner. Er muss im übergeordneten Ordner laufen, in dem appwrite/docker-compose.yml liegt.
2. Container appwrite bleibt lange „starting“: Der Healthcheck hat eine Startphase von 120 Sekunden, beim ersten Start kommen Image-Download und Datenbank-Initialisierung dazu. Mit docker compose logs appwrite postgresql clickhouse prüfen; im Test war der Stack nach rund zehn Minuten bereit.
3. Speicher reicht nicht (OOM, Container starten neu): Der Stack belegte im Test rund 1,8 GB RAM ohne Last. Unter 4 GB RAM ohne Swap wird es eng, sobald Functions bauen. Swap einrichten oder den Host vergrößern; den Embedding-Dienst nur bei Bedarf über COMPOSE_PROFILES=embedding zuschalten.
4. Ports 80, 443, 8883 oder 8084 belegt: Prüfen mit ss -tlnp | grep -E ':(80|443|8883|8084) '. Für MQTT lassen sich _APP_MQTT_PORT und _APP_MQTT_WSS_PORT in der .env ändern, für HTTP und HTTPS _APP_HTTP_PORT und _APP_HTTPS_PORT.
5. „Executor not reachable“ bei Functions: Der Executor-Container (exc1) braucht Zugriff auf /var/run/docker.sock. Prüfen mit docker inspect exc1 | grep docker.sock. Beim ersten Aufruf einer Runtime lädt er das Runtime-Image nach; das dauert und ist kein Fehler.
6. SSL-Zertifikat wird nicht ausgestellt: Let's Encrypt braucht eine öffentlich erreichbare Domain und Port 80 von außen. _APP_DOMAIN=localhost oder eine private IP funktioniert nicht. Für lokale Tests HTTP verwenden.
7. Nach dem Upgrade fehlen Ausführungslogs: Seit 2.2 liegen sie nur in ClickHouse. Ausführungen, die vorher nur in der Projektdatenbank gespeichert waren, zeigt die Console nicht mehr an.
8. Daten nach Umbenennung des Ordners verschwunden: Docker benennt Projekt und Volumes nach dem Ordner appwrite. Prüfen mit docker volume ls | grep appwrite und den Ordnernamen zurücksetzen.
9. Statuscodes in eigenen Skripten passen nicht: Seit 1.9 liefert die API bei gesperrten Ressourcen HTTP 403 statt 401. Dev Keys und der Header X-Appwrite-Dev-Key funktionieren seit 2.3 nicht mehr, verwenden Sie API-Keys.

Häufige Fragen

Wie installiere ich Appwrite am schnellsten?

Mit dem offiziellen Installer. Er startet einen Web-Assistenten auf Port 20080, fragt Domain, Datenbank und erstes Konto ab und startet den Stack:

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:2.3.0

Wer keinen Browserzugang zum Server hat, nutzt die Variante ohne Rückfragen aus Schritt 1 und setzt die Secrets danach selbst (Schritt 2).

Kann ich Appwrite auf einem Raspberry Pi (ARM64) betreiben?

Ja. Die Images von Appwrite 2.3.0 und der mitgelieferten Dienste (PostgreSQL, ClickHouse, Executor, Console) gibt es laut Docker Hub für linux/amd64 und linux/arm64. Getestet wurde nur amd64. Ein Raspberry Pi 5 mit 8 GB RAM und 64-Bit-OS ist für Tests denkbar; bei 4 GB RAM bleibt neben dem gewachsenen 2.x-Stack wenig Reserve.

Welche Programmiersprachen werden für Serverless Functions unterstützt?

Appwrite bietet Runtimes unter anderem für Node.js, Python, PHP, Ruby, Dart und Flutter, Swift, .NET, Go, Bun, Deno, Kotlin, Java und Rust. Welche auf Ihrer Instanz aktiv sind, legt _APP_FUNCTIONS_RUNTIMES in der .env fest; die vom Installer erzeugte Datei aktiviert zunächst nur node-22. Jede Runtime läuft als eigener Container, den der Executor bei Bedarf startet.

Ich habe keine eigene Domain, kann ich Appwrite trotzdem nutzen?

Für lokale Entwicklung belassen Sie _APP_DOMAIN=localhost und greifen über http://localhost zu. Für öffentlichen Zugriff ohne eigene Domain eignen sich Dienste wie nip.io (z. B. 192.168.1.100.nip.io) oder ein Tunnel-Dienst wie Cloudflare Tunnel.

Welche Daten muss ich für ein vollständiges Backup sichern?

Drei Elemente sind kritisch: die .env-Datei mit _APP_OPENSSL_KEY_V1 (ohne diesen Schlüssel sind verschlüsselte Daten wertlos), ein regelmäßiger Datenbank-Dump (PostgreSQL per pg_dumpall, bei übernommenen Installationen MongoDB per mongodump) und das Uploads-Volume appwrite_appwrite-uploads. Laut Hersteller sollten Sie einen Dump nur in eine frische Installation zurückspielen.

Wie unterscheidet sich Appwrite von PocketBase oder Supabase?

Appwrite ist der umfangreichste der drei BaaS-Kandidaten: Ein vollständiger Stack mit gut 15 Containern, PostgreSQL, MariaDB oder MongoDB als Datenbank, Serverless Functions, Sites, Messaging und einer fertigen Web-Console. PocketBase hingegen ist ein einzelnes Go-Binary, ideal für kleine Projekte mit minimaler Infrastruktur. Supabase setzt ebenfalls auf PostgreSQL und bringt einen eigenen Selfhosting-Stack mit. Appwrite eignet sich am besten für Teams, die ein produktionstaugliches Backend mit breitem Feature-Set selbst betreiben wollen.

Fazit

Appwrite 2.3 liefert mit dem offiziellen Installer ein vollständiges Backend-as-a-Service-Setup, das Firebase und Supabase in der Breite kaum nachsteht. Der Preis dafür ist ein deutlich größerer Stack als bei 1.x: Rechnen Sie mit 4 GB RAM als Untergrenze. Der wichtigste Schritt vor dem Start ist das sichere Generieren und dauerhafte Speichern von _APP_OPENSSL_KEY_V1, dieser Schlüssel ist die Achillesferse des gesamten Stacks. Updates laufen immer über upgrade und migrate, nie über einen einfachen Image-Tausch; wer von 1.9 kommt, geht den Umweg über 1.9.6. Wer neben einem vollständigen BaaS auch ein schlankes Einzel-Backend für kleine Projekte sucht, sollte einen Blick auf PocketBase mit Docker werfen.

Weiterführende Anleitungen und Quellen

1. Docker und Docker Compose auf Linux installieren, die Self-Hosting-Grundlage
2. Traefik als Docker-Reverse-Proxy mit automatischem HTTPS einrichten
3. PocketBase mit Docker: schlankes Go-Backend als Alternative
4. Docker Compose absichern: Secrets, Healthchecks und Non-Root

Offizielle Quellen: Appwrite Self-Hosting Installation, Appwrite Environment Variables, Appwrite Updates und Migrationen, Appwrite Backups, Appwrite 2.0.0 Release Notes, Appwrite 2.3.0 Release Notes.