"Self-hosted or hosted" is usually argued as though it were about money, and then decided on a monthly-fee comparison that leaves out most of the cost. Here is the comparison with the rest of it put back in.
What self-hosting actually gets you
Three things, and they are genuinely valuable.
The data is on infrastructure you control. Not "stored in a region you selected" but on a machine whose root password you hold. For some organisations -- healthcare, defence, parts of the public sector -- this is the requirement, and nothing else in the comparison matters.
You can read and change the code. You can audit what is collected rather than believing a privacy policy. You can patch something yourself instead of waiting.
There is no per-event pricing. A traffic spike costs you server capacity, not a bill. If your traffic is enormous and your budget is fixed, this changes the arithmetic entirely.
What it costs after the install
The install is the part everybody estimates, and it is the small part. An analytics stack is not a static site: it is a write-heavy database, an ingestion endpoint exposed to the open internet, and a set of scheduled jobs.
Upgrades, forever. Not just the application: the database, the operating system, the TLS certificates, the runtime. An analytics database is exactly the kind of thing that accumulates a schema migration on every release, and those run against a table with a lot of rows in it.
Backups you have tested. Untested backups are a belief, not a backup. The test is restoring to a fresh machine and confirming the data is there, and it needs doing on a schedule, because a backup job that silently stopped six months ago looks exactly like one that is working.
Storage growth. Event data grows with traffic and never shrinks unless you make it. Somebody has to decide the retention policy, implement it, and notice when the disk is at 80%.
Being on call for it. The ingestion endpoint is public. It will be scanned, it will be sent malformed payloads, and at some point somebody will point a script at it. When it falls over at 3am on a Saturday, the person who fixes it is you.
The knowledge sitting in one head. This is the cost that bites hardest and gets estimated least. In most companies that self-host, exactly one person understands the deployment. When that person leaves, the organisation owns a production system nobody can safely touch. The usual outcome is that it stops being upgraded, which turns a privacy-motivated decision into an unpatched internet-facing service.
Put a plausible number on the hours and compare that to the subscription. For a small team the hosted option is very often cheaper in the only currency that is actually scarce.
When self-hosting is clearly right
- A regulatory or contractual requirement that the data never leaves your infrastructure.
- You already run databases in production and have the on-call rota, the backup discipline and the monitoring. The marginal cost of one more service is small.
- Traffic large enough that per-event pricing dominates, with the engineering capacity to match.
- The tool is genuinely part of your product, and you need to modify it.
When hosted is clearly right
- Fewer than a handful of engineers, all of whom have something more valuable to do.
- Nobody wants to own an internet-facing ingestion endpoint.
- You want the tool to improve without a maintenance window.
- Your requirement is really about where the data lives rather than who operates the machine -- in which case an EU-based processor answers it without the operational burden.
That last point is worth separating out, because the two get conflated. "The data must stay in the EU" and "the data must be on our hardware" sound similar and have very different answers.
The middle ground people forget
You do not have to choose once, for everything, forever.
Some organisations self-host for the product and use a hosted tool for the marketing site, on the reasonable grounds that the risk profiles differ. Some run hosted while they are small and move when the volume justifies the operations work. Some do the reverse after the person who understood the deployment leaves.
The question worth asking before you commit either way is the boring one: can you get your data out? A tool with a full export and a documented schema keeps the decision reversible. One without it makes your first choice permanent, whichever direction it was.
Where Skomi sits
Skomi is hosted, and not open source. Both of those are rows Skomi loses against some of the alternatives, and they are in the comparison tables as rows rather than as footnotes -- next to Matomo, Plausible and Umami, all of which can be run on your own machine.
What Skomi offers instead is the data stored in the EU with nobody to operate, and a full export whenever you want one. If your requirement is genuinely about control of the machine, one of those others is the better tool and this is the paragraph that says so.
Where Skomi stands on the rows that actually decide this, self-hosting and open source among them, both of which it loses, is set out on Matomo. The practical difference is whose problem the machine is: hosted means your retention window is your plan's rather than your disk's, and the Analytics product assumes somebody else is patching the server.