game infrastructure · 2026
Minecraft server stack
Running a game server that stays consistent when the owner is not watching it.
- Role
- Build and operations
- Status
- active
- Stack
- Paper 1.21ProtocolLibDeluxeMenusFancyNpcsDecentHologramsSNBT
A server plugin is not finished when it works once. It is finished when it still behaves correctly after a reload, a restart, and a player using it in a way nobody predicted.
What is on the server
A Paper 1.21 network with custom plugins built on ProtocolLib, where the interaction work — packet-level NPCs, shops, and holograms — lives. Shops are NPC-driven through DeluxeMenus so players never leave the world to trade. Holograms display live server state rather than a value that was set once and quietly went stale.
Items are handed out as SNBT-formatted books, which means a crafted item can carry its own lore, enchantments, and metadata without a plugin having to reconstruct it from a database row.
The engineering problem
Everything that touches packets has to survive a ProtocolLib version bump without taking the server with it. That means wrapping every packet handler in a guard that fails closed, keeping state in a single authoritative source that survives reload, and testing behaviour under load rather than assuming it holds. A crash in a packet handler takes the whole server with it, so the handler is treated as the least trustworthy code in the system.
What I would change
I would move configuration out of code and into validated files that fail loudly on load if a value is wrong. Half the debugging time in this stack went to a typo in a hardcoded constant, and that is entirely avoidable.