Plan: a Minecraft server analytics plugin with its own web dashboard

One jar for every server platform

Player Analytics is described as a fully-fledged solution for the analytics needs of a Minecraft server. The plugin collects data about what players do and when, and a built-in webserver displays insights into different aspects of the server, such as online activity, the playerbase, and how these change over time. That is the whole product in one sentence: the plugin runs inside your server, and it also runs a web server that shows you what it collected.

The platform support is the first thing to check. The readme lists Spigot, Paper, Fabric, Sponge, SpongeForge, Bungeecord, Velocity, Folia and all derivatives, and the claim is one jar for all platforms. That is a significant engineering constraint rather than a convenience, because a plugin that has to run inside both a Bukkit server and a Fabric server and a proxy such as Bungeecord or Velocity cannot use any single platform API for its data collection. It also means the plugin is usable in the proxy layer, which is where you get the clearest picture of who connects to the network rather than to one backend server.

The repository layout matches a plugin of this shape. The Plan/ directory holds the source, there is an architecture overview image at the top level, a scripts/ directory, a sonar-project.properties file, an AGENTS.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md and a jitpack.yml. The wiki is where the documentation and tutorials live, and the readme links the releases page, the development builds from the CI workflow, and the issue tracker.

The web interface is a JavaScript front end served by the plugin

The stack listed under Used Libraries is a good way to understand what you are installing. The web interface is built on the SBAdmin 2 template from Blackrock Digital, with Bootstrap, and it charts data with HighCharts and FullCalendar. The icons come from Font Awesome, and the plugin uses the MaxMind GeoIP2 Country database, which is how it turns connection addresses into country information. The Java side uses Dagger for dependency injection and DependencyDownload for fetching things at runtime.

The licence terms of those dependencies are worth reading, because they are not all the same. Bootstrap, the SBAdmin template, FullCalendar and DependencyDownload are MIT, Dagger is Apache-2.0, Font Awesome is under the SIL Open Font License, MaxMind GeoIP2 is under the MaxMind End User License Agreement, and HighCharts is free for non-commercial use. That last one is the notable line in the list, because a plugin that a server owner runs for free is not obviously a commercial use, but a server operator running a paid server is plausibly commercial, and the readme is upfront about the terms rather than burying them.

The GeoIP database is the other item to note. It is a country level database, so the dashboard can show where players connect from, and it needs a MaxMind account and licence acceptance to download. The project has a CI workflow with a Quality Gate badge from SonarCloud, along with separate lines of code and code coverage badges for the Java and the React sides, which tells you the front end is a separate codebase with its own build.

Building the plugin and consuming it as a library

The build is a Gradle wrapper build from the repository root.

cd Plan
./gradlew build

The readme points to a wiki page on project setup for more, and the CI workflow produces development builds that are linked from the readme, which is a useful arrangement if you want to test an unreleased change.

The plugin is also consumable as a library, which is the more interesting entry point for developers. It is published through JitPack, and the Maven coordinates are set up like this.

<repository>
    <id>jitpack</id>
    <url>https://jitpack.io</url>
</repository>

<dependency>
    <groupId>com.github.plan-player-analytics</groupId>
    <artifactId>Plan</artifactId>
    <version>{jitpack version}</version>
    <scope>provided</scope>
</dependency>

The scope of provided is the detail that makes this usable. The plugin is not meant to be shaded into your own jar, it is meant to sit on the server as a plugin and expose an API that your plugin calls at runtime. There is javadoc published for the API, and an API documentation page in the wiki for version 5, so the extension surface is a documented contract rather than an internal detail. The jitpack.yml file at the top of the repository is the configuration for that publishing process.

On the data side, the repository topics list both mysql and sqlite, along with data-collection and visualization, and the readme's data storage behaviour is not spelled out in the section shown, so the choice between them is something the wiki covers. The versions.txt file at the top level and the naming of the releases, which carry a 5.8 build number such as 5.8 build 3638, suggest the versioning scheme is tied to both a release line and a build counter within it.

What a server owner gets and what they take on

The value proposition is straightforward for anyone running a community server. Play time data tells you when your playerbase is actually online, which is the question every server owner asks and most server managers answer by guessing. The dashboard's online activity and playerbase views over time turn that into something you can look at, and the built-in web interface means you do not have to stand up a separate analytics stack or export data into a hosted service. That last point is worth emphasising, because most analytics products for games send your data somewhere else, and for a server with a community that cares about who can see their play data, a self-hosted dashboard is a different proposition.

The costs are also concrete. You are running an additional web server inside the Minecraft process, which means it has a port, it has an interface you have to decide whether to expose, and it has its own authentication story. The readme's mention of an admin panel and a web server implies an access control decision, and the documentation lives in the wiki rather than in the repository, so the specifics of that decision are where you need to look before putting a server online.

The dependency list is also heavier than a typical small plugin, because a charting front end, a template, an icon set and a GeoIP database all have to be there. HighCharts in particular is a large library, and the React side of the project has its own build. That is a fair trade for a dashboard, but it is not a lightweight plugin and it is not for a server owner who wants a one line config change.

The licence is LGPL-3, which is a reasonable choice for a plugin of this kind: it lets server owners use and modify it, and it requires that modifications to the library itself are shared. For most server operators the practical question is only whether the plugin stays LGPL and whether its dependencies are acceptable for their use, and the readme's licence list lets you check the second one directly.

Where Plan is the wrong tool

Three cases argue against it. The first is a network that cannot run extra services. Plan ships its own webserver, so it needs a port, and if your host blocks that or your players' clients cannot reach the server, the dashboard is not going to help you. A Minecraft server on a platform where you cannot run a plugin at all, or on a network where the proxy is the only thing you control and you want the analysis there, are cases where the one jar promise is less useful than it sounds. The second is a privacy-sensitive server with a small player base. The plugin collects play time, session data and, through the GeoIP database, country information, and it holds all of that in a database on the machine you run it on. For a community that has asked not to be tracked, that is a conversation you need to have with your players, and the plugin being self-hosted does not remove the obligation, it only changes where the data lives.

The third is someone who needs a serious analytics pipeline. Plan is a plugin with a dashboard, and it is a good one, but it is not a data warehouse with a query language, and it is not somewhere you would run cohort analysis or build a model on. The same information is available to you in the database, and the database is the more flexible artifact, but you have to bring your own tooling to use it that way.

On the operational picture, the release naming gives you a way to read the project's state. The newest listed release is 5.8 build 3638 from 2026-09-05, with 5.8 build 3605 in August and 5.8 build 3579 in July, so the 5.8 line is getting builds roughly every three to four weeks, and the last push to master was on 2026-10-12. The build number rather than a semantic version tells you the project is iterating continuously within a line, which is normal for a Minecraft plugin and means you should test an update on a staging server before putting it on your live one, since a plugin update restarts the server it lives in.

Editorial conclusion

Plan suits a Minecraft server owner who wants a self-hosted view of play time, active hours and player base over time, and who is happy to run an extra web server and a database on the same machine. It does not suit a network that cannot expose the plugin's web interface, and it does not suit someone who wants the data to leave the server, because the collection and the dashboard live together. Before you deploy it, read the wiki for the database and web interface setup, decide whether MySQL or the built-in SQLite is right for your player count, and note that the last push was on 2026-10-12 with the newest 5.8 build tagged on 2026-09-05.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. plan-player-analytics/Plan on GitHub
3. Project website
4. README
5. Releases