Config

Runtime config you tune from the dashboard, grouped by server type. Save once and every server of that type picks it up live, no rebuild and no redeploy.

Config is the network’s runtime knobs: values your servers read at boot and on demand, tuned by an operator from the dashboard rather than baked into a build. Change one and the running fleet picks it up live, so you adjust a lobby’s MOTD or a minigame’s player count without rebuilding a plugin or restarting a box.

The defining choice is the scope. Config is not per server and not a single flat blob for the whole network: it is grouped by server type. Every server of a type shares one config, so you tune the type once and the change fans out to its whole scaleout.

Grouped by server type

A group is a server type - lobby, skywars, bedwars. Whatever value you publish to a group is the config for every server registered under that type, now and for any box that joins later. That matches how a network actually scales: you run many interchangeable skywars servers, and they should all behave the same, so they read the same config.

Editing a group fans out to the whole type, not one machine. There is no per-box override to drift out of sync, and a server that boots an hour later reads the same published value as the rest.

Namespaces

Inside a group, config is split into named namespaces - each one an arbitrary JSON document with its own version. A namespace keeps one concern self-contained (your game’s tunables, a routing table, a feature gate) so editing one never touches another.

{
  "minPlayers": 8,
  "maxPlayers": 16,
  "doubleJump": true,
  "kits": ["soldier", "archer", "tank"]
}

Store whatever shape you want; the hub keeps each namespace as a JSON object. Every namespace carries a version that bumps on each save and an updatedAt, so you can see what changed and when.

Edit from the dashboard

The dashboard’s Config section lists a network’s groups (each with its server count and how many namespaces it has). Open a group to see its namespaces, then edit one as JSON:

• Save overwrites the namespace, bumps its version, and pushes a live reload to every server in the group. The running fleet re-reads without a restart.
• Repush re-publishes the reload signal without changing the document - the fix for a server that restarted and missed the last reload, so you can resync it without a no-op edit.

Because a save fans out to the whole server type, you are tuning a fleet, not a box.

Defaults live in your code

A server declares the namespaces it reads and supplies a default document for each, so the type works out of the box before anyone touches the dashboard. The published value overrides those defaults; clear it and you fall back to the code default. Your build always has a sane baseline, and operators tune from there.

For minigames this is fully typed. Your config class’s field defaults are the namespace defaults, an operator overrides them per server type from the dashboard, and the network hands the resolved object to every instance as ctx.config():

public final class SkyWars extends MatchLifecycle<SkyWarsConfig> {
  @Override public void onStart(MatchContext<SkyWarsConfig> ctx) {
    if (ctx.config().doubleJump) ctx.players().forEach(this::enableDoubleJump);
  }
}

At a glance

Next

• Server registry - the live picture of which servers exist and what type each one is.
• Manifest & config - typed, dashboard-tunable config for minigames, read off the lifecycle context.
• Managed servers - provision the boxes a group’s config fans out to.