Steamworks Demo Build Uses Old Depot Content - Branch Pin and BuildID Verification Fix - How to Fix

Problem: You upload a new demo build in Steamworks, publish it, and confirm the pipeline is green, but players, creators, or QA still launch an older content state. Menus or version text may look updated while gameplay assets remain stale.

Common symptoms:

Steam client shows a recent update, but known fixes are missing in-game
demo branch notes mention a new BuildID, but runtime behavior matches older content
one tester sees new content while another sees old data on the same day
event or festival preview machines pull unexpected scenes, balance values, or localization rows

This usually is not a Unity or Unreal runtime bug. It is a branch and depot mapping continuity issue between what you uploaded, what you published, and what the demo app actually resolves at launch.

Why this spikes now (2026 demo cycles)

In 2026, more teams are shipping frequent demo updates around showcases, press beats, and wishlist pushes. That speed creates a failure mode where teams correctly upload content but miss one continuity step: branch defaults, package visibility, or BuildID/depot parity verification.

Steam demo operations now fail most often when multiple actions land in one sprint:

branch default change
depot content push
package or beta access adjustment
last-minute hotfix build

If those are handled in separate tabs by separate people, stale content can survive into external play sessions even when every individual step looked "done."

Root cause

Stale demo content usually comes from one or more of these:

Wrong branch pinned for launch context
The build was uploaded to a non-default branch while QA or public users launch another branch path.
BuildID assumption without depot confirmation
Team confirms a BuildID changed but does not verify the correct depot manifests were attached for the demo app.
Package or visibility drift
Test accounts are granted access to a package path not aligned with the intended demo branch.
Client cache and launch-context shortcuts
QA launches executable directly or reuses stale local content without a clean Steam client refresh.
Cross-app confusion between full game and demo app
Upload or publish changes are applied to the main app workflow while demo app depots lag behind.

Quick fix checklist

Confirm the demo app ID, target branch, and intended BuildID in one written row.
Verify branch default and access policy match your external test path.
Validate that the target BuildID resolves to expected demo depots/manifests.
Run a Steam-client-only smoke test using a clean account session.
Capture a timestamped readback of app ID, branch, BuildID, and in-game version marker before sign-off.

Step 1 - Lock the release tuple before touching anything

Create a single "truth tuple" for this push:

demo_app_id
target_branch
expected_build_id
expected_depot_manifest_ids (or equivalent manifest references used by your team)

Do this first so everyone reviews the same target. Most stale-demo incidents happen when teams compare different tuples without realizing it.

Step 2 - Verify branch default and tester launch path

In Steamworks and QA instructions, confirm:

which branch is default for public demo users
which branch your tester account is actually opted into
whether event machines are forced to a beta branch or default branch

Then align your smoke test instructions:

launch from Steam library (not direct executable)
confirm branch setting before download
relaunch once after branch check

If your account is pinned to a different branch than your publish plan, BuildID verification is meaningless for that test run.

Step 3 - Validate BuildID to depot-manifest continuity

Do not stop at "BuildID exists." Confirm the BuildID maps to the expected depots for the demo app:

open build history for the demo app
inspect depots tied to that BuildID
verify manifest identifiers match your release tuple
confirm no required content depot is still mapped to an older manifest

If one depot remains stale, players can receive mixed state where code updated but content data did not.

Step 4 - Re-check package and entitlement path for testers

For each QA or creator test account:

confirm account entitlement to the intended demo package path
ensure package visibility aligns with target branch
avoid assuming full-game entitlement automatically reflects demo entitlement

This is a common trap in fast launch windows: team validates full app ownership and forgets demo package routing.

Step 5 - Run a deterministic external-style smoke test

Use a standardized test that mirrors real player behavior:

sign out and sign back into Steam client with target account
launch demo from library page
verify in-game version marker or content checksum marker
test one changed asset/feature from this update
restart client once and retest the same marker

Capture logs/screenshots for:

branch name
BuildID shown in Steam client context
in-game marker proving updated content

Treat this as a release gate for every demo push tied to public events.

Verification checklist

After the fix, confirm:

two different accounts pull the same updated content
branch setting and BuildID are documented in the same release row
changed gameplay/content marker is visible in both fresh install and restart paths
no dependency on manual executable launches exists in QA instructions
demo app and full game app were both checked for ID/path confusion

Alternative fixes for stubborn edge cases

If stale state persists:

force reinstall demo content after clearing branch mismatch
rotate to a clean test machine profile to remove local state assumptions
add an in-game startup diagnostics line with branch/build tuple for faster triage
split publish ownership so one person handles upload and another independently verifies tuple continuity

Prevention for future demo pushes

Use a tiny release row template for every demo update:

demo app ID
branch
BuildID
depot manifest set
verification account IDs
verification timestamp
approver

This one row prevents most stale-demo incidents by forcing continuity evidence before external distribution.