---
title: "Unity games"
description: "A Unity game exported for the web runs on KUMODeck as it is."
url: "/docs/guides/unity/"
lang: en
index: "/llms.txt"
---
# 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

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.

The folder looks like this. Keep it as it is: don't rename or unpack anything.

```text
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

| 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](/docs/guides/hosting/index.md#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`:

```text
/*
  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](/docs/guides/godot/index.md) · [Hosting & deploy](/docs/guides/hosting/index.md)