← All insights

Self-hosted analytics in the EU

All three of our production websites — this one, our equity research platform EvidInvest, and its developer-facing search product — run their web analytics on a single self-hosted Umami instance on an EU server. No third-party analytics scripts, no cookies, no data leaving our infrastructure. This is the actual setup, what it costs to operate, and what we gave up to get it.

The short version

One open-source container plus its own Postgres database, deployed with a docker-compose file and a ten-line reverse-proxy config, on a server we were already paying for in Helsinki. It tracks three production sites, sets no cookies, keeps every event first-party in the EU — and exposes an API clean enough that our AI reporting agents query it every morning without a human logging in.

Why we moved off third-party analytics

Three reasons, in the order they actually mattered to us. First, data ownership: with a hosted analytics provider, your traffic history lives in someone else’s account, on their retention schedule, exportable on their terms. Ours now sits in a Postgres database we can query, back up, and join against business data. Second, privacy posture: Umami is cookieless and stores no personal profiles by default, so the analytics layer stops being the thing that forces a consent banner onto every page — and stops silently losing the visitors who decline one. Third, machine access: we run daily AI agents that read traffic data, and giving an agent a scoped, read-only API token against our own instance is far saner than handing it credentials to a third-party account.

The setup

The whole deployment is two files. A docker-compose.yml runs the official Umami image next to a dedicated Postgres container, and a short config file registers the subdomain with the Caddy reverse proxy that already fronts the other services on the machine. The server itself is a single Hetzner VM in Helsinki that also runs our OpenSnow analytics warehouse, a Metabase instance, and a CI runner — analytics for three sites added no new hardware and no new monthly bill.

On the sites, the integration is one script tag. The tracker is a few kilobytes, served from our own domain, and unaffected by the ad-blockers that discard a large share of third-party analytics requests.

What it feeds

The less obvious payoff is that analytics became infrastructure other systems can build on. Umami’s share-token API serves read-only stats without a login, so the daily AI agent loop that runs our SEO pulls yesterday’s visitors, referrers and campaign parameters into its morning report automatically — and can separate paid clicks from organic search before anyone draws a conclusion from a traffic spike.

What you give up

Honesty is part of the method. Compared to Google Analytics you lose the ads ecosystem: no linked ad accounts, no audience exports, no demographic estimates. Bot filtering is more basic — we have caught crawler traffic inflating one site’s numbers and now cross-check against server-side counts, which is a discipline you inherit when you own the stack. And you own the uptime: if the VM is down, so is your measurement. For a marketing team deep in Google’s ad tooling those costs are real. For product and consultancy sites that mostly need honest first-party numbers, we have not missed any of it.

Is this right for your organisation?

The pattern generalises well beyond analytics: pick the boring open-source tool, run it next to infrastructure you already pay for, keep the data in Postgres where your other systems can reach it. If your organisation is weighing data residency, consent fatigue, or just wants its own numbers back, this is a small, reversible first project — the kind we typically stand up alongside a broader data platform engagement.

Want your analytics — and your data — back in-house?

EBD Sweden designs and operates EU-hosted data infrastructure for Nordic organisations — from a single analytics container to a full warehouse with dashboards and AI agents on top.