Skip to main content
Yes, on a standalone server with uuid-type: real (the default). rLogin performs the same encryption handshake an online-mode server does, and hands the server the UUID and signed skin Mojang returned.Your other plugins — permissions, economy, bans — see the same UUID they would on any online-mode server, and switching to online-mode: true later is a non-event.
Only on a standalone online-mode: false server, which is the one setup where rLogin has to do the Mojang verification itself. That happens at the packet level, and PacketEvents is what makes it possible.Starting anyway would mean quietly treating every premium player as cracked — their names become claimable by anyone, and the server silently stops doing the thing it was installed to do. Refusing is noisy, but honest.auth-mode: offline removes the requirement if you genuinely want passwords for everyone.
Because with online-mode enabled, the server or proxy turns away every player without a Minecraft account before rLogin is consulted. On auth-mode: auto or offline — the modes that promise those players can register — that is the entire audience gone, and nothing in the plugin can bring them back.Set online-mode=false, or set auth-mode: online if the server really is premium-only. See what online-mode has to be.
Only if you run more than one backend server. Otherwise SQLite is the right answer and needs no configuration.Running a proxy does not by itself require MySQL — the proxy never touches the database.
Yes, with no configuration and no separate build. They inherit the whole Paper API rLogin uses, and none of them change anything about logins, connections or UUIDs — so there is nothing for rLogin to adapt to.The startup line names whichever fork you are running, which is the part worth quoting in a bug report.Spigot and CraftBukkit are a different matter: rLogin uses Paper APIs and does not run on them.
Yes, from day one. Every scheduled task uses the regional and per-player schedulers; nothing touches Bukkit’s global scheduler where it would matter.
Not by default — premium.protect-premium-names refuses /register on any name that belongs to a real account.If you turn it off, rLogin still keeps them apart: under uuid-type: real the impostor and the real owner are two different accounts, and /rlogin changeuuid can hand the login to the rightful owner. See Password login.
premium.api-failure-policy decides. fail-open (default) treats the player as cracked and asks for /login — the server stays up. fail-closed refuses connections until Mojang answers again.Recent lookups are cached for an hour, so short outages often go unnoticed.
No. The server logs commands before any plugin can cancel them, so rLogin installs a log filter that masks the password.There is no setting to disable it — see Security for why.
Not currently. The language is server-wide, set with general.language. Seventeen are bundled and you can add your own by dropping a lang_<code>.yml into the messages/ folder.
Not yet — only AuthMe is implemented. The command tells you so instead of failing halfway. See Migrating.
Yes, through Geyser/Floodgate. Bedrock players were already verified by Microsoft, so they are treated as premium and never asked to log in. Make sure bedrock.prefix matches Floodgate’s username-prefix.
Yes, MIT licensed. PacketEvents is a separate GPL-3.0 plugin that rLogin talks to at runtime; it is never bundled.

​
Still stuck?

Troubleshooting

Specific symptoms and what causes them.

Discord

Ask, and bring your startup log.