# kinematic > How to set up your casino in the kinematic dashboard, deploy your game server to your own Cloudflare account, and connect the games to your site, your player sessions and your wallet. > ## Agent Instructions > These are the customer docs for kinematic, a name written in lowercase except at the start of a sentence. Kinematic provides provably fair casino games, served to a casino's site by a game server: a Cloudflare Worker that the kinematic dashboard deploys into the casino's own Cloudflare account. > Never put SESSION_SECRET or WALLET_SECRET in code, prompts, logs, commits or chat. Read them from environment variables and ask the person you work with to set them. The dashboard's Integration page shows each secret once. > Values such as lucky-star, luckystar.example, og-rgs-lucky-star.luckystar.workers.dev, games.luckystar.example and player_48213 are examples. Use the casino's own casino ID, game server origin, element tag, session issuer and currencies: the Instructions for your coding agent on the dashboard's Integration page hold them, or ask the person you work with. > To debug, start at https://docs.kinematic.run/troubleshooting and https://docs.kinematic.run/reference/errors. The wallet contract is at https://docs.kinematic.run/api/wallet.openapi.yaml. > Sandbox bets are recorded on Solana devnet. Live game servers record nothing on Solana until the audited mainnet program is deployed. # Use an AI agent Source: https://kinematic.mintlify.app/agents Copy the dashboard's instructions for your coding agent, keep the secrets yourself, check them by fingerprint, and give the agent these docs as Markdown, llms.txt or an MCP server. A coding agent can do most of an integration in your codebase: the embed, the session endpoint, your Content Security Policy and, for a live casino, the wallet endpoints. The dashboard writes the instructions for it, with your casino's values filled in, and these docs are published in forms agents read directly. ## Copy the instructions from the dashboard At the top of the **Integration** page, **Instructions for your coding agent** holds a Markdown text for your agent. As the page says: `Paste them into the agent you use. They cover every step below with your casino's values, and they hold no secrets.` 1. Choose what the instructions cover: **All steps**, **Embed**, **Session tokens** or **Wallet**. 2. Select **Copy instructions**. The text of the scope you chose goes to your clipboard. 3. Paste it into the agent you use, in your site's repository. The dashboard fills the text in when you open the page, so copy it again after you change your settings or deploy another game server. ### What the instructions contain With **All steps**, the text has these sections, in order: | Section | What it holds | | - | - | | `# Lucky Star: integrate the casino games` | The task, and an instruction to read [llms-full.txt](https://docs.kinematic.run/llms-full.txt) first and to follow the docs over anything the agent remembers. | | `## Values from the kinematic dashboard` | Your casino ID, game server origin, element tag, games, session issuer, currencies with their scales, allowed origins, mode and wallet URL. A value you have not set yet becomes an instruction to ask you, such as `Wallet URL: not set yet. Ask me for it; I set it on the dashboard's Settings page.` | | `## Secrets` | The names `SESSION_SECRET` and `WALLET_SECRET`, the rules for handling them, and their fingerprints. Never their values. | | `## 1. Put the games on a page` | The embed with your values and an `onError` handler, the rules for the element, and your Content Security Policy directives. | | `## 2. Sign session tokens` | `POST /api/game-session`, the claims with your values, and a Node signer with no dependencies. | | `## 3. Connect the wallet` | The three endpoints under your wallet URL, the signature check, idempotency, receipts and retries. | | `## Check your work` | The checks the agent runs, and the ones it asks you to run on the dashboard. | | `## Docs` | The docs pages for each step. | **Embed**, **Session tokens** and **Wallet** hold the values and the step for that part only. **Embed** has no secrets section; **Session tokens** names only `SESSION_SECRET`, and **Wallet** only `WALLET_SECRET`. ## Keep the secrets yourself Your casino has two secrets: `SESSION_SECRET`, which signs session tokens, and `WALLET_SECRET`, which checks your game server's wallet calls. The **Integration** page shows their values once, when an owner or an admin selects **Reveal secrets**. * Put them in your servers' environment yourself, through your secret manager or your hosting settings. * Never paste them into a chat with an agent, a prompt, a ticket or a commit. The instructions tell the agent the same: read the secrets from the environment, never ask you to paste one into the chat, never hard-code, log, print or commit one, and stop and name any variable that is missing. ### Check a secret by its fingerprint The agent checks that a variable holds the right secret without seeing it, by computing its fingerprint: the first 12 hex digits of HMAC-SHA256 over the text `kinematic-secret-fingerprint`, keyed with the secret. The instructions give the fingerprint of each secret, and the **Secrets** table on **Integration** shows the same values. ```js fingerprint.mjs theme={null} import { createHmac } from "node:crypto"; const fingerprint = (secret) => createHmac("sha256", secret).update("kinematic-secret-fingerprint").digest("hex").slice(0, 12); for (const name of ["SESSION_SECRET", "WALLET_SECRET"]) { const secret = process.env[name]; console.log(name, secret ? fingerprint(secret) : "is not set"); } ``` The script prints only fingerprints. If one differs from the dashboard's, the variable holds another value. ## When the agent finishes The instructions end with `When you finish, list what you changed, the environment variables I must set and where, and the checks you could not run.` Read that list, then: 1. Set the environment variables it names, yourself. 2. Run the checks it could not run, such as opening the page in a browser and pressing **BET**. 3. Confirm that the bet appears on [Live](/dashboard/live-monitor). 4. Once your casino is in live mode with your wallet URL, run **Check my wallet** on **Integration**. See [Test your integration](/integrate/testing#check-my-wallet). ### Review what the agent wrote Before you deploy, check these points in its changes: * The session endpoint answers only for a signed-in player, and `sub` is that player's stable ID. * Tokens expire within an hour, and the endpoint passes the element's `publicKey` into `cnf` unchanged. * No secret appears in code, logs, client bundles or the repository. * The wallet verifies every signature over the raw body before it parses JSON. * The wallet records each receipt in the same transaction as the balance change, and answers a repeated ID with the original receipt. Then run the checks in [Test your integration](/integrate/testing). ## Give your agent the docs | Form | Address | Use it for | | - | - | - | | llms.txt | [docs.kinematic.run/llms.txt](https://docs.kinematic.run/llms.txt) | An index of every page with its description. | | llms-full.txt | [docs.kinematic.run/llms-full.txt](https://docs.kinematic.run/llms-full.txt) | Every page in one Markdown file. | | Markdown pages | Add `.md` to any page's address, such as [docs.kinematic.run/integrate/wallet.md](https://docs.kinematic.run/integrate/wallet.md), or request it with `Accept: text/markdown`. | One page at a time. | | MCP server | `https://docs.kinematic.run/mcp` | Search and read these docs from the agent while it works. | | Skill | `npx skills add https://docs.kinematic.run` | Install these docs as a skill in agents that support skills. | | OpenAPI | [docs.kinematic.run/api/wallet.openapi.yaml](https://docs.kinematic.run/api/wallet.openapi.yaml) | The wallet contract as OpenAPI 3.1. | The menu at the top of every page copies the page as Markdown, opens it in ChatGPT, Claude or Perplexity, and connects the MCP server to Cursor or VS Code. ### Connect the MCP server ```bash Claude Code theme={null} claude mcp add --transport http kinematic https://docs.kinematic.run/mcp ``` ```json Cursor (mcp.json) theme={null} { "mcpServers": { "kinematic": { "url": "https://docs.kinematic.run/mcp" } } } ``` ```json VS Code (.vscode/mcp.json) theme={null} { "servers": { "kinematic": { "type": "http", "url": "https://docs.kinematic.run/mcp" } } } ``` The server can search these docs, read pages and report a page that looks wrong. It cannot see your casino, your settings or your secrets. ## When something fails The dashboard's instructions build an integration. To have an agent find the cause of a problem in an existing one, give it this prompt: ```text Debugging prompt wrap theme={null} Our kinematic integration has a problem. Read https://docs.kinematic.run/troubleshooting and https://docs.kinematic.run/reference/errors, then find the cause in our code and fix it. Ask me for what I see if you cannot see it yourself: the browser console's errors, the game server's answer in the Network tab, or the sentence the kinematic dashboard shows. Check our session endpoint, our embed, our Content Security Policy and, if we are live, our wallet endpoints against the docs. Do not print, log or change any secret. If the cause is a setting in the kinematic dashboard, tell me which setting to change instead of guessing. ``` ## Agents in your browser When you are signed in to the dashboard in a browser that supports [WebMCP](https://webmachinelearning.github.io/webmcp), an agent in that browser can call these tools on your casino's pages: | Tool | What it returns | | - | - | | `get_casino_status` | Your casino's name, ID and mode, the launch steps, each game server's address, state, release and last report, and your return to player. | | `get_integration_instructions` | The instructions the **Integration** page copies, for all three steps or for `embed`, `session` or `wallet`. They contain no secrets. | | `find_bet` | A bet by its ID, or a Solana transaction by its signature, as the lookup on the **Live** page shows it. | | `list_pages`, `open_page` | Your casino's pages, and the page the agent asks to open. | The tools change nothing in your casino, and every member of your team can use them. No browser turns WebMCP on by default yet; in Chrome, turn on `chrome://flags/#enable-webmcp-testing`. # Your game server Source: https://kinematic.mintlify.app/concepts/game-server Your game server is one Worker in your own Cloudflare account, with its settings from the dashboard, public routes, reports and automatic updates. Your game server is one Cloudflare Worker in your own Cloudflare account. The dashboard deploys it through Cloudflare's API with the access you grant when you connect Cloudflare. Its code is a release that kinematic builds; your settings come from the dashboard. ## What you see in Cloudflare * A Worker named `og-rgs-` unless you chose another name, for example `og-rgs-lucky-star`. * Its address: `https://og-rgs-lucky-star..workers.dev`, or a hostname of your own. * Its Durable Objects, which hold each player's bets, the sandbox test balances, your VRF keys and the game server's Solana key. * Its variables and secrets, which the dashboard sets on every deploy. Your game server runs and stores its data in your account, under your agreement with Cloudflare and at your cost. > [!WARNING] > > Change your game server's settings in the dashboard, not in Cloudflare. Each deploy from the dashboard replaces the Worker's code, variables and secrets. Deleting the Worker or its Durable Objects deletes your players' bet records and your VRF keys. ## Settings without redeploying The dashboard signs your settings: allowed origins, session issuer, wallet URL, currencies and limits, games, return to player, appearance and whether new bets are allowed. Your game server checks the signature, applies them and keeps the last good settings. It fetches them about once a minute, and at once when you save. Your game server refuses settings it must not apply and keeps serving with its last good ones. On the **Game server** page, its card notes the refusal and **Check now** gives the reason. It refuses: * settings for the other mode, until you redeploy the game server in that mode; * a new decimal scale for a currency it already serves, because balances and receipts stay in the scale they were made in. ## Routes | Route | Who calls it | | - | - | | `GET /health` | Anyone. Reports the service (`og-rgs`), the rules ID, the mode (`sandbox`, or `operator` for live), whether new bets are allowed, the release, the settings revision and the Solana record's state. | | `GET /v1/catalog` | Anyone. Your payout tables, your currency's scale and limits, your VRF keys and the release. Add `?currency=` when you serve several currencies. | | `GET /element/v1/loader.js` | Your pages. The element, with your games and theme. Only allowed origins can load it. | | `/v1/stream`, `/v1/commands` | The element, with a session token. Bets, actions and balances. | | `/v1/history`, `/v1/evidence/`, `/v1/math` | The element, with a session token. The player's rounds and proofs. | | `POST /v1/wallet-events` | Your backend, signed with `WALLET_SECRET`. Tells the game server a balance changed outside the games. | | `/v1/ops/...` | The dashboard, signed with a key only the dashboard holds. Status, settings refresh, the live feed and Solana registration. | `GET /health` is the address to watch from your own monitoring: ```bash theme={null} curl -s https://games.luckystar.example/health ``` ```json theme={null} {"service":"og-rgs","rules":"og-v1-h512","mode":"sandbox","enabled":true,"release":"…","control":{"revision":12,"issuedAt":1793629805120},"chain":{"network":"devnet","paused":null,"…":"…"}} ``` ## What it reports Every 60 seconds your game server posts counts to the dashboard: bets, settled rounds, refusals and errors by code, wallet round trips, the newest errors, the Solana record's state, and totals wagered and paid by game and currency. The reports carry no player names or player IDs. Kinematic keeps them for 30 days. The dashboard's **Live** page reads the newest bets from your game server's memory while you watch it. Kinematic stores no individual bets: each bet's records stay in your game server. ## Updates New releases deploy to your game server automatically: the dashboard checks every 5 minutes and updates each deployed game server that has **Update automatically** on, in the mode it already runs, so an automatic update never switches modes. You can turn automatic updates off for a game server on the **Game server** page, and update it yourself with **Update to** and the release. A failed automatic update to the same release is retried after an hour. ## Solana address When it records bets, your game server generates its own Solana key and keeps it in its storage. That address signs and pays for every record and registers your VRF keys on chain. Kinematic keeps the address funded: you never fund it. # How it works Source: https://kinematic.mintlify.app/concepts/how-it-works A kinematic casino has four parts, set up from the dashboard. This page shows where each one runs and what happens between a player pressing BET and the result. A kinematic casino has four parts: the games element on your page, your session endpoint, your game server in your Cloudflare account, and your wallet. The dashboard configures the game server and shows what it reports. ```mermaid theme={null} %%{init: {"theme": "neutral"}}%% flowchart LR subgraph Site["Your site"] E["Games element"] S["Session endpoint"] W["Wallet"] end subgraph CF["Your Cloudflare account"] G["Game server"] end D["Dashboard"] SOL["Solana"] E -- "session token" --> S E -- "bets over WebSocket" --> G G -- "debit, credit, balance" --> W G -- "reports" --> D D -- "signed settings" --> G G -- "records (sandbox: devnet)" --> SOL ``` ## The parts **The games element.** A custom element, `` unless you rename it, that your page imports from your game server. It draws the games, signs each bet with a key kept in the player's browser, and shows the Provably fair dialog. **Your session endpoint.** Your backend signs a short-lived token for the signed-in player. The game server trusts the token because only your backend and your game server know `SESSION_SECRET`. **Your game server.** One Cloudflare Worker that the dashboard deploys into your Cloudflare account. It serves the element, keeps each player's bets in its own storage in your account, calls your wallet, and computes every outcome with a VRF key it generated itself. That key never leaves your game server: kinematic holds no key that decides an outcome. **Your wallet.** In live mode the game server debits stakes from your wallet and credits payouts to it. Your wallet stays the only place a balance changes. In sandbox mode the game server keeps test balances instead. **The dashboard.** It signs your game server's settings, which the game server fetches about once a minute or at once when you save. It deploys new releases, and it shows the counts, errors and recent bets your game server reports. It never handles a bet. ## One bet ```mermaid theme={null} %%{init: {"theme": "neutral"}}%% sequenceDiagram participant B as Player's browser participant G as Game server participant W as Your wallet B->>G: Bet, signed by the player, with the hash of a secret seed G->>W: Debit the stake W-->>G: Applied G-->>B: Signed acceptance B->>G: Reveal the seed G->>G: VRF proof and outcome G->>W: Credit the payout (wins only) G-->>B: Result with its proof ``` 1. **Bet.** The browser picks a fresh random seed and keeps it secret. It signs the bet, with the hash of the seed, using the player's device key, and sends it to your game server. 2. **Debit.** The game server checks the session, your limits and the signature, stores the bet, and debits the stake from your wallet. Bets that arrive together go out in one debit. 3. **Acceptance.** Once the debit applies, the game server signs its acceptance of the bet. The acceptance names the VRF key that will decide it. 4. **Reveal.** Only after the acceptance arrives does the browser send the seed. Until then nobody, including you and kinematic, can know the outcome. 5. **Outcome.** The game server computes the VRF proof over the bet and the seed with your casino's key, and the game engine turns the VRF output into the result. A win is credited to your wallet as its gross payout. 6. **Result.** The browser receives the result with the seed, the proof and the output, and can recompute the outcome itself. In sandbox, each bet is also recorded on Solana devnet after it settles. Play never waits for the record. ## What survives a failure * The game server stores each bet before it acknowledges it. A bet resent after a lost connection is recognized by its ID and never placed twice. * Each wallet call keeps its ID until your wallet answers it. After a timeout or an error the game server sends the same call again, so a stake is never debited twice and a payout is never lost. * The browser keeps a pending bet's seed until the bet settles, and sends it again after a reload or a reconnect. * An accepted bet whose seed never arrives within 24 hours is abandoned, and its stake is refunded. * Stopping new bets never stops a bet already placed: it still settles and pays. [Provably fair](/concepts/provably-fair) explains what a player can check, and [Your game server](/concepts/game-server) what runs in your account. # Provably fair Source: https://kinematic.mintlify.app/concepts/provably-fair Each outcome comes from your casino's VRF key, the player's signed bet and a seed revealed only after acceptance, and players check every step in the Provably fair dialog. Every outcome is the output of a verifiable random function (VRF): your casino's VRF key evaluated over the player's own signed bet and a seed that the player's browser keeps secret until your game server has accepted the bet. The game engine turns that output into the result. Anyone with the bet's records and the published engine can recompute it. ## The guarantees * **Neither you nor kinematic chose the outcome.** The VRF output is the only valid output for the player's signed bet and seed under the key the acceptance named, and the engine computes the result from it. * **Your casino could not know the outcome before it accepted the bet.** The seed stays in the browser until the signed acceptance arrives, and the acceptance fixes the key, the game rules, the engine build and the terms. A refusal after acceptance is itself signed: the bet then ends refunded, never lost. * **The player authorized the bet and each action.** Every bet and action carries the player's signature with a key kept in their browser. ## Your VRF key Your game server generates its VRF key the first time it needs one, and keeps the secret in its own storage in your Cloudflare account. No route returns it, nothing logs it, and nobody can set or read it, kinematic included. The game server publishes every key it has used, with its validity window, at `GET /v1/catalog` under `vrf.keys` and in every signed game manifest. A rotation lists the next key two minutes before it takes over, so every browser knows it in advance. Retired keys stay listed: each bet stays verifiable under the key its acceptance named. ## What players check The element's **Provably fair** button opens a dialog in your theme with three tabs. **Proofs** checks each of the player's bets in the browser, one row per check: * the player's signature on the bet and on each action, * your game server's signatures on each record, and the links between records, * the acceptance came before the reveal and names the bet, its seed hash and its key, * the revealed seed matches the hash the player signed, * the VRF proof verifies under your key, and the output derives from it, * the engine build that settled the bet recomputes the same result, * once recorded, the bet's Solana transaction contains this bet. A bet still in play shows as waiting for its outcome, not as verified. **Odds** shows the game's return to player and the chance of every payout, computed in the browser from your signed payout table at the settings on screen. Its check rows confirm that the table matches the engine's code and carries your game server's signature. See [Return to player](/concepts/return-to-player). **Client seed** lets the player add their own text to every later bet's seed, and lists your VRF keys with each key's ID checked in the browser. ## Solana records In sandbox, your game server records every bet whose proof is disclosed on Solana devnet, after the bet settles. Live game servers record nothing on Solana until the audited mainnet program is deployed. A record is a transaction of the `og-vrf-record` program, signed by your game server's own Solana address. Before it records a bet, the program checks the VRF proof against the key your game server registered for that time. Anyone can then read from the chain that your key produced a valid proof for that bet, and which receipt your game server committed to, at the transaction's time. The dialog's Proofs tab links the transaction and checks that it matches the bet. A record adds a public, timestamped commitment. It does not prove that every bet was recorded, that the record's time is the bet's time, or that a payout reached a wallet. ## What the proofs do not prove * That a winning round's payout reached the player's wallet. A credit can be late; your wallet's ledger is the record of payment. * That the operator is solvent, who the player is in the real world, or that the server's clock is fair. * That every bet the server received was accepted. A server can refuse a bet before it accepts it. * That a server which stops answering after a reveal paid the win. Such a bet is abandoned after 24 hours and its stake refunded. One risk sits with the casino: an insider who holds the casino's VRF key and colludes with a player who shares their seed before betting could know outcomes in advance. Protect access to your Cloudflare account as you would any system that decides money. # Return to player Source: https://kinematic.mintlify.app/concepts/return-to-player Choose your casino's return to player of 99%, 98%, 97% or 96%, which games follow it, how their payouts change, and how players see and verify it. Your casino has one return to player (RTP), which you choose on the **Games** page: 99% (the default), 98%, 97% or 96%. That is a house edge of 1%, 2%, 3% or 4%. ## Which games follow it | Games | At your return | | - | - | | Dice, Limbo, Crash, Mines, Pump, HiLo | Every multiplier follows a formula with your edge in it. | | Wheel | Every layout returns exactly your figure. | | Plinko, Keno, Diamonds | Each payout table is derived from its 99% table for your figure. | | Roulette | Keeps its single-zero rules: 97.30% on every bet. | | Baccarat | Keeps its fixed payouts: Player 98.77%, Banker 98.94%, Tie 85.88%. | | Blackjack | Keeps its fixed rules: 99.49% with basic strategy. | ## How payouts change * **Formula games.** Dice, Limbo, Crash, Mines, Pump and HiLo compute their multipliers with `10000 − edge`, in basis points, where the 99% games use 9900. Over 50.00, Dice pays 1.98× at 99%, 1.96× at 98%, 1.94× at 97% and 1.92× at 96%. * **Wheel.** Every paying segment pays a little less, by the same rule for every layout, so each of the 15 layouts returns exactly your figure. * **Plinko, Keno and Diamonds.** Each 99% table is scaled to your figure and rounded down to the hundredth, then the entries furthest below their scaled value are raised one hundredth at a time while the table stays at or below your figure. Every derived table returns at most your figure and within 0.12 points of it, and no payout is higher at a lower return. * **At 99%** every payout is the same as before the options existed. Multipliers are paid in hundredths, rounded down, so some settings return a little less than your headline figure: some Dice targets, Mines and Pump cash outs, and Crash's small cash outs. The engine also rounds every payout down to the currency's minor unit. ## What players see The return is signed into your catalog and into the manifest that every bet names. Players check it in the **Odds** tab of the Provably fair dialog, which computes the game's return and the chance of every payout in the browser from your signed table, at the settings on screen. The checks under it confirm that the table matches the open engine code, that your game server signed it, and that every casino on the same version at your return pays the same table. Each game returns this at each option. The **Games** page also lists each game's return under `What each game returns at
`. | Game | 99% | 98% | 97% | 96% | | - | - | - | - | - | | Dice | 98.98% | 97.98% | 96.98% | 95.98% | | Limbo | 99.00% | 98.00% | 97.00% | 96.00% | | Crash, by cash out | 98.03% to 99.00% | 97.04% to 98.00% | 96.05% to 97.00% | 95.06% to 96.00% | | Mines, at every setting | 98.28% to 99.00% | 97.28% to 98.00% | 96.25% to 97.00% | 95.30% to 96.00% | | Pump, at every setting | 98.28% to 99.00% | 97.28% to 98.00% | 96.25% to 97.00% | 95.30% to 96.00% | | HiLo, on its first call | 98.46% to 99.00% | 97.31% to 98.00% | 96.46% to 97.00% | 95.38% to 96.00% | | Plinko, at default settings | 98.99% | 98.00% | 97.00% | 96.00% | | Keno, at default settings | 99.04% | 98.00% | 97.00% | 96.00% | | Wheel, at default settings | 99.00% | 98.00% | 97.00% | 96.00% | | Diamonds, at default settings | 99.00% | 98.00% | 97.00% | 96.00% | | Roulette | 97.30% | 97.30% | 97.30% | 97.30% | | Baccarat | Player 98.77%, Banker 98.94%, Tie 85.88% | the same | the same | the same | | Blackjack, with basic strategy | 99.49% | 99.49% | 99.49% | 99.49% | Where the player decides how a round plays, the return is a range across the ways to play. ## Changing it A change applies to new bets. Bets accepted before it settle and verify at the return they were placed under. A bet that a player's browser had already signed under your previous table is refused once with `authorization_binding`, and the player's next bet is signed under the new one. # Sandbox and live Source: https://kinematic.mintlify.app/concepts/sandbox-and-live A casino runs in sandbox, with test balances and Solana devnet records, or live, with your wallet and real money. Your casino has one mode, sandbox or live, and each game server runs in the mode it was deployed in. Every casino starts in sandbox. You choose the mode under **Mode** in [Settings](/dashboard/settings#mode), which describes the two cards like this: * **Sandbox**: `Players bet test credits from a wallet inside your game server. Bets are recorded on Solana devnet.` * **Live**: `Your game server debits and credits your own wallet, with real balances.` | | Sandbox | Live | | - | - | - | | Balances | Test balances kept by the game server: 100,000 of each currency per player to start (100,000.00 TEST, 100,000 BTC). They have no value. | Your wallet, through `/debit`, `/credit` and `/balance`. | | Wallet URL | Optional. If you enter one, it must be https. | Required, https. | | Allowed origins | `https` or `http` | `https` only | | Solana record | Each bet's proof is recorded on Solana devnet. | Nothing is recorded on Solana until the audited mainnet program is deployed. | | Price | Free | A flat fee per quarter, paid upfront. See [Billing](/dashboard/billing). | Everything else is the same in both modes: the games, the element, session tokens, the proofs, your settings and the dashboard's pages. ## Sandbox balances The game server keeps one test balance per player and currency, created at 100,000 units of the currency the first time it reads that player's balance: 10,000,000 minor units at a scale of 2, 100,000,000,000 at a scale of 6. At a scale above 10 it starts at the largest amount a limit can hold, 9,999,999,999,999,999 minor units. Your wallet is never called. Each new `sub` in your session tokens gets a fresh balance, and a balance that exists keeps its amount. **TEST** is the sandbox's play-money currency: the dashboard selects it for you when you choose your currencies in a sandbox casino, and each test player starts with 100,000.00 TEST. You can add other currencies too; in sandbox their balances are test balances as well. When a game server switches to live, every player starts fresh, including a player ID that played in sandbox: the balance is the one your wallet reports, and nothing from sandbox reaches your wallet, not even a sandbox payout still on its way at the switch. Sandbox bets, test balances and Solana devnet records stay with the sandbox, and the **Live** page and **Home** show live bets only. If you switch back to sandbox, the test balances and sandbox history are where you left them. ## Switching to live You switch under **Mode** in **Settings** by choosing **Live** and entering your **Wallet URL**. **Live** opens once your casino is set up: until you finish the first-run steps, the card is disabled and the section says `Live mode opens once your casino is set up.` Live mode accepts only https pages, so the same save moves each `http` origin of a public site to https and removes the other origins that are not https, such as `localhost`; the section lists them before you save. See [Settings](/dashboard/settings#mode). Your game servers keep running in sandbox until you redeploy each one: a game server only applies the settings of the mode it was deployed in. **Settings** lists the game servers still in the other mode, and on **Game server** each one says `This game server runs in sandbox mode and your casino is set to live. Redeploy it to switch.` Select **Redeploy in live mode**; once the deploy finishes, the game server takes your live settings and calls your wallet. Automatic updates never switch a game server's mode. [Go live](/dashboard/go-live) has the full sequence. ## Stopping new bets In both modes you can stop new bets on the **Game server** page with **Stop new bets**. Bets already placed still reveal, settle and pay; only new bets and Blackjack's extra stakes are refused, with `bets_disabled`. # Appearance Source: https://kinematic.mintlify.app/dashboard/appearance Theme the games from your website, upload your logo, name the element and fine-tune colours, shape and type, with a live preview of every change. The **Appearance** page sets how the games look on your site. It has four parts, in this order: **Theme from your site**, **Logo**, **The element** and **Fine-tuning**. Beside them (or under the theme section on a narrow window) is the preview: the real games in your theme, playing scripted rounds. When more than one game is on, a switcher above it chooses the game to preview. The note under it reads `You see scripted rounds with demo credits. Nothing here reaches your game server.` Owners and admins change these settings. Other members see the page with the banner `Only the casino's owners and admins can change these settings.` ## Theme from your site Type your site's address in the address bar, after its fixed `https://` prefix (for example `luckystar.example`), and select **Suggest themes**. Nothing on your site changes. The run takes about a minute, and you can use other pages of the dashboard meanwhile. You see four steps as they happen: 1. Opening `` 2. Reading its colours and fonts 3. Looking for its logo 4. Writing three themes Select **Cancel** to stop the run. When the site has been read, the page shows its screenshot and what it found: its colours, its fonts, its main button and its logo. Three themes follow, **Matched**, **Bold** and **Quiet**, each with one sentence written for your site: * **Matched** stays as close to your site as it can. * **Bold** lets your brand carry more of the frame, with deeper coloured surfaces. * **Quiet** keeps a restrained, neutral frame with modest corners. Choose a theme to see it on the preview. Nothing changes for your players until you use it. If the scan found a logo, it shows on your site's header colour with the switch **Use this logo**; when your casino already has a logo, the hint says `It replaces your current logo.` * **Use this theme** saves the theme, and the logo if you switched it on, at once. The page confirms with `The theme is saved. Your game server gets it within a minute.` * **Keep my current look** forgets the suggestion and saves nothing. Once your casino has a theme, the section offers **Get a new suggestion from your site** instead. ### Upload a screenshot instead Select **Upload a screenshot instead** at any time to get the three themes from a screenshot of your home page: a PNG or JPEG up to 4 MB, taken at full width. The run then shows one step, Writing three themes from your screenshot. The page also offers the upload when your site is blocked. The screenshot window dims and says why: your site showed a Cloudflare challenge, a bot check or another security check, a notice for the region the scan's browser runs in, a captcha or an error page instead of its page, or its page stayed empty. You can scan your site 10 times an hour and ask for 30 suggestions an hour for each casino. The setup wizard's look step offers the same themes, from the address you gave when you created the casino. ## Logo Your page can show your logo above the games. Select **Upload a logo** and choose an SVG, PNG, JPEG, GIF, WebP or AVIF up to 512 KB. It is kept as a PNG of at most 512 × 160 pixels and 24 KB, and it saves as soon as you upload it, apart from **Save**. **Replace** and **Remove** change it later. The games do not draw it: your page reads it from the loader as `config.logo` for its header. ## The element Players' browsers can see the element's name, so it never carries kinematic's. **Element name** is the tag your page writes where the games show, `og-game` by default. You can choose your own, such as `luckystar-games`: * At most 40 characters, starting with a lowercase letter, then lowercase letters, digits, hyphens or underscores. * No dot: `Leave out the dot. The loader finds your elements with a CSS selector, and a dot there starts a class name.` * At least one hyphen: `A custom element name needs a hyphen, such as casino-game.` * Not a name HTML reserves, such as `font-face`. * Not containing kinematic: `Players see this name, so it cannot contain kinematic.` When you change it, change the tag in your pages too. The [embed](/integrate/embed) uses whichever tag you choose. The switch **Show the kinematic mark while a game loads** is off by default, so your games stay white-label. ## Fine-tuning Open **Fine-tuning** to set the colours, shape and type by hand. **Start from** offers six presets: Default, Dark, Verdant, Harbor, Crimson and Aurum. A preset replaces every value below it, and nothing changes for your players until you save. The settings come in three groups. Under **Colour**, **More colours** shows the colours that follow the accent and scheme unless you set them. Each colour has a swatch and a hex field, and **Default** clears a value you set. When the games adjust a colour for contrast, the page shows the colour they use. | Group | Setting | What it sets | | - | - | - | | Colour | Accent | Your brand colour. The bet key, highlights and the screen's line of light come from it. | | Colour | Scheme | Light or Dark: the panels around the game screen. | | Colour | Game screen | Dark or Follows the scheme. Dark keeps the play area dark in both schemes. | | More colours | Background | The level behind the game's frame. | | More colours | Surface | The frame: title bar, controls and toolbar. | | More colours | Text | Main text on the frame. | | More colours | Secondary text | Labels and captions. | | More colours | Bet key label | The label on the bet key. | | More colours | Accent highlight | The lighter accent for highlights. | | More colours | Win | Win digits, the win plate and history. | | More colours | Danger | Hazards and errors only. | | Shape | Corner radius | The game's outer corners, 0 to 48 px. | | Shape | Roundness | Controls from sharp (0) to round (1). The bet key is a pill from 0.5. | | Shape | Density | Comfortable or Compact. Compact tightens the controls for short embeds. | | Type | Font | Your text face as a CSS font list, such as `Inter, sans-serif`. Geist by default. | | Type | Numbers font | The face for amounts and multipliers. Geist Mono by default. | Your page loads these fonts. The preview shows them only if your computer has them. ## Save your changes One **Save** keeps the element name, the mark and the theme together. A logo upload and **Use this theme** save on their own. While changes are unsaved, a bar at the foot of the window says `You have unsaved changes.` with **Discard** and **Save**. Leaving the page then asks `Leave without saving?`, with **Stay** and **Leave without saving**. After a save the page says `Saved. Your game server gets the new settings within a minute.` ## Your page can override the theme A `--og-*` token set inline on an element, in its `style` attribute or with `element.style.setProperty()` before `connect()`, wins over the dashboard's value for that element. So does a call to `applyTheme()`. A token set in your stylesheet loses to the dashboard's value unless it is `!important`. [Element](/reference/element#styling) lists every token. # Billing Source: https://kinematic.mintlify.app/dashboard/billing You pay your tier's flat fee a quarter at a time, upfront, in USDC, USDT or SOL through Solana Pay, and only entirely unused months are refundable. The sandbox is free. When your casino goes live, you pay your tier's flat fee a quarter at a time, upfront, in USDC, USDT or SOL. The fee does not depend on your bets or your revenue, and there are no bet limits per tier. The **Billing** page shows your plan, your declared deposits, your invoices and your refunds. Every member sees the figures; owners and admins pay and change the declared deposits. Other members see `Only the casino's owners and admins can pay and change the declared deposits.` ## Your plan The top of the page shows three figures: * **Tier**: your tier, and the monthly deposits it comes from. * **Fee**: your monthly fee, and what it comes to each quarter. * **Paid through**: the last day of your paid time and how many days are left, or `Not paid yet`. At most one banner shows above them: | Banner | When | | - | - | | `Your casino is in the sandbox, which is free. You pay for a quarter when you go live.` | Your casino is in the sandbox and has no paid quarter. | | `You cannot pay yet, because kinematic's billing wallet is not set up. Your tier and price are below.` | Payments are not open on the dashboard yet. | | `Declare your monthly deposits in setup to see your tier and price.` | You have not finished setting up your casino. **Continue setup** takes you back to it. | | `No paid quarter covers today.` | Your casino is live and no paid quarter covers today. Owners and admins see **Pay now**. | ## Tiers Your tier follows what your players deposit in a typical month. Each tier includes its lower edge: exactly $250,000 is in $250K–\$500K. | Tier | Monthly fee | Quarter | | - | - | - | | Under \$250K | \$263 | \$789 | | $250K–$500K | \$604 | \$1,812 | | $500K–$1M | \$1,136 | \$3,408 | | $1M–$2.5M | \$2,134 | \$6,402 | | $2.5M–$5M | \$4,912 | \$14,736 | | $5M–$10M | \$9,230 | \$27,690 | | \$10M and up | \$17,343 | \$52,029 | ## Declared deposits You first declare your deposits in the setup wizard. Afterwards, owners and admins change them under **Declared deposits**: enter whole US dollars in **Monthly deposits**, check the tier and price shown under the field, and select **Save**. The next quarter you pay is priced at your declaration. Only one invoice is open at a time. If saving would replace an open invoice, the page says `Saving replaces your open invoice, and its earlier payment codes stop counting.` While a payment for the open invoice is on Solana, wait until it shows as paid before you change your deposits. ## Pay for a quarter Payments go straight from your wallet to kinematic's billing wallet through Solana Pay, with no card processor. **1. Open the checkout** Select **Pay for your first quarter** at the top of the page, or **Pay for the next quarter** once you have paid one. The sheet shows the quarter's dates, your tier and the **Amount due**, which covers three months of your tier's fee. **2. Choose a token** Under **Pay in**, choose USDC, USDT or SOL, then select **Continue**. USDC and USDT pay the exact dollar amount. In SOL you pay the dollar amount at the price when you continue, and the quote holds for 15 minutes; for a new quote, choose SOL again. **3. Pay the code** The screen `Waiting for your payment` shows a Solana Pay code and the amount. Scan the code with a Solana wallet, select **Open in your wallet** to open it in a wallet on this device, or select **Copy the payment link**. Beside it are the **Recipient**, when the code **Expires** (a USDC or USDT code never expires), the **Reference** and the **Network**. Pay only through the code or the link. They carry the reference that matches your payment to the invoice. **4. Wait for Solana** The sheet updates on its own. It shows `Payment received` once your payment is on Solana, and `Payment confirmed` with the date you are paid through once Solana finalizes it. To change tokens before you pay, select **Pay with another token**. If you close the sheet while a code waits for payment, a banner on the page opens it again. If a payment does not count, the sheet says why: * A payment that sent less than the amount does not count. Pay the full amount with the same code, and write to [hello@kinematic.run](mailto:hello@kinematic.run) to get the short payment back. * A payment in another token does not count. Pay the amount shown with the same code, and write to [hello@kinematic.run](mailto:hello@kinematic.run) to get the other payment back. * A transaction that failed, or paid nothing to kinematic's wallet, paid nothing. You can pay again with the same code. ### When a quarter starts Your first quarter starts when you open its checkout. A renewal starts where your paid time ends, or when you open the checkout if your paid time has ended. The sheet shows the quarter's dates before you pay. ## Invoices One invoice covers a quarter at your tier on the day it opened. The **Invoices** table lists each with its **Quarter**, **Tier**, **Amount**, **Status** (Open or Paid) and **Payment**, which links to the transfer on Solana Explorer. ## Refunds Only entirely unused months of a paid quarter are refundable. A month that has begun, even by a second, counts as used. To ask for a refund, write to [hello@kinematic.run](mailto:hello@kinematic.run). Once you have a paid quarter, the **Refunds** list shows each refund with its **Quarter of**, **Months**, **Amount** and **Status**: To be paid, then Paid with a link to the transfer. ## Changes to prices and terms Kinematic may change its terms and prices. A change applies from the start of your next billing quarter, never to a quarter in progress: a quarter you have paid for keeps the prices and terms that were in force when you paid for it. Kinematic emails you before a change applies to you. # Create your casino Source: https://kinematic.mintlify.app/dashboard/create-casino Sign up, create your casino and finish the first-run steps: your casino, your team, size and price, currencies, games and look. ## Sign up Open [app.kinematic.run/sign-up](https://app.kinematic.run/sign-up). Enter **Your name**, your **Work email** and a **Password** of 10 to 128 characters, tick `I accept the terms and the privacy notice.` and select **Create account**. You can also select **Continue with Google**, which uses your Google account and needs no confirmation email. The dashboard then shows `Check your email` and sends you a confirmation link that works for 24 hours. Opening it confirms your email and signs you in. If the email does not arrive, select **Send the link again**. Until you confirm, signing in answers `Confirm your email first. A new link is on its way to your inbox.` You stay signed in for 7 days. If you forget your password, select **Forgot your password?** on the sign-in page. The link it sends works once, for an hour, and changing your password signs you out on your other devices. ## Name your casino With no casino yet, the dashboard opens the first step, `What is your casino called?`. Enter the **Casino name**, for example `Lucky Star`, and the **Website** your players visit, for example `luckystar.example`. Once the website reads as an address, the hint under it shows which pages can show the games, for example `Pages on luckystar.example and www.luckystar.example can show the games.` The website must be the public name of your site: no IP address, no port and no local name such as `localhost`. Select **Continue**. The dashboard creates your casino: * **Casino ID.** The dashboard makes it from the name: `Lucky Star` becomes `lucky-star`. You cannot type or change it, and it never changes. Accents are dropped, every run of other characters becomes one hyphen, an ID that would not start with a letter gets `casino-` in front, and one shorter than 3 characters gets `-casino` at the end. If another casino already has the ID, yours gets `-2`, then `-3` and so on up to `-9`, then four random letters. The result is 3 to 51 lowercase letters, digits and hyphens, starting with a letter. Your session tokens carry it as `tenant`, and your game server's default Worker name is built from it: `og-rgs-lucky-star`. * **Mode.** The casino starts in sandbox mode. See [Sandbox and live](/concepts/sandbox-and-live). * **Games.** Every game is on. * **Allowed origins and session issuer.** Both come from your website. A bare domain such as `luckystar.example` gives the origins `https://luckystar.example` and `https://www.luckystar.example`. A `www.` host gives itself and the bare domain. Any other host, such as `play.luckystar.example`, gives only itself. The issuer is `https://` followed by the host you entered. You can change all of them in [Settings](/dashboard/settings#players-and-sessions). * **Look.** The dashboard starts reading your website for the **Look** step at once, so its themes are often ready when you get there. You can change the name and the website later in [Settings](/dashboard/settings#casino). ## The first-run steps The dashboard then walks you through your casino's setup, one question per page, with the steps listed on the left: **Your casino**, **Your team**, **Size and price**, **Currencies**, **Games**, **Look** and **Done**. **Go back** returns to the previous step, and a step you finished links back to its page. You can change every answer later. **1. Your team** `Who's building this with you?` Enter the email of each person who will set up the casino with you, such as your developer, and choose **Admin** or **Member**. **Admin** is chosen by default. Select **Send invitation** (or **Send invitations**); each invitation works for 7 days. See [Team](/dashboard/team). To set up the casino yourself, select **I'll do it myself**; once someone is invited, it reads **I'll do the rest myself**. Once you have invited an admin, choose between **Continue setup** and **Leave the rest to my team**, which takes you to **Home**: your admin continues the setup from there. **2. Size and price** `How much do your players deposit each month?` Move the **Monthly deposits** slider to one of its seven tiers, from `Under $250K` to `$10M and up`. The caption shows your tier's fee, for example `$263 a month, $789 billed each quarter`. Your sandbox is free; you pay your tier's fee once you go live, a quarter at a time. See [Billing](/dashboard/billing). **3. Currencies** `Which currencies do your players use?` Select every currency your players bet in from the **Crypto** and **Fiat** groups, or type any other code under **Add another** and select **Add**. In the sandbox, **TEST** is selected for you: it is play money, and each test player starts with 100,000.00 TEST. Choose at least one currency and at most 16. You set each one's limits later on **Games**. See [Games and limits](/dashboard/games-and-limits). **4. Games** `Which games will you offer?` Every game starts on; turn off any you don't want, keeping at least one. Then choose your **Return to player**: **99% (recommended)**, **98%**, **97%** or **96%**. Roulette, Baccarat and Blackjack keep their fixed rules. See [Return to player](/concepts/return-to-player). **5. Look** `Match the games to your site` offers three themes made from your site's colours, fonts and logo: **Matched**, **Bold** and **Quiet**. Choose one and select **Use this look**. You can also select **Upload a screenshot instead**, and the themes come from a screenshot of your site; the dashboard offers the same when your site refuses to be read. **Keep the default look** moves on without saving a look. You can change the look any time on [Appearance](/dashboard/appearance). **6. Done** `Your sandbox is ready` lists the two steps left before your first bet: deploy your game server, and put the games on your site. Select **Deploy your game server** to open [Game server](/dashboard/game-server), or **Go to Home**. Opening this page finishes the setup. **Your casino**, **Size and price**, **Currencies** and **Games** are required; you can skip **Your team** and **Look**. Only owners and admins can open the steps: a member sees `Only owners and admins set up a casino`. ## Home before launch Until your casino is launched, **Home** shows `Launch your casino`, a checklist of five steps: | Step | Action | | - | - | | Set up your casino | **Continue setup** | | Deploy your game server | **Deploy**, or **Open game server** once it is deployed | | Place your first bet | **Open integration** | | Switch to live mode | **Open settings** | | Pay for your first quarter | **Open billing** | The first step you have not done shows its action. If you left the first-run steps before the end, **Continue setup** opens the first one you have not finished. Under the checklist, `For your developer` links to the [quickstart](/quickstart) and to the instructions for a coding agent on **Integration**. Beside it, **Your games** previews the games in your casino's look, with scripted rounds and demo credits that never reach your game server. Once all five steps are done, **Home** shows your last 24 hours instead. See [Go live](/dashboard/go-live). ## Several casinos One account can belong to several casinos, each with its own team, settings, game servers and billing. **Your casinos** lists them; select **New casino** there to create another. The casino switcher in the sidebar has **All casinos**, which opens that list, and **New casino**. # Game server Source: https://kinematic.mintlify.app/dashboard/game-server Connect Cloudflare, deploy your game server on workers.dev or your own hostname, and run it: its card, deploys and updates, new bets and the Solana record. Your game server is a Cloudflare Worker that the dashboard deploys into your own Cloudflare account. You deploy and run it on the **Game server** page. [Your game server](/concepts/game-server) explains what runs in your account. The page has two states: * **Before your first game server**, it shows two steps: **Connect Cloudflare** and **Choose where it runs**. * **Once a game server exists**, it shows a card for each game server, then the sections **New bets** and **Solana record** (once a game server has deployed) and **Cloudflare**. Owners and admins connect Cloudflare, deploy, update, remove a game server, check it with **Check now** and **Check Solana**, stop new bets and register keys. Members see the game servers, their newest errors and their Solana record, with `Only the casino's owners and admins can deploy, check and change the game server.` Until you finish setting up your casino, the page shows `Finish setting up your casino before you deploy your game server.` with **Continue setup**. ## Connect Cloudflare **1. Select Connect Cloudflare** In the step **Connect Cloudflare**, select **Connect Cloudflare**. The page says `You approve the access on Cloudflare's own page.` and lists the permissions under **What you approve**. **2. Approve on Cloudflare** Sign in to Cloudflare if it asks, choose the accounts the dashboard may use, and approve. If you decline, the page says `You declined in Cloudflare. Nothing changed.` **3. Check the connection** Back on **Game server**, the page says `Cloudflare is connected.` The step becomes **Cloudflare is connected** and shows `Connected as `, with the accounts the connection reaches, the date and who connected it. The dashboard asks for six permissions: | Permission | What the page says | | - | - | | `account-settings.read` | Read your accounts, so you choose the one to deploy to. | | `user-details.read` | Read your Cloudflare email, shown on this page. | | `workers-scripts.admin` | Create and update your game server's Worker: its code, secrets and workers.dev address. | | `workers-routes.write` | Put your game server on a hostname of yours, when you choose one. | | `zone.read` | Read your zones, to put your game server on a hostname of yours. | | `offline_access` | Keep access between your visits, so new releases reach your game server while you are away. | Under the list, the page says `The game servers you deploy belong to your account. Disconnecting stops new deploys from this dashboard and leaves them running.` Once you have a game server, the section **Cloudflare** shows the connection and the same list under **What you authorized**. ### Reconnect and disconnect The dashboard keeps its access between your visits. If Cloudflare refuses to renew it, the page shows `Cloudflare refused to renew access. Reconnect to deploy and update your game servers.` with **Reconnect**, the connection shows **Reconnect needed**, and **Game server** in the sidebar shows **Reconnect**. Your game servers keep running; you cannot deploy or update them until you reconnect. The connection's menu has three items: * **Check connection** asks Cloudflare and answers, for example, `The connection works. It reaches 1 account.` * **Reconnect** opens Cloudflare's page again, so you approve again. * **Disconnect** asks `Disconnect Cloudflare?` first. Your game servers keep running and serving players. Until you connect again, you cannot deploy them, and automatic updates wait. Disconnecting revokes the dashboard's access to your account. Select **Disconnect** to confirm, or **Keep it connected**. ## Create a game server Once Cloudflare is connected, the step **Choose where it runs** shows the form. To add another game server later, select **Add a game server** at the top of the page: `It runs from the same settings as your other game servers, in another account or on another address.` **1. Choose the account** In **Cloudflare account**, pick the account the game server runs in. The list holds the accounts you approved. **2. Name the Worker** **Worker name** is the Worker's name in your Cloudflare account. It starts as `og-rgs-`, for example `og-rgs-lucky-star`, with `-2`, `-3` and so on added when one of your game servers already has that name. A name has 1 to 63 lowercase letters, digits and hyphens, and does not start or end with a hyphen. The form refuses: * a name that breaks these rules: `Use 1–63 lowercase letters, digits and inner hyphens.` * a Worker that already exists in the account: `Your account already has a Worker named . Choose another name.` * a name another game server of yours uses in the account: `A game server with this name exists in this account. Choose another name.` **3. Choose the address** Under **Address**, choose **workers.dev** or **Your own hostname**. For your own hostname, type it in **Hostname**, such as `games.luckystar.example`. See [Choose an address](#choose-an-address). **4. Keep automatic updates** Leave **Update automatically** on: `New releases reach this game server within five minutes. You can turn this off later.` **5. Deploy** Select **Deploy**. The caption names the release and the account. The page shows `Deploying ` with a running clock: it takes about a minute, so keep the page open until it finishes. When it succeeds, the page says `Deployed. Your game server runs release .` and shows the game server's card, first with **Waiting for its first report**, then **Reporting**. Copy the game server's address from its card with **Copy the address**: it goes into your [embed](/integrate/embed) and your [CSP](/integrate/csp). A game server that never deployed can be removed with **Remove**, in its card's menu or under its note. The dialog `Remove ?` says `It never deployed, so nothing runs from it. If an attempt left a Worker of this name in your Cloudflare account, delete it there too.` A game server that has deployed stays on the page. ## Choose an address Your game server is a Worker in your Cloudflare account, so its address belongs to that account too. ### workers.dev The address is `https://..workers.dev`, for example `https://og-rgs-lucky-star.luckystar.workers.dev`. The form previews it as you type the Worker name. Nothing else is needed, as long as the account has a workers.dev subdomain. An account gets its workers.dev subdomain the first time someone opens **Workers & Pages** in its Cloudflare dashboard. If it has none, the form says `This account has no workers.dev subdomain yet. Open Workers & Pages once in its Cloudflare dashboard to create one, or use your own hostname.` with the link **How to create the subdomain**. See [There is no workers.dev subdomain](/troubleshooting#there-is-no-workers-dev-subdomain). ### Your own hostname Use a hostname such as `games.luckystar.example` when you want players' browsers to see your domain. Under **Hostname**, the form says: `This hostname's domain must use Cloudflare DNS in the account above, with no record for the hostname yet, because Cloudflare creates that record for your game server. If your DNS is elsewhere, start on workers.dev and add a game server on your hostname later.` The dashboard attaches the hostname to the Worker as a Cloudflare Workers custom domain, and Cloudflare creates the hostname's DNS record and its certificate. The hostname must meet four conditions: 1. **Its domain is a zone in the same Cloudflare account** as the game server. A domain in another Cloudflare account, or at another DNS provider, does not work. 2. **The zone is active.** Cloudflare marks a zone active once the domain uses Cloudflare's nameservers. 3. **The hostname has no DNS record yet.** Delete an existing record for that exact hostname first, or choose another hostname. 4. **No other game server of your casino serves the hostname.** The form checks conditions 1, 2 and 4 before it deploys; Cloudflare checks condition 3 during the deploy. [The deploy fails on your own hostname](/troubleshooting#the-deploy-fails-on-your-own-hostname) lists every message and its fix. If your domain's DNS is not on Cloudflare yet: **1. Add the domain to the account** In the Cloudflare dashboard of the account the game server runs in, add your domain, for example `luckystar.example`. Cloudflare imports the DNS records it finds; check that every record your domain needs is there before the next step. **2. Point the domain at Cloudflare** At your domain's registrar, replace its nameservers with the two that Cloudflare shows. Wait until Cloudflare marks the zone **Active**. **3. Deploy on the hostname** Create the game server with your hostname. Cloudflare creates the DNS record for `games.luckystar.example` and its certificate. If you cannot move your domain's DNS to Cloudflare, use the workers.dev address. You can add a game server on your hostname later. ## The game server's card Each game server has a card. Its heading is the game server's address, which opens in a new tab, with **Copy the address** beside it. Under the address, the card shows the game server's state, `Last report