Skip to main content
AdminComplete setup walkthrough

How to Configure AuthMe Reloaded on a Minecraft Server

Protect offline-mode servers with registration, login, database storage, password policy, and pre-login restrictions. This guide covers install order, first startup, LuckPerms permissions, config files, use-case presets, integrations, performance checks, common failures, and admin FAQ.

Audience

Owners of offline-mode or cracked servers who understand the security tradeoffs.

Install Jar

AuthMeReloaded.jar.

Tested Stack

Paper or Purpur 1.20.6 to 1.21.x, Java 21, LuckPerms for permissions, and a staging server before production changes.

What AuthMe Does

AuthMe Reloaded should be treated as part of your server architecture, not as a random jar dropped into production. The safe workflow is to define the job the plugin owns, decide which groups can touch it, test the generated files on staging, then move only the reviewed configuration to the live server.

For AuthMe, the main job is: Protect offline-mode servers with registration, login, database storage, password policy, and pre-login restrictions. That means every setting should support a concrete player workflow or staff workflow. If a setting does not have an owner, a test, and a rollback path, leave it at the generated default until you have a reason to change it.

The most common failure pattern is configuring the plugin as OP, seeing it work, and assuming players are ready. Operators bypass too much. For every section below, create a temporary non-OP account in the target LuckPerms group and test the exact command or interaction that normal players will use.

Keep a small audit note beside the config. Record the plugin version, the file paths changed, the exact permissions granted, the test account used, the commands verified, and the rollback file or database backup to restore. When another plugin depends on AuthMe, repeat the same test after updates because the failing part may be the bridge, provider, world context, or display plugin rather than AuthMe itself. Keep the note in your operations runbook.

Installation and First Startup

Back up the server before installing AuthMe Reloaded. At minimum, keep a copy of the existing plugins folder, the world data if the plugin touches worlds or claims, and any database used by related plugins. Upload AuthMeReloaded.jar. into the plugins folder, then perform a full restart so Bukkit, Paper, or Purpur loads the plugin cleanly.

On first startup, do not edit every generated file immediately. Let the plugin create its folder, read the startup log, then run a small command or player action to prove the plugin is alive. The first goal is a known-good baseline. After that, make one config change at a time.

First startup checklist

  • Confirm the server mode and legal/security policy before installing.
  • Start once and review plugins/AuthMe/config.yml.
  • Register and log in with a test account.
  • Test what an unauthenticated player can move, see, and command.

LuckPerms Permission Setup

Configure AuthMe Reloaded permissions through groups. A clean setup usually has default, trusted, helper, moderator, admin, and owner groups. Default players get only the commands required for normal gameplay. Staff groups get narrow operational permissions. Owner keeps destructive, economy-changing, rollback, purge, import, or wildcard permissions.

Use this pattern for every permission below. Replace the group and permission with the row you are granting. Run the command from console or as an owner, then test with a non-OP player in that group.

/lp group <group> permission set <permission> true
/lp group <group> permission check <permission>
/lp user <player> parent add <group>
authme.player.login

Grant to default: Allows login command.

authme.player.register

Grant to default: Allows registration command.

authme.player.changepassword

Grant to default: Allows users to change passwords.

authme.admin.reload

Grant to admin: Allows safe config reloads.

authme.admin.unregister

Grant to owner: Can remove accounts and should be tightly restricted.

Command Workflows

Commands are not just a reference list. They are the operational workflows your staff will use under pressure. Write the exact command patterns into your runbook and include which group may run each one. For sensitive commands, test with a preview, a limited radius, a staging world, or a throwaway account before using them live.

/register <password> <password>

Register a new player when confirmation is enabled.

/login <password>

Log in after joining.

/changepassword <old> <new>

Let players rotate passwords.

/logout

Test logout flow.

/authme reload

Reload AuthMe configuration after supported edits.

/authme accounts <player>

Inspect account information as an admin.

Config File Deep Dive

The config files below are the parts of AuthMe most likely to matter on a real server. Do not copy a random full config from another network. Generated files change between plugin versions, and old examples can silently disable modern safeguards. Keep the generated comments, change only the setting you understand, then reload or restart using the plugin-specific path.

For every setting, write down the old value, the new value, why it changed, and how to back out. This is slower than editing blindly, but it prevents mystery behavior three weeks later when another admin tries to debug the server.

DataSource.backend

plugins/AuthMe/config.yml

Controls whether AuthMe uses SQLITE, MARIADB, MYSQL, or POSTGRESQL in current generated configs.

Recommendation: Use SQLite for small private setups and a real database for public servers or website integration.

Security.unsafePasswords

plugins/AuthMe/config.yml

Lists weak passwords that should be rejected.

Recommendation: Keep common weak passwords blocked and add server-specific banned values.

registration.enabled

plugins/AuthMe/config.yml

Controls whether players can register.

Recommendation: Leave enabled only when you actually allow new account creation.

registration.force

plugins/AuthMe/config.yml

Forces players to register or login before normal play.

Recommendation: Keep forced login enabled for AuthMe's core protection model.

registeredPlayerGroup and unregisteredPlayerGroup

plugins/AuthMe/config.yml

Can move players into special permission groups before or after login.

Recommendation: Use a no-permission unauthenticated group if you need strict pre-login control.

Use-Case Configs

A good AuthMe setup depends on the type of server. Survival wants stability and player trust. Creative wants build speed and plot safety. Skyblock and economy modes care about item generation and abuse loops. Use these presets as decision checklists, then convert them into exact config changes for your own server.

Offline-mode public server

AuthMe blocks account spoofing after join by requiring login.

  • Decide offline-mode policy.
  • Configure database.
  • Set forced registration.
  • Restrict unauthenticated commands.
  • Test account recovery.

Website integration

External account systems usually require database planning.

  • Use MySQL or MariaDB.
  • Align password hashing.
  • Back up database.
  • Test registration from both sides.

Security hardening

Reduce damage before login.

  • Use unlogged group.
  • Block movement and commands.
  • Set weak password list.
  • Monitor failed login attempts.

Plugin Integrations

Most Minecraft plugin problems happen at the boundary between plugins. AuthMe may load correctly while the full workflow still fails because a dependency, bridge, economy provider, permission group, display plugin, or world manager is missing. Check integrations during startup and after every plugin update.

LuckPerms

Can provide restricted groups for unauthenticated players.

Vault

Not required for core AuthMe, but other plugins in the same server may still need it.

Citizens

NPC-like names may need name restrictions or unrestrictions depending on your setup.

Database backups

Authentication data must be part of the backup plan.

Performance and Maintenance

Performance tuning starts with scope. Do not enable every module, world, render, placeholder, command, or log type just because the plugin supports it. Enable the parts that support your server design, measure the impact, and keep a short maintenance checklist for future updates.

  • Use a database backend appropriate for your player count.
  • Keep authentication tables backed up and tested.
  • Do not expose database credentials in public logs or screenshots.
  • Review anti-bot and login attempt settings after attacks.

Common Errors and Fixes

When AuthMe misbehaves, separate facts from guesses. Capture the command used, player group, world, plugin version, and console output. Then work through the smallest reproducible test instead of changing five settings at once.

Players can act before login

  • registration.force is true.
  • Restrictions are enabled.
  • Unauthenticated group has minimal permissions.
  • Bypass permissions are not granted.

Fix: Tighten pre-login restrictions and test with a fresh account.

Database connection fails

  • Backend type.
  • Host and port.
  • Credentials.
  • SSL settings.
  • Database user permissions.

Fix: Test credentials outside Minecraft and restore SQLite only from a known-good backup if needed.

Players forget passwords

  • Recovery workflow exists.
  • Email settings are configured if used.
  • Staff command permissions are restricted.
  • Identity checks are documented.

Fix: Use the documented recovery process and log every manual reset.

AuthMe Reloaded FAQ

Should I configure AuthMe Reloaded on a live production server?

Use a staging copy for the first setup, then move the finished configuration to production during a quiet period. AuthMe Reloaded may read files, register commands, or touch player data during startup, so testing on a copy prevents avoidable downtime.

Can I use /reload after changing AuthMe Reloaded?

Avoid the global /reload command. Use /authme reload when the plugin supports it, or schedule a normal restart when the change affects dependencies, database settings, worlds, generated regions, or plugin jars.

Where should I keep backups before changing AuthMe Reloaded?

Back up the plugin data folder, the jar you are replacing, and any database tables used by the plugin. Keep the backup outside the live plugins folder so a later cleanup or plugin scan cannot accidentally load it.

How should I grant permissions for AuthMe Reloaded?

Grant permissions to LuckPerms groups, not individual players. Use a small default group, a trusted staff group, and an owner group. Temporary exceptions should use LuckPerms temporary permissions with a clear expiration.

Why does AuthMe Reloaded work for operators but not normal players?

Operators bypass many checks, so OP testing is not enough. Test with a non-OP account in the default group and watch the console for missing permission messages or plugin-specific deny output.

How do I know whether AuthMe Reloaded loaded correctly?

Check the startup log for the plugin name, run the main info command, confirm the data folder was created, and test one normal player workflow. Do not assume the plugin is ready just because it appears in /plugins.

Should I edit generated config files by hand?

Yes, but keep comments, indentation, and encoding intact. YAML and HOCON are strict enough that one bad indent or missing quote can stop a plugin from loading its configuration.

How often should I review AuthMe Reloaded settings?

Review the config after major Minecraft updates, plugin major releases, and changes to your server mode. Survival, skyblock, creative, and proxy networks usually need different defaults.

What is the safest way to update AuthMe Reloaded?

Read the changelog, back up the existing jar and data folder, test the new version on staging, then replace the jar during a normal restart. Do not hot swap core plugins that hold data or hook deeply into server internals.

How do I document the final AuthMe Reloaded setup?

Write down the plugin version, config files changed, permissions granted, commands staff use, and rollback steps. Store that note beside your server runbook so another admin can recover the setup later.

Official References

Check the upstream documentation before changing version-specific settings. This tutorial avoids full copied configs because plugin defaults and generated comments can change between releases.