Depots: assigning builds and shipping the right files

What a depot actually is

Three terms get tangled constantly. Keep them straight and the rest is easy:

Term	What it is
App	Your game as a whole. One App ID (e.g. `1000`). It owns store page, builds, depots and packages.
Depot	A versioned container of files. The App ID + 1 is usually your first depot (e.g. `1001`). A build uploads file into depots.
Package	What a customer buys. A package grants one or more depots. Your base game package grants your content depots; a DLC package grants the DLC depot.

Mental model: builds put files into depots, packages hand depots to players. Steam then downloads only the depots a player is entitled to and needs for their platform/language.

When you need more than one depot

A small single-platform game can ship from one depot forever. You add depots when files should reach some players but not others:

Split by	Why a separate depot
Operating system	A Linux player shouldn't download your Windows `.exe` and DLLs. One depot per OS keeps downloads lean and lets Steam pick the right one.
Language	Optional, for big localized assets (voiceover, cutscenes). Players download only their language's depot. Text-only localization rarely justifies it.
DLC / expansions	DLC content lives in its own depot, granted by the DLC package. Owners get it; everyone else doesn't.
Optional content	Soundtracks, art books, high-res texture packs, dedicated server files — anything a player can opt into.

Don't over-split. Each depot is more build config to maintain. Most games need: one depot per shipping OS, plus one per DLC. Add language depots only when the localized assets are genuinely large.

Creating a depot in Steamworks

Add the depot

Go to Steamworks → your app → SteamPipe → Depots. You start with one depot (App ID + 1). Click Add new depot for each extra one; Steam assigns the next free ID. Give each a clear name like Windows Content, Linux Content, Soundtrack DLC.

Set the operating system (if OS-specific)

Under Installation → General Installation, set each depot's Operating System dropdown (Windows / macOS / Linux, or "All"). This is what tells Steam to download the Windows depot only on Windows. Forgetting this is the #1 reason players download the wrong files.

Set the language (if language-specific)

For language depots, set the Language field so the depot only downloads when the player has selected that language for your game in their Steam client.

Attach the depot to a package

A depot nobody owns never downloads. Under Associated Packages & Store, make sure your base game package includes your core content depots, and each DLC package includes its DLC depot. New depots are not auto-added to existing packages — you must add them, or owners won't receive the files.

Every depot change (adding a depot, changing OS/language, package association) must be published from the Steamworks "Publish" tab before it takes effect on the live store. Editing depots and forgetting to publish looks like "my build uploaded but nobody gets the files".

Mapping a build onto your depots

Uploads are driven by two kinds of .vdf script: one app build script that lists every depot in this build, and one depot build script per depot that says which local folder fills it. Replace the IDs with your real App ID and Depot IDs.

scripts/app_build_1000.vdf

"AppBuild"
{
  "AppID" "1000"
  "Desc"  "v1.0.0 launch build"

  "ContentRoot" "..\content\"
  "BuildOutput" "..\output\"

  "Depots"
  {
    "1001" "depot_build_1001.vdf"   // Windows
    "1002" "depot_build_1002.vdf"   // macOS
    "1003" "depot_build_1003.vdf"   // Linux
  }
}

scripts/depot_build_1001.vdf

"DepotBuild"
{
  "DepotID" "1001"

  "FileMapping"
  {
    "LocalPath" "windows\*"   // only the Windows build folder
    "DepotPath" "."
    "Recursive" "1"
  }

  "FileExclusion" "*.pdb"     // never ship debug symbols
}

Each depot script points LocalPath at a different subfolder of your content root, so the macOS depot gets macos\*, the Linux depot gets linux\*, and so on. The same build push uploads all three at once and Steam serves each player the depot matching their OS.

Steam only uploads files that changed since the last build, per depot. Your first push is slow; updates are fast. Don't recreate depots to "force a clean upload" — you'll orphan the old depot and confuse packages.

Branches: testing a build before it goes live

A build is uploaded to depots but not automatically live. Under SteamPipe → Builds you assign a build to a branch:

Branch	Use
default (public)	What everyone plays. Promote a build here only when it's ready to ship.
beta / staging	Create a password-protected branch, set a build live on it, and test the real Steam download/install path before touching the public branch.

Always validate a build on a private branch on a clean machine first. The depot files that download there are exactly what your players will get — it's the only way to catch "works on my dev box, missing a DLL for everyone else".

Common mistakes

Depot has no OS set

Left as "All", every platform downloads it. Windows players pull your Linux binaries. Set the OS on each platform depot.

New depot not added to a package

You added a depot and uploaded files, but never associated it with the base or DLC package. Result: the upload succeeds and nobody downloads it. Check Associated Packages.

Forgot to publish

Depot and package edits sit as drafts until you publish them on the Steamworks Publish tab. Uploading a build does not publish depot config changes.

Shipping junk

No FileExclusion lines, so .pdb symbols, editor logs and source assets ship to players. Bloats the download and can leak internals. Exclude aggressively.

Next step: once your depots and packages are set, follow the Build upload guide for the exact steamcmd commands to push a build on Windows, macOS or Linux.