Security model
What we never trust
- Game clients. They cannot report results, cannot act for another player (a token only works for its own user), and cannot join a server without a join token that the server verifies with Matchdock. Join tokens are signed, bound to one player and one server session, and checked strictly.
- Game server builds. They are your code, but they run on shared machines, so each one runs in a container with no Linux capabilities, no privilege escalation, a read-only filesystem, an unprivileged user, hard CPU, memory and process limits, and only its own port published. It receives its own session credentials and nothing else from the host. Archives whose links point outside the build are refused.
- Other projects. Every query is scoped to the project of the caller. A player token combined with another project's key is rejected.
Credentials
| Credential | If it leaks |
|---|---|
| Client key | Expected to be public. It grants nothing beyond naming the project. |
| Access token | One player's session. Revoke with POST /auth/logout; it expires after 30 days. Stored hashed. |
| Server key | Can manage your project. Revoke it in the console and create a new one. Stored hashed; shown once. |
| Server secret | One match. It is per session, handed over in the environment, stored hashed and never logged by the platform. Do not log it in your server either. |
Transport and operations
All API traffic is HTTPS. Game traffic goes directly between players and the game server on the session's UDP port; the server's address is revealed only to the two players of that match. Requests are rate limited per address. Databases and internal ports are not reachable from the internet, and the platform's own secrets never leave the control plane.
If you find a problem, write to us before you write about it - we fix quickly and credit gladly.