How GS2 Fills the Game Backend Gaps
That Unity Gaming Services Alone Doesn't Cover

UGS is a set of services with strong Unity integration.
GS2 is a BaaS covering the full range of game server features.

UGS is a collection of services for adding online features to games built with Unity. For example, Cloud Save is described as a service that stores player and game data in the cloud, Leaderboards as a service that stores, sorts, and ranks scores, and Relay as a service that connects players through relay servers without running dedicated game servers.

GS2, on the other hand, provides the backend features that come up again and again in game development as services organized around game concepts. For example, GS2 covers areas such as the following.

Most of these areas can be built on UGS as well. However, UGS is designed to provide comparatively general-purpose building blocks. The in-game economy, rewards, loot boxes, stores, quest progression, compensation grants, and ranking rewards a real title needs tend to be implemented by combining Cloud Code, Cloud Save, Economy, Remote Config, and others. GS2 provides these as game-oriented feature units from the start.

In other words, GS2 is not just cloud storage or a serverless execution environment. It is a backend that delivers the features you have rebuilt into every game server as services game developers can work with directly.

Challenges that tend to remain with UGS alone

UGS is a convenient set of services, but in real game development the following challenges often remain.

1. "Storing data" is not the same as "working as a game feature"

UGS Cloud Save is a service for storing player and game data in the cloud. It is described as reducing data loss when players switch devices or reinstall the game.

But what a game backend needs is more than just storing data. Take inventory alone — a real implementation needs specifications like these:

• Managing owned quantities per item type
• Handling stackable and non-stackable items
• Inventory capacity limits
• Constraints on currently equipped items
• Handling duplicates when granting items
• Sending overflow items to a in-game mailbox when the cap is hit
• Integration with consumption, exchange, selling, upgrading, and crafting
• Blocking illegitimate client requests
• Consistency under double execution and retries

Cloud Save gives you a place to store all of this. But the inventory feature itself still has to be designed on the title side.

With GS2, inventory is handled as inventory, paid currency as paid currency, stores as stores, and loot boxes as loot boxes. Instead of low-level data storage design, game developers can build the backend using concepts close to game design.

2. Economy exists, but assembling the whole in-game economy is still your job

UGS includes Economy. It handles concepts like currencies and items, so it can form part of an in-game economy. But a real in-game economy is not complete with Economy alone. For example, you need flows like these:

• Rotate the item shop on daily and weekly resets
• Sell weekly bundles with per-player purchase limits
• Open loot boxes and grant every drop atomically, with bad-luck protection
• Convert duplicate drops into crafting materials
• Grant battle pass tiers and challenge rewards exactly once
• Run daily login streaks with escalating rewards
• Send make-good compensation to affected players after an incident
• Deliver time-limited gifts through the in-game mailbox

Achieving this on UGS usually means combining Economy, Cloud Code, Cloud Save, Remote Config, Leaderboards, and more. Cloud Code is powerful — it runs game logic server-side and integrates with Unity services — but the final design, implementation, and testing of your game's rules remain on the title side.

With GS2, loot boxes, stores, quests, daily login streaks, in-game mail, and rewards are provided as game-oriented features. So instead of asking "how do we combine multiple UGS services to build this," you can develop with the mindset of "which GS2 feature expresses this part of the game design".

3. Live-ops features like loot boxes, rewards, and in-game mail tend to be built one by one

Live-service games need many features after release. For example:

• Battle passes and seasonal reward tracks
• Rotating item shops with daily / weekly resets
• Holiday events and limited-time modes
• Double-XP weekends and boost events
• Daily login streaks
• Ranked season payouts
• Make-good compensation after outages
• In-game mailbox deliveries
• Redeemable promo codes
• News / message of the day
• Version gates and forced updates
• Maintenance windows

These can be built on UGS too, using Cloud Code, Remote Config, and others. But loot boxes, compensation, in-game mail, and reward distribution are not available from the start as high-level, game-oriented services — so similar implementations tend to be repeated for every title.

GS2 provides the features live-service operations commonly need as ready-made game-oriented services. You can build a backend in a short time with post-release operations already accounted for.

4. Matchmaking and lobbies also need to be designed together with the rest of the game

UGS offers multiplayer-related services such as Lobby, Relay, and Matchmaker. Relay is described as a service that uses relay servers as a proxy to establish player-to-player connections without dedicated game servers.

In a real multiplayer game, though, matchmaking and lobbies do not exist in isolation. Around a match, 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

These flows tightly couple matchmaking, lobbies, and real-time communication with rankings, rewards, inventory, quests, and other game features.

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 a separate service, you can design it consistently as part of the backend for the whole game.

5. With Unity Multiplay no longer offered directly, dedicated server hosting needs careful evaluation

When evaluating the multiplayer side of UGS, dedicated game server hosting deserves attention.

According to Unity's status information, Multiplay Game Server Hosting offered by Unity was deprecated as of April 1, 2026, and new game server scaling and new allocations are no longer available. An exception was described for customers who signaled their intent to migrate: they can continue using it until their migration to Multiplay by Rocket Science is complete.

This does not mean UGS Lobby, Relay, Matchmaker, and the rest are gone. But if you want dedicated game server operations to stay entirely within Unity, you need to verify the current offering and migration path.

When evaluating GS2, you can compare from the standpoint of how to build the game backend as a whole — the in-game economy, progression, rewards, rankings, matchmaking, lobbies, chat, and real-time communication. The important thing is to choose based on the backend features your game's specifications and operations require, not simply "we build in Unity, so we use UGS."

6. Costs are metered per service, which complicates estimates

UGS pricing is metered per service. Unity's pricing page, for example, lists Cloud Save storage, reads, and writes; Economy reads and writes; and Cloud Code invocations, compute, and egress separately. Cloud Save includes 5 GiB per month with free tiers for reads and writes, with usage-based billing beyond them; Economy likewise has free tiers and overage pricing per read and write.

This is convenient for starting small. But when you build actual game features, a single player action can touch the billing meters of several services at once. Even a single loot box opening, depending on the design, can involve:

• A Cloud Code invocation
• An Economy currency read
• An Economy currency write
• Economy item writes
• A Cloud Save state write
• A Remote Config lookup
• Logging and analytics events

So you end up totaling costs per service rather than per game feature.

GS2 is based on pay-as-you-go pricing per API request. You can estimate the whole game backend in terms of "how many requests will we use" — across inventory, loot boxes, stores, quests, rewards, rankings, matchmaking, lobbies, and real-time communication — which makes the overall cost picture easy to grasp.

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 considering non-Unity clients or multi-engine expansion

For these games, storing data in the cloud and running serverless functions 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 UGS fits, and when GS2 fits

UGS and GS2 both support game backends, but their strengths show up in different places.

UGS fits teams that want tight integration with their Unity project while using Authentication, Cloud Save, Cloud Code, Economy, Leaderboards, Lobby, Relay, Matchmaker, and Vivox — introducing online features as an extension of Unity development, centered on the Unity editor and the Unity Dashboard. GS2 fits when you want to build the backend features your game needs — in-game economy, progression, rewards, loot boxes, stores, rankings, matchmaking, lobbies, chat, real-time communication — in units that game developers can work with directly.

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

UGS and GS2 can be used together

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

For example, you can keep UGS for Authentication, Cloud Save, Analytics, Remote Config, and Relay, while building the in-game economy, loot boxes, stores, inventory, quests, rewards, rankings, matchmaking, lobbies, chat, and real-time communication on GS2. This lets you keep the ease of Unity integration while GS2 covers the game-feature areas where implementation work tends to remain.

In particular, even for projects already running on UGS, GS2 is worth considering if you face challenges like these:

• Cloud Code logic keeps growing
• Cloud Save data structures have grown complex, shaped by game specifications
• Loot box and store implementations are duplicated per title
• You are not confident in the consistency of paid currency and item grants
• Distributing rewards and compensation is a heavy operational burden
• Quests and missions are implemented one by one
• Ranking rewards and seasonal events have grown complex to implement
• The chain from matchmaking to lobby, chat, and reward payout has grown complex
• Backend development becomes the bottleneck every time you add a feature

GS2 is not only a replacement for UGS — it also works as a complement that covers the game-feature areas where UGS alone tends to leave implementation work.

Summary: Building in Unity doesn't mean
your backend has to stay inside Unity

UGS is a convenient set of services for building online games in Unity. Authentication, Cloud Save, Cloud Code, Economy, Leaderboards, Lobby, Relay, Matchmaker, Vivox, and more are available as an extension of Unity development.

But the truly time-consuming part of game development is not only cloud storage or the serverless execution environment. The bigger challenge is how to safely build — and keep operating after release — the backend features close to your game's own specifications, such as battle passes, rotating item shops, loot drops, ranked seasons, and player compensation. Even with UGS, if these features have to be assembled on the title side, the amount of game-server implementation may not shrink as much as expected.

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

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 post-match state management. It is how fun the game is, retention, event design, and the player experience.

If you want online features as an extension of Unity development, UGS is the natural choice. If you want your game's systems themselves handled as services, that is GS2. With GS2, you can build the common parts of a game backend in a short time and operate them safely. Even if you develop in Unity, your backend does not have to stay inside Unity. If you want to cover the game-feature areas where UGS alone tends to leave implementation work — and reduce the burden of server development — GS2 is a practical choice.