KUMODeck

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.

Build/index.htmlBuild/game.loader.jsBuild/game.wasm.brBuild/game.data.br1Export for the web (Unity: WebGL / Web, Godot: Web)KUMODeckDrop a zip or a folder hereUpload2Put the whole folder on KUMODeck, as it isyour-game▶3Open the link and play

1. Export for the web#

  1. 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.
  2. Open Player Settings › Publishing Settings and pick a Compression Format. Brotli (Unity's default) gives the smallest files. Gzip and Disabled also work.
  3. Leave Decompression Fallback off. You don't need it on KUMODeck, and the game loads faster without it.
  4. Build into an empty folder.
Project Settings › Player › WebAudioGraphicsPlayerQualityPublishing SettingsCompression FormatBrotliDecompression FallbackData Caching
Illustration. Labels may differ slightly.

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 production to 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#

FileWhat the browser gets
….js.br, ….wasm.br, ….data.br, ….symbols.json.brthe file as it is, with Content-Encoding: br and the type of the file inside (text/javascript, application/wasm, …)
the same names ending in .gzthe 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 seeWhat to do
A file is over 100 MBTurn 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 waitOpen 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-corp

With 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