Paragon

Competitive PvP needs isolated matches. A duel should not share a world with a lobby full of idle players, and a ranked queue needs somewhere to put people the moment it finds a match. That shape is standard on Java. On Bedrock it is not, because there is no equivalent of the proxy layer that makes those networks routine.

Paragon builds it anyway: several Bedrock Dedicated Server instances behind a custom proxy, with matchmaking, ranked progression and player data living outside any single server.

One server running every duel couples every match to every other match. A single laggy fight degrades all of them, arenas need manual resets, and there is no way past one machine.

Splitting into instances fixes that and creates two harder problems. Something has to own the player connection and move it between servers. And player identity, meaning rating, stats and party membership, has to stop living in one server's memory.

• Proxy architecture: holding the client connection and pointing it at a different backend.
• Match lifecycle: allocating an instance and arena, running the match, resolving it, returning players to the lobby.
• Persistence: rating, stats and profiles in MariaDB so they survive transfers and restarts.
• Endstone plugins in Python for server-side behaviour beyond the Script API.
• Custom UI for queues, profiles and match flow inside Bedrock's UI constraints.
• Tooling for queue depth, instance health and match history.

Paragon is the part of my work that is not addon scripting. It is server infrastructure, networking and backend engineering with Minecraft at the edge of it.

Marketplace and server content increasingly needs persistent player data, external services, and systems too big for one behaviour pack. This is where that experience comes from.