One Deployment, Many Operators

What multi-tenant means in iGaming

Multi-tenant in most SaaS products means multiple customers sharing the same infrastructure. In iGaming, that description barely scratches the surface. Multi-tenant here means multiple operators — each a licensed entity with its own regulatory obligations — sharing a single platform deployment. Each operator may run multiple brands. Each brand may operate in a different jurisdiction. Each jurisdiction has its own compliance rules, responsible gaming requirements, payment provider restrictions, and reporting obligations.

This is not the same as multiple users on a shared app. An operator in Sweden has different deposit limit enforcement rules than an operator in Ontario. A brand targeting the UK market needs GamStop integration; a brand in Curacao does not. A single operator might run a casino-focused brand and a sportsbook-focused brand, each with different game providers, different bonus structures, different CMS content, and different customer support workflows — all under the same license.

The platform has to support all of this simultaneously. Not by running separate instances. Not by maintaining separate codebases. By running a single deployment that understands the full hierarchy: platform, operator, brand, jurisdiction. Every feature, every rule, every query has to be aware of where it sits in that hierarchy.

Most platforms solve this by deploying separate instances per operator. It works — until you have ten operators, each with three brands, each needing independent upgrades, patches, and monitoring. Then it becomes an operational burden that scales linearly with your customer count. PAM was designed from the start to avoid that trap.

The isolation requirement

Data isolation in a multi-tenant iGaming platform is not a nice-to-have. It is a regulatory requirement. When a support agent for Operator A logs into the back office, they must not be able to see, query, or export any data belonging to Operator B. Not even accidentally. Not even through a reporting tool. Not even through a poorly scoped API call.

This requirement extends deeper than most people expect. A brand's compliance configuration — its deposit limits, its self-exclusion propagation rules, its KYC verification thresholds — must not leak into another brand's configuration. A payment provider integration configured for one operator must not be visible to another operator's admin. A bonus campaign created by one brand must not appear in another brand's CMS.

The isolation is not just about player data. It covers configuration, content, integrations, reports, audit trails, and back-office access. Every layer of the system that stores or serves data has to respect tenant boundaries. And the enforcement cannot happen after the data is retrieved — filtering results in the application layer is not isolation. It is a bug waiting to happen.

How PAM isolates

PAM enforces tenant isolation at the query level. Every database query is scoped to the current operator and brand context before it executes. This is not a middleware that appends a WHERE clause after the fact. The query is constructed with the tenant scope as a fundamental parameter. Data that does not belong to the current context is never fetched, never loaded into memory, never serialized into a response.

The RBAC (Role-Based Access Control) model enforces these boundaries simultaneously across three surfaces:

• The API layer — every authenticated request carries the operator and brand context. API controllers resolve the tenant scope before any business logic executes. There is no API endpoint that returns unscoped data.
• The back office — every back-office user is assigned to an operator and, optionally, to specific brands within that operator. The back-office UI only renders data, navigation, and configuration options that the user's RBAC role permits within their tenant scope.
• The CMS — content management is scoped per brand. A CMS editor for Brand A cannot see or modify Brand B's content, templates, or page structures — even if both brands belong to the same operator, unless explicitly granted cross-brand access.

The enforcement is structural. It is not a policy that developers remember to apply. It is built into the data access layer itself. A developer writing a new feature does not need to remember to add tenant filtering — the repository layer applies it automatically. Forgetting to scope a query does not produce unscoped results. It produces an error.

Independent configuration per tenant

Isolation is not only about data separation. Each operator and brand needs its own independent configuration — and that configuration must be modifiable without affecting any other tenant on the platform.

In PAM, each operator independently configures:

• Payment provider integrations — which providers are enabled, their credentials, deposit and withdrawal limits, currency support, and routing rules. Operator A might use PaymentIQ with one set of PSPs; Operator B might use a completely different payment stack.
• Game provider setup — which game aggregators and direct integrations are active, which games are available per brand, lobby ordering, and game-specific rules like maximum bet limits.
• Compliance rules per jurisdiction — KYC verification requirements, deposit limit enforcement thresholds, self-exclusion propagation scope, AML monitoring triggers, and responsible gaming intervention rules. All configurable per jurisdiction, per brand.
• Bonus configuration — campaign rules, wagering requirements, bonus expiration, eligibility criteria, and trigger conditions. Each brand runs its own bonus engine configuration independently.
• Communication templates — email, SMS, and push notification templates. Each brand has its own branding, tone, and language configuration for every communication type.
• CMS content and skins — each brand has its own visual identity, page layouts, content blocks, and promotional materials. The CMS serves the correct skin based on the brand context of the incoming request.

All of this runs on a single deployment. There is no per-operator infrastructure. There are no per-operator builds. When the platform is updated, every operator receives the update simultaneously — but their configurations remain independent and untouched.

Adding a new operator

Onboarding a new operator to PAM is a configuration task, not a development project. The platform does not change. The deployment does not change. What changes is the configuration layer.

The process follows a predictable sequence:

• Define the operator entity — create the operator record with its licensing details, contact information, and organizational structure.
• Create brands — define each brand under the operator, assign jurisdictions, set default currencies and languages.
• Configure providers — set up payment provider integrations with the operator's own merchant accounts, enable game providers, connect communication services.
• Set up compliance rules — configure KYC requirements, responsible gaming thresholds, and AML rules per jurisdiction. These are selected from the platform's library of jurisdiction-specific rule templates and customized as needed.
• Create back-office users — assign RBAC roles scoped to the new operator. Support agents, compliance officers, marketing managers, and administrators each get role-appropriate access to the operator's data and configuration.
• Deploy CMS content — set up the brand skins, landing pages, and content templates. The CMS is ready to serve the new brand's content immediately.

No code is written. No deployment is triggered. No other operator is affected. The new operator is live on the same infrastructure, with full isolation, within the time it takes to complete the configuration. This is how multi-tenancy should work — the platform scales by adding configuration, not by adding infrastructure.

The principle

Multi-tenancy in iGaming is harder than in most industries because the isolation requirements are regulatory, not just operational. A data leak between tenants is not an inconvenience — it is a compliance violation. A configuration bleed between brands is not a bug — it is a licensing risk.

The only architecture that satisfies these requirements without operational overhead that scales linearly with customer count is one where isolation is structural — enforced at the query level, the RBAC level, and the configuration level simultaneously. Where adding a new operator is configuration, not development. Where the platform deployment is singular, but the tenant experience is fully independent.

PAM was built this way from the start. Not because multi-tenancy is a selling point — but because the alternative, deploying and maintaining separate instances per operator, is an operational model that breaks down the moment you have more than a handful of customers. Single deployment, full isolation, independent configuration. That is how you scale an iGaming platform without scaling your infrastructure team at the same rate.