Minecraft Server Admin

Minecraft Server Administration Skill

Scope and Routing Boundaries

Routing Boundaries

• Use when: the task is infrastructure or live operations for Minecraft servers (deployment choice, tuning, backups, proxying, security, incident response).
• Do not use when: the task is writing plugin code (minecraft-plugin-dev) or writing mods/loaders (minecraft-modding, minecraft-multiloader).
• Do not use when: the task is WorldEdit command workflows (minecraft-worldedit-ops) or EssentialsX workflow/policy design (minecraft-essentials-ops).
• Do not use when: the task is datapack/resource-pack authoring (minecraft-datapack, minecraft-resource-pack).

References

• Read references/deployment-checklists.md when the task is an incident, rollout window, proxy change, or recovery drill and you need a compact checklist before acting.

Deployment Decision Matrix

Use this table when choosing a deployment. For an existing server, inspect its stack and version first and preserve them unless migration is requested.

Deployment Type Routing

• Small SMP and most public plugin servers: use Paper baseline first.
• Use Purpur only when you explicitly need Purpur gameplay controls.
• Use Folia only when plugin compatibility has been validated for region-threading.
• Use Velocity when one process is not enough or you need separate backend roles.
• Use Fabric/NeoForge when the requirement is mod-driven, not plugin-driven.

Java versions

• Paper and Purpur: Minecraft 26.1+ requires Java 25; Minecraft 1.21.x uses Java 21. Verify the exact Paper/Purpur build and installed plugins before a version change.
• Current Velocity 4.x requires Java 25. For a legacy proxy, retain the Java version required by that exact proxy release rather than applying the current version by default.

Playbook: Performance Tuning

Step 1: Establish baseline

Collect a baseline before edits. Linux host example:

free -h
top -b -n 1 | head -n 25

Windows PowerShell host example:

Get-CimInstance Win32_OperatingSystem | Select-Object FreePhysicalMemory,TotalVisibleMemorySize
Get-Process java | Sort-Object CPU -Descending | Select-Object -First 5 Id,CPU,WorkingSet,Path

In server console:

tps
mspt
spark healthreport

Record:

• peak player count
• MSPT at idle and at peak activity
• top plugins by CPU from Spark report

Step 2: Profile the real bottleneck

Use Spark instead of guesswork:

spark profiler --timeout 180
spark tps
spark tickmonitor --threshold-tick 50

The 50 ms threshold reports ticks that exceed one normal 20 TPS tick; adjust it only when the incident threshold is intentionally different.

Then identify whether the issue is:

• plugin task load
• entity count / mob farm pressure
• chunk generation / disk I/O
• garbage-collection pauses

Step 3: Apply targeted fixes

Do not tune everything at once. Apply one group at a time.

1. Chunk and simulation pressure:

• lower view-distance and simulation-distance first
• pre-generate worlds for survival-heavy maps

1. Entity pressure:

• adjust despawn ranges and mob-spawn behavior in Paper world config
• cap problematic entities where appropriate

1. Plugin pressure:

• disable or replace top offenders from Spark traces
• reduce async task frequency where plugin settings allow

Step 4: Use stable startup flags

For Java 25 on current Paper/Purpur, start with a simple measured baseline:

java -Xms4G -Xmx4G -jar server.jar --nogui

Increase heap only when profiling and player load justify it. Add collector flags only after validating them against the exact JDK and Paper version.

Step 5: Verify improvements

After each change set:

spark tps
spark healthreport

Keep the change only if MSPT/tick stability improves under representative load.

Playbook: Plugin Operations

Safe plugin change workflow

1. Build a plugin inventory:

• plugin name and version
• required dependencies
• minimum server version

1. Stage updates:

• apply plugin updates in staging first
• run smoke checks: joins, teleports, economy, permissions, saves

1. Production rollout window:

• announce maintenance window
• stop server cleanly
• snapshot plugin jars and config
• deploy update batch

1. Post-rollout verification:

• watch startup logs for API warnings
• run command and permission sanity checks
• track TPS/MSPT for 15-30 minutes

Rollback checklist

• Keep previous plugin directory snapshot.
• If severe regression occurs:
  • stop server
  • restore prior plugin jars/configs
  • start and confirm login/world integrity
• Document failing plugin/version pair for future blocks.

Playbook: Proxy and Forwarding (Velocity)

Velocity baseline

velocity.toml essentials:

bind = "0.0.0.0:25565"
online-mode = true
player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"

Backend server requirements

server.properties on backend:

online-mode=false

Paper backend forwarding support (config/paper-global.yml):

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "paste-the-shared-forwarding-secret-here"

Use the same secret value stored in Velocity's forwarding.secret file; the backend config takes the secret string itself, not a file path.

Keep enforce-secure-profile at the server default unless you are handling a specific legacy-client or incident workaround. It is not part of the baseline Velocity setup. Also confirm settings.bungeecord: false in spigot.yml; do not enable BungeeCord forwarding and Velocity modern forwarding at the same time.

Validation runbook

1. Confirm proxy port is reachable from clients.
2. Confirm backend is firewalled from direct internet access.
3. Join through proxy and verify:

• UUID consistency
• skin/profile forwarding
• plugin permission behavior

Common proxy incidents

• "Invalid player info forwarding":
  • mismatch in forwarding mode or shared secret between Velocity and backend.
• Random auth/session failures:
  • mixed online-mode expectations or direct backend exposure.

Playbook: Backup and Recovery