Installation#
Slime Login ships as a single jar that runs on Paper, Velocity and BungeeCord. Which role it takes is decided by where you put it.
The three roles#
| Where the jar is | Role | What it does |
|---|---|---|
| A Paper server with no proxy | Standalone | Accounts, passwords, premium detection — everything |
| A Velocity or BungeeCord proxy | Proxy | Authenticates once for the whole network |
| A Paper server behind a proxy | Bridge | Holds players still until the proxy says they are authenticated |
The plugin picks its role at startup and prints it in the console. On Paper it looks at the server's own forwarding settings:
config/paper-global.yml→proxies.velocity.enabled: true, orspigot.yml→settings.bungeecord: true
If either is on, it becomes a bridge. Override it with mode: in config.yml
(auto, standalone or bridge).
Never run two authentication systems at once
A backend server must be either a bridge or standalone — not both, and never alongside a second auth plugin. Two systems fighting over the same player is the most common cause of "it asks me to log in twice".
Step by step#
-
Drop the jar into
plugins/. -
Turn off online mode so cracked players can connect at all:
Premium players are still verified — see Premium detection.
-
Start the server once.
plugins/slimelogin/config.ymlandmessages.ymlare created. -
Add your license key:
-
Restart. The console shows the banner and
License] Verified.
-
Drop the same jar into the proxy's
plugins/and into every backend server'splugins/folder. -
Turn off online mode on the proxy —
online-mode = falseinvelocity.toml, oronline_mode: falsein BungeeCord'sconfig.yml. -
Set up forwarding — this is what stops players connecting to a backend directly and skipping the login entirely:
On Velocity:
each backend: config/paper-global.ymlproxies: velocity: enabled: true online-mode: false secret: '<the same secret>'On BungeeCord (
ip_forward: trueinconfig.yml,bungeecord: truein each backend'sspigot.yml) there is no shared secret, so firewall the backend ports to the proxy's address instead. -
Start the proxy once, then put your license key in
plugins/slimelogin/config.yml. Backend servers need no key. -
Restart everything. The proxy logs
enabled successfully, each backend logsRunning in BRIDGE mode.
Supported versions#
| Platform | Versions | Notes |
|---|---|---|
| Paper | 1.20.1 → 26.2 and later | Every published line from 1.20.1 up compiles. 1.20 and older lack the region scheduler API |
| Paper forks | Purpur, Pufferfish, … | Anything that keeps the Paper API |
| Folia / Canvas | same range | Regionised — see below |
| Velocity | 3.3 → 4.1 | 3.1.1 and older lack PreLoginEvent#getUniqueId(), which premium-name protection needs |
| BungeeCord | 1.16 → 26.1 | Every published line compiles. Forks included: Waterfall, FlameCord |
| Java | 17 or newer | The jar targets 17, so it also runs on 21 and 25 |
The jar is deliberately built against the oldest supported API. Java binds method calls when it compiles, so a jar built that way keeps working on every later build — while one built against the newest would quietly bind to methods older servers do not have.
Re-check any version yourself:
mvn -Dpaper.version=26.2.build.112-stable compile
mvn -Pvelocity-next -Dvelocity.version=4.0.0 compile
The velocity-next profile exists because Velocity 4 moved to Adventure 5 while paper-api is still
on Adventure 4; it pins Adventure for the check only, never for the shipped jar.
Premium detection and very old servers
Premium auto-login reads the server's internals directly. Those became Mojang-mapped in Paper 1.20.5, so on 1.20.1 – 1.20.4 the plugin loads and cracked login works normally, but premium auto-login switches itself off and says so in the console. From 1.20.5 up it is fully active.
The seamless path — where a cracked client using a premium name never has to reconnect — also needs the client to be 1.20.2 or newer, because that is when clients started sending their own UUID with the login.
Folia and its forks#
Slime Login runs on Folia, Canvas and other regionised forks — no separate build, no
setting to turn on. The jar declares folia-supported, every scheduled task goes through the
region scheduler, and every teleport is asynchronous, so nothing assumes a single main thread.
You will see this line on such a server:
The same jar still behaves exactly as before on ordinary Paper — the region scheduler API is part of Paper too, where it simply runs on the main thread.
What gets created#
Only the options your role actually uses are written out, so a bridge server does not get a config full of settings it ignores.
plugins/slimelogin/
├── config.yml # tailored to the role
├── messages.yml # every message, editable
├── players.db # SQLite; proxy or standalone only
├── license.dat # signed proof of the last successful check
└── .instance # random id for this installation
Checking it worked#
Look for these lines in the console.
If a bridge server also prints a block of [Bridge] warnings, your forwarding is not secured —
see Bridge mode.
Updating#
Replace the jar and restart. config.yml and messages.yml are never overwritten, and any option
missing from your file falls back to the new version's default, so upgrades do not need you to
delete anything.
The database schema is migrated automatically when a new column is added.