Game Technology
Unity development and multiplayer infrastructure. From dedicated server deployment to matchmaking, NAT configuration to day-to-day operations — the same architecture we run on our own hardware.
If any of this sounds familiar
- The game works. We have no idea how to get a dedicated server into production.
- Clients connect, packets go out, nothing comes back. UDP behind NAT is broken.
- Our managed multiplayer bill scales faster than our player base.
- Room allocation is manual. We cannot tell which servers are free.
- When an instance dies, we find out from a player complaint.
What's included
Unity game development
Development work on the game itself with multiplayer support. We can join your existing team or take the entire server side.
Server build & packaging
Turning headless Linux builds into container images, including cross-platform builds when you develop on ARM and deploy to x86_64.
Port pool & room management
One UDP port per room. The pool starts automatically, crashed instances come back on their own, and capacity is managed from one place.
NAT & firewall
Routing a UDP port range through a virtual IP, preserving source ports, and the matching host-side rules. This step matters more than people expect: the wrong container network mode silently breaks return traffic.
Matchmaking & slot allocation
Queueing, slot reserve and release, heartbeat-driven health checks. Players never get routed to a dead server.
Server hosting
Hosted on our hardware or installed on yours — your choice. Either way the setup remains yours; we do not create lock-in.
Monitoring
Instance health, room occupancy, and capacity tracked through Prometheus and Grafana. You see the problem before a player does.
Handover & documentation
If your team wants to take over, runbooks and the reasoning behind architectural decisions come with it.
Technologies we use
- Unity
- FishNet
- Nakama
- Docker
- UDP / NAT
We run this multiplayer stack on our own hardware.
We built and operate the entire server side of our own multiplayer game. The architecture below is not something we have read about — it is the system we run every day.
Dedicated server layer. Unity headless FishNet servers, each in its own container, on a UDP 7000–7019 port range with automatic restart on failure. Container networking is configured to preserve source ports so return traffic finds its way back.
Network layer. Traffic arrives on a virtual IP in our own public block, gets NAT’d through OPNsense, and is forwarded to the internal host — with matching host-side firewall rules.
Control plane. A matchmaking layer on Nakama handles slot allocation. Servers heartbeat every 30 seconds and slot state updates accordingly. Matchmaking only assigns players to slots that reported in within the last 90 seconds. On restart, slot records with no matching entry in config are purged automatically — a check we added after stale records started handing clients an unreachable address.
That last paragraph is where tutorials end and operations begin. Those details are not written down anywhere; you learn them keeping a system alive.
How we work
Server infrastructure build
Getting your existing game’s server side built and into production. Defined scope, defined delivery.
Development partnership
We join the team on the game itself. Multiplayer, networking, and the server side stay with us.
Hosting & operations
We host and run the servers, including monitoring, updates, and capacity management.
Frequently asked questions
We do not use FishNet. Can you still help?
Yes. Mirror, Netcode for GameObjects, or your own protocol — it does not matter. Dedicated server deployment, port management, NAT, and slot allocation are the same problems regardless of netcode, and that is where the actual difficulty lives.
Do the servers have to be hosted with you?
Your call. Your hardware, a server you rent, or ours. Whichever you pick, the setup stays yours — we do not build lock-in into it.
How many concurrent players can it handle?
There is no single number. It depends on tick rate, players per room, how heavy the simulation is, and the hardware underneath. We work it out with your numbers on the first call rather than quoting a figure we have not measured.
Can we migrate off a managed multiplayer service?
Yes, and it is a common scenario. Past a certain player count, running your own infrastructure usually becomes the cheaper option. We work out where that threshold sits for you — migrating is not always the right answer.
Our game is still in development. Is it too early?
The opposite — it is the right time. Networking architecture reaches deep into a game’s codebase, and changing it later is always more expensive. Coming in while development is still moving is the lowest-friction path.
Related services
Tell us what you're trying to build.
The first call is technical — no slide deck. We listen to what you're running and tell you whether it's workable. We reply within 2 business days.