Wer Webanalyse ohne Cookies und ohne Datenabfluss an Dritte betreiben will, landet schnell bei Plausible. Die Community Edition ist die selbst betriebene Variante und wird als eigenes Repository mit fertiger compose.yml gepflegt. Diese Anleitung beschreibt die Einrichtung der Version v3.2.1 mit Docker Compose vollständig, von der Vorbereitung über den ersten Start bis zu Backup, Update und sauberer Deinstallation.

Alle Angaben in dieser Anleitung, die als Testlauf gekennzeichnet sind, stammen aus einer eigenen, isolierten Umgebung: Ubuntu, Docker 29.1.3, Docker Compose 2.40.3, 8 GB RAM, Stand 20.09.2026. Alles andere ist ausdrücklich als Angabe aus der offiziellen Dokumentation gekennzeichnet. Es werden keine Ausgaben wiedergegeben, die nicht tatsächlich beobachtet wurden.

Wofür Plausible CE gut ist und wo die Grenzen liegen

Plausible Community Edition ist eine schlanke Webanalyse, die ohne Cookies auskommt und die Besuchsdaten in einer eigenen ClickHouse-Datenbank auf dem eigenen Server ablegt. Für kleine und mittlere Unternehmen ist genau das der Reiz: Reichweitenzahlen, Verweisquellen und Seitenaufrufe bleiben im eigenen Haus, und das Auswertungsmodell ist bewusst einfach gehalten.

Der Preis dafür ist Eigenverantwortung. Selfhosting heißt, dass Betrieb, Überwachung, Backup, Wiederherstellung und Updates komplett bei Ihnen liegen. Es gibt keinen Anbieter, der im Hintergrund migriert oder ein kaputtes Volume wiederherstellt. Wer das nicht leisten will oder kann, ist mit der gehosteten Variante besser bedient.

Gut geeignet, wenn Sie datensparsame Reichweitenmessung für eine überschaubare Zahl von Websites brauchen und einen Docker-Host ohnehin betreiben.
Gut geeignet, wenn die Analysedaten aus regulatorischen oder internen Gründen das eigene Netz nicht verlassen sollen.
Weniger geeignet als Ersatz für eine vollständige Marketing-Suite. Plausible ist bewusst reduziert und bildet keine umfassende Kampagnen- oder CRM-Analytik ab.
Weniger geeignet auf sehr kleinen VPS. ClickHouse ist eine ausgewachsene Analysedatenbank und braucht Arbeitsspeicher, auch im Leerlauf.
Weniger geeignet, wenn niemand im Haus regelmäßig Updates einspielt. Plausible bringt Datenbankmigrationen mit, die beim Start automatisch laufen.

Zur Einordnung der Popularität: Das Hauptprojekt plausible/analytics weist laut GitHub-API am 20.09.2026 29.147 Stars aus und steht unter AGPL-3.0, das Selfhosting-Repository plausible/community-edition kommt auf 2.866 Stars und steht unter MIT-Lizenz.

Abgrenzung zu Matomo und Umami

Auf S-EDV gibt es bereits Anleitungen zu zwei anderen Webanalyse-Werkzeugen, deshalb eine kurze und bewusst grobe Einordnung ohne Detailvergleich: Matomo ist das umfangreichste und schwergewichtigste der drei Werkzeuge mit dem größten Funktionsumfang und entsprechendem Ressourcen- und Pflegebedarf. Umami ist das leichteste, es begnügt sich mit einer einzelnen relationalen Datenbank. Plausible liegt dazwischen: schlanker als Matomo im Funktionsumfang, aber mit ClickHouse als eigener Analysedatenbank technisch anspruchsvoller als Umami. Welche Variante passt, entscheidet sich vor allem an der Frage, wie tief Sie auswerten wollen und wie viel Betriebsaufwand Sie tragen können.

Voraussetzungen und Ressourcenbedarf

Laut offizieller Dokumentation gelten folgende Voraussetzungen:

Docker und Docker Compose sind installiert und lauffähig.
Die CPU muss SSE 4.2 oder NEON unterstützen. Das ist eine Anforderung von ClickHouse und betrifft in der Praxis nur sehr alte x86-Hardware sowie manche ARM-Boards.
Mindestens 2 GB RAM werden empfohlen.
BASE_URL muss auf die später tatsächlich genutzte Adresse zeigen, SECRET_KEY_BASE muss mindestens 64 Byte lang sein.

In unserem Testlauf haben wir den Ressourcenverbrauch im Leerlauf mit docker stats --no-stream gemessen, also ohne jeglichen Messverkehr auf einer frisch installierten Instanz:

Container	Speicher im Leerlauf (gemessen)	Image-Größe (gemessen)
plausible-ce-plausible-1	371,9 MiB	64,8 MB
plausible-ce-plausible_events_db-1 (ClickHouse)	181,2 MiB	155 MB
plausible-ce-plausible_db-1 (PostgreSQL)	68,62 MiB	116 MB
Summe	rund 620 MiB	rund 336 MB

Die empfohlenen 2 GB RAM sind damit realistisch, aber nicht großzügig: rund 620 MiB gehen ohne jede Last weg, und ClickHouse belegt unter Abfragelast deutlich mehr. Planen Sie für produktiven Betrieb lieber 4 GB ein und beobachten Sie den Verbrauch.

Installation Schritt für Schritt

Die folgenden Schritte wurden in unserem Testlauf genau so ausgeführt. Zuerst wird das Selfhosting-Repository mit dem versionierten Branch geklont. Der Branch legt die Version fest, ein Clone des Standardzweigs würde später unkontrolliert auf eine neuere Version zeigen.

# Selfhosting-Repository mit dem versionierten Branch klonen
git clone -b v3.2.1 --single-branch https://github.com/plausible/community-edition plausible-ce

# In das Projektverzeichnis wechseln
cd plausible-ce

# Inhalt pruefen: es muessen LICENSE, README.md, clickhouse/ und compose.yml vorhanden sein
ls -1

Im nächsten Schritt wird das Geheimnis erzeugt. Zeigen Sie einen erzeugten Schlüssel niemals in Dokumentation, Ticketsystemen oder Chats. Der folgende Befehl gibt den Wert aus, der anschließend in die .env übernommen wird:

# Geheimschluessel erzeugen, Ausgabe in die Zwischenablage uebernehmen
openssl rand -base64 48

Die Datei .env liegt im Projektverzeichnis neben der compose.yml und wird von Docker Compose automatisch gelesen. Der Platzhalter unten ist bewusst als solcher erkennbar und muss durch die Ausgabe des Befehls oben ersetzt werden:

# Datei: .env im Projektverzeichnis plausible-ce
# Adresse, unter der Plausible spaeter erreichbar ist
BASE_URL=http://localhost:8123

# Hier die Ausgabe von "openssl rand -base64 48" einsetzen
SECRET_KEY_BASE=BITTE-HIER-EIGENEN-ERZEUGTEN-SCHLUESSEL-EINSETZEN

# Port, auf dem der Plausible-Container im Container-Netz lauscht
HTTP_PORT=8123

Die offizielle compose.yml veröffentlicht bewusst keinen Host-Port. Die Freigabe erfolgt über eine eigene compose.override.yml, die Docker Compose automatisch zusätzlich einliest. So bleibt die mitgelieferte Datei bei einem Update unverändert und Ihre Anpassung geht nicht verloren. In unserem Testlauf sah die Datei so aus:

# Datei: compose.override.yml im Projektverzeichnis
services:
  plausible:
    ports:
      - "8123:8123"

Sicherheitshinweis: Diese Freigabe bindet den Dienst auf allen Adressen des Hosts. Auf einem Server, der aus dem Internet erreichbar ist, binden Sie stattdessen nur auf die lokale Schleife, zum Beispiel "127.0.0.1:8123:8123", und stellen einen Reverse Proxy mit TLS davor. Dazu weiter unten mehr.

Anschließend wird der Stack gestartet:

# Images herunterladen und alle drei Dienste im Hintergrund starten
docker compose up -d

Die compose.yml erklärt

Die mitgelieferte Datei definiert drei Dienste und vier benannte Volumes. Wir zeigen hier alle drei Dienste vollständig. Gekürzt haben wir ausschließlich den langen Block der optionalen Umgebungsvariablen im Dienst plausible; dort sind in der Originaldatei zusätzlich die Variablen für Google-Integration, Geolokalisierung und die verschiedenen E-Mail-Versandwege aufgeführt. Die vollständige Originaldatei liegt im geklonten Repository unter plausible-ce/compose.yml.

services:
  plausible_db:
    image: postgres:16-alpine
    restart: always
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      start_period: 1m

  plausible_events_db:
    image: clickhouse/clickhouse-server:24.12-alpine
    restart: always
    volumes:
      - event-data:/var/lib/clickhouse
      - event-logs:/var/log/clickhouse-server
      - ./clickhouse/logs.xml:/etc/clickhouse-server/config.d/logs.xml:ro
      - ./clickhouse/ipv4-only.xml:/etc/clickhouse-server/config.d/ipv4-only.xml:ro
      - ./clickhouse/low-resources.xml:/etc/clickhouse-server/config.d/low-resources.xml:ro
      - ./clickhouse/default-profile-low-resources-overrides.xml:/etc/clickhouse-server/users.d/default-profile-low-resources-overrides.xml:ro
    ulimits:
      nofile:
        soft: 262144
        hard: 262144
    environment:
      - CLICKHOUSE_SKIP_USER_SETUP=1
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "wget --no-verbose --tries=1 -O - http://127.0.0.1:8123/ping || { exit 1",
        ]
      start_period: 1m

  plausible:
    image: ghcr.io/plausible/community-edition:v3.2.1
    restart: always
    command: sh -c "/entrypoint.sh db createdb & } ;amp;& /entrypoint.sh db migrate && /entrypoint.sh run"
    depends_on:
      plausible_db:
        condition: service_healthy
      plausible_events_db:
        condition: service_healthy
    volumes:
      - plausible-data:/var/lib/plausible
    ulimits:
      nofile:
        soft: 65535
        hard: 65535
    environment:
      - TMPDIR=/var/lib/plausible/tmp
      # required
      - BASE_URL=${BASE_URL}
      - SECRET_KEY_BASE=${SECRET_KEY_BASE}
      # registration
      - TOTP_VAULT_KEY
      - DISABLE_REGISTRATION
      - ENABLE_EMAIL_VERIFICATION
      # web
      - HTTP_PORT
      - HTTPS_PORT
      # databases
      - DATABASE_URL
      - CLICKHOUSE_DATABASE_URL
      # HIER GEKUERZT: weitere optionale Variablen fuer Google, Geolokalisierung
      # und E-Mail-Versand, siehe Originaldatei plausible-ce/compose.yml

volumes:
  db-data:
  event-data:
  event-logs:
  plausible-data:

Die wichtigsten Punkte im Einzelnen:

Drei Dienste. plausible_db ist die PostgreSQL-Datenbank für Konten, Websites und Einstellungen. plausible_events_db ist ClickHouse und hält die eigentlichen Ereignisdaten. plausible ist die Anwendung selbst.
Healthchecks und Startreihenfolge. Der Anwendungsdienst hängt per depends_on mit condition: service_healthy an beiden Datenbanken. Er startet also erst, wenn pg_isready beziehungsweise der /ping-Endpunkt von ClickHouse antworten. Das start_period: 1m gibt den Datenbanken eine Minute Anlaufzeit, bevor fehlgeschlagene Prüfungen zählen.
Das command. Der Anwendungscontainer führt nacheinander db createdb, db migrate und run aus. Datenbanken werden also bei Bedarf angelegt und Migrationen laufen bei jedem Start automatisch. Das ist beim ersten Start entscheidend und für Updates relevant.
ulimits. ClickHouse bekommt 262144 offene Dateideskriptoren, die Anwendung 65535. Analysedatenbanken halten sehr viele Dateien gleichzeitig offen; ohne diese Erhöhung bricht ClickHouse unter Last ab.
Die vier ClickHouse-Konfigurationsdateien aus ./clickhouse. Sie werden schreibgeschützt eingebunden und passen das Standardverhalten an: logs.xml reduziert die sehr gesprächige Protokollierung, ipv4-only.xml bindet ClickHouse nur an IPv4, weil Docker-Bridge-Netze IPv6 standardmäßig nicht aktivieren und der Dienst sonst Warnungen über nicht unterstützte Adressfamilien schreibt, und low-resources.xml zusammen mit default-profile-low-resources-overrides.xml senkt die Speicher- und Cache-Vorgaben für kleine Installationen. Ohne diese Dateien würde ClickHouse mit Standardwerten starten, die auf Server mit deutlich mehr als 16 GB RAM ausgelegt sind.
Kein veröffentlichter Host-Port. Die Datei enthält bewusst keinen ports-Eintrag. Das ist kein Versehen, sondern verhindert, dass ein frisch geklonter Stack ungewollt und ungeschützt im Netz hängt. Die Freigabe ist eine bewusste Entscheidung des Betreibers, über compose.override.yml oder einen Reverse Proxy im selben Docker-Netz.
Vier benannte Volumes statt Bind-Mounts. Damit liegen alle Daten in der Docker-Verwaltung und überleben ein docker compose down.

Wichtige Umgebungsvariablen

Die folgende Tabelle fasst die Variablen zusammen, die im Alltag zählen. Die Beschreibungen folgen der offiziellen Konfigurationsdokumentation im Wiki des Community-Edition-Repositorys.

Variable	Pflicht	Wirkung
`BASE_URL`	ja	Die Adresse, unter der Plausible erreichbar ist. Wird für erzeugte Links und das Messskript verwendet. Muss im Produktivbetrieb die echte Domain mit `https://` sein.
`SECRET_KEY_BASE`	ja	Schlüssel für Sitzungen und verschlüsselte Werte. Mindestens 64 Byte, erzeugt mit `openssl rand -base64 48`. Ändern macht bestehende Sitzungen ungültig.
`HTTP_PORT`	nein	Port, auf dem die Anwendung im Container lauscht. Standard laut Dokumentation 8000. In unserem Testlauf auf 8123 gesetzt und passend veröffentlicht.
`DISABLE_REGISTRATION`	nein	Steuert die Selbstregistrierung. Nach Anlage des ersten Kontos auf `true` setzen, sonst kann sich jeder Besucher ein Konto anlegen.
`ENABLE_EMAIL_VERIFICATION`	nein	Verlangt eine Bestätigung der E-Mail-Adresse bei der Registrierung. Setzt einen funktionierenden E-Mail-Versand voraus.
`TOTP_VAULT_KEY`	nein	Schlüssel zur Ablage der Geheimnisse für die Zwei-Faktor-Anmeldung. Ohne ihn steht 2FA nicht zur Verfügung.
`DATABASE_URL`	nein	Verbindung zur PostgreSQL-Datenbank. Nur nötig, wenn Sie eine externe Datenbank statt des mitgelieferten Dienstes nutzen.
`CLICKHOUSE_DATABASE_URL`	nein	Verbindung zur ClickHouse-Datenbank. Gleiches Prinzip, für externe Analysedatenbanken.
`MAILER_ADAPTER`, `SMTP_HOST_ADDR`, `SMTP_HOST_PORT`, `SMTP_USER_NAME`, `SMTP_USER_PWD`, `SMTP_HOST_SSL_ENABLED`	nein	E-Mail-Versand für Einladungen, Passwort-Zurücksetzung und Berichte. In unserem Testlauf nicht geprüft.
`MAXMIND_LICENSE_KEY`	nein	Lizenzschlüssel für die MaxMind-Geolokalisierungsdatenbank, damit Besuche Ländern zugeordnet werden können. In unserem Testlauf nicht geprüft.

Erster Start und was dabei normal aussieht, aber kein Fehler ist

Das ist der Punkt, an dem die meisten Erstinstallationen unnötig abgebrochen werden. Beim allerersten Start schreibt der Plausible-Container echte Fehlermeldungen ins Protokoll, bevor er funktioniert. In unserem Testlauf erschienen exakt diese beiden Zeilen:

[error] Postgrex.Protocol failed to connect: ** (Postgrex.Error) FATAL 3D000 (invalid_catalog_name) database "plausible_db" does not exist
[error] Ch.Connection failed to connect: ** (Ch.Error) Code: 81. DB::Exception: Database plausible_events_db does not exist. (UNKNOWN_DATABASE)

Unmittelbar danach folgten im selben Protokoll diese Zeilen:

Creating Plausible.Repo database..
Creating Plausible.IngestRepo database..
Creation of Db successful!

Das ist der normale Bootstrap-Ablauf: Der Container startet, findet die beiden Datenbanken noch nicht vor, legt sie über db createdb an und nimmt danach den regulären Betrieb auf. Diese beiden Fehlerzeilen sind beim ersten Start kein Defekt. Problematisch wäre es erst, wenn nach mehreren Minuten kein Creation of Db successful! folgt oder die Meldungen bei jedem Neustart erneut auftauchen. Das Protokoll sehen Sie so:

# Protokoll des Anwendungscontainers fortlaufend mitlesen
docker compose logs -f plausible

Funktionsprüfung

Nach dem Start prüfen Sie zuerst den Zustand der Container. In unserem Testlauf lieferte docker compose ps alle drei Dienste als laufend, die beiden Datenbanken zusätzlich als healthy:

# Zustand aller Dienste des Stacks anzeigen
docker compose ps

Danach folgt der Gesundheitsendpunkt der Anwendung. In unserem Testlauf lieferte der Aufruf exakt folgende Antwort:

# Gesundheitsendpunkt abfragen
curl -s http://localhost:8123/api/health

# Beobachtete Antwort:
# {"sessions":"ok","postgres":"ok","clickhouse":"ok","sites_cache":"ok"}

Vier Komponenten, alle ok. Das ist der beste einzelne Prüfpunkt für eine Überwachung, weil er neben der Anwendung auch beide Datenbanken und den Seiten-Zwischenspeicher abdeckt. Zuletzt die Weiterleitung: Ein Aufruf der Wurzeladresse endet auf einer noch nicht eingerichteten Instanz bei der Registrierungsseite. In unserem Testlauf endete curl -sL http://localhost:8123/ mit HTTP 200 auf http://localhost:8123/register, und der direkte Aufruf von /register lieferte ebenfalls den Statuscode 200:

# Weiterleitungen folgen und Zielstatus ausgeben
curl -sL -o /dev/null -w "%{url_effective} %{http_code}
" http://localhost:8123/

# Registrierungsseite direkt pruefen
curl -s -o /dev/null -w "%{http_code}
" http://localhost:8123/register

Ergänzend haben wir im Testlauf in ClickHouse nachgesehen. SHOW DATABASES lieferte INFORMATION_SCHEMA, default, information_schema, plausible_events_db und system. In plausible_events_db waren unter anderem die Tabellen events, events_v2, sessions, sessions_v2, ingest_counters, schema_migrations, location_data sowie die Import-Tabellen imported_pages, imported_sources, imported_visitors und weitere angelegt. Die Migrationen waren also tatsächlich durchgelaufen.

Erstkonfiguration

Die Ersteinrichtung läuft über die Weboberfläche. Rufen Sie /register auf und legen Sie das erste Konto an. Dieses Konto ist der Eigentümer der Installation.

Unmittelbar danach schließen Sie die Registrierung, sonst kann sich jeder, der die Adresse kennt, ein eigenes Konto anlegen. Dazu ergänzen Sie die .env und starten den Stack neu:

# Ergaenzung in der Datei .env, nachdem das erste Konto angelegt wurde
DISABLE_REGISTRATION=true

# Geaenderte Umgebungsvariablen uebernehmen
docker compose up -d

# Kontrolle: die Variable muss im Container gesetzt sein
docker compose exec plausible env | grep DISABLE_REGISTRATION

Weitere Benutzer laden Sie danach aus der Oberfläche heraus ein. Beachten Sie, dass Einladungen per E-Mail versendet werden und dafür ein konfigurierter Versandweg nötig ist. Diesen Teil haben wir nicht praktisch geprüft.

Persistente Daten und Volumes

Der Stack legt vier benannte Volumes an. Die Namen setzen sich aus dem Projektnamen, also dem Verzeichnisnamen, und dem Volume-Namen zusammen. In unserem Testlauf hieß das Verzeichnis plausible-ce, entsprechend lieferte docker volume ls diese vier Einträge:

Volume	Einhängepunkt im Container	Inhalt
`plausible-ce_db-data`	`/var/lib/postgresql/data`	PostgreSQL: Konten, Websites, Einstellungen, Einladungen. Klein, aber unverzichtbar.
`plausible-ce_event-data`	`/var/lib/clickhouse`	ClickHouse: die eigentlichen Besuchs- und Ereignisdaten. Das größte und wichtigste Volume.
`plausible-ce_event-logs`	`/var/log/clickhouse-server`	Protokolle von ClickHouse. Für die Fehlersuche nützlich, für ein Backup verzichtbar.
`plausible-ce_plausible-data`	`/var/lib/plausible`	Arbeitsdaten der Anwendung inklusive des über `TMPDIR` gesetzten temporären Verzeichnisses und der Geolokalisierungsdatenbank, sofern verwendet.

# Volumes des Projekts auflisten
docker volume ls --filter name=plausible-ce

Betrieb hinter Reverse Proxy mit TLS

Dieser Abschnitt wurde in unserer Testumgebung nicht praktisch durchgeführt. Der Testlauf lief ausschließlich lokal über http://localhost:8123 ohne echte Domain und ohne Zertifikat. Die folgenden Punkte geben daher den dokumentierten und aus dem Aufbau des Stacks ableitbaren Stand wieder, keine eigene Messung.

Kein unverschlüsselter Betrieb im Internet. Plausible verarbeitet Anmeldedaten und Sitzungscookies. Ohne TLS gehört der Dienst nicht ins Internet.
BASE_URL muss auf die echte Adresse zeigen, also auf https://analytics.ihre-domain.de statt auf localhost. Andernfalls erzeugt Plausible Links und Messskript-Verweise auf eine Adresse, die aus Sicht der Besucher nicht existiert.
Nur der Anwendungsport darf freigegeben werden. Die Ports von PostgreSQL und ClickHouse dürfen niemals auf dem Host veröffentlicht werden. Die offizielle compose.yml tut das auch nicht; fügen Sie dort keine ports-Einträge hinzu.
Bindung auf die lokale Schleife. Wenn der Reverse Proxy auf demselben Host läuft, binden Sie in der compose.override.yml auf "127.0.0.1:8123:8123". Läuft der Proxy als Container, ist ein gemeinsames Docker-Netz ohne jede Host-Freigabe die sauberere Lösung.
Weiterleitungs-Header. Der Proxy sollte die üblichen Header für das ursprüngliche Schema und den ursprünglichen Host setzen, damit erzeugte Links korrekt auf https zeigen.

Backup und Wiederherstellung

Zwei Datenbanken bedeuten zwei Sicherungswege. Beide haben wir im Testlauf ausgeführt.

PostgreSQL sichern

Der Abzug funktioniert im laufenden Betrieb, ohne Ausfall. In unserem Testlauf erzeugte der folgende Befehl auf der frisch installierten Instanz eine rund 39 KB große Datei:

# Logischen Abzug der PostgreSQL-Datenbank erzeugen und komprimiert ablegen
docker compose exec -T plausible_db pg_dump -U postgres -d plausible_db | gzip > plausible-pg.sql.gz

# Groesse der Sicherung pruefen
ls -lh plausible-pg.sql.gz

ClickHouse sichern

Der naheliegende Weg über den eingebauten BACKUP-Befehl funktioniert mit der mitgelieferten Konfiguration nicht. In unserem Testlauf scheiterte BACKUP DATABASE plausible_events_db TO Disk('backups','test.zip') exakt mit dieser Meldung:

# Beobachtete Fehlermeldung von ClickHouse:
Code: 318. DB::Exception: The 'backups.allowed_disk' configuration parameter is not set, cannot use 'Disk' backup engine. (INVALID_CONFIG_PARAMETER)

Der Weg, der ohne Zusatzkonfiguration funktioniert, ist die Sicherung des Volumes bei gestopptem Container. Genau so haben wir es getestet:

# ClickHouse anhalten, damit der Datenbestand konsistent ist
docker compose stop plausible_events_db

# Volume ueber einen Wegwerf-Container als Archiv sichern
docker run --rm -v plausible-ce_event-data:/src:ro -v $(pwd):/dst alpine tar czf /dst/plausible-ch.tgz -C /src .

# ClickHouse wieder starten
docker compose start plausible_events_db

# Danach den Gesundheitsendpunkt erneut pruefen
curl -s http://localhost:8123/api/health

In unserem Testlauf entstand dabei ein 2,4 MB großes Archiv der noch leeren Instanz, und der Gesundheitsendpunkt lieferte anschließend wieder alle vier Komponenten als ok. Rechnen Sie bei produktiven Instanzen mit deutlich größeren Archiven und einer Ausfallzeit der Messdatenerfassung für die Dauer des Kopiervorgangs.

Wichtige Einschränkung, ausdrücklich benannt: In diesem Test wurde nur die Erzeugung der Sicherungen geprüft. Ein vollständiger Restore in eine neue, leere Instanz wurde nicht durchgeführt. Ein Backup, dessen Wiederherstellung nie geprobt wurde, ist kein verlässliches Backup. Planen Sie eine Testwiederherstellung auf einem separaten Host ein, bevor Sie sich im Ernstfall darauf verlassen.

Updates und Rollback-Grenzen

Ein Update besteht aus dem Anheben der Version und einem Neustart des Stacks. Entweder Sie setzen den Tag im image-Eintrag der compose.yml höher, oder Sie klonen den Branch der neuen Version neu und übernehmen Ihre .env und compose.override.yml.

# Vor jedem Update: beide Sicherungen erzeugen, siehe Abschnitt Backup
# Danach die neuen Images herunterladen
docker compose pull

# Container mit den neuen Images neu erstellen
docker compose up -d

# Protokoll beobachten, bis die Migrationen durchgelaufen sind
docker compose logs -f plausible

Der entscheidende Punkt: Der Anwendungscontainer führt bei jedem Start db migrate aus. Datenbankmigrationen laufen also automatisch und verändern das Schema in PostgreSQL und ClickHouse. Ein Downgrade auf die vorherige Version ist nach einer durchgelaufenen Migration nicht ohne Weiteres möglich, weil die ältere Anwendung mit dem neueren Schema in der Regel nicht arbeiten kann. Damit ist ein Backup vor dem Update keine Empfehlung, sondern Pflicht. Der realistische Rückweg im Fehlerfall ist: alten Image-Tag wiederherstellen und die vor dem Update gesicherten Datenbanken zurücksetzen, nicht das bloße Zurücksetzen des Tags.

Ein Upgrade von einer älteren Community-Edition-Version auf v3.2.1 haben wir in diesem Testlauf nicht durchgeführt. Die Installation erfolgte direkt als Neuinstallation von v3.2.1.

Typische Fehler mit Diagnose und Lösung

Fehlerbild	Diagnose	Lösung
`invalid_catalog_name` und `UNKNOWN_DATABASE` im Protokoll	Tritt beim allerersten Start auf, noch bevor die Datenbanken existieren	Kein Fehler. Warten, bis `Creation of Db successful!` folgt. Nur eingreifen, wenn die Meldungen bei jedem Neustart wiederkehren.
Anwendung startet nicht, Beschwerde über den Schlüssel	`SECRET_KEY_BASE` fehlt in der `.env` oder ist kürzer als 64 Byte	Mit `openssl rand -base64 48` neu erzeugen und in die `.env` eintragen, dann `docker compose up -d`.
Oberfläche lädt, aber Links und Messskript zeigen auf die falsche Adresse	`BASE_URL` steht noch auf `localhost` statt auf der echten Domain	`BASE_URL` in der `.env` auf `https://` plus echte Domain setzen und den Stack neu starten.
Kein Zugriff aus dem Netz, obwohl alle Container laufen	Die offizielle `compose.yml` veröffentlicht bewusst keinen Host-Port, `docker compose ps` zeigt keine Portzuordnung	`compose.override.yml` mit `ports` anlegen oder den Reverse Proxy ins selbe Docker-Netz hängen.
ClickHouse startet nicht und beendet sich sofort	Sehr alte CPU ohne SSE 4.2, laut Dokumentation Voraussetzung für ClickHouse	Auf einen Host mit ausreichend neuer CPU wechseln. Auf ARM wird NEON benötigt.
Container werden ohne erkennbaren Grund beendet	Zu wenig Arbeitsspeicher; ClickHouse ist der erste Kandidat für einen Abbruch	Mindestens 2 GB bereitstellen, besser mehr. Verbrauch mit `docker stats` beobachten.
`backups.allowed_disk is not set` beim ClickHouse-Backup	Der `Disk`-Backup-Engine ist in der mitgelieferten Konfiguration nicht freigeschaltet	Volume-Sicherung bei gestopptem Container nutzen, siehe Abschnitt Backup.
Fremde Konten tauchen auf	Die Selbstregistrierung ist noch offen	`DISABLE_REGISTRATION=true` setzen und den Stack neu starten.

Saubere Deinstallation

Hier ist der Unterschied zwischen zwei sehr ähnlichen Befehlen entscheidend, und er ist nicht umkehrbar.

# Variante 1: Container und Netzwerk entfernen, ALLE Daten bleiben erhalten
docker compose down

Diese Variante entfernt nur die Container und das Netzwerk. Die vier benannten Volumes bleiben bestehen, ein späteres docker compose up -d im selben Verzeichnis nimmt den Betrieb mit allen Daten wieder auf.

Warnung, bitte aufmerksam lesen: Der folgende Befehl löscht sämtliche Statistikdaten unwiderruflich. Mit -v entfernt Docker Compose zusätzlich alle vier benannten Volumes, also PostgreSQL-Datenbank, ClickHouse-Ereignisdaten, Protokolle und Anwendungsdaten. Es gibt keine Rückfrage und keinen Papierkorb. Führen Sie diesen Befehl nur aus, wenn Sie entweder eine geprüfte Sicherung besitzen oder die Daten sicher nicht mehr brauchen.

# Variante 2: Container UND alle Volumes entfernen, Daten sind danach verloren
docker compose down -v

# Kontrolle: es duerfen keine Volumes des Projekts mehr uebrig sein
docker volume ls --filter name=plausible-ce

Das geklonte Projektverzeichnis können Sie danach ganz normal löschen, es enthält außer Ihrer .env und der compose.override.yml keine Nutzdaten.

Was in diesem Test nicht geprüft wurde

Der Vollständigkeit halber und zur klaren Trennung von Messung und Dokumentation: Die folgenden Punkte wurden in unserer Umgebung nicht praktisch ausgeführt und beruhen ausschließlich auf der offiziellen Dokumentation.

Betrieb hinter einem Reverse Proxy mit TLS und echter Domain
E-Mail-Versand über SMTP, damit auch Einladungen und Passwort-Zurücksetzung
Geolokalisierung über MaxMind
Die Anbindung an die Google Search Console
Ein echter Restore der ClickHouse-Daten in eine neue Instanz; erzeugt wurde nur das Sicherungsarchiv
Ein Upgrade von einer älteren Community-Edition-Version auf v3.2.1

Passende Anleitungen auf S-EDV

Umami auf Synology: cookielose Webanalyse: die leichtgewichtige Alternative, wenn Ihnen ClickHouse zu viel Betriebsaufwand ist.
Matomo auf Synology: Webanalyse im eigenen Haus: die umfangreichere und schwergewichtigere Lösung, wenn Sie tiefer auswerten wollen.
Traefik als Docker-Reverse-Proxy mit HTTPS einrichten: der passende Unterbau, um Plausible sicher mit TLS zu veröffentlichen.

Quellen

plausible/community-edition auf GitHub: Repository mit der offiziellen compose.yml und den ClickHouse-Konfigurationsdateien, Lizenz MIT, 2.866 Stars laut GitHub-API, Abruf 20.09.2026.
Community Edition Wiki: Configuration: offizielle Referenz aller Umgebungsvariablen, Abruf 20.09.2026.
plausible/analytics auf GitHub: Hauptprojekt der Anwendung, Lizenz AGPL-3.0, 29.147 Stars laut GitHub-API, Abruf 20.09.2026.
Plausible Blog: Community Edition: Hintergrund des Herstellers zur selbst betriebenen Variante, Abruf 20.09.2026.