Slime Login

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:

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#

  1. Drop the jar into plugins/.

  2. Turn off online mode so cracked players can connect at all:

    server.properties
    online-mode=false
    

    Premium players are still verified — see Premium detection.

  3. Start the server once. plugins/slimelogin/config.yml and messages.yml are created.

  4. Add your license key:

    plugins/slimelogin/config.yml
    license-key: "YOUR-KEY-HERE"
    
  5. Restart. The console shows the banner and License] Verified.

  1. Drop the same jar into the proxy's plugins/ and into every backend server's plugins/ folder.

  2. Turn off online mode on the proxyonline-mode = false in velocity.toml, or online_mode: false in BungeeCord's config.yml.

  3. Set up forwarding — this is what stops players connecting to a backend directly and skipping the login entirely:

    On Velocity:

    velocity.toml
    player-info-forwarding-mode = "modern"
    forwarding-secret-file = "forwarding.secret"
    
    each backend: config/paper-global.yml
    proxies:
      velocity:
        enabled: true
        online-mode: false
        secret: '<the same secret>'
    

    On BungeeCord (ip_forward: true in config.yml, bungeecord: true in each backend's spigot.yml) there is no shared secret, so firewall the backend ports to the proxy's address instead.

  4. Start the proxy once, then put your license key in plugins/slimelogin/config.yml. Backend servers need no key.

  5. Restart everything. The proxy logs enabled successfully, each backend logs Running in BRIDGE mode.

Full network guide

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:

[slimelogin] Folia detected - scheduling per region and teleporting asynchronously.

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.

[slimelogin] SQLite database connected successfully.
[slimelogin] [License] Verified (lifetime).
[slimelogin] [Premium] Packet hook initialized (mode: auto-detect).
[slimelogin] Slimelogin has been enabled successfully!
[slimelogin] Running in BRIDGE mode: this server is behind a proxy, so Slime Login on
             the proxy handles the accounts and this side only holds players until it
             says they are authenticated.
[slimelogin] No license key is needed here - the proxy holds the license for the network.

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.