I wanted analytics for this site without the baggage that usually comes with them — no cookies, no tracking scripts that make the page feel like it’s reporting on someone. Umami fit what I was looking for, so that’s what I set up.
Why Umami
The short version: it doesn’t use cookies, and it’s built to be privacy-respecting by default rather than as an afterthought. It’s GDPR compliant, which isn’t something I strictly need — I’m not running a business with EU users to worry about — but it’s a good bar to aim for anyway. If a tool is built to meet that standard, it’s usually built with the right instincts elsewhere too.
Fitting It Into an Existing Setup
Everything on this site already runs through Docker Compose behind Traefik, so the real question was how much friction Umami would add. Not much, as it turns out. It’s a single service plus a Postgres database, and it slotted into the existing compose file without fighting the rest of the stack. Traefik picked it up the same way it picks up everything else — a couple of labels and it’s routed.
The official install guide covers the Docker setup well enough that I won’t repeat it here. If you’re already running Compose for other services, adding Umami is mostly a matter of dropping their service block into your existing file and pointing Traefik at it.
Using It
I logged in, looked around, and basically knew where everything was. That’s rare enough to be worth mentioning. No manual, no “let me find the docs for this,” just clicking around and having it make sense.
I know you can build out custom dashboards — Umami supports it — but I haven’t gotten there yet. Honestly haven’t needed to. The default view already tells me what I actually want to know: is anyone showing up, and where are they coming from. That’s most of it, for now.
I’ve only had it running a short while, so this is more of a first-impressions thing than a verdict. I’ll probably do a follow-up once I’ve lived with it longer and hit whatever edges are out there.