Security model
A web app's or game's code runs on your users' machines, and anyone can read and modify it. KUMODeck is designed around that fact: the browser is trusted with nothing it could abuse.
Never ship a secret key#
Publishable pk_… | Secret sk_… | |
|---|---|---|
| Safe in the browser / public repo | yes | never |
| Sign users (players) in, read/write their own data | yes | — |
| Push config, deploy, read any player | no | yes |
The SDK throws if you pass it an sk_ key. Keep secret keys in your CI secrets or your own server's environment
variables. If one leaks, create a new key in the dashboard, update CI, and revoke the old key — revocation is
immediate. Keys are stored as hashes; a lost key cannot be recovered, only replaced.
Development and production are isolated#
Players, data, rooms are separate per environment, and every key belongs to exactly one
environment. A pk_dev_ key cannot touch production data, and a leaked dev key
exposes no real users.
What a modified client can and cannot do#
| A cheater can… | …but cannot |
|---|---|
| write their own cloud save | read or write another player's save (so keep anything valuable out of saves) |
| send room messages | exceed 30 msg/s, read another environment's rooms, or keep a connection after a ban |
Design rule: put anything valuable behind a server-side decision — your own Functions —
never behind a client-side if. For competitive multiplayer, make the host authoritative, or run the match logic in
your own Functions.
Stats can be checked on the server before they count: value ranges, a
submission rate and a signed webhook to your own server (integrity.stats, see the config reference).
Players#
- Access tokens (JWT, 15 min) are verified without a database round-trip; refresh tokens (90 days) rotate on every use and a replayed token revokes the whole chain.
- Passwords are hashed with a memory-hard KDF; login errors do not reveal whether an email exists.
- Other users' data is invisible: requests for resources you don't own return 404.
Hosting#
Apps and games are served from a separate registrable domain (<slug>.kumodeck.app), one subdomain per project. A
project's JavaScript therefore cannot read the dashboard's session or another project's localStorage. Development deployments
are marked noindex.
Functions#
Your server code runs isolated from other creators' code and from KUMODeck itself. Each environment gets its own database, KV, files and queues; your code can reach only the resources bound to it, and KUMODeck's own systems only through the secret key issued for that environment. Secret values go straight to the runtime and are never stored by KUMODeck. Raw TCP sockets are blocked, and per-request CPU and subrequest limits apply.
Your developer account#
- Log in with an email and password, or with Google or GitHub. The buttons appear in the dashboard only for the providers the server operator has turned on. From a terminal,
kumodeck login --google(or--github) opens your browser and waits on a local127.0.0.1port with PKCE, likeghandgcloud; there is no code to type on another device. - KUMODeck never connects a Google or GitHub account to an existing account just because the email address matches: a "verified" email at a provider does not prove who owns that address today. If an account with that email already exists, log in the usual way first, then add the provider under Account → Sign-in methods in the dashboard.
- Adding or removing a sign-in method, setting a password and closing the account first ask you to confirm it is you — with your password, or by signing in with a provider you already added. Removing a method or setting / changing the password signs out your other devices and connected tools (CLI and MCP). The last way to sign in cannot be removed.
AI agents and other MCP clients#
Assistants act with the scopes and projects you choose on the consent screen. Changes to production, bans and deletions need your confirmation even when the assistant auto-approves tools . See Use from an AI agent.
Reporting a vulnerability#
Please report security issues privately to the maintainers rather than in a public issue.