Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

There is no single plug-in that is “best” for every Minecraft Bedrock server. Your first choice is the server architecture. A native Minecraft Bedrock Dedicated Server uses behavior packs and Bedrock Script API modules; Java plug-ins cannot be dropped into it. A Java server running Paper can accept Bedrock players through Geyser, with Floodgate added when you need Bedrock authentication and related features. Once that decision is made, choose PvP components for combat tagging, arenas, kits, claims, permissions, moderation and anti-cheat, then verify compatibility with your exact Minecraft, Geyser, Floodgate, proxy and plug-in versions.

For a hosted Bedrock deployment, Godlike.Host offers Minecraft Bedrock hosting through its own game panel, with free DDoS protection and up to three free backups a day with restore.

What “Bedrock PvP plugins” actually means

The phrase combines two different technologies. Minecraft Bedrock Dedicated Server and Minecraft: Java Edition servers do not share the same extension system, so the installation path depends on which server software is running.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Native Bedrock Dedicated Server

On a native Bedrock server, game changes are delivered through behavior packs (also called add-ons) and, where needed, Bedrock Script API modules. Behavior packs can alter entity functions, rules, mechanics and other game behavior. Script API modules add server-side logic for systems such as arenas, kits, scoreboards, combat rules and custom events.

Microsoft’s Bedrock Dedicated Server documentation covers server.properties, configuration folders, permissions, variables, secrets and Script API modules. The additional APIs discussed there are identified as experimental and do not apply to Realms. That distinction matters: a pack designed for a dedicated server is not automatically a supported Realms solution.

Java server with Bedrock access

On the other architecture, Paper is the Java Edition server base and exposes the plug-in API used by most modern Java PvP extensions. Geyser translates connections so Bedrock clients can join that Java server. Floodgate is installed alongside Geyser when Bedrock players should authenticate without a paid Java Edition account or when plug-ins need Bedrock-specific skins, forms, account linking or API access.

In this model, the PvP plug-in itself is a Java plug-in. Geyser does not turn a Bedrock server into a Java plug-in host; it lets Bedrock clients interact with a Java server and its server-side plug-ins.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Choose the architecture before choosing a PvP add-on

Question Native Bedrock Dedicated Server Paper plus Geyser
Extension format Behavior packs/add-ons and Bedrock Script API modules Java plug-ins for Paper (or another supported Java platform), with Geyser translating Bedrock connections
Can Java plug-ins be installed directly? No Yes, on the Java server; Bedrock players access those features through Geyser
Bedrock login without a Java account Handled by the Bedrock server’s own identity system Floodgate can provide this capability when installed with Geyser
Typical PvP implementation Behavior-pack rules, Script API code, custom entities, scoreboards and commands Java plug-ins for combat tagging, arenas, kits, claims, permissions, moderation and related systems
Realms applicability Microsoft’s additional Script APIs described for the dedicated server do not apply to Realms Not a Realms architecture; it requires a Java server and a Geyser-compatible deployment
Primary compatibility checks Bedrock server version, pack format, Script API version and experimental-feature requirements Java version, Paper build, Geyser build, Floodgate build, proxy (if any) and each plug-in’s compatibility matrix

If you want a lightweight, Bedrock-native survival or arena server, start with a behavior pack and add Script API only for logic the pack cannot provide. If you need the broad Java plug-in ecosystem, run Paper and expose it to Bedrock clients through Geyser.

Best native Bedrock PvP stack

Use a behavior pack for rules and content

A behavior pack is the foundation for native Bedrock PvP. Use it for changes to entity behavior, combat rules, item or kit definitions, arena mechanics and other data-driven changes. Keep the pack’s manifest and format version aligned with the Bedrock server build. A pack that loads but targets an incompatible format can produce missing functions, ignored components or silent fallbacks to vanilla behavior.

Add Script API only when the pack needs server logic

Use Script API modules for stateful systems that are difficult to express in data files: tracking combat tags, assigning players to arenas, resetting maps, rotating kits, updating scoreboards or enforcing custom win conditions. Microsoft classifies the additional APIs in its dedicated-server guidance as experimental. Test them on the exact server build you intend to run and do not assume that a script accepted by a dedicated server is available on Realms.

Native installation workflow

  1. Back up the world and configuration. Copy the world folder, server.properties, permissions data and existing packs before changing combat logic.
  2. Confirm the Bedrock server build. Record the exact version and check the behavior-pack format and Script API module versions required by the add-on.
  3. Install the behavior pack. Place the pack in the server’s behavior-pack location, verify its manifest, and activate it for the target world through the world’s pack settings.
  4. Enable required experiments only when documented. If the module requires experimental APIs, enable the specified experiment on a test copy first. Do not enable unrelated experiments on a production world.
  5. Install Script API modules in the documented server locations. Keep scripts server-side; do not rely on a client download for authoritative combat decisions.
  6. Restart and inspect the console. Resolve manifest, dependency or script errors before players join. A clean startup does not prove every event handler is functioning, so run each arena, kit and combat-tag path.
  7. Test with two Bedrock accounts. Verify hit registration, respawn, inventory restoration, scoreboards, arena reset and logout handling from both sides of a fight.

Native Bedrock limitations to plan for

  • Java plug-ins are not a drop-in option. A Paper plug-in must be replaced by a behavior-pack or Script API implementation.
  • Experimental Script API features can change between Bedrock releases. Pin a server version for tournaments or other events instead of updating automatically.
  • Client UI assumptions can break across Bedrock devices. Touch, controller and keyboard users may expose different input timing and form-navigation issues.
  • Realms and dedicated-server capabilities are not interchangeable when Microsoft’s documentation excludes the additional APIs from Realms.

Best Java-plus-Geyser PvP stack

Paper is the plug-in host

Paper is a Minecraft: Java Edition server designed to improve performance and expose an API for plug-ins. Install the PvP plug-ins on Paper, not in the Bedrock client and not in the Geyser translation layer. If you use a proxy, install each component in the location its author documents; a plug-in built for Paper is not automatically a proxy plug-in.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Geyser provides the Bedrock connection

Install the Geyser variant matching your server or proxy. Configure its Bedrock UDP listener; Geyser setup examples use port 19132. Forward that UDP port through the host and firewall, then use Geyser’s diagnostic command:

geyser connectiontest <ip> <port>

The test checks reachability to the specified address and port. A successful test does not validate every PvP plug-in, but it separates basic Bedrock connectivity problems from combat-system problems.

Floodgate is optional but useful

Floodgate is installed in addition to Geyser. Add it when Bedrock players should join without a paid Java Edition account, or when your plug-ins need Bedrock skins, forms, account linking or Floodgate API access. GeyserMC documents Floodgate contexts for Paper/Spigot, BungeeCord, Velocity and Fabric. Select the package that matches the point where your players connect and where authentication is handled.

Java-plus-Geyser installation workflow

  1. Choose the Java version and Paper build first. Write down the exact versions; every subsequent compatibility check depends on them.
  2. Install Paper and start it once. Accept the EULA as required by your deployment, let Paper generate its folders, then stop the server cleanly before adding plug-ins.
  3. Install Geyser in the matching location. Use the server or proxy form that corresponds to your topology. Set the Bedrock listener and document the external UDP port, using 19132 only if that port is available and appropriate for your host.
  4. Open and forward UDP. Configure the host firewall, cloud firewall and router (if applicable) for the same UDP port. TCP-only forwarding will not provide a working Bedrock path.
  5. Run the connection test. Execute geyser connectiontest <ip> <port> from the environment recommended by Geyser’s setup instructions and correct network errors before installing a large plug-in stack.
  6. Add Floodgate if required. Install it alongside Geyser, generate or place its configuration as documented, and test a Bedrock account before adding account-linking rules or permissions.
  7. Add one PvP capability at a time. Restart after each plug-in, read the startup log and test a controlled fight. This makes a conflict attributable instead of leaving several simultaneous errors.
  8. Verify Bedrock behavior. Test touch, controller and keyboard clients, inventory screens, forms, knockback, projectiles, respawn and reconnects. A Java-only test is not enough.

Geyser explicitly supports server-side mods; client-side-only mods do not work through it. Do not select a PvP feature that requires every Bedrock player to install a Java client mod.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Which PvP capabilities should you install?

Instead of selecting a plug-in by a popularity ranking, select the smallest set that covers your game mode. The following capability map applies to both architectures, although the implementation format differs.

PvP need Native Bedrock implementation Paper/Geyser implementation Questions to verify
Combat tagging and logout prevention Script API state plus behavior-pack or command actions Java combat-tag plug-in What starts and ends a tag? Does a disconnect count as a kill? Are Bedrock reconnects handled correctly?
Arenas and minigames Scripted queues, teleport logic, scoreboards and world reset functions Arena or minigame plug-in Can it reset maps safely, isolate spectators and restore inventories for Bedrock users?
Kits and loadouts Behavior-pack item definitions and Script API assignment Kit/loadout plug-in Are item components, enchantments, cooldowns and forms translated correctly?
Factions, claims and protected areas Scripted region checks and command permissions Claims or factions plug-in Does protection cover block breaking, explosions, projectiles and container access in every world?
Permissions Bedrock permissions, commands and script checks Java permissions plug-in plus the server’s permission system Are Floodgate identities mapped consistently, especially behind a proxy?
Moderation Commands, scoreboards and Script API logging Mute, ban, report and staff-tool plug-ins Do forms and messages remain usable on Bedrock clients? Are audit records retained?
Anti-cheat Server-authoritative Bedrock settings and server-side checks Java anti-cheat plus Geyser-aware configuration and server-authoritative settings Which checks understand translated movement, reach, inventory and latency?

How to compare candidate PvP plug-ins

1. Match the platform and protocol path

Read the author’s compatibility matrix for the exact Java version, Paper build, Geyser build, Floodgate build and proxy. A plug-in can work for Java players while misclassifying Bedrock movement or forms. For a native server, check the Bedrock pack format, Script API version and whether experimental features are mandatory.

2. Test Bedrock input and UI, not only combat math

Bedrock players may use touch, controller or keyboard input. Menus designed for Java inventory clicks can be awkward or unusable when translated. Check kit selection, queue joining, confirmation dialogs, spectator controls and report forms on each input type. Record whether a button requires a second tap, whether a form closes after teleporting and whether a player can recover after a lost connection.

3. Treat protocol compatibility as a release constraint

Geyser, Floodgate, Paper and Minecraft versions evolve independently. Pin compatible builds for a competition season, stage upgrades on a copy of the world and read changelogs for protocol, authentication and API changes. Do not infer compatibility from a plug-in’s age or download count.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

4. Measure server cost under the intended fight load

Combat tagging, region checks, entity tracking, scoreboards and anti-cheat checks all consume server time. Profile a realistic scenario: several simultaneous arenas, projectiles, respawns and reconnects. Watch tick time, memory, entity counts and log volume. A feature that is inexpensive for ten players can become the bottleneck for a tournament lobby.

5. Evaluate false-positive risk

Bedrock movement is translated into a Java server’s expectations. Latency, touch controls, mobile frame rate and protocol conversion can look unusual to a Java-centric check. A plug-in that immediately kicks on one suspicious movement may punish legitimate Bedrock players. Prefer configurable thresholds, staged alerts and staff review while you establish normal data for your player base.

6. Check maintenance and recovery behavior

Confirm how the plug-in stores combat tags, claims, kits and punishments, and how to back up or migrate that data. Look for documented reload behavior; if a reload can duplicate items or lose arena state, schedule a full restart instead. A maintained plug-in with a clear migration path is safer than a feature-rich plug-in that stops at an old server version.

Anti-cheat and fairness baseline

Mojang’s Bedrock protocol guide documents server-authoritative controls. The current 2026 guide lists these settings:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Setting Documented value What it controls
player-rewind-min-correction-delay-ticks 5 ticks Minimum delay before a rewind correction is applied
player-rewind-history-size-ticks 40 ticks Movement history retained for rewind checks
player-position-acceptance-threshold 0.5 Documented player-position acceptance threshold
server-authoritative-block-breaking true Server authority for block-breaking decisions
server-authoritative-block-breaking-pick-range-scalar 1.5 Pick-range scalar used with server-authoritative block breaking

Minecraft runs at 20 ticks per second, so 40 ticks represents about two seconds of two-way latency history. These are server controls, not proof that any third-party anti-cheat is compatible with every Bedrock client path. Apply them deliberately, then validate hit registration, mining, placement and movement with real Bedrock clients.

A practical anti-cheat rollout

  1. Establish the authoritative baseline. Record the existing values in server.properties and back up the file.
  2. Change one class of control at a time. Test movement and block breaking separately so a false positive has an identifiable cause.
  3. Use alert-only mode first for third-party checks. Collect staff-reviewed examples from touch, controller and keyboard players before enabling automatic punishment.
  4. Segment by connection path. Compare Java-only, Bedrock-through-Geyser and proxy-connected sessions. A threshold that is safe for one path may be too strict for another.
  5. Document appeals and reversals. Keep evidence for a kick or ban and provide staff with a way to clear a false positive without resetting unrelated punishment data.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Recommended stacks by server goal

Small native Bedrock arena

Use one behavior pack for combat rules and arena content, with a narrowly scoped Script API module for queues, tags, resets and scoreboards. Keep the number of scripts small, test every pack update on a copy and avoid adding Java plug-in terminology to the deployment plan.

Cross-play Java survival server

Use Paper as the Java base, Geyser for Bedrock connections and Floodgate if account-free Bedrock login or Bedrock-specific API features are required. Add only the combat-tag, claims, permissions and moderation capabilities your rules need. Verify every component against the exact Paper, Geyser, Floodgate and proxy versions before opening the server.

Competitive minigame network

Use a staged environment with version-pinned Paper servers, a matching Geyser deployment and a tested Floodgate configuration. Separate lobby, queue, arena and moderation responsibilities when the plug-ins support that topology. Run load tests with simultaneous fights, projectiles, spectator movement and reconnects, then publish the accepted client versions and input limitations to players.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Troubleshooting by symptom

Bedrock players cannot connect

  • Confirm that the Geyser Bedrock listener is enabled and that the client is using UDP, not only TCP.
  • Check that the advertised port matches the forwarded firewall and router port. The common setup example is 19132, but your host may require another available port.
  • Run geyser connectiontest <ip> <port> and inspect both the Geyser and proxy logs.
  • If Java players can connect but Bedrock players cannot, troubleshoot the Geyser path before changing PvP plug-ins.

Bedrock login or skins are wrong

  • Confirm whether Floodgate is required for your account policy and whether it is installed in the same supported context as Geyser.
  • Check permission and account-linking rules for the Bedrock identity format, especially when a proxy is involved.
  • Test with a new account and an existing linked account; do not assume that a successful Java login proves Floodgate is configured.

Combat tags disappear after a restart

  • Check whether the implementation persists tag state or intentionally clears it on shutdown.
  • Test an orderly restart and an unexpected process termination separately.
  • For a native Script API implementation, verify that the script restores state before players can move or disconnect.

Legitimate Bedrock players are kicked for cheating

  • Switch the third-party check to alerts and collect the player’s device, input method, latency and connection path.
  • Compare the event with the server-authoritative movement settings and Geyser version.
  • Adjust one threshold or exemption at a time, then retest in a controlled arena. Do not disable every check globally to solve one unexplained event.

A kit or arena menu is unusable

  • Test the form or inventory interaction on touch, controller and keyboard.
  • Check whether teleporting, respawning or closing a form leaves a stale queue or duplicate inventory.
  • Replace a Java-client-only interaction with a server-side command or Bedrock-compatible form when the plug-in supports that alternative.

Maintenance checklist

  • Record the Minecraft Bedrock or Java version, Paper build, Geyser build, Floodgate build, proxy type and every PvP component version.
  • Back up worlds, behavior packs, Script API files, server.properties, permissions and plug-in data before each upgrade.
  • Stage updates on a test server with representative Bedrock and Java accounts.
  • Test login, permissions, kit assignment, combat tagging, arena reset, projectiles, block breaking, death, respawn, logout and reconnect.
  • Review startup logs for dependency, API and protocol warnings; do not ignore warnings merely because the server reaches the lobby.
  • Keep a rollback copy of the previous server and data versions until the new build has survived normal peak load.
  • Publish supported client versions and known input or UI limitations to players.

Final selection framework

Choose native Bedrock when your priority is a Bedrock-first server and you are comfortable implementing PvP with behavior packs and Script API modules. Choose Paper plus Geyser when you need Java plug-ins and want Bedrock clients to join. Add Floodgate only for the authentication, identity and Bedrock-specific features it provides.

Within either architecture, select PvP components by capability and compatibility rather than by an unverified “top plug-ins” list. The decisive checks are Bedrock input and UI behavior, protocol and version support, server performance, anti-cheat false positives, persistence and maintenance quality. There is no authoritative adoption statistic or universally compatible third-party plug-in matrix that justifies naming one product as the best for every Bedrock server.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.