Plausible passt gut, wenn du brauchbare Traffic-Zahlen möchtest, ohne jeden Seitenaufruf an Googles Werbesystem zu senden. Mit Community Edition läuft dieselbe Kernanwendung auf deinem eigenen Server. Damit entscheidest du, wo Datenbanken und Backups liegen.
Plausible ist eine quelloffene, cookiefreie Webanalyse. Das Dashboard zeigt Seitenaufrufe, Besucher, Referrer, Einstiegs- und Ausstiegsseiten, Länder, Geräte, Ziele und benutzerdefinierte Events, ohne für jeden Besucher ein Werbeprofil anzulegen.
Auf einem Linux-VPS läuft der Stack mit Docker Compose hinter Nginx und Let's Encrypt. Wir binden den Anwendungsport an localhost und kümmern uns zum Schluss um Updates und Backups. Die Analytics-Daten bleiben bei dir, die Serverwartung allerdings auch.
Was Plausible auf deinem Server ablegt
Plausible verteilt die Daten auf zwei Datenbanken. PostgreSQL speichert Konten und Website-Einstellungen; ClickHouse speichert die Analytics-Events. Laut der Sicherheits- und Datenschutzdokumentation von Plausible nutzt das normale Tracking keine Cookies und speichert weder rohe IP-Adressen noch User-Agent-Strings. Stattdessen erzeugt Plausible eine tägliche Kennung mit einem rotierenden Salt.
Das sind deutlich weniger Besucherdaten als bei werbebasierten Analytics-Diensten. Rechtskonform wird eine selbst gehostete Installation dadurch nicht automatisch. Hosting-Standort, Nginx-Logs, Eigenschaften benutzerdefinierter Events, Aufbewahrungsfristen, Zugriffsrechte und deine Datenschutzerklärung zählen weiterhin. Namen, E-Mail-Adressen, Konto-IDs und andere personenbezogene Daten gehören nicht in benutzerdefinierte Eigenschaften.
ClickHouse bestimmt die Untergrenze für den Server. Das offizielle Repository von Plausible Community Edition empfiehlt mindestens 2 GB RAM und einen Prozessor mit SSE-4.2- oder NEON-Unterstützung. Für eine kleine Website ist ein QDE KVM VPS mit mindestens 2 GB RAM ein vernünftiger Einstieg und bietet den für Docker nötigen Root-Zugriff. Plane mehr ein, wenn du viel Traffic, lange Aufbewahrungsfristen oder mehrere Websites auf einer Instanz erwartest.
Voraussetzungen
Folgendes sollte bereitstehen:
- Einen frisch installierten Server mit Debian, Ubuntu, CentOS Stream, Rocky Linux oder AlmaLinux
- Root-Zugriff oder einen Benutzer mit
sudo-Rechten - Mindestens 2 GB RAM
- Eine Domain oder Subdomain wie
plausible.example.com - DNS-A- und, falls verwendet, AAAA-Records, die auf den Server zeigen
- Offene Ports 80 und 443 in der Firewall des Servers und des Hosting-Anbieters
In den Beispielen verwenden wir plausible.example.com. Ersetze den Namen durch deinen echten Hostnamen und warte auf die DNS-Auflösung, bevor du Certbot ein Zertifikat anfordern lässt.
1. Benötigte Systempakete installieren
Unter Debian oder Ubuntu:
sudo apt update
sudo apt install -y git curl openssl ca-certificatesUnter CentOS Stream, Rocky Linux oder AlmaLinux:
sudo dnf install -y git curl openssl ca-certificatesHier ist nichts Exotisches dabei: Git verwaltet das Repository, curl lädt den Docker-Installer herunter und prüft lokale Endpunkte, OpenSSL erzeugt die geheimen Werte und das CA-Paket hält HTTPS-Downloads funktionsfähig.
2. Docker und Docker Compose installieren
Das Installationsskript von Docker ist der schnellste Weg. Prüfe es zuerst, falls deine Serverrichtlinien das verlangen, und führe es anschließend aus:
curl -fsSL https://get.docker.com -o get-docker.sh
sudo bash get-docker.shAuf einem Produktionsserver mit strengerer Paketverwaltung solltest du stattdessen die Repository-Anleitung für deine Distribution aus der Installationsdokumentation von Docker Engine verwenden.
Wenn du nicht als root angemeldet bist, füge deinen aktuellen Benutzer zur Gruppe docker hinzu:
sudo usermod -aG docker $USERDie neue Gruppenzugehörigkeit gilt nach dem Ab- und erneuten Anmelden. Wenn du in der aktuellen Sitzung weiterarbeiten möchtest, starte eine neue Shell mit:
newgrp dockerBehandle die Mitgliedschaft in der Gruppe docker wie Root-Zugriff, denn genau das gewährt sie praktisch. Füge nur vertrauenswürdige Administratorkonten hinzu. Docker erklärt die Einzelheiten in seiner Linux-Anleitung für Schritte nach der Installation.
Aktiviere Docker für den Systemstart und prüfe, ob Docker Engine und das Compose-Plugin verfügbar sind:
sudo systemctl enable --now docker
docker version
docker compose versionFalls einer der Versionsbefehle fehlschlägt, repariere zuerst die Docker-Installation. Der Rest der Anleitung setzt voraus, dass Engine und Compose funktionieren.
3. Plausible Community Edition klonen
Klone das offizielle Repository und lasse dir den ausgecheckten Zweig anzeigen:
git clone https://github.com/plausible/community-edition plausible
cd plausible
git branch --show-currentPlausible CE nutzt für jedes Release einen eigenen Zweig, und compose.yml pinnt das passende Anwendungs-Image. Der Clone-Befehl lässt -b weg, damit Git den Versionszweig auscheckt, den das Repository gerade als Standard führt. Vergleiche den angezeigten Zweig mit dem aktuellen offiziellen Quickstart, bevor du weitermachst. Merke dir den Namen: Ein normales git pull springt später nicht automatisch zum nächsten Release.
Das Repository enthält Plausible, PostgreSQL, ClickHouse und ressourcenschonende ClickHouse-Einstellungen. Lege deine lokale Konfiguration in .env und compose.override.yml ab und lasse die von Git verwaltete compose.yml unverändert. Das erspart unnötige Merge-Konflikte beim Upgrade.
4. Umgebung konfigurieren
Beginne mit einer leeren Umgebungsdatei:
touch .envTrage die öffentliche URL ein und erzeuge dann getrennte geheime Werte für Sitzungen und verschlüsselte TOTP-Daten:
echo "BASE_URL=https://plausible.example.com" >> .env
echo "SECRET_KEY_BASE=$(openssl rand -base64 48)" >> .env
echo "TOTP_VAULT_KEY=$(openssl rand -base64 32)" >> .env
chmod 600 .envSECRET_KEY_BASE muss nach der Installation unverändert bleiben. Plausible verwendet den Wert für Sitzungen und weitere abgeleitete Geheimnisse. TOTP_VAULT_KEY schützt gespeicherte Geheimnisse der Zwei-Faktor-Authentifizierung.
Der TOTP-Schlüssel ist optional. Ohne diese Variable leitet Plausible per PBKDF2 einen Schlüssel aus SECRET_KEY_BASE ab. Wir setzen trotzdem einen eigenen Zufallswert. Sichere .env und kopiere keines der Geheimnisse in ein Ticket, einen Chat oder einen Screenshot.
Ein kleines Detail: Die Zuweisung von TOTP_VAULT_KEY hat genau ein Gleichheitszeichen vor dem erzeugten Wert. Endet die OpenSSL-Ausgabe mit =, gehört dieses Zeichen zum Base64-Wert.
Die offizielle Konfigurationsreferenz beschreibt die übrigen Optionen, darunter Registrierung, SMTP, Geolokalisierung, Datenbank-URLs und Docker Secrets.
5. Plausible an localhost-Port 8000 binden
Schreibe den internen HTTP-Port in .env:
echo "HTTP_PORT=8000" >> .envPlausible verwendet ohnehin standardmäßig Port 8000. Der ausdrückliche Eintrag zeigt auch Monate später sofort, wie .env und die Override-Datei zusammengehören.
Erstelle compose.override.yml, damit Docker diesen Port ausschließlich auf 127.0.0.1 veröffentlicht:
cat > compose.override.yml <<'EOF'
services:
plausible:
ports:
- "127.0.0.1:8000:${HTTP_PORT}"
EOFDie Anführungszeichen um 'EOF' erfüllen einen echten Zweck. Sie lassen ${HTTP_PORT} unverändert, bis Docker Compose .env liest. Ohne die Anführungszeichen kann deine Shell zuerst eine nicht gesetzte Variable auflösen und dadurch eine fehlerhafte Portzuordnung schreiben.
Lasse Compose die zusammengeführte Konfiguration prüfen, bevor du etwas startest. Mit --quiet erscheinen die geheimen Werte nicht in der Ausgabe:
docker compose config --quietPlausible lauscht jetzt unter 127.0.0.1:8000, wo nur der Server selbst die Anwendung erreicht. Genau so soll es sein. Nginx übernimmt später den öffentlichen Traffic.
6. Plausible starten
Lade die Container-Images und starte den Stack:
docker compose pull
docker compose up -dDer erste Start ist nicht sofort fertig. PostgreSQL und ClickHouse müssen ihre Healthchecks bestehen, bevor Plausible die Datenbanken einrichten kann. Gib dem Stack einen Moment und prüfe ihn dann:
docker compose ps
docker compose logs --tail=100 plausibleTeste den lokalen HTTP-Endpunkt, sobald die Container laufen:
curl --head http://127.0.0.1:8000Jede HTTP-Antwort bestätigt, dass der Host Plausible erreicht. Schlägt die Verbindung fehl, führe docker compose logs --tail=200 aus und behebe den Containerfehler, bevor Nginx dazukommt.
7. Nginx als Reverse Proxy konfigurieren
Installiere Nginx, Certbot und das Nginx-Plugin von Certbot.
Unter Debian oder Ubuntu:
sudo apt update
sudo apt install -y nginx certbot python3-certbot-nginxUnter CentOS Stream, Rocky Linux oder AlmaLinux:
sudo dnf install -y epel-release
sudo dnf install -y nginx certbot python3-certbot-nginxDer Konfigurationspfad hängt von der Distribution ab. Erstelle unter Debian oder Ubuntu folgende Datei:
/etc/nginx/sites-available/plausible.example.com.confErstelle unter CentOS Stream, Rocky Linux oder AlmaLinux folgende Datei:
/etc/nginx/conf.d/plausible.example.com.confLege denselben Server-Block in einer der beiden Dateien ab:
upstream plausible {
server 127.0.0.1:8000;
}
server {
listen 80;
listen [::]:80;
server_name plausible.example.com;
location / {
proxy_pass http://plausible;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /live/websocket {
proxy_pass http://plausible;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}
}Der Block für /live/websocket wird leicht übersehen, doch das Live-Dashboard braucht ihn. Die übrigen Header übermitteln Plausible den ursprünglichen Hostnamen, die Client-Kette und das Protokoll der Anfrage. Diese Konfiguration folgt der Reverse-Proxy-Anleitung von Plausible und ergänzt die üblichen Forwarded-Header.
Aktiviere die Website unter Debian oder Ubuntu:
sudo ln -s /etc/nginx/sites-available/plausible.example.com.conf /etc/nginx/sites-enabled/Falls der Symlink bereits vorhanden ist, lasse ihn unverändert.
Unter CentOS Stream, Rocky Linux oder AlmaLinux mit aktivem SELinux braucht Nginx zusätzlich die Berechtigung, den lokalen Upstream zu erreichen:
sudo setsebool -P httpd_can_network_connect 1Teste die Konfiguration, aktiviere Nginx für den Systemstart und lade den Dienst neu:
sudo nginx -t
sudo systemctl enable --now nginx
sudo systemctl reload nginxNutze nginx -t als feste Kontrolle. Behebe jeden gemeldeten Fehler, bevor du ein Zertifikat anforderst.
8. HTTPS mit Certbot einrichten
Sobald DNS funktioniert und die Ports 80 und 443 erreichbar sind, lässt du Certbot das Zertifikat anfordern und den virtuellen Nginx-Host anpassen:
sudo certbot --nginx -d plausible.example.comPrüfe die Konfiguration noch einmal, bevor du Nginx neu lädst:
sudo nginx -t
sudo systemctl reload nginxPrüfe den öffentlichen Endpunkt auf der Kommandozeile:
curl --head https://plausible.example.comTeste am besten gleich die Zertifikatsverlängerung, solange die Konfiguration noch frisch im Gedächtnis ist:
sudo certbot renew --dry-run9. Ersten Benutzer anlegen und Registrierung beschränken
Öffne https://plausible.example.com und registriere den ersten Benutzer. Lege deine Website im Dashboard an und kopiere anschließend das Tracking-Snippet von Plausible in den <head> deiner Website.
Nach der Einrichtung des ersten Kontos erlaubt Plausible neue Registrierungen standardmäßig nur auf Einladung. Wir schreiben den Wert trotzdem in .env, damit die Absicht für die nächste Person, die diese Datei liest, sofort klar ist:
echo "DISABLE_REGISTRATION=invite_only" >> .env
docker compose up -dEingeladene Benutzer können sich mit dieser Einstellung weiterhin registrieren. Verwende DISABLE_REGISTRATION=true nur dann, wenn du jedes neue Konto sperren möchtest, Einladungen eingeschlossen.
Prüfe den Stack noch einmal:
docker compose ps
docker compose logs --tail=100 plausiblePlausible aktualisieren
Beim Aktualisieren ist ein Punkt leicht zu übersehen: Jedes Release bekommt einen eigenen Versionszweig, und Sicherheitskorrekturen werden nicht auf alte Versionen zurückportiert. Ein normales git pull bleibt auf dem vorhandenen Zweig; docker compose pull liest danach die Image-Tags aus genau diesem Zweig. Beide Befehle können ohne Fehler durchlaufen, während Plausible weiterhin auf dem alten Release bleibt.
Lies vor jedem Upgrade die Release-Seite des Projekts und die Upgrade-Anleitung. Manche Releases verlangen zusätzliche Schritte für PostgreSQL oder ClickHouse. Erstelle zuerst ein Backup und ersetze dann vX.Y.Z unten durch den exakten Zielzweig aus den Release Notes:
cd plausible
git status --short
git pull origin vX.Y.Z
docker compose pull
docker compose up -ddocker compose pull ist hier optional. Der Befehl lädt alle Images aus der neuen Compose-Datei, doch git pull origin vX.Y.Z wählt das Plausible-Release aus, indem es das fest gepinnte Image aktualisiert. Meldet Git einen Konflikt, halte an und löse ihn. Dasselbe gilt für einen zusätzlichen Migrationsschritt aus den Release Notes.
Prüfe nach dem Upgrade die Container und das Plausible-Log:
docker compose ps
docker compose logs --tail=100 plausibleDa die lokale Portzuordnung in compose.override.yml liegt, bleibt die von Git verwaltete compose.yml sauber und verursacht bei git pull origin vX.Y.Z seltener einen Konflikt.
Backups auf Anwendungsebene anlegen
Ein Server-Snapshot ist nützlich, doch Plausible speichert wichtige Daten sowohl in PostgreSQL- als auch in ClickHouse-Volumes. Sichere beide Datenbanken, bewahre eine Kopie außerhalb des VPS auf und teste mindestens eine Wiederherstellung. Erst nach einem Ausfall zu entdecken, dass ein Backup unvollständig ist, wäre reichlich spät.
QDE erstellt täglich externe VPS-Backups und bietet damit einen zusätzlichen Wiederherstellungspunkt für Fehler, die den ganzen Server betreffen. Betrachte sie als weitere Ebene unter deinen Datenbank-Backups, nicht als Ersatz.
Sobald diese Prüfungen erfolgreich sind, kannst du das Tracking-Snippet einfügen und auf die ersten Besuche warten. Danach geht es nur noch um normale Serverpflege: Release Notes lesen, Updates einspielen, den Speicher im Blick behalten und regelmäßig prüfen, ob sich die Backups noch wiederherstellen lassen.