Plausible Community Edition mit Docker Compose selbst betreiben

Plausible ist eine Webanalyse ohne Cookies, deren Besuchsdaten auf dem eigenen Server in einer ClickHouse-Datenbank bleiben. Die Community Edition (CE) ist die selbst betriebene Variante und wird als eigenes Repository mit fertiger compose.yml gepflegt. Diese Anleitung zeigt die Einrichtung von v3.2.1 mit Docker Compose: Vorbereitung, erster Start mit den irreführenden Bootstrap-Meldungen, Funktionsprüfung, Absicherung, Backup beider Datenbanken und Updates. Grundlage sind Tests am 20.09.2026 (Ubuntu, Docker 29.1.3, Docker Compose 2.40.3) und am 16.10.2026 (Docker 29.8.2, Docker Compose 5.5.1), beide mit v3.2.1, dem weiterhin aktuellen Release.

Voraussetzungen

• Docker mit Docker Compose v2 und git.
• CPU: laut Dokumentation mit SSE 4.2 (x86-64) oder NEON (ARM), eine Anforderung von ClickHouse. Prüfung auf x86: grep -o -m1 -w sse4_2 /proc/cpuinfo.
• RAM: laut Dokumentation mindestens 2 GB. Im Test belegte der Stack ohne jede Last rund 620 MiB, ClickHouse wächst unter Abfragelast deutlich. Planen Sie für den Betrieb 2 Kerne und 4 GB RAM ein.
• Für den Betrieb im Internet: eine eigene Domain und ein Reverse Proxy mit TLS.

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

Eckdaten	Wert
Images	ghcr.io/plausible/community-edition:v3.2.1, postgres:16-alpine, clickhouse/clickhouse-server:24.12-alpine
Port	HTTP_PORT (Standard 8000, im Test 8123), nur über compose.override.yml veröffentlicht
Volumes	db-data, event-data, event-logs, plausible-data
Pflicht-Env	BASE_URL, SECRET_KEY_BASE (mindestens 64 Byte)

Selfhosting heißt: Betrieb, Überwachung, Backup und Updates liegen bei Ihnen. Plausible ist bewusst reduziert und kein Ersatz für eine Marketing-Suite. Zur Einordnung: Matomo ist umfangreicher und schwerer, Umami leichter mit nur einer relationalen Datenbank. Plausible liegt dazwischen, mit ClickHouse als eigener Analysedatenbank.

Schritt 1: Repository klonen und .env anlegen

Klonen Sie den versionierten Branch. 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

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

Die .env liegt neben der compose.yml und wird von Docker Compose automatisch gelesen. Ersetzen Sie den Platzhalter durch die Ausgabe oben und zeigen Sie den Schlüssel nie in Tickets oder Chats:

# 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

Für den Betrieb mit Domain setzen Sie BASE_URL auf https://analytics.example.de. Sonst erzeugt Plausible Links und Verweise auf das Messskript mit einer Adresse, die Besucher nicht erreichen.

Verifizieren: ls -1 zeigt clickhouse und compose.yml, git branch zeigt v3.2.1, und grep -c = .env liefert 3.

Schritt 2: Compose-Dateien verstehen und Port freigeben

Die mitgelieferte compose.yml definiert drei Dienste und vier benannte Volumes. Hier vollständig bis auf den Block optionaler Variablen für Google-Integration, Geolokalisierung und E-Mail-Versand im Dienst plausible:

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 && /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:

• Startreihenfolge: Die Anwendung startet erst, wenn pg_isready und der ClickHouse-Endpunkt /ping antworten.
• command: db createdb, db migrate und run laufen bei jedem Start. Datenbanken werden bei Bedarf angelegt, Migrationen automatisch eingespielt.
• ClickHouse-Dateien aus ./clickhouse: weniger Protokollierung, Bindung nur an IPv4 (Docker-Bridge-Netze haben standardmäßig kein IPv6) und gesenkte Speichervorgaben. Ohne sie startet ClickHouse mit Werten für Server mit deutlich mehr als 16 GB RAM.
• Kein ports-Eintrag: Ein frisch geklonter Stack hängt so nicht ungewollt im Netz. Die Datenbankports veröffentlichen Sie nie.

Die Freigabe erfolgt über eine eigene compose.override.yml, die Docker Compose automatisch mitliest. Die mitgelieferte Datei bleibt so bei Updates unverändert. Im Test sah sie so aus:

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

Sicherheitshinweis: Diese Freigabe bindet den Dienst an alle Adressen des Hosts. Auf einem Server im Internet tragen Sie stattdessen "127.0.0.1:8123:8123" ein und stellen einen Reverse Proxy mit TLS davor (Schritt 5).

Verifizieren: docker compose config --services listet plausible_db, plausible_events_db und plausible, und docker compose config | grep -A3 ports zeigt die Portzuordnung aus der Override-Datei.

Schritt 3: Stack starten

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

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

Beim allerersten Start schreibt der Container echte Fehlermeldungen ins Protokoll, bevor er funktioniert. Im Test erschienen genau 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:

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

Das ist der normale Bootstrap: Der Container findet die Datenbanken noch nicht, legt sie per db createdb an und nimmt den Betrieb auf. Ein Problem besteht erst, wenn nach mehreren Minuten kein Creation of Db successful! folgt oder die Meldungen bei jedem Neustart wiederkehren.

Verifizieren: Das Protokoll enthält Creation of Db successful!, und docker compose ps zeigt alle drei Dienste laufend, die beiden Datenbanken als healthy.

Schritt 4: Funktion prüfen und erstes Konto anlegen

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

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

Der Endpunkt deckt Anwendung, beide Datenbanken und den Seiten-Zwischenspeicher ab und eignet sich damit als Prüfpunkt für eine Überwachung. Eine noch nicht eingerichtete Instanz leitet auf die Registrierung um:

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

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

Im Test endete der erste Aufruf mit http://localhost:8123/register 200. In ClickHouse lagen danach in plausible_events_db unter anderem die Tabellen events_v2, sessions_v2, schema_migrations und die Import-Tabellen, die Migrationen waren also durchgelaufen.

Rufen Sie /register im Browser auf und legen Sie das erste Konto an, es ist Eigentümer der Installation. Schließen Sie danach sofort die Registrierung, sonst kann sich jeder mit Kenntnis der Adresse ein Konto anlegen. Rufen Sie die Oberfläche dabei unter genau der Adresse auf, die in BASE_URL steht. Im Test mit BASE_URL=http://localhost:8123 und Aufruf über eine andere Adresse lud die Seite, das Formular reagierte aber nicht auf „Create my account“: Die Live-Verbindung der Oberfläche wird bei abweichender Herkunft abgewiesen, das Protokoll nennt dazu check_origin. Nach Anpassen von BASE_URL und docker compose up -d klappte die Registrierung.

# 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 aus der Oberfläche ein. Einladungen gehen per E-Mail und setzen einen konfigurierten Versand voraus (MAILER_ADAPTER, SMTP_HOST_ADDR, SMTP_HOST_PORT, SMTP_USER_NAME, SMTP_USER_PWD). Für Zwei-Faktor-Anmeldung setzen Sie TOTP_VAULT_KEY, für die Zuordnung von Besuchen zu Ländern MAXMIND_LICENSE_KEY. Alle Variablen beschreibt das Konfigurations-Wiki.

Nach der Registrierung fragt Plausible nach Domain und Zeitzone der ersten Website und zeigt danach das Messskript für den head-Bereich Ihrer Seiten. Die Skriptadresse bildet Plausible aus BASE_URL.

Verifizieren: /api/health meldet viermal ok, env | grep zeigt DISABLE_REGISTRATION=true, /register leitet mit 302 auf /login um (im Test beobachtet), und die Anmeldung mit dem ersten Konto funktioniert.

Schritt 5: Reverse Proxy mit TLS

Plausible verarbeitet Anmeldedaten und Sitzungscookies und gehört ohne TLS nicht ins Internet.

• BASE_URL auf die echte https://-Adresse setzen und den Stack mit docker compose up -d neu erstellen.
• In der compose.override.yml auf "127.0.0.1:8123:8123" binden, wenn der Proxy auf demselben Host läuft. Läuft der Proxy als Container, ist ein gemeinsames Docker-Netz ohne Host-Freigabe sauberer.
• Der Proxy reicht X-Forwarded-Proto und Host durch, damit erzeugte Links auf https zeigen.

Eine passende Grundlage zeigt die Anleitung Traefik als Docker-Reverse-Proxy mit HTTPS.

Verifizieren: curl -s https://analytics.example.de/api/health liefert viermal ok, und das in der Oberfläche angezeigte Messskript verweist auf die https-Domain.

Schritt 6: Backup beider Datenbanken

Zwei Datenbanken bedeuten zwei Sicherungswege, beide liefen im Test. PostgreSQL mit Konten, Websites und Einstellungen sichern Sie im laufenden Betrieb. Auf der frischen Instanz entstand 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

Der eingebaute BACKUP-Befehl von ClickHouse funktioniert mit der mitgelieferten Konfiguration nicht. Im Test scheiterte BACKUP DATABASE plausible_events_db TO Disk('backups','test.zip') mit:

# 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)

Ohne Zusatzkonfiguration funktioniert die Sicherung des Volumes bei gestopptem ClickHouse. Während des Kopierens erfasst Plausible keine Messdaten. Der Volume-Name beginnt mit dem Projektnamen, also dem Verzeichnisnamen, hier plausible-ce:

# 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

Volume	Inhalt	Sichern
plausible-ce_db-data	PostgreSQL: Konten, Websites, Einstellungen	per pg_dump
plausible-ce_event-data	ClickHouse: Besuchs- und Ereignisdaten	Volume-Archiv
plausible-ce_event-logs	ClickHouse-Protokolle	verzichtbar
plausible-ce_plausible-data	Arbeitsdaten, temporäre Dateien, Geodatenbank	optional

Sichern Sie zusätzlich .env und compose.override.yml. Proben Sie die Wiederherstellung auf einem separaten Host, bevor Sie sich im Ernstfall darauf verlassen.

Verifizieren: Beide Archive existieren und sind größer als null (im Test 39 KB und 2,4 MB auf der leeren Instanz), und /api/health meldet nach dem Neustart wieder viermal ok.

Schritt 7: Updates

Für ein Update setzen Sie den Tag im image-Eintrag höher oder klonen den Branch der neuen Version und übernehmen .env und compose.override.yml. Lesen Sie vorher die Release Notes.

# Vor jedem Update: beide Sicherungen erzeugen, siehe Schritt 6
# 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

db migrate läuft bei jedem Start und verändert das Schema in PostgreSQL und ClickHouse. Ein Downgrade nach durchgelaufener Migration ist nicht ohne Weiteres möglich. Der Rückweg im Fehlerfall heißt: alten Image-Tag und die vor dem Update gesicherten Datenbanken zurückspielen. Das Backup vor dem Update ist deshalb Pflicht.

Verifizieren: Das Protokoll zeigt keine Migrationsfehler, und /api/health meldet viermal ok.

Typische Fehler

Fehlerbild	Ursache	Lösung
invalid_catalog_name und UNKNOWN_DATABASE im Protokoll	Erster Start, Datenbanken existieren noch nicht (im Test beobachtet)	Kein Fehler, auf Creation of Db successful! warten
Anwendung startet nicht, Meldung zum Schlüssel	SECRET_KEY_BASE fehlt oder ist kürzer als 64 Byte	Mit openssl rand -base64 48 neu erzeugen, docker compose up -d
Links und Messskript zeigen auf localhost	BASE_URL nicht angepasst	Echte https://-Domain eintragen, Stack neu erstellen
Registrierungsformular reagiert nicht, Protokoll nennt check_origin	Aufruf über eine andere Adresse als BASE_URL (im Test beobachtet)	BASE_URL auf die tatsächlich genutzte Adresse setzen, docker compose up -d
Kein Zugriff, obwohl alle Container laufen	compose.yml veröffentlicht bewusst keinen Port	compose.override.yml anlegen oder Proxy ins Docker-Netz hängen
ClickHouse beendet sich sofort	CPU ohne SSE 4.2 beziehungsweise NEON	Host mit neuerer CPU verwenden
Container werden ohne erkennbaren Grund beendet	Zu wenig Arbeitsspeicher, meist trifft es ClickHouse	RAM erhöhen, mit docker stats beobachten
backups.allowed_disk ist nicht gesetzt	Disk-Backup-Engine nicht konfiguriert (im Test beobachtet)	Volume bei gestopptem ClickHouse sichern (Schritt 6)

Häufige Fragen

Wie entfernen Sie Plausible CE wieder?

docker compose down entfernt Container und Netzwerk, die vier Volumes bleiben. docker compose down -v löscht zusätzlich alle Volumes und damit sämtliche Statistikdaten unwiderruflich, ohne Rückfrage. Führen Sie den Befehl nur mit geprüfter Sicherung aus und kontrollieren Sie danach mit docker volume ls --filter name=plausible-ce.

Reichen 2 GB RAM?

Für eine kleine Instanz ja, das ist die Mindestempfehlung der Dokumentation. Im Test belegte der Stack ohne Last bereits rund 620 MiB, ClickHouse braucht unter Abfragelast deutlich mehr. Mit 4 GB haben Sie Reserve.

Lassen sich externe Datenbanken nutzen?

Ja. Laut Konfigurations-Wiki zeigen DATABASE_URL auf eine externe PostgreSQL- und CLICKHOUSE_DATABASE_URL auf eine externe ClickHouse-Instanz. Die mitgelieferten Datenbankdienste entfallen dann.

Fazit

Plausible CE läuft mit der offiziellen compose.yml nach wenigen Befehlen. Die Fehlermeldungen beim ersten Start sind normal, /api/health ist der verlässliche Prüfpunkt. Für den Betrieb zählen ein versionierter Branch, ein Port nur hinter TLS-Proxy, die geschlossene Registrierung und zwei getrennte Sicherungswege vor jedem Update.

Weiterführende Anleitungen und Quellen

• Umami auf Synology: cookielose Webanalyse
• Matomo auf Synology: Webanalyse im eigenen Haus
• Traefik als Docker-Reverse-Proxy mit HTTPS einrichten
• plausible/community-edition auf GitHub
• Community Edition Wiki: Configuration
• plausible/analytics auf GitHub