A Minecraft practice server needs more than a large RAM allocation. Stable PvP depends on Java compatibility, single-thread CPU performance, predictable world loading, safe arena resets, database persistence and a plugin stack whose versions have been tested together.
This checklist covers the requirements for ShyamDuels Core and explains why the complete Advance ShyamDuels Setup recommends a larger production allocation.
ShyamDuels targets Minecraft 1.21.x through the Paper API and is tested on Paper 1.21.11. Compatible Paper forks such as Purpur may work, but they should be tested with the complete stack before production.
Do not mix arbitrary plugin builds from different Minecraft versions. Update the server jar, required dependencies and plugins in a staging environment first.
Use Java 21 or newer. If the console reports an unsupported class-version error, the server is running an older JVM even if the control panel displays a newer Java option elsewhere.
Confirm the runtime used by the actual server process, not only the Java version installed on the machine.
All four dependencies below are hard requirements:
If one is absent, ShyamDuels intentionally refuses to enable rather than starting with incomplete match behavior.
There is no universal RAM number for every practice server. Memory usage depends on:
The premade ShyamDuels setup recommends at least 16 GB because it represents a complete server stack rather than only one plugin. Do not interpret that as the core plugin consuming 16 GB by itself.
Leave memory for the operating system and hosting panel. Allocating every available gigabyte to Java can cause the machine to swap or terminate background services.
Minecraft still depends heavily on main-thread performance. Prefer a modern CPU with strong per-core speed over an old many-core processor marketed only by total core count.
Monitor tick duration under real combat. Crystal explosions, projectiles, block changes, chunk loading and arena resets produce workloads that an idle lobby test will not reveal.
Use SSD or NVMe storage. Arena cloning and schematic restoration create disk activity, and slow storage can lengthen startup or reset operations.
Plan space for:
SQLite is simple and suitable for initial testing or a small single-server deployment. MySQL is preferable when concurrency grows, data must be accessed by multiple services, or local database locking becomes a concern.
The ShyamDuels troubleshooting guidance recommends considering MySQL for servers above roughly 200 concurrent players. That is not a guarantee that every smaller server should use SQLite; operational requirements still matter.
Every simultaneous duel needs an eligible arena. If one kit can use only two arenas, the third match must wait even when the server has abundant RAM.
Arena cloning can increase capacity when templates are located in one base world. Keep cloning disabled when arenas intentionally live across different worlds or each copy needs a unique layout.
For a Velocity or multi-server network, decide where player profiles, punishments, ranks and statistics are authoritative. Use secure forwarding, restrict backend ports and keep database credentials outside public downloads.
Test transfers during active queues and ensure players cannot bypass match cleanup by reconnecting through another backend.
Continue with Paper vs Purpur for Practice Servers and the complete Minecraft practice-server build guide. If you want to skip most initial integration work, evaluate the Advance ShyamDuels Setup.
More RAM does not fix lag: inspect the main thread, packet workload and reset operations with a profiler.
Staging is fast but production is slow: reproduce the proxy, database distance, view settings and real plugin list.
Use ShyamDuels Core for a configurable stack, or the prepared setup when a documented baseline is the faster path.
This checklist covers the requirements for ShyamDuels Core and explains why the complete Advance ShyamDuels Setup recommends a larger production allocation.
Minecraft server software
ShyamDuels targets Minecraft 1.21.x through the Paper API and is tested on Paper 1.21.11. Compatible Paper forks such as Purpur may work, but they should be tested with the complete stack before production.
Do not mix arbitrary plugin builds from different Minecraft versions. Update the server jar, required dependencies and plugins in a staging environment first.
Java requirement
Use Java 21 or newer. If the console reports an unsupported class-version error, the server is running an older JVM even if the control panel displays a newer Java option elsewhere.
Confirm the runtime used by the actual server process, not only the Java version installed on the machine.
Code:
java -versionRequired ShyamDuels dependencies
All four dependencies below are hard requirements:
- FastAsyncWorldEdit 2.x: schematic capture and arena restoration.
- LuckPerms 5.x: permission tiers, administrative access and configurable feature limits.
- PlaceholderAPI 2.11+: dynamic scoreboard and integration placeholders.
- PacketEvents 2.x: packet-driven displays, tab features, nametags and client-side borders.
If one is absent, ShyamDuels intentionally refuses to enable rather than starting with incomplete match behavior.
RAM planning
There is no universal RAM number for every practice server. Memory usage depends on:
- Concurrent players
- Loaded worlds and arena clones
- View and simulation distance
- The number of plugins
- Database caches
- Map size and entity count
- Operating-system overhead
The premade ShyamDuels setup recommends at least 16 GB because it represents a complete server stack rather than only one plugin. Do not interpret that as the core plugin consuming 16 GB by itself.
Leave memory for the operating system and hosting panel. Allocating every available gigabyte to Java can cause the machine to swap or terminate background services.
CPU and tick performance
Minecraft still depends heavily on main-thread performance. Prefer a modern CPU with strong per-core speed over an old many-core processor marketed only by total core count.
Monitor tick duration under real combat. Crystal explosions, projectiles, block changes, chunk loading and arena resets produce workloads that an idle lobby test will not reveal.
Storage
Use SSD or NVMe storage. Arena cloning and schematic restoration create disk activity, and slow storage can lengthen startup or reset operations.
Plan space for:
- Base worlds and arena clone worlds
- FAWE schematics and history data
- Plugin configurations
- Logs and crash reports
- Database backups
- Daily server backups
SQLite or MySQL?
SQLite is simple and suitable for initial testing or a small single-server deployment. MySQL is preferable when concurrency grows, data must be accessed by multiple services, or local database locking becomes a concern.
The ShyamDuels troubleshooting guidance recommends considering MySQL for servers above roughly 200 concurrent players. That is not a guarantee that every smaller server should use SQLite; operational requirements still matter.
World and arena capacity
Every simultaneous duel needs an eligible arena. If one kit can use only two arenas, the third match must wait even when the server has abundant RAM.
Arena cloning can increase capacity when templates are located in one base world. Keep cloning disabled when arenas intentionally live across different worlds or each copy needs a unique layout.
Network and proxy considerations
For a Velocity or multi-server network, decide where player profiles, punishments, ranks and statistics are authoritative. Use secure forwarding, restrict backend ports and keep database credentials outside public downloads.
Test transfers during active queues and ensure players cannot bypass match cleanup by reconnecting through another backend.
Operational checklist
- Paper-compatible 1.21.x server build
- Java 21 runtime confirmed from the server process
- FAWE, LuckPerms, PlaceholderAPI and PacketEvents enabled
- SSD/NVMe storage with backup capacity
- Enough eligible arenas for expected concurrent matches
- SQLite or MySQL selected intentionally
- Automated off-machine backups
- Staging server for updates
- Full restarts instead of `/reload`
- Monitoring for tick time, memory, database and reset errors
Next steps
Continue with Paper vs Purpur for Practice Servers and the complete Minecraft practice-server build guide. If you want to skip most initial integration work, evaluate the Advance ShyamDuels Setup.
Direct sizing answer and validation method
Quick answer: a Minecraft 1.21 practice server needs Java 21, a compatible Paper-family server, a supported PvP core, its declared dependencies, persistent storage, test arenas and enough single-thread CPU performance for concurrent combat. RAM is a safety budget, not a substitute for CPU profiling or correct plugin behavior.Who this is for
Use this checklist before buying a setup, ordering hosting or migrating an existing practice network. It is most useful when you can reproduce production-like matches on staging.Who should not use a fixed player-capacity promise
Do not size a server from RAM alone or accept a universal players-per-gigabyte claim. Different CPUs, worlds, plugins, entities, view distances and arena reset strategies produce different limits.Measurement methodology
Start with idle baselines, then run one, five and ten simultaneous matches using representative kits. Record MSPT, tick percentiles, CPU saturation, heap after garbage collection, database latency and arena-reset duration. Increase load only after each stage remains stable. Repeat after every major plugin or server update.Common requirement failures
Server starts but matches fail: check required dependencies and version compatibility, not only the final startup line.More RAM does not fix lag: inspect the main thread, packet workload and reset operations with a profiler.
Staging is fast but production is slow: reproduce the proxy, database distance, view settings and real plugin list.
Use ShyamDuels Core for a configurable stack, or the prepared setup when a documented baseline is the faster path.
Last edited: