Your infrastructure
The deployment runs on infrastructure that belongs to you. Hosting, region and the operational envelope are agreed with you rather than inherited from a shared estate.
A complete private copy, not a skin
Your infrastructure, your data, your player accounts, your branding. One customer cannot see or affect another, because there is nothing shared between them to see.
What you get
The whole platform, deployed for one customer
A dedicated deployment is not a tenant slot with a different logo on it. It is the product, running where you decide, holding only your records.
Your data and your player accounts
Player records, financial history and the audit trail live inside your copy. When a regulator asks who holds the player data, the answer is you.
Your branding, at every level
Brand identity, page layout and language are yours to change without a release, because Brand Studio ships inside the copy rather than beside it.
Your audit trail
Every action by every player, staff member and system is recorded inside your deployment, in one searchable stream with the actor, the location and the device.
Screenshots are captures of the MaxBet and LuckyOni demo tenants. Every figure on screen is demo data.
Shared platform, or a copy that is yours
Two deployment models, described plainly. Both exist across the category. The second is the one we sell to licensed operators.
Shared platform
One estate, many customers
- InfrastructureWhere the platform software actually runs.
- Shared between customers
- Player databaseWhere player records and financial history are stored.
- One store, separated logically
- Who holds the player recordsThe question a regulator, a bank or an acquirer asks first.
- The platform, on your behalf
- Exposure to another customer's incidentWhat happens to you when something goes wrong for somebody else on the same platform.
- Shared infrastructure, shared exposure
- Branding controlHow deep a change you can make to what players see.
- Theme levelA look applied over a shared front end
- Software versionWhich build of the platform you are running.
- Whatever the shared estate runs
- If you sell or restructureWhat actually transfers when the business changes hands.
- Negotiated as a data export
Private copy
One estate, one customer
- InfrastructureWhere the platform software actually runs.
- Dedicated to one customer
- Player databaseWhere player records and financial history are stored.
- A store only your brands are in
- Who holds the player recordsThe question a regulator, a bank or an acquirer asks first.
- You, inside your own deployment
- Exposure to another customer's incidentWhat happens to you when something goes wrong for somebody else on the same platform.
- NoneNo other customer is inside the deployment
- Branding controlHow deep a change you can make to what players see.
- Page and layout levelBrand Studio ships inside the copy
- Software versionWhich build of the platform you are running.
- The same codebase as every other deployment
- If you sell or restructureWhat actually transfers when the business changes hands.
- The deployment is the asset
A description of two deployment models, not a comparison of named vendors. Checked August 2026.
One codebase behind every deployment
Our own brands and every private copy run identical software. An improvement is built once and reaches everyone, so quality compounds instead of forking. A private copy is not a snapshot you are then left to maintain.
No bespoke fork
Your copy is not a branch. It is the product, deployed for you.
Upgrades from the same product team
The people who build the platform are the people who ship into your deployment.
Windows agreed, not announced
Upgrade timing is scheduled with your operation rather than dropped on it.
What you own, and what we operate
A dedicated deployment splits responsibility rather than blurring it. The split below is the one written into the agreement.
Yours
The infrastructure account and its costs
Named on your cloud contract, in the region you choose.
Player records and financial history
Held inside your deployment for as long as your retention policy says.
Brands, domains and content
Identity, layout, translations and media, changed without a release.
Staff, roles and permissions
Who can see what, decided by you and recorded in your audit trail.
Your licence and your regulator relationship
The Turnkey route runs on your licence, and our licence does not apply to it.
Ours
The platform software and its upgrades
Built once, shipped to every deployment from the same codebase.
The security architecture
Zero-trust internally, with every system proving its identity on every request.
Game aggregation and catalogue sync
One integration carrying the studio catalogue into your brands.
Technical support and the service level agreement
24 hour technical support against an agreed response commitment.
Who it is for
Three situations where a private copy is the right answer
Licensed operators
You hold the licence and the payment relationships already. The platform layer underneath them is the part you are replacing.
Multi-brand groups
Several brands that have to stay separated at the identity layer, on one operational spine you control end to end.
Operators with a residency requirement
A regulator, a bank or a partner has asked where player data physically sits, and the answer has to be specific.
The questions a private copy changes
Who is the data controller
On a shared platform the provider processes player data on the operator's behalf and the contract decides the rest. Inside a private copy the records never leave your deployment, so the controller question has a short answer and the sub-processor list is shorter with it. That matters at two moments in particular: when a regulator asks who holds the player data, and when a bank asks the same thing in different words.
What happens if you want to leave
Portability is usually negotiated as an export. A file arrives, and somebody has to prove it is complete. A private copy inverts the problem, because the running system is the asset rather than a report about it. The deployment, the database and the audit history are already yours, and moving means changing who operates them rather than reassembling them somewhere else.
What is genuinely shared
The software. Every private copy runs the same codebase as our own brands, which is the whole reason a fix reaches you rather than joining a queue behind a bespoke branch. Nothing else crosses the boundary: no database, no cache, no queue, no shared login. Identity isolation holds inside the deployment too, so one brand in your group is not an account in another.
What it does not solve on its own
Owning the deployment does not make you compliant in a market, and it does not remove the work of licence approval, payment onboarding or content agreements. It changes where the data lives and who controls it. Jurisdictional fit is still assessed with you during discovery, and we would rather say so here than let the architecture imply otherwise.
What operators ask about isolation
On a dedicated deployment, completely. A private platform copy is your own environment holding your infrastructure, your data, your player accounts and your branding, and there is nothing shared for another customer to reach.
On shared deployments, brands are separated at the identity and account level, so credentials and player records do not cross between them. If data residency or isolation has a specific meaning for your licence, raise it in discovery, because it shapes where your deployment sits.
In the deployment your brand runs on, hosted through our infrastructure partner CloudWalker. On a dedicated deployment that is your own environment, and where it sits is a decision we take with you rather than a default we apply, because residency is often driven by your licence and your target markets.
On shared deployments, brands remain separated at the identity and account level. If residency is a hard requirement, bring it to discovery early, because it shapes the deployment plan.
Separated. Every brand runs its own login and account system, so a player on one brand is not a player on another unless they choose to be, even inside a single group. Credentials are walled off, and a compromise on the smallest brand does not become an incident on the largest.
This is an architectural choice rather than a setting, and it is what makes a brand separately auditable, separately reportable and separately sellable later.
That is one of the reasons brands are genuinely separated. A brand carries its own player accounts, its own creative library, its own back office and its own audit history, so it can be treated as a discrete asset rather than a slice of a shared database that has to be untangled first.
The commercial and regulatory work of a sale is still real, including the licence position and the player communications. The platform is not the part that blocks it.
What this page covers in the feature matrix
Each capability below is a row in the platform index, where its tier sits beside the method and the date behind it. Read the full feature matrix.
Private platform copies (dedicated deployments)
A complete private copy of the platform, sold to a licensed operator as their own: their infrastructure, their data, their player accounts, their branding.
Single codebase, every deployment
Our own brands and every sold copy run identical software. An improvement is built once and reaches everyone, so quality compounds while cost stays flat.
Identity isolation per brand
Every brand runs its own separated login and account system. Player credentials are walled off between brands, even inside a single operator group.
Zero-trust internal security
Every internal system proves its identity on every request. Nothing inside the platform is implicitly trusted, and security is on by default.
Walk the architecture with the engineers who built it
Bring your infrastructure constraints, the questions your regulator asks and your migration timeline. We will put the deployment model against them.
We reply within one working day.
