Self-Hosted vs Hosted Privacy Analytics: How to Choose

Self-hosted vs hosted privacy analytics is usually presented as a values question — do you want to own your data or not? In practice it’s an operations question, and the honest version is: who is going to apply the security update at eleven at night when you’re on holiday?

Both models can be genuinely privacy-first. Neither is automatically more compliant than the other. What differs is where the work sits and what you’re accountable for. Here’s how I decide, and where the decision goes wrong.

What Self-Hosting Actually Changes

The first thing to get straight: self-hosting is not what makes analytics private. A tool that collects personal data collects it on your server too — you’ve changed the address, not the practice.

What self-hosting changes is the relationship. With a hosted tool, the vendor is a processor acting on your instructions, and you need an agreement with them. Self-host and there is no third party at all — nothing leaves your infrastructure, so there’s nothing to disclose, no transfer to justify, no processor agreement to maintain.

That’s a real simplification of your paperwork, and it’s the strongest argument for self-hosting. It only holds, though, if the tool itself is privacy-first by design. Running a data-hungry platform on your own box gives you all the obligations and none of the convenience. The design question comes first, the hosting question second — which is the order I argued in what privacy-first analytics actually means.

The Two Bills Nobody Compares Properly

Cost comparisons in this space are almost always dishonest, because only one side gets counted.

A hosted plan has one number and you can read it on the pricing page. Self-hosting has two: the server, which is small and visible, and your time, which is large and invisible. A small VPS costs a few euros a month — genuinely cheap. The maintenance costs somewhere between one and six hours a month depending on the tool’s architecture, and that’s the line item that decides the answer.

Price your own hour honestly. At even a modest rate, two hours a month makes a cheap server more expensive than most hosted plans. That doesn’t make self-hosting wrong — it makes “it’s cheaper” the wrong reason to choose it. Choose it for control and data ownership, and treat the cost as roughly a wash.

The architecture drives the hours more than the traffic does. A tool that runs as a single process with a file-based database is close to zero upkeep. A tool that needs a second database engine for analytical queries needs monitoring, tuning and its own backup strategy. That difference is bigger than any pricing difference between vendors.

The Question That Actually Decides It

Forget features for a moment. Answer these four honestly.

That last row is the one people skip, and it’s the most important. A self-hosted analytics instance is a public web service holding behavioural data. It needs patching like anything else. If nobody on your side reads release notes, hosted is not a compromise — it’s the more responsible choice, because the vendor patches it whether you noticed or not.

I’ve seen a self-hosted instance left two major versions behind for a year because the person who set it up changed jobs. That’s a worse privacy outcome than any hosted plan.

What Each Model Is Genuinely Better At

Neither wins outright. They win at different things.

Self-hosting wins when data residency is contractual rather than preferential, when you already have infrastructure and someone accountable for it, when you want unlimited retention without per-event pricing, or when you need to modify the tool itself.

Hosted wins when you have no ops capacity, when you’d rather spend your attention on the site than the stack, when you need reliability you don’t have to provide, or when the team changes often enough that “the person who set it up” is a real risk.

There’s a middle path worth knowing about: hosted, but with a vendor whose servers sit in your jurisdiction. You keep the processor relationship and the agreement, but the transfer question disappears. For most European sites this is the pragmatic default, and it’s what I recommend when someone wants the compliance benefit without the operational one.

If You Self-Host, Do These Five Things

Self-hosting done badly is worse than hosted done well. The minimum viable setup:

1. Automate backups and test a restore. An untested backup is a belief, not a backup. Restore once to a scratch server so you know the procedure works.
2. Put it behind HTTPS with automatic certificate renewal. Expired certificates are the most common self-hosted outage, and they’re entirely preventable.
3. Subscribe to the project’s release notes. You need to hear about security releases from the project, not from an incident.
4. Set a retention period and enforce it in the tool. Unlimited retention is a feature until it’s a liability. Pick a number and configure it — the reasoning is in the compliance checklist.
5. Write down who owns it. One name, and a second person who knows where it runs. This is the step that prevents the abandoned-instance scenario above.

Half an hour of setup on each of those saves the weekend you’d otherwise lose.

If You Go Hosted, Check These Three

Hosted isn’t zero-diligence either.

Where the servers physically are. “EU company” and “EU hosting” are different claims. Ask for the region, not the headquarters.

Whether the processor agreement is actually accepted. Most vendors publish a standard one, and it usually isn’t automatic — you have to accept it in the dashboard. Go and do it rather than assume.

What happens to your data if you leave. Export format and deletion policy. If you can’t get your numbers out in a readable file, you’re renting your own history.

Monitoring: the Part People Skip

If you self-host, one more thing separates a setup that stays healthy from one that quietly rots: you need to find out it’s broken before your readers do.

Analytics fails silently. Unlike your website, nobody complains when it stops recording — the pages still load, the dashboard still opens, and the only symptom is a line that flattens. I’ve seen an instance stop collecting for three weeks because a disk filled up, and the only reason it surfaced was somebody wondering why a good week looked quiet.

Three checks cover almost everything, and none of them need a monitoring platform:

• An uptime check on the analytics URL. Free services will ping it every few minutes and email you when it stops answering.
• A disk-space alert. Analytics databases grow steadily and then hit a wall. A warning at 80% gives you a calm afternoon instead of an outage.
• A weekly glance at yesterday’s number. Not the dashboard, just the count. If it’s zero on a normal Tuesday, something broke.

That third one is the cheapest and catches the most. Automated checks tell you the service is up; only looking at the number tells you it’s still recording anything meaningful.

With a hosted tool, all of this is the vendor’s job — which is precisely what you’re paying for, and worth remembering when you compare the two bills.

Frequently Asked Questions

Is self-hosted analytics more GDPR-compliant?

Not inherently. It removes the processor and transfer questions, which shortens your paperwork. It does nothing about what the tool collects, how long you keep it, or whether you can honour a deletion request. Those obligations follow the data, not the address — as covered in this piece on compliant tracking.

Can I start hosted and move to self-hosted later?

Yes, and it’s a sensible order. Prove the tool answers your questions on a hosted plan, then move it in-house once you know it’s worth the operational commitment. Expect to start the data fresh unless the tool has an import path.

What if my traffic is tiny?

Then hosted almost certainly wins. At low volume the free or entry tiers cover you, and the maintenance hours of self-hosting buy you nothing. If you’re not sure you need analytics at all, this is worth reading first.

Does self-hosting mean no consent banner?

No — that depends on whether the tool stores anything on the visitor’s device, not on where it runs. A cookie-setting tool on your own server still triggers the storage rule.

Bottom Line

Self-hosted vs hosted is a question about operational capacity, not virtue. Self-hosting removes the third party and the transfer question, and gives you unlimited retention on your terms — in exchange for patching, backups, certificates and a named owner. Hosted buys that back and costs you a processor relationship you have to document.

Pick the tool for what it collects first. Pick the hosting model second, based on whether someone will genuinely notice a security advisory within the week. If the honest answer is no, hosted with EU-based servers is the better privacy outcome, not the lazier one.

For the tools that work either way, see the privacy-first alternatives I’ve tested. On the legal side, the transfer rules live in Chapter V of the GDPR, and the ICO’s organisation guidance covers processor obligations in readable terms, and the EDPB guidelines cover the processor relationship in more depth.