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, but dormant: it needs one platform-wide Redis/Valkey instance as 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.
Everything else is ready. The control-plane limits that previously prevented a second shard from being provisioned at all have been lifted, a realm's first shard is registered automatically, and shard addresses publish themselves as their servers come online.
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. A realm running without the fabric says so on your dashboard rather than failing quietly.
Servers created from now on can join multi-server without being re-created: ED5 delivers the shard settings to the running server, and they take effect at its next update or after an in-game countdown. They show read-only in Game Server Settings.
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.