Definition
An RGS (Remote Game Server) is the studio-hosted server environment where a casino game's logic actually executes: the RNG calls, the math model, the win evaluation. The operator's site embeds only the game client — the graphics and interface in the player's browser. Every spin is resolved on the studio's certified infrastructure and settled against the operator's wallet.
How an RGS round works
Conceptually, one game round is a short conversation between three parties:
- The client asks. The player presses spin; the game client sends the bet request to the studio's RGS.
- The wallet authorizes. The RGS asks the operator's platform to debit the stake. If the balance check fails, the round never happens — the wallet, not the game, is the gatekeeper.
- The RGS resolves. The certified build draws from the RNG, evaluates the result against the math model, and returns the outcome.
- The wallet settles. Wins are credited back to the operator's ledger; the client renders an outcome that was already decided server-side. Animations are presentation, not computation.
If the connection drops mid-round, wallet protocols complete or roll back the unresolved round on reconnection — the ledger must always end consistent.
Why the industry converged on this model
The RGS pattern solves two problems at once. For studios: one certified build, hosted once, serves every operator — a bug fix or a new game deploys globally without touching operator infrastructure. For regulators and players: the game math is executed in an environment the studio controls and a lab has certified, not on servers each operator could quietly modify. Integrity by architecture, not by trust in the operator.
RGS vs local integration
| Dimension | RGS (remote) | Local / on-premise |
|---|---|---|
| Where math runs | Studio's certified servers | Operator's or licensee's infrastructure |
| Game updates | Deployed once by the studio, live everywhere | Rolled out per installation |
| Certification scope | One hosted build per jurisdiction | Each deployment environment in scope |
| Typical use | Default for online casino content | Markets whose regulations require local hosting |
What regulators certify
Certification attaches to the specific build running on the RGS: the RNG implementation, the math model, and the approved RTP configurations for a given jurisdiction. The process and the documents involved are covered in our entry on game certification — the operational point here is that certification names an exact version. A studio cannot swap the math behind a certified game without re-certification, and an operator cannot modify it at all.
What operators should verify
- Build and market match. Confirm the exact game versions and RTP configurations certified for your jurisdictions — a title being "live elsewhere" proves nothing about your market.
- Wallet protocol quality. Test round recovery, rollbacks and reconciliation before launch; this is where integration defects surface as player-facing balance disputes.
- Supply-chain licensing. The RGS host — studio or aggregator — may need its own supplier authorization in your regulated markets.
In practice most operators reach RGS content through an aggregation layer rather than one integration per studio — the model behind T-Hub, the Turbo Stars games aggregator, which routes wallet traffic to each studio's RGS through a single API.
Related terms: Game Aggregator · RNG · Game Certification · RTP
Common questions
What is an RGS in iGaming?
A Remote Game Server is the studio-hosted environment where a game's logic runs: the RNG, the math model and the win evaluation. The casino site embeds only the game's client; outcomes are computed on the studio's servers and settled against the operator's wallet.
Who owns and operates the RGS?
The game studio, or in some setups an aggregator hosting studio content under license. The operator never runs the game logic itself — that separation is what lets one certified build serve many operators and keeps the math out of any single operator's reach.
Does the operator host casino games on its own servers?
In the standard RGS model, no. The operator hosts the lobby and the account layer; the game executes remotely. On-premise deployment still exists in some regulated markets that require local hosting, but it is the exception and comes with its own certification duties.
Can an operator change the RTP of a game on an RGS?
Only by selecting among the configurations the studio has had certified, where the game offers them and the jurisdiction permits it. An operator cannot alter the math itself — the certified build on the RGS is the authority, which is exactly the point of the model.
What is the difference between an RGS and a game aggregator?
The RGS executes games; the aggregator distributes them. An aggregator routes launches and wallet traffic between operators and many studios' RGS environments, but rounds are still resolved on each studio's own servers.
What happens to bets if the RGS connection fails mid-round?
Wallet protocols define recovery: unresolved rounds are completed or rolled back when the connection restores, so the ledger ends consistent. Round recovery behavior is part of certification and should be part of any operator's integration testing.