What Is a Remote Gaming Server (RGS)?

A Remote Gaming Server, or RGS, is the server-side platform that runs online casino games and connects them to the rest of the gaming ecosystem. That's the short answer.

The longer one is more useful. An RGS isn't a single box so much as a set of responsibilities: launching games, managing sessions and rounds, handling transactions, talking to operator wallets, keeping records, and connecting games to operators and aggregators. Different platforms draw those lines in different places — there's no fixed spec for exactly what sits inside an RGS and what doesn't.

The easiest way to understand one is to follow a game through it.

Where does the RGS sit?

A player opens an online casino and picks a game. That game was probably built by a studio with no direct relationship to the player. The player's account and money live somewhere else entirely — usually with the operator, sometimes with an aggregator sitting in between.

Somewhere in that chain, something has to know how to launch the game, keep its session alive, manage its rounds, and talk to whatever's on the other side. That's the RGS.

The RGS usually isn't the operator's full player-account platform, and it doesn't have to hold the player's money. The RNG might live inside it, next to it, or elsewhere in the game architecture — that depends on the implementation.

What stays fairly constant is the role: server-side infrastructure that lets games run and connect to everything around them. A studio can have several good games finished and still have nowhere to put them.

What happens when a player launches a game?

Say a player picks a slot from the lobby. The request that reaches the platform usually carries enough to establish context — player or session, operator, game, currency, configuration. The RGS validates what needs validating, opens the session, and lets the client load.

The game also needs a way to move money against the player's balance, which in most integrations means calling an operator wallet through some agreed API. The specifics shift by integration — an aggregator may sit in the middle, wallet models differ — but the underlying problem stays the same: several independent systems have to agree on who's playing, what they're playing, and what happens to their money.

Then the player hits Spin.

Follow one game round

Take a simplified round. The player has a balance of €100 and bets €5.

The game sends the request to the RGS. The platform identifies the session and round, validates the bet, and fires the debit at the operator wallet. The operator accepts it — the balance drops to €95.

The outcome gets determined. Say the round wins €12. That result becomes part of the round state, the win transaction reaches the wallet, and the balance lands at €107. The RGS records the round and its transactions so the whole thing can be reconstructed and reconciled later.

That's the happy path, and it's genuinely uneventful.

Say the RGS sends that €5 debit and gets nothing back. Did it fail? Maybe. Or maybe the operator processed it fine and the response got lost on the way home. The RGS can't just fire another debit every time it's unsure — doubling every wager would make the reconciliation problem obvious fast, but obvious isn't the same as acceptable.

This is why transaction identity, idempotency, retries, and round state end up mattering as much as they do. The same failure mode shows up on the win side. Services restart. Connections drop. For a moment, one system knows something the other doesn't.

Eventually everyone has to agree on what actually happened — and getting there is most of the real engineering behind an RGS, even if it's the part that never makes the demo.

What does an RGS actually manage?

Games and rounds. The platform needs a reliable model of a round: when it started, what happened, its outcome, whether it's closed. A slot spin is simple. Other game types have more complicated opinions about when a round actually ends.

Sessions. Sessions tie an incoming player to the right operator, game, currency, and configuration, with rules for expiry, invalidation, and recovery — ordinary right up until they aren't.

Transactions and wallets. Bets, wins, and other transaction types need durable IDs and known states. Retries have to be safe; a duplicate request can't become a duplicate financial event. The wallet contract itself depends on the integration model — the RGS's job is to hold up its end of it reliably. Retrying a failed API call is a fine instinct. Retrying a debit is a more serious decision.

RNG and game outcomes. Randomness needs to come from a proper RNG and get used correctly by the game. Where it physically lives — inside the RGS, beside it, elsewhere in the stack — depends on the architecture, and certification requirements make that distinction matter more than it might look.

Operator and aggregator integrations. Games aren't commercially useful just because they run on a laptop. The RGS typically carries the integration layer — launch flows, sessions, wallet calls, callbacks — so a new operator doesn't become a new engineering project for every game.

Configuration. Operators want different games, currencies, limits, endpoints, credentials, and behaviours. The platform has to absorb that variation without deployment turning into a pile of exceptions only one engineer remembers.

Reporting and reconciliation. Reporting says what the platform believes happened. Reconciliation checks whether anyone else agrees. If the RGS logs a €5 bet the operator doesn't have, someone eventually has to go find it — usually not on a good day.

Operations. Monitoring, logs, health checks, diagnostics, admin tooling. Production always finds something the demo didn't cover.

RGS, operator platform, aggregator, and game: what's the difference?

The terms blur because these systems sit close together, and no two platforms draw the lines identically.

The game is what the player experiences — rules, presentation, and game logic, split however the studio chose between client and server.

The RGS is the server-side infrastructure that runs and distributes those games.

The aggregator connects content from multiple providers to operators, so an operator doesn't need a separate integration for every studio.

The operator platform, or PAM, covers the wider relationship with the player — accounts, wallets, authentication, responsible-gaming controls, and other casino-level functions.

One company's RGS is another company's separate service. The architecture diagram tells you more than the product label does.

Why does a game studio need an RGS?

Building a game and operating one are different jobs. A studio might have the math, the art, the front end, the game logic — and still need somewhere for all of that to actually run, for real players, real operators, real money.

Sessions need managing. Wallet calls need to behave. Operators need integrating. Rounds need recording. Production needs watching. Books need reconciling. At one game and one integration, a studio can get away with doing this by hand. At ten games and several operators, the duplicated platform work starts costing real time.

An RGS moves that shared work up to the platform level instead of rebuilding it inside every game and every integration. Some studios want to own that platform. Others would rather start further along.

Building the games, but not the RGS underneath them? Explore SPHINX →

Build an RGS, license one, or start from existing source code?

Once the need is clear, the next question is where the RGS comes from.

Build it yourself and you get full architectural control, along with all the platform engineering that comes with it. License a managed RGS and you trade some of that control for a lighter engineering load. Or start from an existing codebase under a source-code handover licence, then deploy and modify it as your own.

None of these is the obviously right choice — the trade-off is between time, engineering effort, control, and how much you're willing to depend on someone else's roadmap. That's really its own article.

Read next: Build, License or Acquire an RGS? →

What should you look for in an RGS?

Feature lists are easy to write and not always useful. Better questions:

• —Can a new operator be integrated without touching every game?
• —What happens when a wallet transaction succeeds but the response never arrives?
• —Can a disputed round be reconstructed clearly, after the fact?
• —How are retries and duplicates actually handled?
• —Can parts of the platform be deployed independently of each other?
• —What happens when an external system goes slow — and can you reproduce that in testing?
• —How does reconciliation actually work, in practice?

An RGS is infrastructure. The interesting questions tend to show up after the demo has already gone well.

A few practical questions

The platform underneath the game

A Remote Gaming Server is easiest to understand by tracing everything that has to happen between a player pressing Play and every system involved agreeing on what happened next: the session, the round, the transaction, the result, the record — and, sooner or later, the ability to explain why something didn't go quite as expected.

That's the platform underneath the game.

SPHINX is CoreStack Gaming's Remote Gaming Server platform, available through source-code handover, licensing, and managed deployment. Explore SPHINX →