Blog

Minecraft Java Server Setup and a Curated Plugin List

May 12, 2025 6 min read
Game ServersMinecraftLinux
Running a small self-hosted Minecraft Java server with Paper and a few curated plugins

A handful of friends wanted a long-running world — five or six of us — and the requirements were plain: stable uptime, few lag spikes, and the ability to roll back when something breaks. Below I've written it as an ops handbook — steps you can actually tick off, light on sentiment. You can print the whole thing as a checklist and work from the first item to the last before opening the server.

I used to open servers from memory: which day I changed the render distance, when I added a plugin — all of it lived in group-chat logs. One bad upgrade twisted the claims plugin into a version knot and cost me half a day of rollbacks. Since then, every step that can be checked off gets checked off, and only then do I hit start. It looks fussy; what it saves is a whole evening of apologies.

A small server has no dedicated ops person — the owner usually has a day job. The point of a handbook is to turn "only I understand this" into "follow the steps and nothing explodes". When a friend takes over a maintenance window, being readable beats being clever.

Manual 0: environment checks before opening

  • Host memory headroom: beyond the Xmx you plan to give the JVM, leave the system at least 1–2G
  • Disk: put the world directory on SSD; with a spinning disk, accept the risk of save lag
  • Java version matches what Paper requires (check the current Paper docs)
  • Dedicated system user mc — don't run long-term as root
  • Firewall/security group: only expose the people and ports you need (default 25565)
  • Backup destination directory already exists: /var/backups/mc/
  • Maintenance windows and "who has the power to stop the server" are clear in the group

CPU single-core performance matters a lot for MC. An old many-core CPU doesn't always beat a new N100 for a game server. Test before you promise "render distance 12". Screenshot the memory and disk headroom before opening, so you're not discovering a full root partition when the group asks "why can't I join?".

If it shares a box with your NAS or monitoring, draw the lines in your notes first: how much memory MC may eat at most, and backup windows that avoid the evening peak. If the resource budget isn't settled, every later optimization is patching holes on a sinking ship.

Manual 1: directory and core install

Pick Paper as the core. The vanilla server.jar runs, but the plugin ecosystem and performance docs are more mature on Paper. Downstream forks like Purpur work too; I play it simple and pin a stable Paper build instead of chasing the latest every day. Note the build number when you first download it — otherwise you won't know which version you're jumping from at upgrade time.

/opt/minecraft/
  paper.jar
  start.sh
  server.properties
  eula.txt
  plugins/
  world/
  world_nether/
  world_the_end/

Checklist:

  • eula=true accepted, as required
  • server.properties: whitelist on, online-mode per your account policy
  • Render distance 8–10 (priority on small machines); don't crank simulation distance blindly
  • Difficulty, PvP, spawn protection pinned per group rules, so day one doesn't start with an argument
sudo useradd -r -m -d /opt/minecraft -s /bin/bash mc
# chown the files to mc:mc

Manual 2: start script and systemd

start.sh:

#!/bin/bash
cd /opt/minecraft
exec java -Xms2G -Xmx2G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -jar paper.jar --nogui
  • Xms equals Xmx to avoid runtime resize jitter (common on small servers)
  • Xmx stays under the machine's headroom; a 4G VPS handing 3G to MC tends to swap and lag more
  • chmod +x start.sh, owner mc
  • Run ./start.sh once manually as the mc user and confirm you reach the main world before handing it to systemd

Aikar's longer flag sets are common on big servers; for a five-or-six-player box, first get Xmx and G1 stable. Copy-pasting a whole parameter block from a forum without understanding it makes rollbacks harder when something breaks.

systemd:

[Unit]
Description=Minecraft Paper
After=network.target

[Service]
User=mc
WorkingDirectory=/opt/minecraft
ExecStart=/opt/minecraft/start.sh
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target
  • systemctl enable --now minecraft (unit name per your file)
  • journalctl -u minecraft -f shows startup completing
  • Don't run production under screen; send commands via rcon or Paper's console channel so scripts can drive it

Manual 3: a curated plugin list (less is more)

Before installing:

  • Plugin version matches the game version
  • Add one at a time; check the log for errors before the next

Categories I usually run:

Category Rule of thumb Check
Permissions LuckPerms — one permission source [ ]
Claims One actively maintained plugin, not three fighting each other [ ]
Anti-cheat Moderate — flagging a friend hurts more than cheaters do [ ]
Backup Plugin or system cron, pick one — don't duplicate [ ]

Plugin upgrade order is fixed: stop the server → back up the world → swap the Paper build → start and watch the log → then add or update plugins. That "must-install modpack" a friend drops in goes to a test directory first, not straight into production plugins/. A small server's goodwill runs on stability, not feature stacking.

Manual 4: daily start/stop and player changes

Day-to-day running eats more time than the original setup. Whoever wants a mod at midnight, whoever can't join — they all find you. Turn starting and stopping into fixed actions and cut down on improvisation.

Start:

sudo systemctl start minecraft
# wait for "Done" in the log

Stop:

  • Announce in the group at least fifteen minutes ahead
  • Via rcon: save-all then stop, or systemctl stop and confirm the process exited
  • Confirm no leftover java process holds the world lock
  • If maintenance runs over half an hour, post the expected recovery time in the group

Whitelist:

  • Check new player IDs against the premium/offline policy
  • whitelist add, then whitelist reload
  • Write permission-group changes in the notes: who's admin, who can teleport
  • Strip high permissions from friends who leave, so a lost account isn't a lingering risk

After starting, walk the world yourself once: spawn, storage, the usual claim teleports. A green log doesn't mean a good experience — problems stuck at the loading screen sometimes only show up client-side.

Manual 5: when it lags, tick these

In order, no superstition:

  1. Player count and time of day: was there a burst of exploration loading?
  2. spark or timings: which is high — entities, chunks, GC?
  3. Did someone crank render or simulation distance?
  4. Redstone machines or mob farms exploding in population?
  5. Is disk I/O choking world saves (iowait, spinning disks)?
  6. Is memory starting to swap (free -h)?

Temporary triage: lower render distance, clear entities, restart (save-all first). Long-term fixes: limit mob spawns, tear down machines, add RAM or swap the disk. Write each lag incident as one line in ~/notes/mc-lag.md: time, online count, spark screenshot path, action taken. After three entries the pattern surfaces by itself — more useful than "it lags again" in the group chat.

Manual 6: backup checklist

The world is worth more than the plugins. Plugins reinstall; three years of claims and builds don't.

# conceptual flow
rcon save-all
rcon save-off
rsync -a /opt/minecraft/world* /var/backups/mc/$(date +%F)/
rcon save-on
  • Keep the last 7 days of daily backups
  • Tag important milestones (big build finished, before a version upgrade) manually
  • Drop a second compressed copy off-site
  • Copying only plugins without the world = no backup at all
  • Once a quarter, do a "spin up a test server from the backup directory" drill

Manual 7: networking and version upgrades

Networking:

  • If exposed publicly, plan for DDoS and enforce premium accounts; whitelist the port if you can
  • If it's LAN/WireGuard-only, block port 25565 from the internet in the firewall
  • If you use a domain SRV record or reverse proxy, test that the client actually joins through it

Version upgrade checklist:

  • Full backup of world and config
  • Read the Paper and plugin changelogs
  • Run a test server first
  • Post a maintenance notice in the group
  • After upgrading, watch TPS and player feedback
  • Know the rollback path if something breaks

Manual 8: what "in service" means

Only when all of these hold is it "we can play again tonight":

  • systemd pulls it back up automatically
  • Whitelist and permissions match the group rules
  • A backup from the last 24h exists and is a sane size
  • Nobody is persistently complaining about TPS
  • You know the three routines: stop, roll back, upgrade

A small server lives on stability, rollback-ability, and plugin restraint. A checklist beats memory; ticking before playing is cheaper than apologizing after a crash. The handbook gets dirty and gets edited — after every incident, add one more checkbox item. That's where this checklist actually earns its keep.

← Back to Blog