Send a build to testers

You'll make a project, push a build to a branch, make a campaign, mint invite codes, bake a config into a playtest build and send each tester the Launcher and a code. The recording goes from the tester's PC into the project's storage: Mulno Cloud, or your own bucket, where Mulno's servers never see the footage.

1. Make a workspace and a project

Sign in at app.mulno.com (new accounts come from the beta waitlist: who can have an account), make a workspace, then a project for your game. Storage is chosen per project. Mulno Cloud is the default and needs no setup; a Free workspace has 15 GB for builds and sessions. A Private bucket is your own R2 bucket: set it up as in section 6. The choice and what each holds is in Your own bucket and the lent key.

2. Bake the config and build

In Unity, select your PlaytestConfig and set:

Then use Tools › Mulno Playtest › Build Playtest Player (Windows x64). The build folder includes mulno_capture.dll and MulnoUploader.exe automatically. Keep a copy of the exact consent and NDA texts you shipped: a session's record holds only their version and hash.

3. Push it to a branch

From Unity (Tools › Mulno Playtest › Push to Branch…) or the command line, as in Push a build. Then, on the web app's Builds & branches page, Set live on the branch you want testers to get. Pointing the branch at an older build later is Roll back.

4. Make a campaign and mint codes

• New campaign: on the branch, give it a name (never shown to testers, but avoid your game's title if it's under NDA). A branch's default campaign is named Share.
• Marks and consent: the campaign's own switches: the watermark, the per-tester mark and your overlay (the last two come with Indie and Team), and whether you collected a parent's or guardian's consent.
• Privacy notice and NDA: add your own privacy notice for testers (there is a template) and, if you need one, an NDA. The Launcher shows the notice first, without asking the tester to agree to it, then the NDA, both before the code is used and before anything downloads. Write them with Privacy for studios and testers open.
• Mint codes: choose how many, and copy them at once. This is the only time you ever see them. Each one looks like MULNO-4K7H-9QWZ-3R2M-84F2 and is single-use by default.

Free allows one active campaign and 20 codes redeemed in a rolling 30 days; Plans and quotas has the rest. There is no copy-an-invite-link button, so what you hand out is the code.

5. What testers see

A tester installs the Launcher from the Download page (Windows shows a SmartScreen warning for it, as for Studio), types the code, reads your privacy notice, accepts your NDA if you set one, and the build installs and starts. In the game they agree to what gets recorded, then play. A small REC light is on screen while anything records. Point them at the page for testers, and read Privacy for studios and testers before a real tester plays. Their session arrives in the project and opens in the web app: Review in the browser.

6. If a project keeps sessions in your own bucket

You need one Cloudflare R2 bucket and an upload key for it. Cloudflare R2 has no write-only object permission: its narrowest scope, Object Read & Write, can also list and read the whole bucket. If you choose R2, accept that once, on the record, in these words:

A leaked copy of this campaign's bucket key — or Mulno's own sealed working copy of it — could list and read every session in this bucket, and could write, overwrite or delete anything outside incoming/, and anything inside it once the bucket lock rule's retention has passed.

Mulno keeps a sealed working copy of the key so that it can sign upload links; that is why the sentence names it. The full picture, and the second bucket a platform project needs for builds, is in Your own bucket and the lent key.

What limits the damage: testers never hold this key (they only get one-object, one-hour upload links), each campaign gets its own bucket, and that bucket gets a lock rule on incoming/ so a leaked key can't delete or overwrite what's already uploaded.

npx wrangler r2 bucket create studio-playtest-spring-4 --location apac
npx wrangler r2 bucket lock add studio-playtest-spring-4 mulno-incoming incoming/ --retention-days 7
# then, in the Cloudflare dashboard: R2 › Manage R2 API Tokens › an "Object Read & Write" token
# scoped to this one bucket

The bucket form checks the key before anything uploads: Check my bucket runs four checks (write, no-overwrite, no-read, no-list) and says in plain words what to fix. On R2 the no-read and no-list checks fail, which is expected, and you'll be asked to accept the sentence above. A campaign takes no upload until this passes.

7. Without the platform: Studio's Campaigns screen

A studio with no workspace can run a campaign from Studio, against our broker, with its own bucket and a build it zips and sends itself. Set up the bucket as in section 6, then:

• Connect Studio. Open the Campaigns screen (or press Ctrl K and choose Campaigns). Connect with broker URL https://api.mulno.com and the studio token we issue each beta studio over a channel you already trust. Studio checks it, then keeps it in Windows Credential Manager: never in a config file, never shown again except as its public id.
• New campaign: a name (never shown to testers), an expiry, the minimum tester age, and upload limits.
• Bucket tab: fill in the endpoint, bucket and key, then Check my bucket.
• Codes tab: Mint codes, and save the CSV somewhere safe. This is the only time you ever see them.
• Copy the campaign id at the top of the campaign and bake it into the config (section 2).

Build the player, zip the build folder and send it to your testers the way you'd send any build, each with a code. They run the game, type the code there, agree to your NDA if you set one and to what gets recorded, then play.