Unity games
A Unity game exported for the web runs on KUMODeck as it is. Export it, put the whole folder on KUMODeck, and open the link.
You don't change any server settings: KUMODeck sends Unity's compressed files (.br, .gz) the way the browser needs them.
1. Export for the web#
- In Unity, open File › Build Profiles (Unity 6) or File › Build Settings (2022 and earlier), pick Web (called WebGL before Unity 6) and switch to it.
- Open Player Settings › Publishing Settings and pick a Compression Format. Brotli (Unity's default) gives the smallest files. Gzip and Disabled also work.
- Leave Decompression Fallback off. You don't need it on KUMODeck, and the game loads faster without it.
- Build into an empty folder.
The folder looks like this. Keep it as it is: don't rename or unpack anything.
index.html
Build/
game.loader.js
game.framework.js.br
game.wasm.br
game.data.br
TemplateData/
StreamingAssets/ (only if your project has one)2. Put the folder on KUMODeck#
Pick one:
- Ask your AI: "Publish my Unity game in this folder with KUMODeck." A Unity build is usually larger than an AI can send in a message, so your AI gives you a link to an upload page. Drop the folder (or a zip of it) there.
- From a terminal:
kumodeck deploy path/to/the/folder(add--env productionto put it on the public version).
It goes on the test version first. Open the link it gives you and play.
What KUMODeck does for you#
| File | What the browser gets |
|---|---|
….js.br, ….wasm.br, ….data.br, ….symbols.json.br | the file as it is, with Content-Encoding: br and the type of the file inside (text/javascript, application/wasm, …) |
the same names ending in .gz | the same, with Content-Encoding: gzip |
.wasm (uncompressed builds) | application/wasm, so the browser can start compiling while it downloads |
This works for files ending in .js, .mjs, .wasm, .data, .json, .css, .pck, .mem or .bin followed by .br or .gz.
Other files ending in .gz (for example a .tar.gz your players download) are sent as they are, without Content-Encoding.
You can't set Content-Encoding yourself in _headers (KUMODeck keeps it so it always matches the file).
If something goes wrong#
| What you see | What to do |
|---|---|
| A file is over 100 MB | Turn on Brotli or Gzip compression. One file can be up to 100 MB (Limits); an uncompressed .data file is often the largest. |
| "Unable to parse Build/….br" | The folder was changed after the build (a file renamed or unpacked). Build again and upload the folder as it is. |
| A blank page after a long wait | Open the browser's console. A file that is missing in the upload shows as a 404 there. |
Multithreading#
If you turn on Unity's experimental multithreading for the web, the page needs two extra headers. Put a file named
_headers (no extension) next to index.html:
/*
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corpWith these headers, images or scripts from other sites load only if those sites allow it. Without multithreading, you don't need this file.
Using KUMODeck features from Unity#
Sign-in, cloud saves, multiplayer and the other features are JavaScript calls in the browser (the KUMODeck SDK). From C#, you reach
them the same way as any browser API in a Unity web game: through a .jslib plugin. Hosting itself needs nothing from the SDK.
See also: Godot games · Hosting & deploy