People arrive at this decision having already made the big one: they chose Matomo, usually for ownership and GDPR posture. Then the second decision, self-hosted or cloud, gets made by vibes. "Self-hosted, obviously, it's free and it's more private." One of those claims is half-true and the other needs qualifying, so let us do both properly.
What self-hosting actually involves
Matomo is a PHP application with a MySQL (or MariaDB) database. At small scale, a modest server runs it without drama, and the setup honestly is approachable: this is mature, well-documented software.
The costs arrive with traffic and time:
- The database grows relentlessly, because raw visit data is the product. At real e-commerce volume, you are doing MySQL capacity planning, whether or not anyone on your team enjoys that sentence.
- Archiving (Matomo's report pre-computation) needs cron jobs, memory, and at scale, actual tuning. Skipped or misconfigured archiving is the classic "Matomo is slow" root cause.
- Updates are yours: core, plugins, PHP versions, security patches. An unpatched analytics server holding visitor data is a liability with a login page.
- Backups, monitoring, TLS, uptime: the whole boring liturgy of running a service, applied to a system marketing depends on daily.
None of this is exotic. All of it is recurring. The license costs nothing; the marriage costs hours every month, and the hours belong to whoever your named owner is. No named owner, no self-hosting: that rule alone would prevent most of the sad Matomo instances I encounter.
What cloud actually involves
Matomo Cloud is the same product, hosted by the company that makes it, on EU infrastructure, with updates, scaling, and backups handled. You pay per traffic tier (check the current pricing page; tiers shift), and some plugins that cost extra on-premise are bundled.
The tradeoffs are equally plain: recurring cost that scales with traffic, and your visitor data now sits with a processor, albeit an EU-based one whose entire brand is privacy. For most companies' GDPR posture, "EU processor with a DPA" is a perfectly good story; it is simply a different story than "our server, our building, our jurisdiction."
Compliance nuance worth stating precisely: cloud hosting does not weaken most of Matomo's privacy advantages over GA4 (no ad-giant data sharing, cookieless options, raw data access). What it changes is the residency and processor chapter of your privacy documentation. Whether that chapter matters at the "hard requirement" level is a question for your DPO, not your developer.
The decision, without romance
Choose self-hosted when all three hold:
- A hard residency or sovereignty requirement actually exists, from a regulator, a contract, or a risk posture someone senior signed, not from a feeling that self-hosting sounds more serious.
- A named person owns the instance, with time budgeted, and a fallback when they leave.
- Your traffic and team scale make the operational work proportionate. A company already running production infrastructure adds Matomo cheaply; a five-person team with no ops hires a part-time sysadmin disguised as a free license.
Choose cloud in every other case, which, in my honest experience, is most cases. The ownership story you actually wanted (out of Google, EU jurisdiction, raw data yours, exportable) survives intact, and the hours you did not spend on MySQL go into the part that determines whether any of this pays off: implementation quality.
The total-cost math in one paragraph
Price cloud at your traffic tier over three years. Price self-hosting as server costs plus, more importantly, a realistic monthly hour count (setup, updates, the occasional archiving fire) multiplied by what those hours cost you, multiplied by three years. Add one incident: a day of downtime or a weekend recovery, because over three years there will be one. In my experience the lines cross only at meaningful scale or where infrastructure capacity already exists as a sunk cost. Below that, "free" is the most expensive word in the sentence.
Either way, do this
Whichever side you land on: turn on regular raw-data exports or backups you control (ownership is a practice, not a hosting checkbox), document the consent and cookieless configuration decisions that motivated Matomo in the first place, and put the instance on the same verification routine as any other tracking. A privacy-respecting tool measuring the wrong numbers is still measuring the wrong numbers, just more politely. And if the decision above is genuinely unclear for your situation, it usually means the residency requirement was never actually pinned down; pinning it down is a one-conversation task with whoever owns your compliance, and it is worth having before the invoice, not after.