Self-hosting Umami Analytics on a VPS: Postgres, APP_SECRET, and the admin login you must change firstUmami Analytics selbst hosten auf einem VPS: Postgres, APP_SECRET und der Admin-Login, den du zuerst ändern musst

What you are standing upWas du hier aufsetzt

The official image, ghcr.io/umami-software/umami, is a single Next.js application that talks to a database you provide. Umami supports both MySQL and Postgres; Postgres is the more common pairing in the official Docker Compose examples and the one this guide uses. Unlike Plausible's ClickHouse-plus-Postgres pair, there is no second, RAM-hungry store doing the actual event aggregation — Postgres holds both your configuration and every recorded pageview, in ordinary relational tables. That single-database shape is the main reason Umami sits comfortably on a smaller VPS than a ClickHouse-backed tool does.Das offizielle Image, ghcr.io/umami-software/umami, ist eine einzelne Next.js-Anwendung, die mit einer Datenbank spricht, die du bereitstellst. Umami unterstützt sowohl MySQL als auch Postgres; Postgres ist die gängigere Kombination in den offiziellen Docker-Compose-Beispielen und die, die diese Anleitung verwendet. Anders als bei Plausibles Kombination aus ClickHouse und Postgres gibt es keinen zweiten, RAM-hungrigen Speicher, der die eigentliche Event-Aggregation übernimmt — Postgres hält sowohl deine Konfiguration als auch jeden aufgezeichneten Seitenaufruf in ganz gewöhnlichen relationalen Tabellen. Diese Ein-Datenbank-Form ist der Hauptgrund, warum Umami bequem auf einem kleineren VPS läuft als ein ClickHouse-gestütztes Tool.

The compose fileDie Compose-Datei

Pin both image tags before the first run, not after something breaks on a restart:Pinne beide Image-Tags vor dem ersten Start, nicht erst, nachdem bei einem Neustart etwas kaputtgeht:

services:
  umami:
    image: ghcr.io/umami-software/umami:postgresql-v2.14.0  # check the self-hosting docs at umami.is for the current image and tag
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      DATABASE_URL: postgresql://umami:change-this-password@db:5432/umami
      DATABASE_TYPE: postgresql
      APP_SECRET: replace-with-a-long-random-string
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:15-alpine  # check hub.docker.com/_/postgres/tags for the current minor
    restart: unless-stopped
    environment:
      POSTGRES_DB: umami
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: change-this-password
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB"]
      interval: 5s
      timeout: 5s
      retries: 5
    volumes:
      - umami-db-data:/var/lib/postgresql/data

volumes:
  umami-db-data:

Bind the published port to 127.0.0.1. The only thing that should reach port 3000 directly is a reverse proxy running on the same host, not the open internet. Once you have filled in real values, this file also holds a live database password and your session secret — keep it out of version control and run chmod 600 docker-compose.yml rather than leaving it world-readable.Binde den veröffentlichten Port an 127.0.0.1. Das Einzige, was Port 3000 direkt erreichen sollte, ist ein Reverse-Proxy auf demselben Host, nicht das offene Internet. Sobald du echte Werte eingetragen hast, enthält diese Datei auch ein aktives Datenbank-Passwort und dein Session-Secret — halte sie aus der Versionskontrolle heraus und führe chmod 600 docker-compose.yml aus, statt sie für alle lesbar zu lassen.

The db healthcheck is what makes umami's depends_on: db: condition: service_healthy mean something on the very first boot. Plain depends_on only waits for the db container process to start, not for Postgres to finish initialising a brand-new volume, which can take several seconds longer on a slow VPS disk than umami takes to attempt its own first connection. Skip the healthcheck and umami can restart once or twice while it waits for Postgres to actually start accepting connections — expected on a fresh volume, and it self-heals, but confusing the first time you watch it happen.Der db-Healthcheck ist das, was umamis depends_on: db: condition: service_healthy beim allerersten Boot überhaupt bedeutungsvoll macht. Ein einfaches depends_on wartet nur darauf, dass der db-Container-Prozess startet, nicht darauf, dass Postgres die Initialisierung eines brandneuen Volumes abschließt — das kann auf einer langsamen VPS-Festplatte mehrere Sekunden länger dauern, als umami für seinen eigenen ersten Verbindungsversuch braucht. Überspringst du den Healthcheck, kann umami ein- oder zweimal neu starten, während es darauf wartet, dass Postgres tatsächlich anfängt, Verbindungen anzunehmen — auf einem frischen Volume normal, und es heilt sich von selbst, ist aber verwirrend, wenn du es zum ersten Mal beobachtest.

One thing that bites later: Postgres only reads POSTGRES_DB, POSTGRES_USER and POSTGRES_PASSWORD the first time it initialises an empty data directory. Edit that password in the compose file after the volume already exists and nothing happens — the database keeps the old one, DATABASE_URL and the container disagree, and Umami fails to start with a connection error that has nothing obviously to do with a password you were sure you'd just changed. Get the password right before the first docker compose up, or change it properly with ALTER USER inside Postgres and update DATABASE_URL to match.Eine Sache, die dich später beißt: Postgres liest POSTGRES_DB, POSTGRES_USER und POSTGRES_PASSWORD nur beim allerersten Mal, wenn es ein leeres Datenverzeichnis initialisiert. Änderst du das Passwort in der Compose-Datei, nachdem das Volume schon existiert, passiert nichts — die Datenbank behält das alte, DATABASE_URL und der Container sind sich uneinig, und Umami scheitert beim Start mit einem Verbindungsfehler, der offensichtlich nichts mit einem Passwort zu tun hat, von dem du sicher warst, es gerade geändert zu haben. Setze das Passwort richtig, bevor du zum ersten Mal docker compose up ausführst, oder ändere es sauber mit ALTER USER innerhalb von Postgres und aktualisiere DATABASE_URL entsprechend.

APP_SECRET, and the default admin login you must change firstAPP_SECRET und der Standard-Admin-Login, den du zuerst ändern musst

APP_SECRET signs the sessions Umami hands out to logged-in users. Generate it properly rather than typing something memorable:APP_SECRET signiert die Sessions, die Umami an eingeloggte Nutzer ausgibt. Erzeuge es richtig, statt dir etwas Merkbares auszudenken:

openssl rand -base64 32

Paste the output straight into the compose file with no line breaks, and keep a copy in a password manager — rotating it later logs out every active session, which is a fine trade the day you actually need it but a bad surprise if you change it by accident.Füge die Ausgabe direkt und ohne Zeilenumbrüche in die Compose-Datei ein und bewahre eine Kopie in einem Passwort-Manager auf — rotierst du es später, werden alle aktiven Sessions abgemeldet, was an dem Tag, an dem du es wirklich brauchst, ein guter Kompromiss ist, aber eine böse Überraschung, wenn du es aus Versehen änderst.

Bring the stack up:Fahre den Stack hoch:

docker compose up -d

Port 3000 is bound to the VPS's own loopback interface, not the public internet, so the only way to open the dashboard from your own machine is through an SSH tunnel: ssh -L 3000:127.0.0.1:3000 user@your-vps, then visit http://127.0.0.1:3000 in a browser on your own machine.Port 3000 ist an das eigene Loopback-Interface des VPS gebunden, nicht ans öffentliche Internet, sodass der einzige Weg, das Dashboard von deiner eigenen Maschine aus zu öffnen, über einen SSH-Tunnel führt: ssh -L 3000:127.0.0.1:3000 user@your-vps, danach rufst du http://127.0.0.1:3000 in einem Browser auf deiner eigenen Maschine auf.

The first login is a fixed default: username admin, password umami. That credential is not a placeholder Umami expects you to notice and change eventually — it is public, documented, and identical on every fresh install anywhere in the world. Log in, go to Settings → Users, edit the admin account, and set a real username and a real password before you point a domain at this container or add a single website to track. Do this in the same sitting you bring the stack up, not as a follow-up task for later.Der erste Login ist ein fester Standardwert: Benutzername admin, Passwort umami. Diese Zugangsdaten sind kein Platzhalter, von dem Umami erwartet, dass du ihn irgendwann bemerkst und änderst — sie sind öffentlich, dokumentiert und auf jeder frischen Installation weltweit identisch. Logg dich ein, geh zu Einstellungen → Nutzer, bearbeite das Admin-Konto und setze einen echten Benutzernamen und ein echtes Passwort, bevor du eine Domain auf diesen Container zeigen lässt oder auch nur eine einzige Website zum Erfassen hinzufügst. Erledige das in derselben Sitzung, in der du den Stack hochfährst, nicht als Folgeaufgabe für später.

HTTPS behind Caddy, and read this before you buy: the NAT IPv4 catchHTTPS hinter Caddy, und lies das, bevor du kaufst: die NAT-IPv4-Falle

Caddy in front of the bound port is the least fuss:Caddy vor dem gebundenen Port ist der Weg mit dem wenigsten Aufwand:

analytics.example.com {
    reverse_proxy 127.0.0.1:3000
}

That line issues and renews the certificate on its own the first time it starts, as long as port 80 and 443 are actually reachable from the public internet for the ACME challenge and the traffic that follows.Diese Zeile fordert das Zertifikat beim ersten Start automatisch an und erneuert es auch automatisch, solange Port 80 und 443 tatsächlich vom öffentlichen Internet aus erreichbar sind — für die ACME-Challenge und den Traffic danach.

That "as long as" is the catch. NAT IPv4 on a VPS means a shared address with a small, fixed set of forwarded ports rather than 80 and 443 of your own — and whether 80 and 443 happen to be among the ports your plan forwards varies by plan and is not something to assume either way; check what your specific plan forwards before you rely on it. Both the dashboard login and every visitor's browser loading the tracking script need to reach port 443, and a browser asking for https://analytics.example.com only ever tries 443, never a forwarded high port instead. A dedicated IPv4 sidesteps the whole question — on our plans that's arranged by e-mail, not a self-service add-on — and short of that, get 443 forwarded specifically, or switch Caddy to a DNS-01 challenge with a DNS-provider module (built via xcaddy, e.g. caddy-dns/cloudflare) so certificate issuance stops depending on any inbound port reaching the box at all; stock Caddy ships no DNS-01 providers built in. Read NAT IPv4 vs a dedicated IP and NAT IPv4, ports and forwarding before you order if this is not already sorted, and if the dashboard is only for you, skipping public exposure entirely and reaching it over an SSH tunnel is a legitimate answer too.Dieses „solange“ ist der Haken. NAT-IPv4 auf einem VPS bedeutet eine gemeinsam genutzte Adresse mit einer kleinen, festen Anzahl weitergeleiteter Ports statt eigener 80 und 443 — und ob 80 und 443 zu den Ports gehören, die dein Plan weiterleitet, variiert je nach Plan und ist so oder so nichts, was du einfach annehmen solltest; prüfe, was dein konkreter Plan weiterleitet, bevor du dich darauf verlässt. Sowohl der Dashboard-Login als auch der Browser jedes Besuchers, der das Tracking-Skript lädt, müssen Port 443 erreichen, und ein Browser, der https://analytics.example.com anfragt, versucht immer nur 443, nie stattdessen einen weitergeleiteten hohen Port. Eine dedizierte IPv4 umgeht die ganze Frage — bei unseren Plänen wird das per E-Mail geregelt, nicht als Self-Service-Zusatz — und wenn das nicht infrage kommt, lass gezielt 443 weiterleiten oder stelle Caddy auf eine DNS-01-Challenge mit einem DNS-Provider-Modul um (gebaut über xcaddy, z. B. caddy-dns/cloudflare), damit die Zertifikatsausstellung überhaupt nicht mehr davon abhängt, dass irgendein eingehender Port die Maschine erreicht; Standard-Caddy bringt keine DNS-01-Provider eingebaut mit. Lies NAT IPv4 vs. dedizierte IP und NAT IPv4, Ports und Weiterleitung, bevor du bestellst, falls das noch nicht geklärt ist, und ist das Dashboard nur für dich gedacht, ist es auch eine legitime Antwort, öffentliche Exponierung ganz zu überspringen und es über einen SSH-Tunnel zu erreichen.

The tracking snippetDas Tracking-Snippet

Inside the dashboard, add a website under Websites, which generates a unique website ID. Umami then hands you the snippet to paste before </head>:Füge im Dashboard unter Websites eine Website hinzu, wodurch eine eindeutige Website-ID erzeugt wird. Umami gibt dir dann das Snippet, das du vor </head> einfügst:

<script defer src="https://analytics.example.com/script.js" data-website-id="your-website-id"></script>

That single tag is the entire integration on the visitor's side — no separate cookie, and by default no persistent identifier written to the browser at all. Umami hashes together the visitor's IP, user agent and a daily-rotating salt to produce a session identifier that changes every day rather than tracking someone indefinitely, which is the actual mechanism behind the "cookieless" claim, not just a marketing line.Dieses eine Tag ist die gesamte Integration auf Seiten des Besuchers — kein separates Cookie, und standardmäßig überhaupt kein dauerhafter Identifier, der in den Browser geschrieben wird. Umami hasht die IP des Besuchers, den User-Agent und ein täglich rotierendes Salt zu einem Session-Identifier zusammen, der sich jeden Tag ändert, statt jemanden dauerhaft zu verfolgen — das ist der tatsächliche Mechanismus hinter dem „cookielos“-Anspruch, nicht bloß eine Marketing-Aussage.

Cookieless still isn't policy-freeCookielos heißt nicht gleich richtlinienfrei

Not writing a cookie is a real, checkable technical property of the script. Whether that means your site needs zero mention of analytics in its privacy policy is a different question, and one this guide will not answer for you: GDPR's information obligations generally apply to processing personal data at all, cookie or not, and IP addresses feeding into even a rotating daily hash are commonly treated as personal data by supervisory authorities and courts. Plenty of sites running cookieless analytics still carry a short paragraph naming the tool and what it collects, precisely because "no cookie" and "no data processing" are not the same claim. Treat this as a prompt to have that conversation with whoever actually handles your privacy policy, not as legal advice from a hosting guide.Kein Cookie zu setzen ist eine echte, überprüfbare technische Eigenschaft des Skripts. Ob das bedeutet, dass deine Seite in der Datenschutzerklärung überhaupt keine Analytics erwähnen muss, ist eine andere Frage, die diese Anleitung nicht für dich beantwortet: Die Informationspflichten der DSGVO gelten grundsätzlich für jede Verarbeitung personenbezogener Daten, Cookie hin oder her, und IP-Adressen, die selbst in einen täglich rotierenden Hash einfließen, werden von Aufsichtsbehörden und Gerichten häufig als personenbezogene Daten eingestuft. Viele Seiten, die cookielose Analytics einsetzen, führen trotzdem einen kurzen Absatz, der das Tool nennt und was es erfasst — eben weil „kein Cookie“ und „keine Datenverarbeitung“ nicht dieselbe Aussage sind. Nimm das als Anstoß, dieses Gespräch mit der Person zu führen, die tatsächlich deine Datenschutzerklärung betreut, nicht als Rechtsberatung aus einer Hosting-Anleitung.

Sizing: Starter is real, until Postgres tells you otherwiseDimensionierung: Der Starter reicht, bis Postgres dir das Gegenteil sagt

Umami's own footprint is small: a Node.js process serving a dashboard and an ingestion endpoint, not a background worker chewing through a queue. On a 1 vCPU / 1 GiB Starter, Umami plus Postgres for a personal site or a small blog fits with room left for the OS and Docker itself — genuinely different from Plausible, where self-hosting Plausible Analytics explains why ClickHouse alone pushes the realistic floor to 2 GiB.Umamis eigener Fußabdruck ist klein: ein Node.js-Prozess, der ein Dashboard und einen Ingestion-Endpoint bedient, kein Background-Worker, der sich durch eine Queue frisst. Auf einem 1-vCPU-/1-GiB-Starter passen Umami plus Postgres für eine persönliche Seite oder einen kleinen Blog bequem hinein, mit Raum für das Betriebssystem und Docker selbst übrig — ein echter Unterschied zu Plausible, wo Plausible Analytics selbst hosten erklärt, warum ClickHouse allein die realistische Untergrenze auf 2 GiB treibt.

What actually grows is Postgres, and it grows with pageviews and events, not with visitor count in any complicated way — every hit is a row, indexed for the dashboard's queries. A handful of low-traffic sites stays small for a long time; a busier one, or several sites pushed into the same instance, eventually turns "the database is slow" and "disk is filling up" into the same conversation. There is no fixed pageview number where that happens, because it depends on retention and how many sites share the instance — watch Postgres's own disk usage and query latency rather than picking a number in advance, and move up a tier once either one is visibly under pressure. run a database on your VPS is worth reading generally before any real database sits on a VPS.Was tatsächlich wächst, ist Postgres, und zwar mit Seitenaufrufen und Events, nicht auf irgendeine komplizierte Weise mit der Besucherzahl — jeder Treffer ist eine Zeile, indexiert für die Abfragen des Dashboards. Eine Handvoll Seiten mit wenig Traffic bleibt lange klein; eine belebtere, oder mehrere Seiten, die in dieselbe Instanz gepresst werden, machen irgendwann aus „die Datenbank ist langsam“ und „die Platte läuft voll“ dasselbe Gespräch. Es gibt keine feste Pageview-Zahl, ab der das passiert, weil es von der Aufbewahrungsdauer abhängt und davon, wie viele Seiten sich die Instanz teilen — behalte Postgres' eigene Festplattennutzung und Query-Latenz im Auge, statt vorab eine Zahl festzulegen, und steig eine Stufe höher, sobald eines von beiden sichtbar unter Druck gerät. eine Datenbank auf deinem VPS betreiben lohnt sich generell zu lesen, bevor irgendeine echte Datenbank auf einem VPS landet.

Backups: the Postgres volume is the whole thingBackups: Das Postgres-Volume ist das Ganze

Everything Umami knows — accounts, websites, every recorded event — lives in that one Postgres volume. pg_dump is the straightforward path:Alles, was Umami weiß — Accounts, Websites, jedes aufgezeichnete Event — lebt in genau diesem einen Postgres-Volume. pg_dump ist der unkomplizierte Weg:

docker compose exec db pg_dump -U umami umami > umami-db-$(date +%F).sql

Copy that file off the VPS before you consider it a backup; a dump sitting on the same disk as the database disappears with that disk. back up your VPS covers what is and is not included by default if you would rather not run this by hand on a schedule.Kopiere diese Datei vom VPS herunter, bevor du sie als Backup betrachtest; ein Dump, der auf derselben Festplatte liegt wie die Datenbank, verschwindet mit dieser Festplatte. Backup deines VPS beschreibt, was standardmäßig enthalten ist und was nicht, falls du das lieber nicht von Hand nach Zeitplan machen willst.

UpdatesUpdates

docker compose pull
docker compose up -d

Umami runs its own database migrations on startup, and a version bump can carry more schema change than a minor-version number suggests. Read the release notes for the version you're jumping to, and take the pg_dump above immediately before you pull — a migration is not something you cleanly reverse once it has already run against your data.Umami führt seine eigenen Datenbank-Migrationen beim Start aus, und ein Versionssprung kann mehr Schema-Änderung mit sich bringen, als die Minor-Versionsnummer vermuten lässt. Lies die Release Notes zu der Version, auf die du springst, und mach den pg_dump von oben unmittelbar bevor du pullst — eine Migration ist nichts, was du sauber rückgängig machen kannst, sobald sie schon gegen deine Daten gelaufen ist.

On overnight.hostBei overnight.host

Full disclosure: this is what we sell. A 1 vCPU / 1 GiB / 25 GB Starter runs Umami and its own Postgres comfortably for a small site; move up once pageview volume actually grows the database and starts competing for the same GiB, not on a fixed schedule.Zur vollen Transparenz: Das ist, was wir verkaufen. Ein 1-vCPU-/1-GiB-/25-GB-Starter betreibt Umami und sein eigenes Postgres bequem für eine kleine Seite; steige eine Stufe höher, sobald das Pageview-Volumen die Datenbank tatsächlich wachsen lässt und sie anfängt, um denselben GiB zu konkurrieren — nicht nach festem Zeitplan.

Linux KVM VPS — EUR 4.99 to EUR 59.99 a month, on our own single-tenant bare metal in Dallas, TX and Charlotte, NC. Full hardware virtualisation (KVM), your own kernel, full root. Six tiers, vps-starter to vps-ultra. Starter is 1 vCPU, 1 GiB RAM, 25 GB disk.Linux-KVM-VPS — 4,99 bis 59,99 EUR im Monat, auf unserer eigenen Single-Tenant-Bare-Metal-Hardware in Dallas, TX und Charlotte, NC. Vollständige Hardware-Virtualisierung (KVM), eigener Kernel, volles Root. Sechs Tarife, vps-starter bis vps-ultra. Starter hat 1 vCPU, 1 GiB RAM, 25 GB Speicher.

You order in the shop, pay by card (Stripe) or SEPA bank transfer, and your login details are e-mailed to you once the service is set up. Support is e-mail, run by one person, with no guaranteed response time. All prices are final totals under the German small-business rule (§19 UStG); no VAT is added or shown.Du bestellst im Shop, zahlst per Karte (Stripe) oder SEPA-Überweisung, und deine Zugangsdaten werden dir per E-Mail zugeschickt, sobald der Dienst eingerichtet ist. Support läuft per E-Mail, von einer einzelnen Person betrieben, ohne garantierte Reaktionszeit. Alle Preise sind Endpreise. Gemäß § 19 UStG wird keine Umsatzsteuer ausgewiesen.

Order vps-starter → · Linux KVM VPS overviewvps-starter bestellen → · Übersicht Linux-KVM-VPS

Written by the person who runs overnight.host: a small, honest hosting company on dedicated bare metal — Linux VPS, game servers, web hosting. Live status at up.overnight.host.Geschrieben von der Person, die overnight.host betreibt: ein kleines, ehrliches Hosting-Unternehmen auf dedizierter Bare-Metal-Hardware — Linux-VPS, Gameserver, Webhosting. Live-Status unter up.overnight.host.