Split one world across several servers when it outgrows a single machine.
Multi-Server & Sharding
One game server handles a real player population comfortably. When a world outgrows a single machine, a realm can run across several shards — separate server processes that behave, to players, like one world.
What Sharding Gives You
| Capability | Behavior |
|---|---|
| Zone assignment | Each zone is assigned to a shard; heavy zones get their own machine |
| Zone handoff | Crossing into a zone on another shard hands the player over — no relog |
| Cross-shard presence | Friends lists and online status span the realm |
| Cross-shard chat | Global, guild, alliance and whisper reach players on other shards |
| Cross-shard guilds | Guild membership and state are realm-wide |
| Login queue | Overflow players queue rather than being refused |
| Failure recovery | A shard that dies has its zones reassigned |
| Drain-roll deploys | Shards drain and roll one at a time, so the realm stays up through a deploy |
| Rebalance & autoscale | Zone assignment rebalances by load, and shard count can scale with demand |
Limits & Entitlement
- Multi-shard realms (more than one shard) are Enterprise-only — every other tier is capped server-side at 1 shard, regardless of what any client asks for
- A realm is hard-capped at 8 shards, Enterprise and admin included
- Autoscaling shards is consent-gated and billed at machine cost plus a small monthly fee — you opt in before anything provisions
Current Status
The sharding stack is built and deployed, but dormant: it needs a platform-wide Redis/Valkey instance for its coordination fabric, and that has not been provisioned yet. Until it is, every project runs as a healthy single server and nothing about your world changes.
Order matters when it is switched on — Redis and its environment variable must exist before any shard is provisioned, because a managed server bakes its environment at provisioning time and a shard created without the coordination fabric has to be re-provisioned.
> Sharding is about population, not reliability. A single managed server already restarts, persists and rolls safely on its own — reach for shards when concurrency, not uptime, is the constraint.