GorBot Cluster

RELIABLE INFRASTRUCTURE

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

Built Beyond a Single Discord Machine

Modern GorBot infrastructure is designed around a managed cluster rather than one Discord bot process permanently tied to one computer.

Multiple GorBot Discord nodes can share Gateway work, remain ready to take over for one another, use shared authoritative state, receive centrally managed software releases, and continue operating as one coordinated platform.

This architecture allows GorBot to grow without making one machine the permanent center of the Discord service.

The goal is continuity, not just duplication.

Running multiple nodes only matters if they can share state, divide work, detect failure, and take over real Discord connections when another node becomes unavailable.

HOW THE PLATFORM IS ORGANIZED

The game world, Discord nodes, and shared web infrastructure serve different technical roles.

Shared Web Infrastructure RackNerd hosts the public GorBot web services, shared SQL state, releases, backups, provisioning services, and other central infrastructure that should remain independent of any one Discord node.

Managed Discord Nodes Independent GorBot siblings run the Discord runtime, own assigned Gateway shards, maintain hot-standby capability, and report health back to the shared platform.

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

HIGH AVAILABILITY

One failed node should not automatically mean GorBot is offline.

GorBot uses multiple independent Discord nodes so active work can be redistributed when one node becomes unavailable.

The current high-availability model includes:

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

The shared web infrastructure is intentionally separate from the Discord nodes so the broader platform does not disappear simply because one Discord machine fails.

DISCORD GATEWAY SHARDS

Discord work can be divided and distributed between healthy managed nodes.

The current GorBot cluster operates with 4 Discord Gateway shards.

Those shards can be distributed between healthy nodes instead of all being forced onto one machine.

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

100 / 100 → 2 shards / 2 shards

If one node is given a lower relative weight:

100 / 50 → approximately 3 shards / 1 shard

Weights influence relative workload and are not literal CPU percentages.

WEIGHTED LOAD SHARING

Different machines can carry different amounts of Discord work.

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

Unequal Weight A preferred or more capable node can receive a higher relative weight so it normally carries more Gateway work.

Weight 0 Standby A healthy node can remain fully started with no normal shard assignment while staying ready to participate when failover or configuration changes require it.

HOT STANDBY

Standby capacity can remain ready without opening duplicate Discord sessions.

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;
• runtime configuration validated;
• cluster communication active;
• update capability available.

Only assigned Discord Gateway shards open active Discord sessions.

This makes standby capacity ready for takeover without creating duplicate shard ownership.

FAILOVER

Moving an assignment is not enough — the replacement connection has to work.

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, its Gateway shards can be reassigned to healthy capacity.

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

A successful takeover 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 shard being assigned to a node is not the same as that shard actually being connected to Discord.

MULTI-LAYER HEALTH

A reliable node must be healthy at more than one level.

Agent Online The managed node agent is alive and still communicating with the shared platform.	Bot Running The GorBot process is running and its runtime has started successfully.	Discord READY Assigned Gateway sessions have actually connected and reached a usable Discord state.
Assigned vs Connected Shards The system can distinguish how many shards a node should own from how many are actually connected.	Heartbeat ACK Per-shard heartbeat acknowledgements help confirm that connected Gateway sessions remain responsive.

SHARED AUTHORITATIVE STATE

Multiple nodes should still behave like one service.

RackNerd SQL acts as the authoritative shared state for the managed GorBot platform.

This allows important persistent data to remain consistent even when requests are handled by different healthy nodes.

Shared state is especially important for systems such as:

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

Local runtime caching can still improve performance, but authoritative persistence remains centralized.

WEB-BASED CONTROL

The Web Dashboard can work with live GorBot services without depending permanently on one fixed Discord machine.

Some web-based GorBot features need to communicate with the live Discord runtime.

The modern infrastructure supports this through managed outbound communication between healthy Discord nodes and the shared web platform.

This allows supported live web actions to continue using healthy cluster capacity rather than being permanently tied to a single node.

The design also avoids requiring every managed Discord node to expose a public inbound management service for normal web control.

CENTRALIZED UPDATES

Managed nodes can receive coordinated software updates without rebuilding every machine manually.

Managed Agent Updates The node-management runtime can be updated centrally and independently from the Discord application itself.

NodeApp Updates Approved GorBot NodeApp releases can be distributed to managed nodes as their own application release stream.

Agent and NodeApp versions are separate components.

Updating one does not automatically imply that the other changed, and standalone GorBot node updates do not automatically require updating the RunUO game-side BridgeOnly installation.

ROLLING MAINTENANCE

Update nodes in sequence while healthy capacity continues carrying service.

GorBot's managed update model supports serialized rolling deployment rather than intentionally restarting every node at once.

A controlled update can:

• prepare one node;
• apply the update;
• verify that it returns;
• continue to the next node.

This helps reduce service interruption while allowing the fleet to move forward together.

BACKUPS AND ROLLBACK

Reliability also means being able to recover from a bad update.

The managed platform includes centralized backup and rollback support.

Scheduled backups and retained release history provide recovery options when an update or local node problem causes unexpected behavior.

This complements failover:

• failover handles loss of active service capacity;
• rollback handles bad software or broken deployment state.

MANAGED NODE PROVISIONING

Adding capacity should be repeatable instead of becoming a custom installation project every time.

GorBot supports generated managed-node packages intended to simplify deployment.

The design goal is a near-turnkey process:

1. generate a node package;
2. download it;
3. extract it;
4. start it;
5. allow the node to enroll and retrieve its approved runtime configuration;
6. verify Agent, Bot, and Discord health.

Supported deployment work has included:

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

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

SECURE PROVISIONING AND RUNTIME CONFIGURATION

Managed deployment should not require placing long-lived secrets inside reusable downloads or runtime images.

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

Private tooling and runtime secrets remain protected rather than being treated as public web assets.

The generated-node model is designed so reusable runtime packages and container images do not need to contain long-lived production secrets.

THE SHARED WEB PLATFORM IS INDEPENDENT OF THE DISCORD NODES

The web layer should remain available even during Discord-node outages.

One of the most important architectural choices in GorBot is keeping shared web services separate from the managed Discord-node fleet.

If one Discord node fails, the shared platform remains available.

If several Discord nodes fail, shared SQL state, releases, backups, and web services remain independent of those individual machines.

This keeps recovery and continuity from depending on the same node that just failed.

BUILT TO GROW

The infrastructure should remain practical as more managed nodes are added.

The GorBot cluster model is designed so additional managed nodes can add capacity, redundancy, or standby coverage without changing the basic service model.

A larger fleet can include active shard-owning nodes and healthy standby capacity.

This allows the platform to grow from a small number of qualification nodes into a larger mixed fleet of Windows, Linux, or containerized systems while still sharing one authoritative state and one coordinated Discord service.

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 services, shared state, automation, roleplay profiles, NPC systems, and the high-availability services surrounding the community.

The RunUO server itself is not a managed GorBot Discord sibling.

COMMON QUESTIONS

A quick guide to the GorBot cluster model.

What happens if one GorBot node goes 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 balance nodes equally, prefer one node, or keep a node at weight 0 as hot standby.
Does “Online” automatically mean Discord is healthy? No. Agent heartbeat, bot process state, Discord READY, connected shard count, and Gateway heartbeat acknowledgements all matter.	Can the web platform stay available if a Discord node fails? Yes. Shared web services and authoritative state are intentionally hosted independently from any one managed Discord node.
Is the RunUO server one of the GorBot Discord nodes? No. It is part of the same Gor Ultima ecosystem, but the game server itself is not a managed GorBot Discord sibling.	Can GorBot nodes be updated centrally? Yes. Managed Agent and NodeApp releases can be coordinated centrally and rolled through the fleet in sequence.

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 infrastructure is built so the platform can grow, recover, and remain maintainable without depending on one permanent Discord machine.