# Minecraft Server Admin

> Set up, operate, tune, and troubleshoot Minecraft Java 26.x and legacy 1.21.x servers across Paper, Purpur, Folia, Velocity, Fabric, and NeoForge. Use for infrastructure, backups, proxies, and live operations, not plugin or mod development.

- Skill: `gabrielmoreira/minecraft-server-admin` (Agent Skill)
- Install (CLI): `npx skillmds@latest add gabrielmoreira/minecraft-server-admin`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gabrielmoreira/minecraft-server-admin/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: gabrielmoreira (https://skillmd.com/u/gabrielmoreira)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/gabrielmoreira/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`).

## Support Assets

- 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 profile | Recommended stack | Pick this when | Watch-outs |
|---|---|---|---|
| Small SMP on Paper | Paper only | Up to ~30 concurrent players, broad plugin compatibility, low ops overhead | Do not over-tune early; profile before changing many defaults |
| Larger public Paper server | Paper + Spark + stricter plugin/change control | Public server with frequent joins, moderate plugin set, uptime matters | Plugin sprawl is the top TPS risk |
| Velocity-backed network | Velocity + multiple Paper backends | Hub/minigame/factions split across servers, need shared entrypoint | Forwarding/auth mismatches can block joins |
| Purpur gameplay-heavy server | Purpur (optionally behind Velocity) | You want gameplay knobs exposed in config without custom plugin code | Extra toggles increase misconfiguration risk |
| Folia high-concurrency server | Folia + Folia-compatible plugins only | Very high concurrency with region-threading goals | Many plugins are not Folia-safe |
| Fabric/NeoForge mod server | Fabric or NeoForge server build | You require loader mods, custom content, modpack behavior | Bukkit/Paper plugins do not apply |

### 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 and version lanes

- 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
  lane 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
  lane by default.

---

## Playbook: Performance Tuning

### Step 1: Establish baseline

Collect a baseline before edits. Linux host example:

```bash
free -h
top -b -n 1 | head -n 25
```

Windows PowerShell host example:

```powershell
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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```toml
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:

```properties
online-mode=false
```

Paper backend forwarding support (`config/paper-global.yml`):

```yaml
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

### Backup policy template

| Asset | Frequency | Retention | Notes |
|---|---|---|---|
| Every configured world folder | Hourly incremental + daily full | 7 daily, 4 weekly | Include custom and externally stored worlds |
| `plugins/`, `config/`, and root server state | Daily | 14 daily | Required for operational restore |
| Proxy config/secrets | Daily | 30 daily | Store encrypted off-host |
| Container/orchestration files | On change + weekly | 8 weeks | Git-tracked where possible |

### Example backup script (Paper/Purpur)

For a production server, quiesce world writes before copying live world folders.
The example below assumes a maintenance window and a cleanly stopped server. If
you use RCON-based live backups instead, choose a client/secret mechanism that
does not expose the password in command arguments. A safe implementation must
run `save-off`, then `save-all`, copy the data, and guarantee `save-on` cleanup
even when the copy fails. Do not treat a flush or `save-all` alone as a live
backup protocol. Folia disables `save-all`; use a clean stop or a verified
platform snapshot there. Test the restore path before trusting any backup.

For Fabric or NeoForge recovery, additionally inventory `mods/` and record the
exact loader launch state: Minecraft and loader versions, Java version, launch
command and arguments, launcher or installer artifacts, and any version or
library manifests used by that deployment. Restore those matching components
with the configured world folders; this Paper/Purpur example does not capture
them for you.

Supply the complete world-folder list as arguments, relative to `SERVER_ROOT`,
after checking `level-name` and any multi-world plugin configuration. Back up
worlds stored outside that root separately; do not infer coverage from `world*`.

```bash
#!/usr/bin/env bash
set -euo pipefail

if [[ "${SERVER_STOPPED_CONFIRMED:-}" != "1" ]]; then
  echo "Set SERVER_STOPPED_CONFIRMED=1 only after stopping the server cleanly." >&2
  exit 1
fi

DATE="$(date +%Y-%m-%d_%H-%M-%S)"
BACKUP_ROOT="/backups/minecraft"
SERVER_ROOT="/srv/minecraft"
DEST="${BACKUP_ROOT}/${DATE}"

if [[ "$#" -eq 0 ]]; then
  echo "Usage: backup.sh <world-folder> [additional-world-folders...]" >&2
  exit 1
fi
for world_dir in "$@"; do
  if [[ ! -d "$SERVER_ROOT/$world_dir" ]]; then
    echo "Missing configured world folder: $world_dir" >&2
    exit 1
  fi
done

mkdir -p "$DEST"

tar -czf "${DEST}/worlds.tar.gz" -C "$SERVER_ROOT" -- "$@"

state_items=()
for item in \
  plugins config server.properties bukkit.yml spigot.yml paper-global.yml \
  paper-world-defaults.yml permissions.yml ops.json whitelist.json \
  banned-players.json banned-ips.json; do
  [[ -e "$SERVER_ROOT/$item" ]] && state_items+=("$item")
done

if [[ "${#state_items[@]}" -gt 0 ]]; then
  tar -czf "${DEST}/server-state.tar.gz" -C "$SERVER_ROOT" "${state_items[@]}"
fi
```

### Recovery drill (must be tested)

1. Stop server.
2. Restore selected backup to staging directory.
3. Validate ownership/permissions.
4. Start server in maintenance mode.
5. Verify:
- world spawn loads
- player data is readable
- key plugins initialize
1. Reopen to players.

Define targets:
- `RPO` (acceptable data loss window)
- `RTO` (acceptable restore duration)

---

## Playbook: Live Troubleshooting

### Incident triage flow

1. Classify incident:
- crash on startup
- severe lag / TPS collapse
- join/auth failures
- memory/disk pressure

1. Capture evidence first. Linux host example:

```bash
df -h
free -h
```

Windows PowerShell host example:

```powershell
Get-PSDrive -PSProvider FileSystem
Get-CimInstance Win32_OperatingSystem | Select-Object FreePhysicalMemory,TotalVisibleMemorySize
```

From server/proxy console:

```bash
spark tps
spark healthreport
```

1. Stabilize:
- stop risky rollout changes
- disable newest suspect plugin first
- reduce player impact (maintenance mode, temporary queue, restricted worlds)

1. Recover and document:
- apply rollback or hotfix
- document root cause and permanent preventive action

### Fast symptom map

| Symptom | First checks | Typical root cause |
|---|---|---|
| Startup crash after plugin update | latest logs, plugin dependency chain | incompatible plugin/API mismatch |
| High MSPT only at peak hours | Spark profiler, entity/chunk stats | mob farms, heavy scheduled tasks, chunk I/O |
| Players cannot join via proxy | forwarding mode + secret + backend exposure | Velocity/backend config mismatch |
| Periodic hard lag spikes | GC pauses + autosave + backup overlap | memory pressure, backup I/O contention |

---

## Operational Config Reference

### `server.properties` high-impact keys

```properties
max-players=100
view-distance=10
simulation-distance=8
sync-chunk-writes=true
max-tick-time=60000
enable-rcon=false
```

### `bukkit.yml` and `spigot.yml`

Use Spigot/Bukkit docs as authoritative for version-specific defaults and side effects.
Tune conservatively and re-measure after every change set.

### Paper config files

- `config/paper-global.yml`
- `config/paper-world-defaults.yml`

Adjust these only after profiling identifies an actionable bottleneck.

---

## Deployment Patterns

### Docker Compose (Paper)

```yaml
services:
  paper:
    image: itzg/minecraft-server:java25
    container_name: mc-paper
    environment:
      EULA: "TRUE"
      TYPE: "PAPER"
      VERSION: "26.2"
      MEMORY: "10G"
    ports:
      - "25565:25565"
    volumes:
      - ./data:/data
    restart: unless-stopped
```

This Docker example targets current Paper 26.2 and Java 25. Re-check plugin
compatibility and take a restorable backup before changing an existing server's
Minecraft or Java line.

### Pterodactyl/Wings notes

- Keep startup command and memory allocations consistent with tested JVM flags.
- Pin panel and Wings versions to supported combinations.
- Validate backup mount and restore workflow before production.

---

## Security Hardening Checklist

- Keep `online-mode=true` unless proxy forwarding requires backend `online-mode=false`.
- Never expose backend Paper ports directly when using Velocity.
- Restrict RCON and panel/admin surfaces by firewall/IP allowlist.
- Rotate secrets (`forwarding.secret`, panel credentials, backup credentials).
- Keep plugin sources trusted; verify checksum/release source before install.
- Maintain off-host encrypted backups.
- Keep Java runtime and host OS patched.

---

## References

### Paper (primary)

- https://docs.papermc.io/paper/
- https://docs.papermc.io/paper/getting-started/
- https://docs.papermc.io/paper/admin
- https://docs.papermc.io/paper/profiling/

### Spigot/Bukkit (primary config reference)

- https://www.spigotmc.org/wiki/spigot-configuration/
- https://www.spigotmc.org/wiki/bukkit-configuration/
- https://www.spigotmc.org/wiki/start-up-parameters/

### Proxy and ecosystem docs

- https://docs.papermc.io/velocity/
- https://docs.papermc.io/velocity/getting-started/
- https://docs.papermc.io/folia/faq/
- https://spark.lucko.me/docs
- https://spark.lucko.me/docs/Command-Usage
- https://github.com/itzg/docker-mc-backup
- https://geysermc.org/wiki/geyser/
- https://pterodactyl.io/project/introduction.html

