LiteBans vs AdvancedBan: welches Moderations-Plugin wählen (2026)

Sobald ein Server zwanzig gleichzeitige Spieler überschreitet und die Registrierung offen ist, kommt man ohne ein dediziertes Strafen-Plugin nicht mehr aus. Das Vanilla-Bukkit-/ban macht genau eins: schreibt den Namen in banned-players.json und kickt mit einer generischen Nachricht. Keine Historie, kein Grundfeld, kein IP-Tracking, keine Proxy-Synchronisation, kein Web-Interface für Mods. Reicht für einen SMP mit zehn Freunden. Auf einem Netzwerk mit Proxy und mehreren Backends ist das ein Albtraum.

Zwei Plugins dominieren diese Nische auf der Spigot/Paper-Seite: LiteBans (kostenpflichtig, ca. 15 USD auf BuiltByBit, proprietär) und AdvancedBan (kostenlos, MIT, Open Source). Beide werden 2026 aktiv gepflegt, beide sprechen per-network Bans über MySQL, beide decken /ban, /tempban, /mute, /warn, /kick ab. Der Unterschied liegt im Politur-Grad, Web-UI, API und wieviel Zeit und Geld man investieren will. Brechen wir es auf.

Wozu überhaupt ein dediziertes Strafen-Plugin

Bukkits eingebautes /ban macht drei Dinge: hängt einen Namen an eine JSON-Datei an, kickt den Spieler, druckt in die Konsole. Das wird sehr schnell zu wenig. Man braucht:

• Strafen-Historie pro Spieler. Wer hat gebannt, wann, weshalb, wie viele Vorwarnungen.
• Grund und Dauer im Kick-Screen. Der Spieler soll Banned for: x-ray client / 30 days / appeal: example.com sehen.
• Persistenter Speicher in einer echten Datenbank. JSON korrumpiert bei Crashes, skaliert nicht, synct nicht.
• Per-network Bans. Wenn Lobby, Survival und Minigames hinter Velocity/BungeeCord laufen, soll ein Bann auf einem Knoten überall greifen.
• Mute, Warn, Kick als eigene Entitäten mit Historie.
• IP- und UUID-Verkettung. Alts werden über IP-Tracking gefangen.
• Web-UI für Moderatoren ohne SSH-Zugang.
• API für die Anbindung an Discord-Bot, Anticheat, eigene Plugins.

LiteBans und AdvancedBan decken diese Liste, die Art wie sie es tun ist der Unterschied.

LiteBans: der bezahlte Premium-Standard mit vollem Web-UI

LiteBans wird auf BuiltByBit (früher Teil des SpigotMC-Marketplaces) für ca. 15 USD verkauft. Wird von einem Entwickler gepflegt, aktueller Major-Branch ist 2.x. Unterstützt Bukkit/Spigot/Paper von 1.8.x bis 1.21.x, BungeeCord, Velocity, Sponge. Storage ist MySQL/MariaDB-first, mit PostgreSQL-Support und H2-Fallback für Single-Server (in der Praxis nicht empfohlen).

Das Killer-Feature ist das PHP-Web-Frontend. Kein "API-Endpunkt", sondern ein fertiges Admin-Panel mit Strafentabelle, Filtern, Suche nach Name/UUID/IP, Sektionen für Bans/Mutes/Warns/Kicks, voller Historie pro Spieler. Theming via CSS, Light- und Dark-Themes ab Werk. Es gibt einen Admin-Login mit Permissions. Installation: litebans-php Ordner nach /var/www/ packen, MySQL-Credentials in config.php eintragen, fertig.

Die Befehle decken alles Standard ab:

/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>      # aktuell aktive Strafen
/dupeip <player>     # Alts via IP

LiteBans unterstützt Layouts: Kick-Screen-Templates mit Platzhaltern wie {reason}, {duration}, {banned-by-name}, {appeal-link}. Man kann verschiedene Layouts pro Strafart und pro Dauer definieren. Ein permanenter Bann sieht anders aus als ein 7-Tage-Bann, der wiederum anders als ein Mute.

Per-network Bans laufen über gemeinsames MySQL. Gleicher database Block auf allen Backends und auf dem Proxy, LiteBans schreibt in eine litebans_bans Tabelle, der Lookup passiert beim Login. Auf einem Proxy gibt es einen dedizierten JAR, der den Spieler abfängt bevor er an ein Backend weitergeleitet wird, was minimal schneller ist als am Backend selbst zu fangen.

Die Plugin-API exponiert Bukkit-Style-Events: LiteBansBanEvent, LiteBansMuteEvent, LiteBansWarnEvent, LiteBansKickEvent, LiteBansUnbanEvent. Aus dem eigenen Plugin abonnieren und z.B. jeden Bann in Discord oder ans Anticheat-Backend pipen.

@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);
}

Schwächen von LiteBans:

• Kostet Geld. Für einen 5-Mann-SMP overkill.
• Closed Source. Verschwindet der Autor, gibt es keinen Fork.
• MySQL ist de facto Pflicht. H2-Fallback existiert, niemand fährt ihn produktiv.
• Web-UI braucht eigenes PHP-Hosting. Wer auf Pterodactyl ohne eigenen Webserver lebt, muss Nginx + PHP-FPM separat hochziehen.

AdvancedBan: das kostenlose Arbeitspferd

AdvancedBan lebt auf GitHub unter DevLeoko/AdvancedBan, Lizenz MIT. Verteilt über Hangar (PaperMC), Modrinth und SpigotMC kostenlos. Unterstützt Bukkit/Spigot/Paper von 1.8 bis 1.21+, BungeeCord-Support via Addon. Der JAR ist drei- bis viermal kleiner als LiteBans, ohne fremde Dependencies.

Storage ab Werk: SQLite oder MySQL. SQLite liegt in plugins/AdvancedBan/data.db, reicht für Single-Server bis ~100 online. MySQL aktivieren durch Umlegen eines Blocks in config.yml:

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

Befehle nahezu eins-zu-eins zu 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 Auswahl
/history <player>
/check <player>
/banlist

Der Zeit-Parser akzeptiert s, m, h, d, w, mo, y Suffixe (/tempban Notch 7d griefing).

Layouts gibt es ebenfalls, etwas einfacher als bei 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 Bans via MySQL: gleicher Block auf allen Backends, AdvancedBan schreibt in ein gemeinsames Schema. Für BungeeCord gibt es ein separates Addon, das den Proxy-Login einhakt.

Web-UI ist einfacher und nicht offiziell im Hauptrepo. Mehrere Community-Forks (AdvancedBanWeb, AdvancedBan-Frontend) lesen MySQL und rendern Strafentabellen. Optisch spartanisch, weniger Filter, kein Admin-Login, keine Themes. Wer LiteBans-Niveau will, baut selbst oder migriert.

Die AdvancedBan-API exponiert ebenfalls Events:

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

Plus direkten Repository-Zugriff: PunishmentManager.get().getActivePunishments(uuid) liefert die Liste aktuell aktiver Strafen.

Schwächen von AdvancedBan:

• Web-UI nur Community, gröber im Look.
• Layouts haben weniger Platzhalter, weniger Segmentierung.
• Übersetzungen und Templates verteilen sich auf mehrere yml-Dateien, weniger ordentlich.
• Langsamerer Release-Takt: neue Major-Versionen alle paar Monate.

Installations-Flow für beide

LiteBans:

1. Auf builtbybit.com kaufen, LiteBans.jar laden
2. In plugins/, Server neustarten
3. plugins/LiteBans/config.yml und settings.yml öffnen
4. MySQL-Credentials in settings.yml -> sql:
5. Neustart, Plugin legt litebans_* Tabellen an
6. Web-UI: php-Frontend nach /var/www/litebans/ entpacken
7. Gleiche MySQL-Creds in config.php

AdvancedBan:

1. AdvancedBan.jar von hangar.papermc.io oder github releases laden
2. In plugins/, neustarten
3. plugins/AdvancedBan/config.yml öffnen
4. use-MySQL: true und MySQL-Block ausfüllen
5. Neustart, Plugin legt punishments Tabelle an
6. Optional: BungeeCord-Addon aus releases laden

Für ein Velocity-Proxy-Netzwerk:

1. Jedes Backend hat den Haupt-JAR mit identischem MySQL-Block.
2. Velocity hat den passenden Proxy-JAR (LiteBans-Velocity, AdvancedBanVelocityFix oder Fork-Branch).
3. Login-Listener auf dem Proxy fragt MySQL ab, bevor an ein Backend weitergegeben wird.
4. Jedes Backend prüft beim Login-Event nochmal als Fallback.

Befehle und ein realer Moderations-Flow

Spieler Hacker_77 nutzt x-ray. Standard-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 (eigener Listener)

[Hacker_77 reconnects]
[Plugin] Kick screen mit Layout, Grund, Dauer, Appeal-Link

Stellt sich raus, der Bann muss permanent sein:

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

Für Chat-Moderation:

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

Warns akkumulieren und konvertieren automatisch zu einem Bann ab einem Schwellenwert via AdvancedBan WarnActions oder LiteBans Triggers.

Per-network Bans auf Velocity/BungeeCord

Beide können das, die Implementierungen unterscheiden sich. LiteBans verwendet einen MySQL-Layer für Proxy und Backend gemeinsam. Spieler kommt auf Velocity, das LiteBans-Velocity-Plugin fragt litebans_bans, bei aktivem Eintrag kickt es mit dem korrekten Layout. Wird ein Bann live hinzugefügt, sieht der Proxy das INSERT und triggert einen Kick.

AdvancedBan: Hauptlogik liegt am Backend. Velocity/BungeeCord-Addon hängt sich an Login und fragt MySQL ab. Etwas weniger zentralisiert, funktioniert.

Falle: das Schema muss synchron über alle Instanzen bleiben. Laufen zwei Backends auf unterschiedlichen Major-Versionen von LiteBans, kann eines davon eine Schema-Migration anstoßen, die die anderen bricht. Regel: eine Plugin-Version, ein Update-Fenster, alle Backends gleichzeitig.

Web-UIs: hier zieht LiteBans davon

LiteBans Web-UI:

• Fertige PHP-Seite ab Werk (im Kauf enthalten).
• Themes: light, dark, eigene CSS-Overrides.
• Filter: nach Strafart (ban/mute/warn/kick), Status (active/expired/permanent), Name/UUID/IP.
• Pagination, sortierbare Spalten.
• Spielerhistorie ein Klick entfernt.
• Optional: Admin-Login obendrauf, Public sieht nur Banlist, Staff alles.

AdvancedBan Web-UI:

• Kein offizielles Frontend. Community: AdvancedBanWeb (PHP), advancedban-frontend (Node/React).
• Minimal: Banlist, Suche nach Name.
• Keine Auth-Tiers, keine erweiterten Filter.
• LiteBans-Niveau heißt: selbst bauen oder migrieren.

Auf einem öffentlichen Server mit häufigen Appeals ist das Web-UI die Linie zwischen "handhabbar" und "unhandhabbar". Mod ohne SSH, Spieler im Appeal, Owner mit Audit-Anspruch, alle leben im Web-UI. Wenn das Budget passt, löst LiteBans das für einen.

Plugin-API für eigene Integrationen

Jeden Bann nach Discord und in das eigene Anticheat schicken.

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()
        ));
    }
}

Beide sauber. LiteBans separiert pro Typ, AdvancedBan ein gemeinsames Event mit Filter.

Direktes SQL aus dem eigenen Code geht, ist aber schlecht: Schema-Bump bricht alles. API verwenden.

Datenmigration zwischen den beiden

Typisches Szenario: Start auf AdvancedBan, gewachsen, jetzt LiteBans wegen Web-UI, Historie soll mit.

Es gibt keinen offiziellen Importer von AdvancedBan zu LiteBans. Drei Wege:

1. Eigenes SQL-Skript. AdvancedBan-Schema: eine punishments Tabelle mit name, uuid, reason, operator, punishmentType, start, end, calculation. LiteBans: separate Tabellen litebans_bans, litebans_mutes, litebans_warnings, litebans_kicks, litebans_history. Mapping: Strafart → Zieltabelle, Millisekunden → LiteBans-Timestamps.

-- Bans aus AdvancedBan in LiteBans importieren (vereinfacht)
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 parallel read-only laufen lassen. LiteBans auf neuer DB, AdvancedBan nur für History-Lookups. Hässlich aber einfach.

3. Drittanbieter-Importer. GitHub hat ein paar in unterschiedlicher Frische. Vorher DB sichern.

Andere Richtung (LiteBans → AdvancedBan) seltener, aber auch SQL: Per-Typ-Tabellen in eine gemeinsame punishments Tabelle kollabieren, Typ-Spalte aus dem Source-Tabellennamen ableiten.

Performance unter Last

200+ gleichzeitige Spieler stemmen beide locker. Was zählt:

• Connection Pooling. LiteBans nutzt HikariCP, AdvancedBan ebenfalls in neueren Versionen. Default-Pool 10 reicht fast immer.
• Async überall. Beide schreiben asynchron in die DB. Main-Thread checkt nur Cache beim Login.
• Login-Query muss billig sein. UUID-Index ist Pflicht (beide legen ihn an). Bei hunderttausenden Einträgen EXPLAIN laufen lassen, ref Plan über UUID-Index erwartet.
• MySQL nahe. MySQL auf der gleichen Box wie Minecraft oder einen Private-Network-Hop weg. 1-2 ms Latenz okay, 20+ ms macht sich als Login-Lag bemerkbar.

LiteBans ist im Memory etwas schwerer wegen reicherem Caching. Die 100 MB JAR-Größe täuscht, JVM-Overhead unter 30 MB. AdvancedBan bei 15-20 MB.

Tick-Lag bringt keiner ein, solange MySQL gesund ist. Wird MySQL langsam, blockieren die Async-Writes den Main-Thread nicht, aber die Fallback-Queue wächst. Bei 1000+ Events/Minute lohnt sich ein Prometheus-Alert.

Preis und Lizenz

Punkt	LiteBans	AdvancedBan
Lizenz	proprietär, kostenpflichtig	MIT, kostenlos
Preis	~15 USD auf BuiltByBit	0
Support	aktiver Dev	Community + Dev
Web-UI	inklusive	Community-Forks
Open Source	nein	ja

Budget null: klare Sache. 15 USD einmalig: LiteBans spart Stunden bei Web-UI und Layouts.

Wann was wählen

LiteBans wenn:

• Großer öffentlicher Server, 100+ gleichzeitig.
• Mehrere Mods ohne SSH, Web-UI Pflicht.
• Netzwerk mit Proxy, mehrere Backends, Lobby, robuste Synchronisation.
• Spieler appellieren oft, öffentliche Banlist gewünscht.
• 15 USD einmalig im Budget.
• Fertiges Produkt statt Stunden Community-Frontend.

AdvancedBan wenn:

• SMP bis 50 gleichzeitig oder whitelisted.
• Kein Budget für Paid-Plugins.
• Open Source ist wichtig (Audit, Fork, Customisation).
• Web-UI optional oder eigener Stack vorhanden.
• Einfache Struktur, kein komplexes Network-Routing.
• "Installieren und vergessen" als Ziel.

Beide lösen die Kernaufgabe. Der Spalt liegt im Polish und gebündelten UI.

Pre-Production Checkliste

• MySQL-Backup eingerichtet (mysqldump in cron, mindestens täglich).
• Layouts für ban/mute/warn/kick mit Appeal-URL.
• Permissions nach Rollen (modkick, modban, admin).
• /staffhistory aktiviert, Accountability sichern.
• Discord-Webhook bei jeder Strafe via eigenem Listener.
• Test-Flow: ban → reconnect → Kick-Screen mit korrektem Layout.
• Per-network: Bann auf einem Knoten greift überall.
• Web-UI (bei LiteBans) hinter Auth, nicht öffentlich frei browsbar.
• DDoS-Schutz (z.B. MineGuard) drüber, weil 9 von 10 Attacks direkt nach einem Permaban kommen.

FAQ

Beide gleichzeitig betreiben?

Theoretisch ja, vor allem mit umbenannten Befehlen. Praktisch nie. Zwei Historien, zwei DBs, zwei Logs, zwei Layouts, zwei Stellen zum Nachschauen. Eines wählen.

Velocity 3.x Support?

LiteBans: ja, dedizierter Velocity-JAR. AdvancedBan: teilweise, via Community-Fork AdvancedBanVelocityFix oder neuere Main-JAR-Releases. Auf Staging testen vor Prod.

LiteBans ohne Web-UI sinnvoll?

Funktioniert, klar, aber 80% des LiteBans-Wertes ist das gebündelte Web-UI. Ohne spart AdvancedBan 15 USD ohne Funktionsverlust.

SQLite oder MySQL für AdvancedBan?

Single Server, bis 50 online, kein Proxy: SQLite okay. Alles andere: MySQL. SQLite kann kein Multi-Server, die Datei ist Single-Writer.

Wo werden Spieler-IPs gespeichert?

Beide loggen die letzte IP beim Login. LiteBans persistiert in litebans_history, AdvancedBan cached für /ipban. DSGVO im Auge behalten bei EU-Publikum: rohe IPs nicht in öffentliches Web-UI ohne Hashing.

Historie aus MaxBans nach LiteBans oder AdvancedBan?

Per SQL-Skript ja. Kein offizieller Importer bekannt, Schemas weichen ab. Vorher Backup, Spalten manuell mappen.

Ein solides Moderations-Plugin ist mehr als Befehle und Tabellen. Es ist Versicherung für müde Nachtschicht-Mods, Audit-Trail für Appeals, stabile API für Automatisierung. LiteBans und AdvancedBan liefern beides. Die Wahl reduziert sich auf eine Frage: 15 USD für ein poliertes Web-UI oder Stunden eigener Zeit auf einem Community-Frontend. Kommerzieller Server: klar. Privater SMP für Freunde: anders herum.