Medama Analytics: a single Go binary for cookie-free web analytics

The problem Medama targets: pageview numbers without a consent banner

Google Analytics and its peers work by setting a cookie or a device identifier, storing it, and joining visits over time. That is what makes funnel and retention reports possible, and it is also what puts the deployment inside GDPR and PECR consent flows. Medama takes the other branch. The README states the tracker is under 1KB and uses no cookies, no IP addresses and no additional identifiers. The stated goal is compliance with GDPR, PECR and similar rules without a consent gate in front of the script. The trade is explicit: if you keep no identifier, you cannot reconstruct the same person across two visits. Medama is for people who want to know which pages are being read and how many people are on the site right now, and who have decided that per-visitor history is not worth the banner. The README also positions it for self-hosting on a VM with 256MB of memory for most small websites, which tells you the intended scale: a personal blog, a documentation site, a small product page. It is not pitched at an organisation tracking millions of sessions a day.

How the tracker, the Go server and DuckDB fit together

There are three directories in the repository, and the README describes them separately: /core, /dashboard and /tracker. The tracker is the JavaScript that goes on your pages. The core is the Go server that receives events. The dashboard is the UI you look at. The README calls the server OpenAPI-based, which means the HTTP surface is described by a specification rather than only by the dashboard's own calls, so you can point your own scripts or internal dashboards at the same endpoints. DuckDB appears in the repository topics, so the analytics store is an embedded columnar database rather than a separate service you install alongside it. That is the architectural decision that makes the single-binary claim possible: no Postgres, no ClickHouse, no Redis to keep alive. The README describes the setup as a single binary with no external dependencies. The consequence is that the database is a file on disk next to the server, and everything the dashboard shows is read from that file. For a small site this is a good fit. For a site where you want to run analytical SQL against years of raw events while the ingest path keeps writing, an embedded store is a different kind of system, and the material here does not describe how Medama handles that concurrency.

Getting it running: what the README and docs actually give you

The README does not inline the install commands. It links to an installation page at oss.medama.io/deployment/installation, and the repository description says the project is self-hostable with a single-binary setup. So the honest answer to how you run it is: the deployment instructions live on the documentation site, not in the README, and you should read that page rather than a blog post. What the README does commit to is the shape of the deployment. One binary, no external dependencies, target hardware of a 256MB VM for most small websites. On the client side, integration means adding the tracker script to your pages and pointing it at your server. The tracker is the MIT-licensed part of the repo, which makes it the easiest piece to read if you want to know exactly what is sent before you put it on a production page. The README also links an OpenAPI reference at oss.medama.io/api-reference/introduction, which is where you would look to build a custom report or push events from something other than a browser. A demo instance is linked at demo.medama.io, which is the fastest way to see the dashboard before you spend time on a server. I have not installed or run any of this, so treat the installation page as the source of truth for image tags, ports and volume mounts.

The licensing split is the first thing to read carefully

Medama is not one licence. The README states that /core and /dashboard are under Apache License 2.0, and that /tracker is under the MIT License. That is a permissive combination, but the split matters for a specific reason: the two directories that make up the server and the UI are under a licence with an explicit patent grant and a notice-and-change requirement, while the small script you embed in your pages is under a shorter, simpler licence. If you fork the dashboard to add a report, you are working under Apache 2.0 terms in that directory. If you vendor the tracker into your own build pipeline, you are working under MIT terms. The repository metadata supplied here lists the licence as unknown, which is a reminder that the top-level repository may not carry a single LICENSE file covering everything. Check core/LICENSE, dashboard/LICENSE and tracker/LICENSE individually. This is not legal advice, and if you plan to redistribute a modified Medama, the directory you touch determines which terms you inherit.

Where Medama stops being the right tool

The cookie-free, identifier-free design is the whole product, and it is also the limitation. Without a stored identifier, Medama cannot tell you that the person who read your pricing page on Tuesday is the same person who signed up on Friday. It cannot deduplicate a visitor who moves from a laptop to a phone. It cannot build a cohort. The README's compliance framing is the benefit; the missing visitor history is the cost, and it is not a bug that will be patched later, because patching it would break the compliance claim. There is a second limitation in the deployment model. A single binary with an embedded database is easy to run and hard to scale horizontally. The README's own reference point is a 256MB VM for most small websites, which is a statement about the intended load, not a ceiling that has been benchmarked here. If your traffic profile is spiky, or if you need the analytics store to survive the loss of one machine without you restoring a file, the architecture pushes that work onto you. Third, the release history supplied here shows v0.6.0 in August 2025, v0.6.1 a week later, v0.6.2 in January 2026, and no release since, while the repository's last push is dated August 2026. A gap between releases and commits is normal for a small project, but it means you should check the issue tracker and commit log yourself before assuming a problem you hit is already fixed.

How it differs from Plausible and Umami, and from server-side logging

The obvious alternatives in this category are Plausible and Umami, both self-hostable and both cookie-free by default. The difference is in the runtime shape. Plausible runs on PostgreSQL and ClickHouse, and Umami runs on PostgreSQL or MySQL, so both ask you to operate a database server next to the application. Medama's README claims a single binary with no external dependencies, and the repository topics name DuckDB, an embedded database. That is a real operational difference: one process and one file versus an application plus a database service to back up, upgrade and monitor. The cost of the simpler shape is that you inherit the embedded database's constraints rather than a database server's features. A second alternative is not an analytics product at all: parsing your web server's access logs. That gives you raw request data and no client-side script, but it also gives you bot traffic, no JavaScript-dependent pageview semantics, and no realtime dashboard unless you build one. Medama sits between those two: more structured than log parsing, less infrastructure than the Postgres-and-ClickHouse stack. The README's OpenAPI-based server is what makes it usable as a data source rather than only as a dashboard, which is the part worth checking against your own reporting needs.

Maintenance cost and what to verify before you deploy

The maintenance story follows from the single-binary design. There is no database service to patch, so upgrades are a matter of replacing the binary or image and restarting. The thing you have to think about is the DuckDB file: it is your entire analytics history, it lives on the host, and backing it up is your job rather than a managed service's. The README does not describe a backup procedure, so treat that as something to design before you point the tracker at production. On upgrades, the release list supplied here shows three releases across roughly six months in 2025 and 2026, which suggests you should read release notes rather than assume a drop-in binary swap, particularly if the on-disk format changes between minor versions. The dashboard and core are Apache 2.0, so if you modify them you carry the notice obligations; the tracker is MIT. If you only deploy the published image and embed the unmodified tracker, the licence question is simpler than if you fork. The demo at demo.medama.io is the cheapest way to check whether the reports answer your questions before you commit a VM to it.

Editorial conclusion

Adopt Medama if you run a small or medium site, you want the analytics database on your own hardware, and a pageview-and-realtime dashboard is enough. Do not adopt it if you need session stitching across subdomains, cross-device attribution, or a vendor to call when the server stops ingesting. Before you commit, verify three things against the current docs: the exact Docker image tag and volume path for the DuckDB file, whether your jurisdiction accepts a cookie-free single-visit count as consent-free under GDPR and PECR, and which licence file applies to the directory you plan to modify.

Official sources

1. Issues
2. medama-io/medama on GitHub
3. Project website
4. README
5. Releases