ServerFabric

What is ServerFabric?

ServerFabric is a lightweight multi-part system for managing Minecraft server instances across one or more hosts.

It is built around three focused components:

• ServerFabric-Host — standalone Java application that creates, starts, stops, restarts, kills, and manages server instances on a machine
• ServerFabric-Proxy — proxy plugin that connects to one or more hosts, registers/routs instances, and keeps the network in sync
• ServerFabric-Client — Paper/Spigot/Purpur plugin with an in-game GUI for viewing and controlling instances

There is also a public developer module:

• SFabricAPI — proxy-side API for plugins that want to interact with ServerFabric without touching raw HTTP or internal messaging

The goal is simple: keep it practical, understandable, and easy to extend while still being useful on real multi-host networks.


Main Features

• Multi-host support
• Proxy-safe restarts (restarting the proxy does not restart running instances)
• Persistent instance metadata on the host
• Host reboot recovery for instances marked to auto-start
• Template-based instance creation
• Version-aware server creation
• Build cache for generated jars
• Runtime stats support
• In-game GUI for managing instances
• Developer API for external plugins

ServerFabric-Host

The host is the part that does the actual work.

• Create / start / stop / restart / kill / delete instances
• Send console commands to running instances
• Track runtime information and recent logs
• Provide stats such as uptime, PID, RAM, VMEM, and disk usage
• Create default folders/config on first boot
• Build server jars from templates when needed
• Cache build output so the same version does not need to be rebuilt repeatedly

Templates & Version-Aware Creation

ServerFabric supports template-driven creation using a template.json.

Templates can define:

• default Minecraft/server version
• build command
• jar name
• readiness logic
• JVM arguments
• persistent data behavior

This means you do not need a separate template folder for every single server version.

A template can define a default version, and creation can later override it when needed.


In-Game GUI

The client plugin adds an in-game GUI for managing instances.

• View instances and their states
• Join servers from the GUI
• Start / stop / restart / kill instances
• Send commands to server consoles
• Browse templates
• View per-instance details and runtime stats

Developer API (SFabricAPI)

ServerFabric also includes a public API module for developers.

Plugins can use SFabricAPI to:

• query hosts
• query instances
• query templates
• query instance stats
• create instances
• start / stop / restart / kill instances
• send commands

This is meant to be the supported integration layer instead of calling host HTTP endpoints directly.


Architecture


The host owns the processes and filesystem.

The proxy acts as the controller/router.

This keeps the proxy and host separated cleanly, and allows the proxy to restart without taking down the running servers.


Current State

ServerFabric is already usable and actively being expanded.

Current work is focused on:

• stable host behavior
• version-aware templates
• build caching
• runtime stats
• cleaner developer API
• continued proxy/client polish

Requirements

• Java 21 for current ServerFabric builds
• BungeeCord / Waterfall / compatible proxy
• Paper / Spigot / Purpur for the client plugin

Included Components
include:

• ServerFabricHost.jar
• ServerFabricProxy.jar
• ServerFabricClient.jar
• SFabricAPI / serverfabricapi for developers

Why I made it

ServerFabric was inspired by the general idea behind SubServers, but is being built as its own system with a focus on:

• clear separation of responsibility
• multi-host orchestration
• proxy-safe routing
• template-driven creation
• developer-friendly extensibility

Screenshots

• Instances overview
  
• Instance details view
  
• Host startup and managed instance launch
• Template-driven creation and build flow
• SFabricAPI example usage

Planned / Ongoing Improvements

• more API coverage and events
• more template/build flexibility
• continued GUI polish
• better web-based administration later on
• additional host/network visibility

Feedback is welcome.
If you test it, integrate it, or break it in interesting ways, let me know.