Plan

Last reviewed Sep 13, 2026 · 856 words

Plan takes about 3 minutes to go from jar file to a working dashboard: drop Plan.jar in your plugins folder, restart, run /plan register in-game, and open port 8804 in a browser. What you get is far past what a free Minecraft plugin usually offers, which is session history per player, retention and playtime graphs, TPS and memory over time, geolocation, and per-world activity, stored in SQLite by default. The one decision that matters comes later, when you run more than one server and want them in one view.

The install is genuinely easy

Plan supports the platforms that matter: Paper and Spigot on the Java edition, Fabric and Sponge, plus the proxies (Velocity and BungeeCord) for networks, and Nukkit on the Bedrock side. On a Paper server the install is the plugin drop described above. The embedded web server starts on 8804, and the first /plan register links your in-game account to a web login; from then on the dashboard is a normal website with users and permissions rather than something you have to be online in-game to read.

The web pages themselves are served by the plugin, so there is no separate container, database service or Node process to run. The 256 MB figure in the catalogue is the memory Plan adds to the JVM; on a 4 GB server allocation you will not notice it.

SQLite for one server, MySQL for a network

By default Plan writes to an SQLite file inside its plugin folder, which is perfect for a single survival server and needs no configuration. The moment you have a proxy in front of two or more backend servers, switch to MySQL (or MariaDB) and point every Plan instance, including the one on the Velocity proxy, at the same database. That is how the network view works: the proxy instance becomes the one that serves the dashboard, and the backend servers feed it.

The switch is a config.yml change plus a database migration command that Plan provides; do it before the SQLite file gets large, because migrating months of session data is slower than you would like on a shared VPS.

The overhead is real but manageable

The catalogue lists "adds server overhead" as a con, and it is true in a specific way: Plan hooks player joins, leaves, world changes and periodic TPS samples, and it writes all of that to the database. On a healthy Paper server the cost is a small, steady trickle of async database writes. Where it bites is a server that is already at the edge (a 2 GB allocation with 40 players and a dozen heavy plugins), where any extra work shows up as a TPS dip. If you are there, fix the server before adding analytics to measure it. Plan's own performance page will then tell you whether the fix worked, which is the point.

Its extension system pulls data from other plugins (economy balances, jobs, protection plugins, Litebans and the like) into the same player pages, and this is where the value compounds for a community server: staff can look at one page per player instead of tailing five plugin logs.

Do not expose port 8804 raw

The embedded web server can do HTTPS on its own if you hand it a keystore, but the sane pattern for a homelab is the same as everything else: keep 8804 bound to localhost or the LAN, and put your reverse proxy in front of it with a real certificate. Plan supports being served under a path and behind a proxy, and the dashboard has its own user accounts and permission groups, so you can give moderators a login without giving them the console. Treat the dashboard as staff-only unless you specifically want players to see their own stats, which Plan does support as a public player page.

If your server runs under a panel such as Crafty Controller or Pterodactyl, remember to add 8804 to the container's allocated ports, which is the number one "the dashboard does not load" question in the project's support channels.

What it replaces

Nothing self-hosted really competes. Commercial game analytics products are built for studios, not for a friend group's SMP, and the older Minecraft stats plugins stopped at scoreboards. Plan's 1,030 stars and an active maintainer since 2017 put it in a comfortable position: niche, but the settled answer inside that niche, under LGPL-3.0 with no paid tier.

What I'd do

Install Plan on any server with more than a handful of regulars; the retention graph alone will change how you plan events. Stay on SQLite until you add a proxy, then move to MariaDB before the file passes a few hundred megabytes. Bind the web server to the LAN, proxy it with HTTPS, give moderators their own logins, and back up the database with the rest of the server's data. It is one of the few plugins I would call worth the restart.