How the WW Games casino platform is hosted and secured
What an operator is entitled to ask before putting their players and their money on someone else's software: where it runs, who can reach it, what is recorded, what happens when something is lost — and which claims we cannot make.
Where does a WW Games casino run?
On a server rented for your brand alone, running its own application stack and its own database. The hosting provider and the region are agreed per deployment and are not published here.
The machine itself holds almost nothing. There is no repository on it, no application source, no .env files: the server runs Docker, and every key and connection string arrives with the deployment as an encrypted secret rather than as a file somebody left behind on the host. A rebuilt server inherits its configuration from the deployment pipeline, not from whatever was on the old disk.
Public traffic arrives through a Cloudflare tunnel. The server dials out to Cloudflare's edge and publishes nothing of its own, so there is no inbound listener on the origin to find, flood or filter; the host firewall denies incoming traffic apart from administrative access. The domain resolves to the tunnel rather than to the server, and those records are always proxied, so the origin address never appears in DNS. With no port answering and no certificate served from the origin, an internet-wide scanner has nothing to match back to the brand — which is how an origin behind a firewalled but open port is usually found, since its certificate names the domain.
What that buys and what it does not. It removes the target an L3 or L4 attack needs: a volumetric flood has to be aimed at an address, and there is no address published, resolvable or answering. It does not make the host's bandwidth unlimited — if an address is learned some other way, packets aimed at it still land. That is the other reason the provider and the region are not published: it tells a buyer nothing about how the platform is built, and it is worth more to someone attacking a brand than to someone evaluating one.
That the origin refuses direct connections is checked by the deployment smoke test rather than assumed, together with service health and host routing.
Is your data shared with other operators?
No. One brand means one deployment with its own database. There is no shared player table, no shared back office and no shared balance ledger between brands on the platform.
The practical consequence is the one that matters when something goes wrong elsewhere: an incident affecting another operator's brand does not reach your players, because there is no place where both sets of data meet. The same separation is why a brand can be exported as a whole rather than extracted from a shared system.
It is worth asking every vendor this question plainly, because the answer varies and is rarely on the pricing page. Some platforms run all brands in one database with a tenant column, some charge per brand for a separate deployment — the Scalara comparison is an example of the second.
What happens if another brand on the platform is attacked?
Nothing reaches you. Every brand is its own deployment with its own application, database, domain and entry point, so an attack, a block or an outage on one brand has no path into another. There is no shared cluster whose capacity everyone draws on, and no shared address everyone answers on.
This is the difference between separation on paper and separation in practice. Where every brand shares one cluster behind one entry point, a denial-of-service attack aimed at one operator is absorbed by the same machines answering everyone else's players, and a block applied to one domain lands on infrastructure the others are sitting on. The blast radius is the whole platform, and the operator who gets hit is not necessarily the one who caused it.
Here each brand's traffic arrives through its own domain and its own Cloudflare tunnel, in your own Cloudflare account. Behind it: a separate database, a separate back office with its own administrator accounts, and backups written under a key prefix of their own. There is no object one brand can reach that another brand also uses.
What it does not mean: this is not denial-of-service protection, and it does nothing about an attack aimed at you. It means an incident stays the size of one brand instead of becoming the platform's incident — including when the brand having the incident is somebody else's.
The honest trade-off is capacity. With no shared pool, a brand's headroom is the server it runs on: sized for it, resizable, and not quietly borrowed from a neighbour who is having a good month. We would rather size that deliberately than find out the pool was shared on the night it mattered.
How is the database backed up?
A full dump every night, verified before it is uploaded, stored in Cloudflare R2 object storage, verified again in place, and only then are older copies pruned. Several days of copies are kept, and a minimum number is always retained no matter how old they are.
The order is the point. A dump that dies halfway through can land in a bucket looking like a valid object, and nobody finds out until a restore is needed, so nothing is uploaded before the local copy has been checked. Old copies are removed only after the new one is confirmed in place, which means a failed backup run can never be the thing that deletes the last good copy — a plain "delete anything older than N days" rule can, and usually does so on the quietest day of the week.
The honest limit: this is a nightly logical dump, so a restore returns the database to the last nightly copy. Up to a day of writes can be lost. Recovering to an arbitrary moment would need continuous write-ahead log archiving, which we do not run today. A vendor who does not state a recovery point is not thereby better at this; they have just not told you.
A backup also only counts once it has actually been restored. The restore drill is part of the deployment runbook rather than an intention.
Who on your team can do what in the back office?
Access is granted as individual permissions, not as job titles: 56 of them across 24 areas of the back office, assigned per account. A support agent who can read a player's history does not thereby get the ability to move money.
Nineteen operations need more than a logged-in session: a fresh two-factor code entered again at the moment of the action, valid for five minutes. They are the ones where a hijacked session would do real damage — banning a player, setting a balance, granting a bonus or points, deciding a fraud case, approving or declining a payout, and anything that touches other administrators: creating one, changing one, deleting one, resetting someone's password or two-factor, revoking their session.
Players sign in differently. The site supports passkeys — WebAuthn credentials, several devices per player, resistant to phishing in a way a code typed into a page is not — alongside Telegram, Google and email with a password.
- Viewing is separate from acting
- Seeing players, payouts, transactions and balances are separate permissions from adjusting a balance, approving a payout, granting a bonus or banning an account.
- Secrets are their own permission
- Issuing and rotating a tracker key is separate from managing trackers, because rotating a key displays the secret.
- Two-factor is not optional
- Every back-office account has TOTP two-factor, with the secret stored encrypted (AES-256-GCM). Affiliate accounts have their own two-factor.
- Sessions can be revoked
- Every authenticated request resolves its session, so revoking one takes effect immediately rather than when a token happens to expire.
What is recorded when staff act?
Every sensitive action and every authentication attempt: who did it, what the action was, what it was aimed at, whether it succeeded, was denied or errored, the IP and browser it came from, and when. Reading the audit log is itself a separate permission.
Failed logins are recorded too, with the login that was tried, even though no account was authenticated by definition. That is the record that shows someone probing the back office before anything is lost, which is exactly the one most systems do not keep.
The stored payload is sanitised before it is written: no passwords and no two-factor codes end up in the log. An audit trail that quietly accumulates credentials is a new problem rather than a control.
Outcomes are recorded as success, denied or error rather than as a single "happened" flag. A denied action is the interesting one — it is what an account trying to exceed its permissions looks like.
Is the platform load tested?
Yes, internally, against the path that actually carries money: the seamless-wallet spin, which is a signed debit of the bet followed by a credit of the win for the same round — not a simple page request.
The harness fails a run if the 95th percentile exceeds 400 ms or more than 1% of requests error, so a run either meets that standard or it is a failure rather than a chart. Tests run against a cluster of backend replicas behind a balancer, which is the shape of a production deployment rather than a single process on a laptop.
We do not publish a throughput number, because a number without the hardware it was measured on is marketing. The tuning profile — replica count, database pool size, connection limits — is chosen from the CPU and memory of the server a brand actually runs on.
These are our own tests. They are not an external audit, and we do not describe them as one.
What does WW Games not claim?
No third-party certifications: no GLI-19, no ISO 27001, no PCI DSS, and no published external penetration test. If certification is a requirement for your market or your auditor, a larger vendor is the right answer and we will say so.
Certification matters most in regulated markets, where a licensed operator has to show an auditor a document rather than a description. The SoftSwiss comparison sets out what a vendor with those certificates offers and where that leaves us.
Licensing is the operator's responsibility and is not covered by anything on this page. WW Games does not hold or sublicense a gambling licence, and can put you in touch with licensing providers.
Everything above is checkable in the way that matters: ask us to demonstrate it in the back office during a walkthrough, and ask the same questions of every other vendor you are talking to. The answers vary more than the marketing does.
Read next
Security questions operators ask
Does my brand share a database with other casinos?
No. Each brand runs as its own deployment with its own database, so there is no shared player table, back office or ledger between brands.
Is the server's IP address exposed to attackers?
Not through the site. The origin sits behind a Cloudflare tunnel with no published ports, and the domain resolves to the tunnel rather than to the server, so the address is neither in DNS nor discoverable from a certificate on an open port. That removes the target an L3 or L4 flood needs; it does not make the host's bandwidth unlimited if an address is learned some other way.
If another casino on the platform is attacked, does it affect mine?
No. Each brand runs as its own deployment with its own domain, entry point and database, so there is no shared cluster or shared address through which an attack on one brand reaches another. It is not denial-of-service protection for your own brand — it keeps someone else's incident from becoming yours.
Where is the data hosted?
On a server rented for your brand, with the provider and region agreed per deployment. We do not publish either, because it helps someone attacking a brand more than someone evaluating the platform.
How often is the database backed up, and how much could be lost?
Nightly. A restore returns the database to the last nightly copy, so up to a day of writes can be lost. Point-in-time recovery would require continuous write-ahead log archiving, which we do not run today.
Is two-factor authentication supported?
Yes, and it is mandatory for back-office accounts, with the secret stored encrypted. Nineteen sensitive operations require the code again at the moment of the action, valid for five minutes. Players can use passkeys alongside Telegram, Google and password sign-in.
Can I see who did what in the back office?
Yes. Every sensitive action and authentication attempt is recorded with the account, the action, the target, the outcome, the IP and the browser. Access to the log is its own permission.
Is WW Games ISO 27001 or PCI DSS certified?
No. WW Games holds no third-party security certifications and publishes no external penetration test. If your market or your auditor requires them, that is a reason to choose a certified vendor.
Ask us to show it
We will walk through permissions, the audit log and the back office on a call, on a live deployment rather than on slides.