lightbulb Grow simply. Multiply fast.
You don't rebuild the casino for every new client — you multiply it. We take the existing, proven casino platform and make a separate, private copy of it for each client. Every copy runs in its own isolated space, with its own database, login secrets, security certificate, web address and country rules. Clients manage everything through one shared admin system; their players only ever see their own casino, never another client's.
- Tenant
- — one client's private casino.
- White-label
- — the client runs that casino under their own brand.
- Control-plane
- — the system that creates and manages every tenant.
- Provisioning
- — the automated setup of a new tenant.
tune Key decisions
Control-plane on top of the existing runtime — maximum reuse, minimum risk.
Silo: each client gets a fully separate copy with its own database — so the existing code needs no rework.
Existing Kubernetes clusters; Cloudflare at the edge for routing, WAF and TLS.
White-label B2B — external operators as tenants, each with its own brand and billing.
Each client is defined as code in Git; an automation tool (ArgoCD) keeps the live system matching that definition.
A second client's casino, working end-to-end: set up by one command, fully separate from the first.
account_tree System context
There are two layers. The control-plane is where you create and manage clients. The data-plane is the set of running casinos — one separate copy per client. Clients use the control-plane; players use only their own casino.
apartment Why "silo" isolation
In a regulated business, keeping each client physically separate is safer than mixing everyone into the same shared tables. Each client's data lives in its own database, so it can sit in the country its licence requires, and a problem with one client can never spill over to another. It also lets us reuse the existing casino code as-is, with no risky rewrites. The trade-off: the real effort moves into automating the setup of each separate copy.
| Criterion | Silo (chosen) | Pooled + RLS |
|---|---|---|
| Data isolation | Physical (strongest) | Logical (RLS) |
| Blast radius | 1 tenant | All tenants |
| Reuse of current code | Total | Invasive refactor |
| Cost per tenant | Higher | Lower |
rocket_launch Provisioning flow
The setup is idempotent — meaning you can run it as many times as you like and always end up in the same correct state, never with duplicates. If a step already succeeded, it is simply confirmed and skipped.
cloud The Cloudflare edge
The same setup process also configures the public internet entry point on Cloudflare. Each client gets their own web address and HTTPS certificate, plus a small program running at Cloudflare's edge that recognises the address, sends the visitor to the right client, and applies that client's brand. It also adds per-client security filtering and traffic limits. All of this is written as code with Terraform, so it is repeatable.
Put together, the visitor arrives at Cloudflare, which checks and filters the request and then forwards it to the right client's casino running inside the cluster:
dns Where to run it: on-prem, AWS or Cloudflare
The casino itself runs on Kubernetes — either on your own hardware (on-premise) or in a managed cloud like AWS. Cloudflare always sits in front as the public front door. The same setup tool and the same package work on all three; only the location changes, so you can start on-premise and move to the cloud later without rewriting anything.
Your own servers. Maximum control and data stays in your building.
- Setup tool creates the namespace, database, secrets and certificate.
- GitOps deploys the tenant package.
- Security & compliance gate runs; casino goes live.
Managed cloud. Scales up and down on demand, less hardware to run.
- Terraform builds the network, managed Kubernetes and managed database.
- The same package deploys each tenant.
- Same gate runs; casino goes live.
The global front door — not where the casino runs, but what every player hits first.
- Terraform sets up the web address, certificate and security rules.
- An edge program routes each player to the right tenant and applies the brand.
- Traffic is filtered and forwarded to the chosen runtime.
| On-prem K8s | AWS | Cloudflare | |
|---|---|---|---|
| Role | Runs the casino | Runs the casino | Public front door |
| Control | Full | Shared (managed) | Edge settings only |
| Scaling | Buy hardware | Elastic, on demand | Global, automatic |
| Cost | Fixed (owned hardware) | Pay-as-you-go | Low / per request |
| Data location | In your building | Pick a region | Edge (cache only) |
| Ops effort | You run it | Less (managed) | Minimal |
| Latency to player | Regional | Regional | Global edge |
timeline Tenant lifecycle
shield Isolation by tenant
verified_user Regulation, security & compliance
A new casino does not go live until it passes an automatic gate. First come the security scans: known vulnerabilities in the software, leaked passwords, unsafe configuration, and confirmation that the casino is locked down at the pod and network level. Then come the compliance checks, tied to the client's country: identity and anti-money-laundering rules, responsible-gambling limits, a complete audit trail, and the reports the regulator requires. If anything fails, the casino stays switched off and the team is alerted.
The exact rules come from each client's country setting. Brazil, for example, requires CPF identity checks, PIX payments and real-time SIGAP reporting; Malta (MGA) and the UK (UKGC) each have their own identity, payment and reporting requirements. A demo casino runs with no real money and only minimal checks.
map Roadmap to the MVP
- One tenant definition in Git
- Reusable chart values per brand
- Baseline secrets and certificate model
- Namespace, NetworkPolicy and database
- OpenBao, cert-manager and Helm release
- Migrations and smoke test wired in
- Signup, deposit and bet work on tenant B
- Balances and player data stay separate
- Automated isolation test blocks cross-access
- Status, billing and usage views
- Tenant lifecycle actions
- Compliance evidence per jurisdiction
The first milestone is reached when: one command creates a second, fully separate casino from scratch; running that command again changes nothing; a player can sign up, deposit and bet on it; that player's balance stays completely separate from the first casino; and an automated test proves the two casinos cannot reach each other's network, data or secrets.