A practical guide to judging whether a self-hosted analytics project is still actively developed, using the public signals every open-source repository exposes.
If you are planning to self-host your website analytics, maintenance activity is one of the first things worth checking. A tool you run on your own server needs security patches, dependency updates and bug fixes to stay safe and useful, and an open-source project that has gone quiet leaves you carrying that burden alone.
The good news is that maintenance activity is not a matter of guesswork. Open-source analytics tools are developed in public, so the same signals a developer uses to judge any repository apply here: how recently code was committed, how often releases ship, how many issues and pull requests are open, and how the project handles the split between its hosted service and its self-hostable edition. This guide walks through those signals and reads them against a live example, Plausible Analytics, using figures observed on its GitHub repository on 2026-08-17.
The short version
Before you start
Maintenance activity is easy to verify because open-source analytics tools develop in public. Read the releases feed, recent commits, and open issues and pull requests together rather than trusting any single number. As a live example, Plausible's GitHub repository showed roughly 28.6k stars, 4,352 commits, 24 open issues and 32 open pull requests as of 2026-08-17; its README states the hosted cloud updates multiple times per week while the self-hostable Community Edition ships as a long-term release twice per year. Watch for the split between the fast-moving hosted service and the slower stable self-hosted edition, which is normal and does not mean a project is neglected.
52 weeks of commits, week by week (measured 2026-08-17)
| Repository | 2025-08-18 → 2025-11-17 | 2025-11-17 → 2026-02-16 | 2026-02-16 → 2026-05-18 | 2026-05-18 → 2026-08-17 | 52-week total | Week by week |
|---|---|---|---|---|---|---|
| Plausible | 189 | 116 | 190 | 138 | 633 | |
| Umami | 333 | 374 | 482 | 341 | 1,530 | |
| Matomo | 154 | 186 | 245 | 323 | 908 | |
| PostHog | 3,453 | 4,552 | 7,437 | 13,241 | 28,683 |
On 2026-08-17 we queried each project's public GitHub statistics endpoint ourselves and tallied weekly commit counts across the same 52 weeks, binned into four 13-week windows. Over that span PostHog's repository logged 28,683 commits — rising window over window from 3,453 to 13,241 — while Plausible recorded 633 and Umami 1,530, and Matomo's 908 climbed steadily from 154 to 323 in the most recent quarter. For someone weighing whether to depend on one of these tools, that shape is a rough signal of ongoing maintenance activity and its trend: all four show commits within the last few days of the 2026-08-17 snapshot, and none has visibly stalled. It says nothing, however, about code quality, whether those commits represent real progress or churn, how many people actually run the software, or whether any of these projects will still be maintained a year from now — commit volume also reflects team size and workflow, so the raw counts are not comparable as a measure of effort.
Weekly commit counts for the last 52 weeks, from each repository's own GitHub statistics endpoint, grouped into four 13-week windows. Every repository is measured over the same 52 weeks, so the columns are directly comparable. Commit counts include merges, dependency bumps and documentation edits, and a monorepo will always show more commits than a single-purpose repository — this measures how busy a repository is, not progress, quality, or how much of the work reaches users. Collected by this site on 2026-08-17 (2026-08-17T00:31:57Z) by calling the public APIs ourselves — 12 of 12 requests returned data. These are our own readings, not figures supplied by any vendor.
What "actively maintained" means for a self-hosted tool
For software you host yourself, maintenance covers more than new features. The things that matter most are security fixes, updates to underlying dependencies, and compatibility with current database and runtime versions. A project can look feature-complete and still be risky to run if nobody is shipping patches when a vulnerability is disclosed.
There is also a distinction that trips people up. Many analytics tools offer a paid hosted service alongside a free self-hostable edition, and the two often move at different speeds. The hosted version can receive changes continuously while the self-hosted build is cut into stable releases at a slower, predictable cadence. Both can be actively maintained even though the version you install lags behind what runs on the vendor's cloud.
The GitHub signals that reveal maintenance activity
Because these projects develop in the open, you can assess them without installing anything. When you open a repository, look for the following.
Recent commits and total commit count. The date of the most recent commit tells you whether work is ongoing right now. A high lifetime commit count shows sustained effort over the years.
Release cadence. Check the releases feed for how regularly tagged versions ship. This is the version you would actually deploy, so its rhythm matters more than raw commit noise.
Open issues and pull requests. An active project usually has a steady flow of both. A large backlog is not automatically bad; it often reflects an engaged user base. What you want to see is that issues and pull requests are being triaged and merged, not left untouched.
Contributor breadth and stars. Stars and forks indicate community interest, while the mix of contributors hints at whether the project depends on a single person or has a broader base.
Security policy. A published security policy and a channel for reporting vulnerabilities signal that the maintainers take patching seriously.
No single number settles the question. Read several together, and weight the release feed and recent commits most heavily.
A worked example: reading Plausible's repository
Plausible Analytics is a good project to practise on because its repository is public and busy. On its GitHub page as of 2026-08-17, the repository showed about 28.6k stars and 1.8k forks, with 4,352 commits recorded against the master branch (github.com/plausible/analytics). At that same observation, the issues tab listed 24 open issues and the pull requests tab listed 32 open pull requests.
Read those together and a picture forms. The commit total reflects years of sustained work; the copyright notice on the repository runs from 2018 to the present (github.com/plausible/analytics, as of 2026-08-17), which lines up with a project that has been developed steadily rather than abandoned. A live flow of open issues and pull requests points to ongoing triage and contribution rather than a dormant codebase.
The project also documents its own release rhythm, which is the single most useful maintenance signal for a self-hoster. According to the repository's README (as of 2026-08-17), the hosted Plausible Analytics Cloud is "continuously developed and improved with new features and updates multiple times per week," while the self-hostable Plausible Community Edition is described as "a long term release published twice per year so latest features and improvements won't be immediately available."
Why the cloud and self-hosted editions move at different speeds
The gap between those two cadences is deliberate, and understanding it will save you from misreading a healthy project as a slow one. A twice-yearly stable release for the self-hostable edition does not mean development has stalled; it means the maintainers batch continuous work into long-term releases that are meant to be dependable on your own server.
Plausible's README is explicit that the self-hosted Community Edition is a free, community-supported build, and that some capabilities are held back from it. As of 2026-08-17, the README lists marketing funnels, ecommerce revenue goals, SSO and the sites API as premium features that are not included in the Community Edition, which the project frames as a way to support its long-term sustainability. When you evaluate any self-hosted analytics tool, separate two questions: is the project actively maintained, and does the free self-hostable edition include the specific features you need. A project can score well on the first while still gating features you want behind the paid tier.
Why maintenance matters more for privacy-focused analytics
Analytics software sits in the request path of every page on your site and processes visitor data, so staleness carries real consequences. Outdated dependencies can turn into security exposure, and compliance expectations shift over time. Plausible positions itself as a privacy-first, cookie-free tool and states in its README that it is compliant with GDPR, CCPA and PECR (github.com/plausible/analytics, as of 2026-08-17). Claims like those only hold if someone keeps the code current as regulations and browsers evolve, which is exactly why maintenance activity is not a cosmetic concern for this category.
There is a data-portability angle too. The README notes that self-hosting gives you direct access to the raw data in the underlying ClickHouse database (as of 2026-08-17). That control is valuable, and it also means the responsibility for backups, upgrades and security rests with you, so choosing a well-maintained upstream project reduces how much of that burden you inherit.
How to check any self-hosted analytics tool before you commit
Run the same short checklist against any candidate before you deploy it.
Open the releases feed first. Confirm that tagged releases ship on some regular cadence and that a recent one exists.
Scan recent commits. A repository with commits in the last days or weeks is being worked on now.
Sample the open issues and pull requests. Look for maintainer replies and merged pull requests, which show the project is responsive.
Find the security policy. A documented way to report vulnerabilities is a sign the project is run responsibly.
Confirm the license and the edition split. Check which license governs the code and whether the free self-hostable edition covers the features you actually need.
You can apply this method to more than one project. Plausible's repository is at github.com/plausible/analytics, and Umami, another open-source, self-hostable analytics tool, keeps its repository at github.com/umami-software/umami; open each one and read the same signals side by side before deciding what to run.
Bottom line
You do not have to take a vendor's word for how actively its analytics tool is maintained, because the evidence is public. The most reliable read comes from the release feed, the date and volume of recent commits, and the flow of open issues and pull requests, judged together rather than one at a time. Weight the release cadence highest, since that is the version you will actually install.
Plausible works well as a reference point. As of 2026-08-17 its GitHub repository carried 4,352 commits and about 28.6k stars, with 24 open issues and 32 open pull requests, and its README documents a hosted edition updated multiple times per week alongside a self-hostable Community Edition released twice per year. Expect that same two-speed pattern from other tools in this space, treat a slower stable self-hosted cadence as normal, and always confirm separately that the free self-hostable edition includes the features you need before you commit a server to it.
FAQ
Is Plausible Analytics actively maintained?
The public signals point that way. As of 2026-08-17 its GitHub repository showed about 28.6k stars, 4,352 commits, 24 open issues and 32 open pull requests, and its README describes a hosted cloud updated multiple times per week and a self-hostable Community Edition released twice per year (github.com/plausible/analytics).
How often does the self-hosted version of Plausible get updated?
According to its GitHub README as of 2026-08-17, the self-hostable Plausible Community Edition is a long-term release published twice per year, so new features that appear on the hosted cloud are not immediately available in the self-hosted build.
Does an open-source license tell you whether a project is maintained?
No. A license describes the legal terms for using, modifying and redistributing the code. Whether developers are still shipping changes is a separate question, and you answer it from the release feed, recent commit dates, and the flow of merged pull requests.
Which signals should I check first when evaluating a self-hosted analytics tool?
Start with the releases feed to see whether tagged versions ship regularly, then scan recent commits for current activity, then sample open issues and pull requests to confirm maintainers are responding. Finish by checking the security policy, the license, and which features the free self-hostable edition actually includes.
Sources
Originally published at https://utilverse.info/compare/how-actively-are-self-hosted-analytics-tools-maintained-how-to-check-for-yourself/.
Top comments (0)