Steam Demo Build Identity and Depot Parity - Ninety-Minute Pass for Unity and Godot PC Teams (2026)

Your trailer can be perfect. Your capsule can be honest. Your Discord can be calm. None of that saves you when the file players actually download is not the file your QA lead just blessed.

On Steam, that failure mode is ordinary: a default branch still pointing at yesterday’s depot, a demo app id sharing the wrong package graph, two engineers uploading different zips with the same marketing version string, or a festival-week hotfix that never reached the depot your store page advertises. In 2026, demo density is higher, festivals are noisier, and teams are smaller—so the margin for “we thought it was live” keeps shrinking.

This guide is a ninety-minute ritual to prove build identity and depot parity for Unity and Godot PC demos. It is written for leads who already know how to cook a build, but still need one boring hour where the chain from binary to Steam client becomes falsifiable.

If you are also fighting store copy hygiene, pair this pass with our Steam store page capsule and short description ninety-minute QA. If you need the deeper depot versus package mental model, start from Steam depots, beta branches, and default build discipline. When Git LFS pointers or large-binary drift might explain why two machines “built from main” diverge, run Git LFS and large binary hygiene ninety-minute pass on the same calendar day.

Why this matters now

Three pressures make demo identity a front-page engineering problem, not a release-manager footnote.

First, Steam Next Fest and similar windows concentrate downloads into short spikes. Players do not file polite tickets—they refund, they meme, and they move on. A wrong binary during that window wastes marketing heat you cannot replay on demand.

Second, Unity and Godot both make it easy to produce multiple “almost the same” PC folders: development versus shipping renders, mono versus IL2CPP, different scripting backends, and Godot export templates that change crash signatures without changing your spreadsheet version cell.

Third, evidence culture is catching up with indies. Publishers, platform partners, and your future self all ask the same question: “Which artifact did we sign off, and which Steam depot served it?” If you cannot answer in one row, you are guessing.

Direct answer

A Steam demo is parity-safe when you can draw one straight line: local artifact fingerprint equals uploaded depot content equals default or beta branch pointer equals what the store page promises—and you wrote that line down before you tweeted.

This pass produces that line in about ninety minutes once your pipeline is healthy; longer if you are still learning Steamworks.

Who this is for

• Engineers responsible for PC uploads during a demo or festival week
• Solo devs who are also the release manager and need a repeatable script
• Producers who need a spreadsheet-friendly evidence format for go or no-go calls

Time: about ten minutes to read, ninety minutes to execute with two people, or a bit longer solo if you must diff everything yourself.

Before you start

Collect:

• Your Steam app id for the demo (or the full game if the demo is not a separate app—know which model you use)
• Access to Steamworks depots, packages, and branches you are allowed to touch
• One clean PC build folder from Unity or Godot that you intend to ship
• The branch name players should receive on default (or the named beta branch your store text references)
• A checksum tool you trust (sha256sum, Get-FileHash, or your CI artifact hasher)

Pro tip: If your team argues about “which Steam model we use,” stop and resolve that before this pass. Demo-on-same-app versus separate demo app changes package graphs and where players expect saves to land.

Step 1 - Name the artifact like an engineer, not a marketer

Marketing versions are for humans. Artifact identity is for machines.

Create a row with:

• artifact_local_path (the folder or installer you will upload)
• artifact_bytes or artifact_zip_sha256 (hash the exact bytes Steam will ingest)
• engine (unity or godot)
• engine_version and project commit hash or tag
• build_configuration (for example Unity Release player, Godot export preset name)
• scripting_backend if Unity (IL2CPP versus Mono matters for crash signatures)

Common mistake: Hashing only the .exe while Steam ingests a folder with different DLLs beside it. Hash the same boundary Steam will ship.

Step 2 - Map Steamworks objects without hand-waving

Write down the depot id that receives your PC bits, the package id players receive, and which branch points at that package for your demo window.

If you cannot list those three identifiers in five minutes, you are not ready for a festival upload night. Go read your Steamworks notes or the depots discipline article, then return.

This step is also where you confirm whether your demo uses:

• the same app as the full game with a time-limited demo flag, or
• a separate demo app id

Mixing those stories between engineering and store copy creates brutal support threads.

Step 3 - Unity upload discipline (IL2CPP, Mono, and Player settings)

For Unity PC demos:

1. Build from a known profile (same Scripting Backend you tested).
2. Capture Player Settings screenshots or a dump of the Build Profile name in your evidence packet.
3. Prefer non-development players for public demos unless you have a deliberate reason and a warning path.
4. If you use Addressables or embedded bundles, confirm the catalog and bundle hashes you built are the ones sitting next to the player you hashed in Step 1.

Common mistake: Uploading a folder that still contains *_BackUpThisFolder_ButDontShipItWithYourGame content or stale burst debug artifacts. Your demo zip should look like what players should see.

Cross-link: when Android enters the same repo, keep platform evidence separate—our Google Play pre-launch report triage article is the parallel ritual for Play-side noise.

Step 4 - Godot export discipline (templates, presets, and GPU reality)

For Godot PC demos:

1. Export using the exact export preset you named in Step 1.
2. Record Godot version and whether you ship embedded PCK or sidecar pck—both are valid, but switching without noticing breaks “same build” claims.
3. If your demo targets integrated GPUs, do not treat desktop validation as optional—our Godot 4.5 Vulkan validation and Intel iGPU fallback guide is the PC-side companion when laptops behave differently than your tower.

Common mistake: Editing project settings after export but before upload, then assuming the folder on disk is still the one you hashed.

Step 5 - Upload, then re-fetch proof (do not trust memory)

After upload:

1. Download or mount what Steam would serve for your target branch using Steamworks tools or a clean client install path your team agrees is authoritative.
2. Re-hash the fetched bits using the same method as Step 1.
3. If hashes disagree, you are not done—no social post, no influencer key blast.

This is the step that catches “upload succeeded” stories that never reached the branch players use.

Step 6 - Default branch versus demo beta branch honesty

If your store page tells players to use a beta branch, the password, branch name, and instructions must match the package you validated.

If players stay on default, they must receive the same bits you validated without secret steps.

Teams lose trust fastest when marketing says “demo live” while default still serves last week’s crash build. If you intentionally keep an older build on default, say so in the store update and patch notes—our Steam demo patch notes template gives you player-safe language patterns.

Step 7 - Ninety-minute agenda you can run in a call

Minutes 0–10 - Read artifact_zip_sha256, Steam depot id, package id, and branch aloud; fix typos.
Minutes 10–25 - Re-hash local artifact; store hash in the shared row.
Minutes 25–40 - Upload or confirm upload pipeline output; capture Steamworks build id or equivalent log pointer your team uses.
Minutes 40–55 - Re-fetch from Steam; compute second hash; compare.
Minutes 55–70 - Launch fetched build on a clean PC profile; run a five-minute smoke route.
Minutes 70–85 - Update store page text if branch instructions changed; verify short description still matches reality.
Minutes 85–90 - Assign one owner to post patch notes or festival update copy if anything moved.

Evidence rows producers can require

Add these to your release spreadsheet:

• steam_app_id
• steam_depot_id_pc
• steam_package_id_player_facing
• steam_branch_name
• artifact_sha256_precheck
• artifact_sha256_postfetch
• steam_build_label_or_id
• unity_build_profile_or_godot_preset
• decision (green, yellow, red) with owner and timestamp

Yellow is acceptable only with a written reason—for example, “hash match deferred until CDN propagation completes in 30 minutes” with a retest time.

When you should widen scope

Widen this pass when:

• You share depots between demo and full game in a way that can overwrite player files
• You run multiple PC configurations (DX11 versus DX12 toggles) off one store surface
• You coordinate same-day patches during a festival and need rollback posture

For rollback thinking beyond Steam, our patch rollback checklist framing sits inside the depots discipline article’s promotion section.

CI fingerprints and cloud build honesty

If your PC demo comes from CI instead of a laptop folder, the identity problem does not disappear—it moves upstream.

Add three fields to your evidence row when automation is in play:

• ci_run_id (or pipeline url that resolves to one immutable run)
• artifact_name_as_uploaded (the object name your Steam upload step consumed)
• worker_image_or_toolchain_label (so “same commit” cannot hide different MSVC or DirectX dependency layers)

Why this matters: Teams frequently “verify green” on a worker that links against a newer runtime than your home PC. Players then crash on clean Windows installs while your QA tower looks fine. If your Unity or Godot project pins redistributables, copy that pin into the same spreadsheet row as artifact_sha256_precheck.

When two pipelines can emit PC folders (for example a nightly and a release worker), forbid ambiguous “latest” tags in upload scripts. Require explicit artifact paths so the human running the festival pass never uploads the wrong green box.

Troubleshooting table for demo-week panics

Use the table in standups so panic does not become improvisation.

Red-team questions for producers

Ask these before approving green:

1. If a streamer installs right now from default, what exact steam_build_label_or_id do they get?
2. Which commit produced that build, and who merged after it?
3. If we roll back, do we revert branch pointer only, or also replace depot bytes?
4. Does our save path collide between demo and full game in a way that creates support debt?
5. Who is on-call when the festival clock hits hour six and hashes disagree?

If any answer is “we will figure it out live,” the state is yellow until owners exist.

Notebook habit: Paste the final hash pair into your sprint doc the same hour you go green. Future you will not trust chat scrollback when a player video shows a crash you thought you fixed.

Outbound references worth bookmarking

• Steamworks documentation for depots, packages, and branches (use the pages that match your current Steamworks UI generation).
• Your engine’s official player build documentation for the version you ship.

How this connects to install size and secondary stores

Demo weeks are not the time to discover you shipped debug symbols or duplicate audio banks. If size spikes appear during this pass, our ninety-minute install size team pass helps you decide what is worth cutting before players complain about download bars.

If you also ship itch.io builds the same week, mirror identity discipline there—our Butler upload and store page QA pass is the parallel checklist.

Key takeaways

• Hash the boundary Steam ships, not a convenient single file, when you claim identity.
• Depot id, package id, and branch must be written down before upload, not reconstructed from memory at midnight.
• Re-fetch after upload and re-hash; “upload succeeded” is not proof players get the new bits.
• Unity demos need explicit scripting backend and build profile evidence; Godot demos need preset and PCK layout evidence.
• Default versus beta instructions must match the package you validated.
• Store copy and engineering reality drift is a shipping bug—patch notes exist to reduce refund confusion.
• Ninety minutes of discipline beats a week of social damage control during a festival spike.
• Yellow states need owners and timers; red states need halted promos, not hope.
• Integrated GPU and Vulkan paths are part of PC reality—test the slow machine, not only the demo kiosk tower.
• Secondary stores deserve the same identity rows if you promise same-week parity.

FAQ

Do we need a separate Steam app id for every demo?

Not always. Some teams ship demos under the main app with Steam’s demo flows; others use a dedicated demo app. Pick one model per project and keep engineering, store copy, and saves expectations aligned.

What if Steam CDN lag makes post-fetch hashing flaky?

Treat CDN delay as a timed yellow. Retry with a clocked wait, document the window, and do not announce until two consecutive fetches match your pre-upload hash policy.

Can we skip re-fetch if our internal tool says the branch updated?

Only if that tool is your contracted system of record and your producer accepts it. For festival weeks, an independent re-fetch still pays for itself.

Should demos ship with crash reporters attached?

Often yes, but disclose privacy posture in your store or demo footer. Identity parity matters even more when telemetry is on—players should know what build sent what signal.

What if Unity Addressables changed catalogs after we hashed the player folder?

Re-run Step 1 on the folder you will upload. Addressables drift is a top cause of “works in editor, wrong content in demo.”

Does Godot embedded PCK change this checklist?

It changes what you hash and how you diff hotfixes. Pick a layout per milestone and stop improvising mid-festival.

Conclusion

Steam rewards teams who treat demos like released products: measurable bytes, explicit branches, and honest store language. Spend ninety minutes proving identity before you spend ninety hours recovering from the wrong upload.

Bookmark this pass for festival weeks, publisher milestones, and any week when two engineers might touch the same depot. Share it when someone says “the build is live” without a hash, a branch, and a build id on the same row.