Guides · Product

Which config options do server owners actually change?

Your config.yml has dozens of options. Find out which ones server owners actually change, fix the defaults everyone changes, and read nothing private.

Updated 21 October 2026 · by Skilled · 4 min read

Every plugin's config.yml grows the same way. Someone asks for a toggle, you add it. Someone else wants a number tweakable, you add that too. Two years later there are 80 options, every new one has to be documented, migrated and tested, and you have no idea which of them anyone has ever changed.

The answer is sitting on every server that runs your plugin. This guide is about reading it, and about what to do with it.

Three questions a config can answer

• Which defaults are wrong? If most servers change max-players-per-arena from 8 to 16, your default is 8 for nobody. Change it, and every new install starts closer to how people really play.
• Which options can go? An option nobody has touched in a year costs you a line of docs, a migration and a test case for nothing. Removing it (or hiding it in an advanced section) makes the config easier for everyone.
• What do servers actually run? Storage backends, economy providers, language choices. Before you drop SQLite support or add a new database, know how many servers it affects.

Why asking doesn't work

You could post a poll in your Discord. The people who answer are the ones who read your Discord: the most engaged admins, who are also the ones most likely to have customized everything. The servers that installed your plugin, kept the defaults and never joined anything are most of your installs, and they never vote.

Reading it from the servers

PluginAnalytics reads your plugin's config.yml on each server and shows, for every option, the most common value, the default your jar ships, and the share of servers that changed it. You don't write any code for it: every 5 minutes, from its own thread, the SDK compares your getConfig() with the defaults bundled in your jar and sends what changed (and every value once a day).

Config usage is part of Pro and Premium. Config usage

Only plain choices, never anything private

A config file is full of things that must never leave a server: database passwords, webhook URLs, Discord tokens, hostnames. So only plain choices are read:

• true / false
• numbers
• short words like sqlite or en_US

Everything else is skipped: lists, sections, text with spaces or color codes, and anything that looks like an IP address, a UUID, an id or a password. And whole keys are never read when their path mentions things like password, token, key, host, url, webhook, database, discord, message or world, so storage.mysql.password or webhook-url never even get looked at.

If you have options that are fine by those rules but you'd still rather not see, leave them out:

analytics.excludeConfig("rewards.commands", "storage.mysql");
// or nothing at all
analytics.trackConfig(false);

What to do with what you find

Open the list sorted by "changed by". Three patterns are worth acting on:

Changed by most servers. The default is wrong. Ship the value most servers choose as the new default in your next update, and say so in the changelog: existing configs keep their value, new installs get the better one.

Changed by nobody, for months. Either the option is useless or nobody knows it exists. Check your docs: if it's documented and still untouched, it's a candidate for removal. If it isn't documented, document it and look again in a month.

Split down the middle. Half the servers on one value, half on another. That's a real choice, and a good one to keep. It's also worth a line in your setup message or wiki explaining when to pick which.

Server settings that aren't in your config

Some choices don't live in config.yml: which storage a server ended up using, how many arenas it has created. Report those as properties, and they show up next to the config options as the share of servers per value:

analytics.property("storage", () -> storage.type().name().toLowerCase());
analytics.property("arenas", () -> arenaManager.count());

The supplier runs on the SDK's thread every 5 minutes, so only read things that are safe off the main thread (fields, counters, config), never worlds or entities. Keep the values plain: nothing that identifies a server or a person. Properties

Dependencies come for free: every plugin in your depend and softdepend lists is reported as installed or missing, so you know how many servers have Vault or PlaceholderAPI before you build on them.

Tell server owners

Reading someone's config, even only the harmless parts, is something to say out loud. Mention it in your description, link your public page, which lists the options your plugin reported, and remind people that one setting turns analytics off for every plugin using the SDK. If you publish on Modrinth, it belongs in the telemetry disclosure too.

More guides