LiteBans vs AdvancedBan: który plugin moderacji wybrać (2026)

Gdy serwer przekracza dwadzieścia osób online i ma otwartą rejestrację, bez dedykowanego pluginu kar nie da rady. Vanillowe /ban z Bukkita robi dokładnie jedno: dopisuje nick do banned-players.json i wyrzuca z generycznym komunikatem. Bez historii, bez pola powodu, bez śledzenia IP, bez synchronizacji proxy, bez panelu webowego dla moderacji. Pasuje na SMP z dziesięcioma znajomymi. Na sieci z proxy i kilkoma backendami to katastrofa.

Dwa pluginy dominują tę niszę po stronie Spigot/Paper: LiteBans (płatny, około 15 USD na BuiltByBit, zamknięty kod) oraz AdvancedBan (darmowy, MIT, open source). Oba w 2026 nadal aktywnie rozwijane, oba potrafią per-network bany przez MySQL, oba pokrywają /ban, /tempban, /mute, /warn, /kick. Różnica leży w wykończeniu, web-UI, API i ile czasu i pieniędzy chcemy zainwestować. Rozłóżmy to na czynniki.

Po co w ogóle dedykowany plugin moderacji

Wbudowane /ban w Bukkicie robi trzy rzeczy: dopisuje nick do JSON-a, kickuje, drukuje na konsolę. Tego brakuje od początku. Potrzebne:

• Historia kar per gracz. Kto dał, kiedy, za co, ile było wcześniej.
• Powód i czas w ekranie kicka. Gracz powinien widzieć Banned for: x-ray client / 30 days / appeal: example.com.
• Trwały storage w prawdziwej bazie. JSON psuje się przy crashach, nie skaluje, nie synchronizuje.
• Per-network bany. Lobby, survival, minigames za Velocity/BungeeCord, ban na jednym węźle ma się propagować wszędzie.
• Mute, warn, kick jako osobne byty z własną historią.
• Powiązanie po IP i UUID. Alty łapane przez tracking IP.
• Web-UI dla moderacji bez dostępu SSH.
• API do integracji z botem Discord, anticheatem, własnymi pluginami.

LiteBans i AdvancedBan oba pokrywają tę listę, sposób w jaki to robią to cała różnica.

LiteBans: płatny premium standard z pełnym web UI

LiteBans sprzedaje się na BuiltByBit (kiedyś część SpigotMC marketplace) za około 15 USD. Utrzymywany przez jednego dewelopera, aktualna gałąź major to 2.x. Wspiera Bukkit/Spigot/Paper od 1.8.x do 1.21.x, BungeeCord, Velocity, Sponge. Storage: MySQL/MariaDB w pierwszej kolejności, wsparcie PostgreSQL, fallback H2 dla single-server (w praktyce nie zalecany).

Główna funkcja, za którą się płaci, to PHP web frontend. Nie "endpoint API", tylko gotowy panel administracyjny z tabelą kar, filtrami, wyszukiwarką po nicku/UUID/IP, sekcjami ban/mute/warn/kick, pełną historią per gracz. Theming przez CSS, motywy light i dark od razu w paczce. Jest admin login z permissions. Instalacja: rozpakować folder litebans-php do /var/www/, wpisać poświadczenia MySQL w config.php, frontend czyta te same tabele co plugin. Bez osobnych migracji.

Komendy pokrywają standard:

/ban <player> [time] <reason>
/tempban <player> <time> <reason>
/ipban <player|ip> [time] <reason>
/mute <player> [time] <reason>
/tempmute <player> <time> <reason>
/warn <player> <reason>
/kick <player> <reason>
/unban <player>
/unmute <player>
/unwarn <id>
/banlist [type]
/history <player>
/staffhistory <staff>
/check <player>      # aktualnie aktywne kary
/dupeip <player>     # alty po IP

LiteBans wspiera layouts: szablony ekranu kicka z placeholderami {reason}, {duration}, {banned-by-name}, {appeal-link}. Można definiować różne layouty per typ kary i pasmo czasu. Permanent ban może wyglądać inaczej niż 7-dniowy, a ten inaczej niż mute.

Per-network bany działają przez współdzielone MySQL. Ten sam blok database na każdym backendzie i na proxy, LiteBans pisze do jednej tabeli litebans_bans, lookup przy logowaniu. Na proxy (BungeeCord/Velocity) jest osobny jar, który łapie gracza zanim trafi na backend, co jest minimalnie szybsze niż łapanie na samym backendzie.

API LiteBans wystawia eventy w stylu Bukkita: LiteBansBanEvent, LiteBansMuteEvent, LiteBansWarnEvent, LiteBansKickEvent, LiteBansUnbanEvent. Subskrybujemy z własnego pluginu i np. wysyłamy każdy ban do webhooka Discord albo ciągniemy backend anticheata do cross-reference.

@EventHandler
public void onBan(LiteBansBanEvent event) {
    String target = event.getTargetName();
    String reason = event.getReason();
    String executor = event.getExecutorName();
    long duration = event.getDuration();
    discordBridge.sendBanLog(target, reason, executor, duration);
}

Wady LiteBans:

• Kosztuje. Dla 5-osobowego SMP to przesada.
• Zamknięty kod. Jeśli autor zniknie, fork niemożliwy.
• MySQL praktycznie obowiązkowy. H2 fallback istnieje, nikt go długo nie ciągnie.
• Web-UI wymaga osobnego hostingu PHP. Na Pterodactyl bez własnego webserwera trzeba postawić Nginx + PHP-FPM gdzieś z boku.

AdvancedBan: darmowy koń roboczy

AdvancedBan żyje na GitHubie pod DevLeoko/AdvancedBan z licencją MIT. Dystrybuowany przez Hangar (PaperMC), Modrinth i SpigotMC za darmo. Wspiera Bukkit/Spigot/Paper od 1.8 do 1.21+, BungeeCord przez addon. JAR jest trzy do czterech razy mniejszy niż LiteBans, bez zewnętrznych zależności.

Storage od razu: SQLite albo MySQL. SQLite leży w plugins/AdvancedBan/data.db, wystarcza dla single-server do około 100 online. MySQL włącza się przełączeniem bloku w config.yml:

MySQL:
  use-MySQL: true
  ip: 127.0.0.1
  port: 3306
  db-name: advancedban
  username: ab_user
  password: changeme

Komendy mapują się prawie jeden do jednego z LiteBans:

/ban <player> <reason>
/tempban <player> <time> <reason>
/ipban <player> <reason>
/mute <player> <reason>
/tempmute <player> <time> <reason>
/warn <player> <reason>
/tempwarn <player> <time> <reason>
/kick <player> <reason>
/unban <player>
/unmute <player>
/punish <player>     # GUI wyboru
/history <player>
/check <player>
/banlist

Parser czasu przyjmuje sufiksy s, m, h, d, w, mo, y (/tempban Notch 7d griefing).

Layouty też są, format prostszy niż w LiteBans:

Ban:
  - "&8&m=================================="
  - "&cYou are banned from this server"
  - ""
  - "&7Reason: &f{reason}"
  - "&7By: &f{operator}"
  - "&7Until: &f{duration}"
  - ""
  - "&7Appeal: &fdiscord.gg/example"
  - "&8&m=================================="

Per-network bany przez MySQL: ten sam blok na każdym backendzie, AdvancedBan pisze do wspólnego schematu. Dla BungeeCord osobny addon, który podpina się pod login proxy.

Web-UI jest prostsze i oficjalnie nie ma go w głównym repo. Kilka community forków (AdvancedBanWeb, AdvancedBan-Frontend) czyta MySQL i renderuje tabele kar. Wizualnie spartańsko, mniej filtrów, brak admin login, brak motywów. Jeśli chcemy poziomu LiteBans, albo budujemy własny, albo migrujemy.

API AdvancedBan też wystawia eventy:

@EventHandler
public void onPunish(PunishmentEvent event) {
    Punishment p = event.getPunishment();
    if (p.getType() == PunishmentType.BAN) {
        // forward do Discord
    }
}

Plus bezpośredni dostęp do repo: PunishmentManager.get().getActivePunishments(uuid) zwraca listę aktualnie aktywnych kar.

Wady AdvancedBan:

• Web-UI tylko community, surowiej wygląda.
• Layouty mają mniej placeholderów, mniej segmentacji.
• Tłumaczenia i szablony rozsypane po wielu yml, mniej schludnie.
• Wolniejsze tempo wydań: nowe major-y co kilka miesięcy.

Flow instalacji obu pluginów

LiteBans:

1. Kupić na builtbybit.com, pobrać LiteBans.jar
2. Wrzucić do plugins/, restart serwera
3. Otworzyć plugins/LiteBans/config.yml i settings.yml
4. Wpisać poświadczenia MySQL w settings.yml -> sql:
5. Restart, plugin tworzy tabele litebans_*
6. Web-UI: rozpakować php frontend do /var/www/litebans/
7. Te same poświadczenia MySQL w config.php

AdvancedBan:

1. Pobrać AdvancedBan.jar z hangar.papermc.io albo github releases
2. Wrzucić do plugins/, restart
3. Otworzyć plugins/AdvancedBan/config.yml
4. use-MySQL: true i wypełnić blok MySQL
5. Restart, plugin tworzy tabelę punishments
6. Opcjonalnie: addon BungeeCord z releases

Dla sieci z proxy (Velocity):

1. Każdy backend ma główny jar z identycznym blokiem MySQL.
2. Velocity ma odpowiedni proxy jar (LiteBans-Velocity, AdvancedBanVelocityFix lub fork).
3. Login listener na proxy pyta MySQL zanim przekaże gracza na backend.
4. Każdy backend ponownie sprawdza w login event jako fallback.

Komendy i realny flow moderacji

Załóżmy, że gracz Hacker_77 używa x-raya. Standardowy flow:

[Moderator] /check Hacker_77
[Plugin] Active: 1 warn (caps abuse, 2026-04-12)
         History: 3 entries

[Moderator] /tempban Hacker_77 30d x-ray client (proof: clip url)
[Plugin] Hacker_77 banned for 30 days. Reason: x-ray client
[Plugin] Discord webhook fires (przez własny listener)

[Hacker_77 reconnects]
[Plugin] Ekran kicka z layoutem, powodem, czasem, linkiem do appela

Jeśli się okazuje, że ban musi być permanentny:

/unban Hacker_77
/ban Hacker_77 x-ray client + bypass attempts (perm)

Dla moderacji czatu:

/tempmute spammer 1h spam
/tempmute toxic_kid 1d slurs (proof: log url)

Warny się kumulują i konwertują automatycznie do bana po przekroczeniu progu via AdvancedBan WarnActions lub LiteBans triggers.

Per-network bany na Velocity/BungeeCord

Oba potrafią, implementacje się różnią. LiteBans używa jednej warstwy MySQL współdzielonej przez proxy i backend. Gracz łączy się z Velocity, plugin LiteBans-Velocity pyta litebans_bans, jeśli rekord aktywny, kicka z poprawnym layoutem. Jeśli ban dodany na żywo, proxy widzi INSERT i triggeruje kick.

AdvancedBan: główna logika na backendzie. Velocity/BungeeCord addon wpina się w login i pyta MySQL. Mniej zcentralizowane, działa.

Pułapka: schemat musi być spójny między wszystkimi instancjami. Jeśli dwa backendy mają różne major LiteBans, jeden z nich może wystartować migrację schematu, która łamie pozostałe. Reguła: jedna wersja pluginu, jedno okno aktualizacji, wszystkie backendy razem.

Web-UI: gdzie LiteBans odjeżdża

LiteBans Web-UI:

• Gotowa strona PHP w paczce (w cenie zakupu).
• Motywy: light, dark, własne CSS.
• Filtry: po typie (ban/mute/warn/kick), statusie (active/expired/permanent), nicku/UUID/IP.
• Paginacja, sortowane kolumny.
• Historia per gracz na jeden klik.
• Opcjonalnie: admin login na wierzchu, public widzi tylko banlist, staff wszystko.

AdvancedBan Web-UI:

• Brak oficjalnego frontendu. Community: AdvancedBanWeb (PHP), advancedban-frontend (Node/React).
• Minimum: lista banów, wyszukiwarka po nicku.
• Brak warstw uwierzytelnienia, brak zaawansowanych filtrów.
• Poziom LiteBans? Budować samemu albo migrować.

Na publicznym serwerze z częstymi appellami web-UI to różnica między "do ogarnięcia" a "nie do ogarnięcia". Mod bez SSH, gracz w trakcie appelu, owner wymagający audytu, wszyscy żyją w web-UI. Jeśli budżet pozwala, LiteBans rozwiązuje to za nas.

Plugin API do własnych integracji

Każdy ban ma trafić do Discord i do własnego anticheata.

LiteBans:

public class BanLogger implements Listener {
    @EventHandler
    public void onBan(LiteBansBanEvent e) {
        String target = e.getTargetName();
        String reason = e.getReason();
        long duration = e.getDuration();
        DiscordWebhook.send(String.format(
            "BAN | %s | %s | %s",
            target, reason, formatDuration(duration)
        ));
    }
}

AdvancedBan:

public class BanLogger implements Listener {
    @EventHandler
    public void onPunish(PunishmentEvent e) {
        Punishment p = e.getPunishment();
        if (p.getType() != PunishmentType.BAN
            && p.getType() != PunishmentType.TEMP_BAN) return;
        DiscordWebhook.send(String.format(
            "BAN | %s | %s | by %s",
            p.getName(), p.getReason(), p.getOperator()
        ));
    }
}

Oba czyste. LiteBans rozdziela per typ, AdvancedBan jeden wspólny event z filtrem.

Bezpośredni SQL z własnego kodu działa, ale jest zły: bump schematu wszystko łamie. Używać API.

Migracja danych między pluginami

Typowy scenariusz: start na AdvancedBan, urośliśmy, chcemy LiteBans dla web-UI, historia ma jechać.

Nie ma oficjalnego importera z AdvancedBan do LiteBans. Trzy drogi:

1. Własny skrypt SQL. Schemat AdvancedBan: jedna tabela punishments z name, uuid, reason, operator, punishmentType, start, end, calculation. LiteBans: osobne tabele litebans_bans, litebans_mutes, litebans_warnings, litebans_kicks, litebans_history. Mapowanie: typ kary → tabela docelowa, milisekundy → timestampy LiteBans.

-- import banów z AdvancedBan do LiteBans (uproszczony)
INSERT INTO litebans_bans (uuid, ip, reason, banned_by_uuid, banned_by_name, time, until, server_scope, server_origin, active)
SELECT
    uuid,
    NULL,
    reason,
    NULL,
    operator,
    start,
    CASE WHEN end = -1 THEN -1 ELSE end END,
    '*',
    'global',
    1
FROM advancedban.punishments
WHERE punishmentType IN ('BAN', 'TEMP_BAN');

2. AdvancedBan zostaje równolegle w trybie read-only. LiteBans na nowej DB, AdvancedBan tylko do podglądu starej historii. Brzydkie ale proste.

3. Importer od trzecich firm. GitHub ma kilka, w różnym stanie świeżości. Backup DB obowiązkowy.

Druga strona (LiteBans → AdvancedBan) rzadsza, ale też SQL: zwinąć tabele per typ do wspólnej punishments AdvancedBan, kolumna typu z nazwy tabeli źródłowej.

Wydajność pod obciążeniem

200+ graczy online oba ciągną na luzie. Co się liczy:

• Connection pooling. LiteBans używa HikariCP, AdvancedBan w nowych wersjach też. Domyślny pool 10 zwykle wystarcza.
• Async wszędzie. Oba piszą do DB asynchronicznie. Main thread sprawdza tylko cache przy logowaniu.
• Login query musi być tani. Index po UUID obowiązkowy (oba go tworzą). Przy setkach tysięcy rekordów EXPLAIN powinien pokazać ref po indexie UUID.
• MySQL blisko. MySQL na tym samym hoście co Minecraft albo o jeden hop sieci prywatnej. 1-2 ms latencji ok, 20+ ms widać jako lag przy logowaniu.

LiteBans w pamięci nieco cięższy z powodu bogatszego cache. JAR 100 MB myli, JVM overhead pod 30 MB. AdvancedBan w okolicy 15-20 MB.

Tick-laga nie wnosi żaden, o ile MySQL żyje. Jeśli MySQL spowolni, async writes nie blokują main thread, ale fallback queue rośnie. Przy 1000+ eventów/minutę warto Prometheus alert.

Cena i licencja

Pozycja	LiteBans	AdvancedBan
Licencja	własnościowa, płatna	MIT, darmowa
Cena	~15 USD na BuiltByBit	0
Wsparcie	aktywny dev	community + dev
Web-UI	w paczce	community forki
Open source	nie	tak

Budżet zero: oczywiste. 15 USD jednorazowo: LiteBans oszczędza godziny przy web-UI i layoutach.

Kiedy co wybrać

Wybierz LiteBans gdy:

• Duży publiczny serwer, 100+ online.
• Wielu moderów bez SSH, web-UI obowiązkowy.
• Sieć z proxy, kilka backendów, lobby, solidna synchronizacja.
• Gracze często appellują, publiczna banlist potrzebna.
• 15 USD jednorazowo w budżecie.
• Gotowy produkt zamiast godzin community-frontendu.

Wybierz AdvancedBan gdy:

• SMP do 50 online albo whitelisted.
• Brak budżetu na płatne pluginy.
• Open source ważny (audyt, fork, customizacja).
• Web-UI opcjonalny albo własny stack.
• Prosta struktura, bez skomplikowanego routingu sieci.
• Cel: postaw i zapomnij.

Oba rozwiązują rdzeń. Różnica w polerze i dołączonym UI.

Checklista przed produkcją

• Backup MySQL skonfigurowany (mysqldump w cron, minimum codziennie).
• Layouty ban/mute/warn/kick z linkiem appela.
• Permissions per rola (modkick, modban, admin).
• /staffhistory włączony, audyt zapewniony.
• Discord webhook na każdą karę przez własny listener.
• Test flow: ban → reconnect → ekran kicka z poprawnym layoutem.
• Per-network: ban na jednym węźle działa wszędzie.
• Web-UI (jeśli LiteBans) za auth, nie publicznie przeglądalny.
• Ochrona DDoS (np. MineGuard) na wierzchu, bo 9 na 10 ataków idzie zaraz po permabanie.

FAQ

Można odpalić oba pluginy naraz?

Technicznie tak, zwłaszcza po przemianowaniu komend jednego. Praktycznie nigdy. Dwie historie, dwie DB, dwa logi, dwa layouty, dwa miejsca do sprawdzenia. Wybrać jeden.

Velocity 3.x?

LiteBans: tak, dedykowany jar Velocity. AdvancedBan: częściowo, przez community fork AdvancedBanVelocityFix albo nowsze wydania głównego jara. Test na staging przed prod.

LiteBans bez web-UI ma sens?

Plugin działa bez web-UI, jasne, ale 80% wartości LiteBans to dołączony web-UI. Bez niego AdvancedBan oszczędza 15 USD bez utraty funkcji.

SQLite czy MySQL dla AdvancedBan?

Single server, do 50 online, bez proxy: SQLite ok. Wszystko inne: MySQL. SQLite nie pociągnie multi-server, plik jest single-writer.

Gdzie są przechowywane IP graczy?

Oba zapisują ostatni IP przy logowaniu. LiteBans w litebans_history, AdvancedBan cache do /ipban. Pamiętaj o RODO przy publiczności z UE: nie publikować surowych IP w publicznym web-UI bez hashowania.

Migracja historii z MaxBans do LiteBans lub AdvancedBan?

Skryptem SQL tak. Oficjalny importer mi nie znany, schematy się różnią. Backup, mapowanie kolumn ręcznie.

Solidny plugin moderacji to coś więcej niż komendy i tabele. To ubezpieczenie dla zmęczonych nocnych mods, audit trail dla appeli, stabilne API pod automatyzację. LiteBans i AdvancedBan oba dowożą. Wybór sprowadza się do jednego pytania: 15 USD za wypolerowany web-UI czy godziny własnego czasu na community-frontend. Serwer komercyjny: jasne. Prywatny SMP dla znajomych: odwrotnie.