Dedicated server per match
The classic model: one process per match from your own engine or a dedicated server build, over UDP or TCP. It's allocated when players are matched and torn down when the match ends.
GAME SERVER ORCHESTRATION
Every match gets a home.
ShardNexus runs your authoritative game servers, whether that's a dedicated server per match, many rooms per process or a persistent world. It uses the machines you already have, scales out when a game takes off, and never ends a match to patch a host.
h1 · openbsd · 4 cores62 / 80 rooms
h2 · linux · 4 vCPU41 / 64 rooms
h3 · linux · draining3 matches left
1,344players on one 4 vCPU cloud host, measured on a browser game with 12-player rooms at 30 Hz
2.6×less CPU than one process per match, with 16× less memory
≤ 1.5%orchestration overhead from the host agent and SDK
−50%bandwidth with the shared binary snapshot format
Bring the server you already have
One orchestrator for every kind of game server
Ship a Linux or OpenBSD build, describe it in one manifest and pick the model that fits your game. You can mix them in one fleet.
Many rooms per process
For lightweight and browser games: rooms are reserved inside long-running processes in milliseconds, so dozens of games share a machine until one takes off.
Persistent worlds
Long-lived shards with checkpoints and regional failover, moved only at safe points instead of on a timer.
Built for small studios with big nights
Cheap when it is quiet. Ready when it is not.
Matchmaking built in
Quickplay, parties, private room codes, backfill and rejoin through one player API. Allocation places each match on the host with room for it.
Drain until empty
Cordon a host for patches, upgrades or removal. It takes no new matches and signals the moment its last room closes.
Direct connections, relays when needed
Players connect straight to the game with signed join tokens: UDP, TCP or WSS with per-host certificates. Authenticated relays cover networks that block direct paths.
Reconnects that hold the seat
A dropped player keeps their place for minutes while a bot stands in, then resumes exactly where they left off.
Scale out, scale to zero
Idle game processes exit on their own. When rooms run short, ShardNexus asks your provisioning tool for another host.
Updates without kicks
New builds take new rooms at once. Old processes finish their matches and exit, with canary percentages and automatic rollback.
Your servers or ours
Run it on your machines, or let us run them
How it works
From build to battle in four steps
- Describe your serverOne manifest names the command, ports, session model and limits. It works unchanged on small and large machines.
- Enroll your hostsRun the host agent on any Linux or OpenBSD box with a one-time token.
- Players ask for a matchQuickplay, parties, private codes and rejoin through the player API, from any client.
- Grow and shrink safelySigned webhooks tell your tooling when to add a host and when one is empty.
schema_version: 2 fleet: arena-shooter runtime: command: ./ArenaServer arguments: ["-port", "${SNX_PORT_GAME}"] ports: - { name: game, protocol: udp, container_port: 0 } session_model: type: one_session # or multi_room, persistent_world capacities: { players: 16 } scaling: { minimum_ready_processes: 2 }
Put your next game on the Nexus.
ShardNexus is in early access. Tell us about your game and how you want to host it, and we'll get in touch when there is room for your studio.
Already invited? Sign in to the console.