Google Analytics ist schnell eingebaut. Der Betrieb fühlt sich oft weniger gut an. Bei einer kleinen Website lädst du schnell ein schweres Skript eines Drittanbieters und schickst Besucherdaten von deinem Server weg, nur um gelegentlich eine Traffic-Grafik anzusehen.
Umami ist die kleinere, sauberere Option. Es ist eine Open-Source-Analytics-Plattform mit Fokus auf Datenschutz für Pageviews, Referrer, Geräte, Länder, Events und Kampagnendaten. Du kannst Umami mit PostgreSQL auf deinem eigenen Server betreiben, und die offizielle Docker-Variante ist kurz genug, um sie vor dem Einfügen zu verstehen.
Unten steht ein kompletter VPS-Aufbau: Docker Compose für Umami und PostgreSQL, Nginx als öffentlicher Reverse Proxy, Let's Encrypt-Zertifikate über Certbot und die zwei Wartungsaufgaben, die gern vergessen werden: Backups und Updates.
Warum Analytics-Daten lokal bleiben sollten
Website-Analytics kann harmlos wirken, weil das Dashboard sauber aussieht. Dahinter stecken trotzdem Verhaltensdaten: besuchte URLs, Zeitstempel, Referrer, Geräteinformationen, Standort auf Länderebene und Eventnamen, die du selbst definierst. Wenn du einen externen Analytics-Dienst nutzt, verlässt dieser Datenstrom absichtlich deine Infrastruktur.
Wenn du Umami selbst hostest, bleiben diese Daten auf deiner Seite. Deine Traffic-Daten landen in deiner PostgreSQL-Datenbank, auf deinem Server und unter deiner Backup-Policy. Du brauchst weiterhin eine Datenschutzerklärung und musst verstehen, welche Einwilligungsregeln für deine Website gelten. Der Unterschied ist, dass du Analytics nicht an ein großes Werbe-Ökosystem sendest, nur um zu sehen, welcher Blogpost Traffic bekommt.
Der Ressourcenbedarf ist überschaubar. Ein kleiner KVM VPS reicht für eine persönliche Website oder ein paar Projekte mit wenig Traffic. Eine größere Instanz gibt PostgreSQL mehr Luft, wenn du mehrere Websites trackst oder Daten lange aufbewahrst. Schneller Storage hilft mehr, als viele erwarten, weil Analytics vor allem aus Datenbank-Lese- und Schreibvorgängen besteht.
Was du vor der Installation brauchst
Du brauchst:
- Einen Linux-Server mit Root- oder sudo-Zugriff
- Eine Domain oder Subdomain für Umami, zum Beispiel
stat.example.com - DNS, das diesen Hostnamen bereits auf die IPv4-Adresse deines Servers zeigt
- Offene Ports 80 und 443 auf der Server-Firewall
- Eine Shell-Sitzung als
rootoder als Benutzer mit sudo-Rechten
Die Compose-Datei unten bindet Umami an 127.0.0.1:3000, damit der App-Port nicht direkt öffentlich erreichbar ist. Nginx nimmt öffentlichen HTTP/HTTPS-Traffic an und proxyt ihn an den lokalen Container.
Docker und Docker Compose installieren
Unter Debian ist extrepo ein kurzer Weg, wenn deine Release den Docker CE Repository-Eintrag enthält:
sudo apt update
sudo apt install extrepo
sudo extrepo enable docker-ce
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
Für andere Linux-Systeme ist das Convenience Script von Docker der schnelle Weg:
curl -fsSL https://get.docker.com -o get-docker.sh
sudo bash get-docker.sh
Die Dokumentation von Docker beschreibt dieses Script als nützlich für Test- und Entwicklungsumgebungen. Lies es vorher, wenn das ein Produktionsserver ist. Stelle unter Debian oder Ubuntu sicher, dass das Compose-Plugin vorhanden ist:
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
Unter CentOS Stream, Rocky Linux oder AlmaLinux installierst du dieselben Pakete mit dnf, nachdem das Docker-Repository konfiguriert wurde:
sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
Wenn du nicht als root arbeitest, füge deinen aktuellen Benutzer zur Gruppe docker hinzu:
sudo usermod -aG docker youruser
Melde dich ab und wieder an, oder führe newgrp docker aus, bevor du testest. Der Linux post-installation guide von Docker warnt, dass Mitglieder der Gruppe docker Root-Rechte erhalten. Füge also nur Benutzer hinzu, die diese Zugriffsebene haben sollen.
Aktiviere Docker und prüfe, ob Docker und das Compose-Plugin funktionieren:
sudo systemctl enable --now docker
docker version
docker compose version
Die Umami Compose-Datei erstellen
Erstelle ein eigenes Verzeichnis für Umami:
mkdir -p ~/services/umami
cd ~/services/umami
Erzeuge zwei zufällige Werte, bevor du die Datei schreibst: einen für Umami-Authentifizierungstokens und einen für PostgreSQL:
openssl rand -hex 32
openssl rand -hex 32
Erstelle compose.yaml:
name: umami
services:
umami:
container_name: umami
image: docker.umami.is/umami-software/umami:latest
ports:
- "127.0.0.1:3000:3000"
environment:
DATABASE_URL: postgresql://umami:CHANGE_ME_DB_PASSWORD@umami-db:5432/umami
DATABASE_TYPE: postgresql
APP_SECRET: CHANGE_ME_APP_SECRET
depends_on:
umami-db:
condition: service_healthy
init: true
restart: always
healthcheck:
test: ["CMD-SHELL", "curl http://localhost:3000/api/heartbeat"]
interval: 5s
timeout: 5s
retries: 5
umami-db:
container_name: umami-db
image: postgres:18-alpine
environment:
POSTGRES_DB: umami
POSTGRES_USER: umami
POSTGRES_PASSWORD: CHANGE_ME_DB_PASSWORD
volumes:
- ./data:/var/lib/postgresql
restart: always
healthcheck:
test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
interval: 5s
timeout: 5s
retries: 5
Ersetze beide CHANGE_ME_DB_PASSWORD-Werte durch dasselbe PostgreSQL-Passwort. Ersetze CHANGE_ME_APP_SECRET durch einen anderen zufälligen String. Die Umami environment variable docs beschreiben APP_SECRET als Wert zum Absichern von Authentifizierungstokens. Verwende ihn also nicht noch an anderer Stelle.
Geprüft am 2. Juli 2026 listet Docker Hub postgres:18-alpine als aktiven offiziellen Postgres-Image-Tag. Für eine frische Umami-Installation ist das eine sinnvolle Wahl. Bei einer bestehenden Installation solltest du Datenbank-Major-Versionen vorsichtig behandeln: Erstelle einen pg_dump, teste eine Wiederherstellung und ändere erst danach den Image-Tag.
Umami starten
Ziehe die Images und starte den Stack:
docker compose pull
docker compose up -d
Prüfe die Container:
docker compose ps
docker compose logs -f umami
Umami lauscht auf dem Host unter http://127.0.0.1:3000. Da der Container an localhost gebunden ist, öffnest du ihn noch nicht direkt im Browser. Nginx wird der öffentliche Einstiegspunkt.
Das Standard-Administratorkonto lautet:
- Benutzername:
admin - Passwort:
umami
Der Login-Leitfaden von Umami sagt, dass du dieses Passwort direkt nach der ersten Anmeldung ändern sollst. Erledige das, bevor du Websites hinzufügst oder die URL teilst.
Nginx als Reverse Proxy konfigurieren
Installiere Nginx:
# Debian or Ubuntu
sudo apt update
sudo apt install nginx
# CentOS Stream, Rocky Linux, or AlmaLinux
sudo dnf update
sudo dnf install nginx
In diesem Beispiel ist der Analytics-Hostname stat.example.com. Ersetze ihn durch deinen echten Hostnamen.
Unter Debian oder Ubuntu erstellst du /etc/nginx/sites-available/stat.example.com.conf:
upstream umami_backend {
server 127.0.0.1:3000;
}
server {
listen 80;
listen [::]:80;
server_name stat.example.com;
location / {
proxy_pass http://umami_backend;
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;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
Aktiviere die Site:
sudo ln -s /etc/nginx/sites-available/stat.example.com.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
Unter CentOS Stream, Rocky Linux oder AlmaLinux legst du denselben Server Block hier ab:
/etc/nginx/conf.d/stat.example.com.conf
Teste Nginx und starte oder lade den Dienst neu:
sudo nginx -t
sudo systemctl enable --now nginx
sudo systemctl reload nginx
Nginx-Konfigurationsdateien unter /etc/nginx/ benötigen Root-Rechte. Wenn nginx -t fehlschlägt, behebe das zuerst, bevor du Certbot anfasst.
HTTPS mit Certbot hinzufügen
Installiere Certbot und das Nginx-Plugin:
# Debian or Ubuntu
sudo apt install certbot python3-certbot-nginx
# CentOS Stream, Rocky Linux, or AlmaLinux
sudo dnf install epel-release
sudo dnf install certbot python3-certbot-nginx
Stelle das Zertifikat aus:
sudo certbot --nginx -d stat.example.com
Nachdem Certbot die Nginx-Konfiguration angepasst hat, prüfst du die Site:
sudo nginx -t
sudo systemctl reload nginx
Öffne jetzt:
https://stat.example.com/
Melde dich mit admin und umami an und ändere danach das Passwort in den Settings, bevor du irgendetwas anderes machst. Ein öffentliches Analytics-Dashboard mit Standardzugangsdaten bleibt nicht lange deins.
Certbot-Pakete installieren oft einen systemd Timer für Verlängerungen. Prüfe ihn:
systemctl list-timers | grep certbot
sudo certbot renew --dry-run
Wenn deine Installation keinen Timer anlegt und du Certbots pip/virtualenv-Methode nutzt, verwenden die Certbot-Anweisungen der EFF einen Cronjob wie diesen:
echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null
Bei Distributionspaketen ist der Paket-Timer vorzuziehen, wenn er existiert. Führe trotzdem sudo certbot renew --dry-run aus, damit du weißt, dass die Erneuerung funktioniert, bevor das Zertifikat kurz vor dem Ablauf steht.
Eine Website hinzufügen und das Tracking Script installieren
Sobald du angemeldet bist, gehst du zu Websites und klickst auf Add website. Der Add-a-Website-Leitfaden von Umami beschreibt die zwei Felder, die zählen: Der Name kann frei gewählt werden, und die Domain sollte die echte Website-Domain sein, damit Umami deine eigene Website korrekt aus den Referrern herausfiltern kann.
Öffne nach dem Speichern den Bearbeitungsbereich der Website und kopiere den Tracking-Code. Der Collect-Data-Leitfaden von Umami sagt, dass du diesen Code in den <head>-Bereich der Website einfügst, die du tracken möchtest.
Er sieht ungefähr so aus:
<script defer src="https://stat.example.com/script.js" data-website-id="YOUR-WEBSITE-ID"></script>
Besuche deine Website und kehre danach zum Umami-Dashboard zurück. Wenn keine Daten erscheinen, öffne die Entwicklertools im Browser und prüfe, ob script.js und /api/send-Anfragen stat.example.com erreichen. Browser-Erweiterungen und aggressive Content-Blocker können Analytics-Skripte blockieren, selbst wenn du sie selbst hostest.
Umami sichern
Der wichtige Zustand von Umami liegt in PostgreSQL. Erstelle ein Backup-Verzeichnis und dumpe die Datenbank:
mkdir -p ~/services/umami/backups
cd ~/services/umami
docker exec umami-db pg_dump -U umami -d umami | gzip > backups/umami_$(date +%F).sql.gz
Kopiere diese .sql.gz-Datei an einen Ort außerhalb des VPS. Bewahre auch eine Kopie von compose.yaml auf, weil darin Image, Ports und die Form der Environment Variables stehen, die du für eine saubere Wiederherstellung brauchst.
Wenn du Umami auf QDE hostest, sind tägliche Backups auf Plattformebene eine nützliche zweite Schicht, aber kein Ersatz für einen Datenbank-Dump auf Anwendungsebene. Ein Dump ist portabel. Ein Server-Snapshot ist bequem. Behalte beides.
Umami aktualisieren
Erstelle zuerst ein Backup und aktualisiere dann aus dem Umami-Verzeichnis:
cd ~/services/umami
docker compose pull
docker compose up -d
Beobachte nach dem Update die Logs:
docker compose logs -f umami
Das Umami README empfiehlt für Docker-basierte Updates, das neue Image zu pullen und den Container neu zu erstellen. Lies bei Major Releases vorher die Release Notes. Analytics-Daten sind klein im Vergleich zu einer Fotobibliothek, aber sie zu verlieren, weil du die Datenbank zu locker behandelst, ist trotzdem ärgerlich.
Halte Analytics nah an der App
Wenn du Umami selbst hostest, bekommst du brauchbare Traffic-Zahlen, ohne Besucherdaten durch Google Analytics zu leiten. Die Teile sind gewöhnlich: Docker für App und PostgreSQL, Nginx für den öffentlichen Hostnamen, Certbot für HTTPS und eine kleine Backup-Routine, die du per Cron ausführen kannst.
Der Datenschutzvorteil ist am stärksten, wenn der Rest des Stacks dazu passt. Betreibe Umami auf Infrastruktur, die du kontrollierst, halte die Datenbank in einer Rechtsordnung, die du verstehst, und füge nicht mehr Drittanbieter-Skripte hinzu, als du gerade entfernt hast.
QDE bietet datenschutzfreundliches VPS-Hosting in den Niederlanden mit KVM-Virtualisierung, NVMe-Storage, 10 Gbps-Uplinks, vollem Root-Zugriff und täglichen externen Backups. Das ist ein praktischer Ort für Umami, während deine Analytics-Daten unter deiner eigenen Verwaltung bleiben.
Häufige Fragen zum Self-Hosting von Umami
Ist Umami beim Self-Hosting kostenlos?
Ja. Umami ist Open Source und kann auf deinem eigenen Server laufen. Deine Kosten sind der VPS, die Domain und die Zeit, die du in Wartung steckst.
Ersetzt Umami Google Analytics?
Für die meisten kleinen und mittleren Websites ja. Umami liefert Pageviews, Referrer, Länder, Geräte, Events und Kampagnen-Tracking. Es ersetzt nicht jeden fortgeschrittenen Google-Analytics-Workflow, deckt aber die Zahlen ab, die viele Website-Betreiber wirklich nutzen.
Brauche ich einen großen VPS für Umami?
Nein. Ein kleiner VPS reicht für eine persönliche Website oder ein paar Websites mit wenig Traffic. Wenn du viele Domains trackst, Daten lange aufbewahrst oder andere Dienste auf derselben Maschine betreibst, gib PostgreSQL mehr RAM und Festplattenreserve.
Warum Umami an 127.0.0.1 binden?
Die Bindung an 127.0.0.1:3000 hält den App-Port privat. Nur Nginx ist öffentlich auf den Ports 80 und 443 erreichbar, sodass du einen einzigen öffentlichen Einstiegspunkt für TLS, Header und Zugriffskontrolle hast.
Wo speichert Umami Daten?
In der Compose-Datei oben speichert Umami Analytics-Daten in PostgreSQL, und PostgreSQL schreibt seine Dateien auf dem Host unter ~/services/umami/data. Das portable Backup ist die Ausgabe von pg_dump und nicht das rohe Datenbankverzeichnis.
Was sollte ich direkt nach der ersten Anmeldung tun?
Ändere das Standardpasswort von admin. Die offizielle Umami-Dokumentation nennt als Standardkonto admin mit dem Passwort umami, und die erste Aufgabe nach der Anmeldung ist das Ändern dieses Passworts.

