GorBot Cluster

RELIABLE INFRASTRUCTURE

Managed Discord nodes, shared state, failover, load sharing, centralized updates, and web-based control built to grow beyond one machine.

GorBot Is Designed to Survive the Loss of a Single Machine

The modern GorBot infrastructure is built around a managed cluster rather than one Discord bot process running on one computer.

Multiple GorBot Discord nodes can share Gateway work, remain ready to take over for one another, use RackNerd SQL as shared authoritative state, receive centralized software updates, participate in rolling maintenance, and report health back to a web-based control plane.

The result is a platform that can continue growing without treating a single Discord node as the permanent center of the system.

RackNerd is the control plane. Managed GorBot nodes are the workers.

The web platform, authoritative state, releases, backups, provisioning, and cluster coordination remain centralized while Discord Gateway work can move between managed nodes.

HOW THE CLUSTER IS ORGANIZED

Different parts of the system have different responsibilities.

RackNerd Control Plane

Hosts the public GorBot website, Web Dashboard, Admin Gateway, authoritative SQL state, cluster control, releases, backups, provisioning, runtime-secret vault, and private tooling.

Managed Discord Nodes

Independent GorBot siblings run the Discord runtime, own assigned Gateway shards, maintain hot standby capability, process supported live-control work, and report health to the control plane.

RunUO Game World

The Gor Ultima RunUO server is part of the same overall ecosystem but is not a GorBot cluster sibling. Its game-side BridgeOnly role remains separate from the managed Discord node fleet.

HIGH AVAILABILITY

The platform is designed so one node can fail without becoming the failure of the entire system.

GorBot's managed cluster uses multiple independent Discord nodes so work can be redistributed when one node becomes unavailable.

The current cluster foundation includes:

automatic failover;
weighted load sharing;
gradual rebalancing;
hot standby behavior;
serialized rolling updates;
heartbeat-based health monitoring;
centralized release management;
centralized backups;
managed node provisioning.

The web control plane is intentionally hosted separately from the Discord nodes. That means RackNerd can remain available for administration even if every Discord node is temporarily offline.

DISCORD GATEWAY SHARDS

Discord work is divided so it can be distributed between multiple managed nodes.

The current GorBot cluster operates with 4 Discord Gateway shards.

Those shards can be divided among healthy managed nodes instead of all being forced onto one machine.

With two equally weighted active nodes, the expected distribution is approximately:

100 / 100 → 2 shards / 2 shards

A different weight can intentionally shift more work toward one node:

100 / 50 → approximately 3 shards / 1 shard

These weights are relative rather than absolute capacity percentages.

WEIGHTED LOAD SHARING

Not every node has to carry the same amount of Discord work.

Equal Weight

Nodes with the same weight are candidates for approximately equal shard distribution.

Unequal Weight

A stronger or preferred node can receive a larger relative weight so it normally carries more Gateway work.

Weight 0 Standby

A healthy node can remain fully started with weight 0 and no normal shard assignment, ready to participate when failover or configuration changes require it.

HOT STANDBY

Standby does not have to mean shut down.

A healthy GorBot node can remain fully started even when it currently owns no Discord Gateway shards.

A hot standby node can keep:

its node agent running;
the GorBot process running;
the DiscordBot runtime loaded;
secrets validated;
cluster communication active;
update capability active;
backup and rollback support available.

Only assigned Discord Gateway shards open sessions.

This reduces takeover delay while avoiding duplicate Gateway ownership.

FAILOVER

Reassigning work is only the first half of a successful takeover.

The current cluster uses an Agent heartbeat of approximately 10 seconds and an offline threshold of approximately 45 seconds.

When a node is considered unavailable, the control plane can reassign its Gateway shards to healthy capacity.

However, GorBot does not treat shard ownership alone as proof of successful failover.

A real takeover must also show that the replacement Discord sessions actually connected.

Successful failover should include:

Agent heartbeat present;
GorBot process running;
Discord Gateway READY;
assigned shard count;
connected shard count;
recent per-shard heartbeat acknowledgement;
visible online behavior in the affected Discord communities.

A scheduler saying “this node owns shard 3” is not enough if shard 3 never reaches Discord READY.

HEALTH IS MORE THAN “ONLINE”

Different layers of the node can be healthy or unhealthy independently.

Agent Online The managed node agent is alive and communicating with the control plane.	Bot Running The GorBot child process is running on the node and its runtime has started.	Discord READY The assigned Discord Gateway sessions actually connected and reached a healthy Discord state.
Assigned vs Connected Shards The control plane can compare how many shards a node should own with how many are actually connected.	Heartbeat ACK Per-shard Gateway heartbeat acknowledgement helps show that a connected session is still communicating properly with Discord.

SHARED AUTHORITATIVE STATE

The cluster should share one source of truth instead of becoming several unrelated copies of the bot.

RackNerd SQL is the authoritative shared state for the managed GorBot platform.

This allows important DiscordBot state to remain shared even when requests are processed by different healthy nodes.

The cluster does not depend on one node's local cache being the permanent source of truth.

This shared-state model is especially important for systems such as:

Characters & Profiles;
NPC Database;
community features;
persistent DiscordBot configuration;
other state that must survive node replacement or failover.

Local runtime caching can still be used for performance, while authoritative persistence remains centralized.

HIGH-AVAILABILITY DASHBOARD CONTROL

The Web Dashboard can reach live Discord runtime functions without depending on one fixed machine.

GorBot uses an outbound managed relay model for live dashboard control.

Healthy shard-owning nodes participate in the fast relay pool, while healthy non-owner nodes can remain lower-frequency standby relays.

This allows the web dashboard to perform supported live Discord actions without exposing a public inbound management port on every GorBot machine.

The scalable relay model distinguishes:

Dashboard Relay Ready — active fast relay;
Dashboard Relay Standby — healthy scalable standby;
Waiting / Recovery — relay state that actually needs recovery.

A standby node can be promoted to the fast relay tier when it receives Discord shards.

CENTRALIZED UPDATES

A cluster is easier to maintain when nodes do not have to be updated one machine at a time by hand.

Managed Agent Updates

The node-management runtime can be updated centrally. Version-aware deployment skips matching versions unless a reinstall is intentionally requested.

NodeApp Updates

Approved GorBot NodeApp releases can be uploaded centrally and rolled through managed nodes in a controlled sequence.

Agent and NodeApp versions are separate component streams.

Updating the managed node runtime does not automatically mean the DiscordBot application itself changed, and a NodeApp release does not require changing the RunUO game-side BridgeOnly installation.

SERIALIZED ROLLING MAINTENANCE

Update one managed node while healthy capacity continues carrying the service.

GorBot's managed update system performs serialized fleet updates rather than intentionally restarting every node at the same time.

A controlled rolling update can:

select one node;
drain or prepare it as required;
apply the update;
verify that it returns;
continue to the next managed node.

The system is also designed to refuse unsafe rolling-update behavior when sufficient redundancy is not available.

BACKUPS AND ROLLBACK

Reliability includes recovering from a bad update, not only surviving a failed machine.

The managed platform includes centralized backup and rollback support.

The current operating policy includes scheduled backups and retained rollback history so a deployment problem does not automatically become permanent.

Release retention and backup retention are intentionally managed separately, giving administrators both software rollback options and node-level recovery history.

GENERATED MANAGED NODES

Adding capacity should become a repeatable deployment process rather than a custom installation project every time.

The Admin Gateway can generate managed GorBot node packages for supported deployment modes.

The generated-node model is designed around a near-turnkey process:

generate a node;
download the package;
extract it;
start it;
allow the node to enroll and retrieve its approved runtime configuration;
verify Agent, Bot, Relay, and Discord health.

Supported deployment work has included:

Windows bare metal;
Ubuntu/Linux bare metal;
Docker.

A generated node uses its own managed credential and should run only one execution mode at a time.

SECURE PROVISIONING AND CONTROL

Infrastructure automation should not require placing long-lived secrets inside public downloads.

Managed nodes enroll through the cluster and retrieve the runtime information they require through authenticated provisioning paths.

Private tooling and runtime secrets remain protected by the control plane rather than being treated as public website assets.

The generated-node design avoids embedding long-lived secrets inside reusable runtime images.

The modern dashboard-control model also uses outbound authenticated relay communication so managed nodes do not need a publicly exposed inbound management port for normal dashboard control.

THE WEB PLATFORM IS NOT THE DISCORD NODE

The management plane should remain reachable even during Discord-node outages.

One of the most important design choices in GorBot is keeping RackNerd's control plane separate from the managed Discord-node fleet.

If a Discord node is offline, the Admin Gateway can still report the failure.

If multiple Discord nodes are offline, the control plane can still retain shared state, releases, backups, diagnostics, provisioning, and management information.

Even if every Discord node were temporarily unavailable, RackNerd is intended to remain the place from which the platform can be inspected and recovered.

DRAIN, REMOVE, AND REPLACE

A reliable cluster also needs a safe way to retire machines.

A managed node should normally be drained before removal.

The intended retirement process is:

drain the node;
wait for assigned shards to reach zero;
verify replacement shards are actually connected and READY elsewhere;
stop the retiring node if it is being physically removed;
revoke its credentials;
remove the node from the control plane;
generate a clean replacement when needed;
restore the desired weight after qualification.

This prevents administrative cleanup from being mistaken for a successful service handoff.

DESIGNED TO SCALE BEYOND TWO NODES

The current fleet may be small, but the control model is designed with larger fleets in mind.

GorBot's relay and cluster behavior has been designed so adding more standby capacity does not require every node to behave like an active Discord shard owner.

Fast relay work is concentrated on the nodes that need it, while healthy non-owner capacity can remain in a lower-frequency standby tier until promoted.

This helps the architecture remain practical if the managed fleet grows from a small qualification pair into a much larger collection of Windows, Linux, or containerized nodes.

INFRASTRUCTURE IN THE GOR ULTIMA ECOSYSTEM

One project, with clear technical boundaries between the game world and the managed Discord fleet.

Gor Ultima and GorBot are part of the same overall project and ecosystem.

The RunUO server provides the persistent game world.

GorBot's managed infrastructure provides the Discord cluster, web dashboard, shared state, automation, roleplay profiles, NPC systems, administration, and high-availability services around that community.

The RunUO server is not a GorBot Discord sibling and should not be treated as one merely because game-side integration exists.

COMMON QUESTIONS

A support-ready starting point for understanding the GorBot cluster.

What happens if one GorBot node goes offline? After the node is considered offline, healthy capacity can be assigned its Gateway shards. The takeover is only considered successful when those replacement shards actually connect to Discord and reach READY.	Does every node need the same weight? No. Weights are relative and can be used to prefer one node, balance two nodes equally, or keep a node at weight 0 as hot standby.
Does “Online” mean Discord is healthy? Not by itself. Agent heartbeat, bot process state, Discord READY, connected shard count, and Gateway heartbeat acknowledgements all matter.	Can the dashboard remain available if the Discord nodes fail? Yes. RackNerd is intentionally the independent web/control plane and is designed to remain available even if the managed Discord fleet is temporarily offline.
Is the RunUO server one of the GorBot nodes? No. The game server is part of the same Gor Ultima ecosystem, but the RunUO server itself is not a managed GorBot Discord sibling.	Can updates be applied centrally? Yes. Managed Agent and NodeApp updates can be coordinated centrally and applied through serialized rolling deployment.

A community platform should be able to outlive the machine that happens to be running it today.

Managed nodes. Shared state. Hot standby. Failover. Weighted load. Central updates. Backups. Web control.

GorBot's cluster foundation is built so the platform can grow, recover, and be maintained without depending on one permanent Discord machine.