Nakama vs GS2: Running Your Own Game Server
vs Using Game Server Features as a Service

Nakama + Hiro: an OSS game server and framework.
GS2: a game-feature BaaS.

Nakama's great strength is that it is open source and lets you build a game server to your own requirements.

Nakama is provided as a game server with user accounts, chat, social features, matchmaking, and realtime multiplayer. On GitHub it is presented as a scalable open-source game backend with multiplayer, matchmaking, leaderboards, chat, and social features. Server-side logic can be extended in Go, TypeScript, and Lua.

Hiro adds a layer of gameplay systems on top: an economy with currencies, a store, and IAP validation; inventory; achievements; progression that can express quest chains and skill trees; energy (the equivalent of stamina); streaks for consecutive-login rewards; and seasonal event leaderboards. In short, Nakama + Hiro is a very powerful setup for teams that want to assemble and operate both the game server and its gameplay systems themselves.

GS2, on the other hand, provides the backend features that come up again and again in game development as services organized around game concepts.

If you look only at feature breadth, Nakama + Hiro and GS2 overlap substantially. The difference is the delivery model. Nakama + Hiro is a framework you run on your own servers — configuration, extension, and operations are on the title side. GS2 is a set of managed services: you use the features you have always rebuilt for game servers, without provisioning or operating servers at all.

Challenges that tend to remain even with Nakama + Hiro

Nakama is a very powerful game server framework, and Hiro adds many gameplay systems on top of it. Even so, in real game development the following challenges can remain.

1. OSS and a framework give you freedom to build — and leave operations with you

A big part of Nakama's appeal is that it is open source. If you self-host, you can run it freely on your own infrastructure — it is published on GitHub under the Apache 2.0 license. Hiro's modules likewise run on your own Nakama server. The flip side is that with self-hosting, responsibility for operating the game server stays with you. For example:

• Server provisioning
• Database setup
• Scaling design
• Backups
• Incident response
• Monitoring
• Nakama / Hiro upgrades
• Security
• Load testing
• Multi-region deployment
• Cost optimization

Nakama also has a managed option, Heroic Cloud, which Heroic Labs presents as a managed or private cloud for hosting Nakama and Satori. But even with managed hosting, configuring and designing your game logic and Hiro's systems stays on the title side.

GS2 provides not just managed infrastructure but the game-server features themselves as managed services. Without standing up, extending, or maintaining servers, you can use inventory, loot boxes, stores, quests, rewards, and in-game mail directly.

2. Hiro covers a lot — and still not everything

With Hiro, many areas that used to be custom runtime code on plain Nakama are now provided as framework systems. For example:

• Inventory (Hiro Inventory)
• Currencies, store, and IAP validation (Hiro Economy)
• Achievements (Hiro Achievements)
• Quest chains and skill trees (Hiro Progression)
• Energy, the equivalent of stamina (Hiro Energy)
• Consecutive-login rewards (Hiro Streaks)
• Seasonal event leaderboards (Hiro Event Leaderboards)

At the same time, not every live-ops feature is included. In-game mail with claim deadlines, automatic overflow handling when the inventory cap is exceeded, maintenance and incident compensation, operator-issued serial (campaign) codes with bulk issuance and revocation, news delivery, version checks, maintenance control, buffs, upgrading and crafting, loadouts, and loot-box-specific mechanics such as pity counters and rate display — these still tend to be designed and implemented as your own runtime code, even with Hiro.

Being able to implement something and not having to implement it are different things. Even when a framework provides the foundation, the title-specific specifications you build on top of it — and their design, testing, operations, incident response, and spec-change work — stay with you.

GS2 provides these frequently needed game-backend behaviors as services, feature by feature, operations included. Instead of "how do we implement this with Hiro and runtime code," game developers can think about "which GS2 services do we combine to express this game specification."

3. The integrity of the in-game economy tends to rest on your configuration and code

In an in-game economy, every change to items and currency matters. Problems like the following can seriously damage a live game:

• Premium currency gets double-spent
• Items get duplicated through retry or race-condition exploits (duping)
• Battle pass or challenge rewards get claimed more than once
• Loot box results and the granted drops go out of sync
• Shop purchase limits get bypassed
• Items are lost when the stash is full
• Ranked payouts go to the wrong players
• Season rewards stay claimable after the ladder resets

Hiro's economy and inventory provide a foundation here, and Nakama's storage engine supports batched multi-updates. Still, title-specific rules — duplicate conversion, behavior at the inventory cap, compensation grants, event-window control — are designed by you, combining Hiro configuration with runtime code. The more freedom the setup gives you, the more idempotency, mutual exclusion, double-execution prevention, protection against malicious requests, and rollback design land on the title side.

GS2 provides the features for handling an in-game economy as individual managed services. Inventory is handled as inventory, paid currency as paid currency, stores as stores, loot boxes as loot boxes, and in-game mail as in-game mail — in units designed for operating an in-game economy safely.

4. Matchmaking and realtime are strong — but the game flow around them still needs design

Nakama is strong in matchmaking and realtime multiplayer, and its authoritative multiplayer provides an in-memory area for holding game state while a match runs. For teams that want to build realtime multiplayer themselves, that is a major benefit.

In a real game, though, matchmaking and realtime communication do not exist in isolation. Around a multiplayer session, you need flows like these:

• Reference player ratings and ranks
• Reference owned characters and loadouts
• Move players to a lobby once a match is made
• Manage chat and ready states inside the lobby
• Run real-time communication during the game
• Save match results
• Reflect results in rankings and seasonal standings
• Update quest and mission progress
• Distribute rewards based on the outcome

Hiro's event leaderboards, achievements, and progression support parts of this chain. But the game-specific wiring — which rewards, quests, and ratings a match result feeds into, and how — is still designed by you as runtime code.

GS2 provides matchmaking, lobbies, chat, and real-time communication — and also rankings, rewards, inventory, quests, stores, and loot boxes. So instead of treating multiplayer as separate machinery, you can design it consistently as part of the backend for the whole game.

5. Owning your server is a strength — for the right team

Nakama + Hiro suits teams that want control of their own game server and gameplay systems. For example, it is a good match for teams that:

• Have enough server engineers
• Can write server logic in Go / TypeScript / Lua
• Are experienced in operating infrastructure
• Know Kubernetes and cloud operations
• Want to build their own authoritative server for realtime multiplayer
• Want to extend flexibly on an OSS base and a framework

For game development without a large server team, however, the framework's freedom can turn into a burden. Being able to build a game server matters — but whether you need to keep assembling and operating the features most games need, on your own servers, is a separate question.

GS2 is designed so that you can use the in-game economy, progression, rewards, rankings, matchmaking, lobbies, chat, and real-time communication without a large server team.

6. Cost is not just license fees — count operations and development too

Nakama is available as open source, and self-hosting keeps license costs down. But the real cost is not just the license. Self-hosting incurs costs like:

• Servers
• Databases
• Networking
• Monitoring and logging infrastructure
• Backups
• Incident response
• Load testing
• Security
• Nakama / Hiro version upgrades
• Server engineers' time

With Heroic Cloud you can run Nakama in a managed form, and Hiro is offered as a commercial game framework with its own licensing. But neither managed hosting nor the framework removes the need to design, implement, and operate your title-specific game features.

GS2 is based on pay-as-you-go pricing per API request. Across inventory, loot boxes, stores, quests, rewards, rankings, matchmaking, lobbies, and real-time communication, you can estimate the whole game backend in terms of "how many requests will we use." When comparing costs, include not just server bills and licenses but also the engineering time to build game features, testing, operations, and incident response.

Games GS2 is a good fit for

GS2 is especially well suited to games like these:

• Live-service and games-as-a-service titles
• Free-to-play games with battle passes, item shops, or loot boxes
• Games with inventories, loadouts, crafting, or character progression
• Games that run seasonal events, ranked seasons, or limited-time modes
• Games with daily streaks, challenges, and reward tracks
• Games that need player compensation and in-game mail for live support
• Co-op and competitive games that need matchmaking, lobbies, and chat
• Cross-platform titles spanning PC, console, and mobile
• Teams that want online features without hiring a backend team
• Games that would rather use managed game features as a service than self-host an OSS game server and framework

For these games, being able to stand up a game server is not enough. Player belongings, paid currency, stores, loot boxes, quests, rewards, rankings, matchmaking, lobbies, chat, real-time communication, and live operations all need to be handled as one coherent whole. GS2 covers that territory broadly.

When Nakama fits, and when GS2 fits

Nakama (with Hiro) and GS2 both support game backends, but their strengths show up in different places.

Nakama fits when you want to build, extend, and operate your own game server on an OSS base — with realtime multiplayer, matchmaking, leaderboards, chat, and social features, and server-side logic in Go, TypeScript, and Lua. Adding Hiro brings framework-level gameplay systems: economy, inventory, achievements, progression, energy, and streaks. GS2 fits when you want the backend features your game needs — in-game economy, progression, rewards, loot boxes, stores, rankings, matchmaking, lobbies, chat, real-time communication — as managed services.

For a more exhaustive feature-by-feature comparison, see the feature coverage matrix on our top page.

Nakama and GS2 can be used together

Even if you already use Nakama, using GS2 alongside it is a valid option.

For example, you can keep Nakama for authoritative realtime multiplayer, custom match logic, and your own server extensions, while building the in-game economy, loot boxes, stores, inventory, quests, rewards, rankings, daily login streaks, and in-game mail on GS2. This lets you keep Nakama's strengths — the realtime server and the flexibility of custom logic — while GS2's managed services cover the game-feature areas that would otherwise be self-built and self-operated.

In particular, even for projects already running on Nakama (with Hiro), GS2 is worth considering if you face challenges like these:

• Game logic in runtime code keeps growing
• Adding loot box and store features keeps getting heavier
• You are not confident in the consistency of inventory and paid currency
• Distributing rewards and compensation is a heavy operational burden
• Features outside the framework — in-game mail, serial codes — keep piling up as custom code
• Ranking rewards and seasonal events have grown complex to implement
• The chain from matchmaking to lobby, match results, and reward payout has grown complex
• Both server operations and game-feature development have become a burden
• You want to grow the areas you can operate without building, rather than the areas you can build

GS2 is not only a replacement for Nakama — it also works as a complement that covers the game-feature areas that stay self-built and self-operated even with Nakama + Hiro.

Summary: Nakama + Hiro is a foundation you build and operate.
GS2 is a BaaS for using game server features.

Nakama is a powerful choice as a game server. It is open source, offers realtime multiplayer, matchmaking, leaderboards, chat, and social features, and can be extended in Go, TypeScript, and Lua. Adding Hiro brings gameplay systems — economy, inventory, achievements, progression, energy, streaks — as a framework. For teams that want to own their game server and build flexibly, it is an attractive setup.

On the other hand, the truly time-consuming part of game development is not the ability to run a game server or a framework. The bigger challenge is how to safely build your title-specific specifications and keep operating them after release. Even with Nakama + Hiro, areas such as in-game mail, compensation, serial codes, news, version checks, and loot box pity timers are assembled by you — and everything runs as servers you keep operating.

GS2 solves this by providing the backend features games need over and over again as managed services, operations included.

What game developers should really spend time on is not mutual exclusion for item grants, double-execution prevention for reward claims, persisting draw results, or distributing ranking rewards. It is how fun the game is, retention, event design, and the player experience.

Build and operate freely with Nakama + Hiro — or grow the areas you don't have to build with GS2. Working out which philosophy fits your team is what matters in choosing a game backend. If you want to use game features as managed services and reduce the burden of server development and operations, GS2 is a practical choice.