Concepts
The Depot model in plain words, from studios and games to packages, entitlements and store pages.
This page explains the words the rest of the docs use. Read it once and the commands will make sense.
The shape of it
Players sit outside your studio. They have a Depot account, and they own packages through entitlements.
Studio
A studio is an organization on Depot. Everything you publish belongs to it: games, builds, signing keys, store pages and game keys. People join with a role (owner, admin, publisher or member), and their permissions come from that role. CI and agents use organization API keys (dpk_…) with a chosen set of permissions.
depot org create --slug my-studio --name "My Studio"
depot org invite --email teammate@example.com --role publisherThe studio slug appears in your store URLs and never changes.
Game
A game has a permanent slug, an id (game_…), and everything below. Create one with depot game create.
Release
A release is one signed build of your game for one platform, with a name you choose, such as 1.0.0. Releases are immutable. Pushing again with new files makes a new release. Depot stores builds as content-defined chunks, so a new release uploads only the chunks that changed, and players download only those chunks when they update.
Platform
Each release targets one platform, named like macos-arm64, windows-x64 or linux-x64. Push once per platform. The launch file you push with the release tells the launcher which file to start on each platform.
Channel
A channel is a named pointer to a release, per platform. Players install from a channel and follow it. When you move stable to a newer release, players get the update. Your store page installs from stable unless you choose another channel, and you can keep others, such as beta.
depot channel set --game my-game --platform macos-arm64 --channel stable --release-id <release id>Moving a channel to an older release is a rollback and needs --allow-rollback.
Signing key
You sign every release with your own Ed25519 key. The private key stays on your machine. You enroll the public half for the game, and Depot checks every release against it. The launcher and CLI check it again before they install anything, and they remember the keys a game was first installed with. Depot never re-signs your builds.
depot keys generate
depot keys enroll --game my-gameProtection and encryption
Every game is restricted. Its builds are encrypted chunk by chunk, and only a player who owns the game can download them and receive the key to decrypt them. A store page never authorizes a download on its own. Only an entitlement does.
The first push to a game creates its content key and saves a backup on your machine. You need that backup for every later push, and Depot never returns it.
Once a game is installed, it plays offline. Depot doesn't add runtime DRM to your game. If you want the game itself to check ownership, use the Depot SDK.
Package
A package is something a player can own. Every game starts with a base package. You can add more:
| Kind | What it is |
|---|---|
base | The game itself. Holds the builds you push (the default for depot push). |
dlc | Extra content. Push builds to it with --package <name>, or leave it empty and check it with the SDK. |
bundle | A set of other packages from the same game. Owning a bundle means owning everything in it. |
test | Test builds you want to give to some players only. |
Owning a DLC never gives a player the base game. Ownership only flows from a bundle to its contents.
depot package create --game my-game --name expansion-1 --kind dlc --title "Expansion 1"Entitlement
An entitlement says one player owns one package. It records where it came from: a free claim, a redeemed key, or a grant from you. It can end at a set time, and you can revoke it.
depot entitlement grant --game my-game --handle @playerRevoking stops new downloads and updates at once. Copies already installed keep launching.
Store page and who can get it
Each game can have a public store page at /p/<studio>/<game>. The page's access setting decides who can get the game:
| Access | What players do |
|---|---|
| Free | Anyone signed in with a Depot account claims it from the page. |
| Key only | Players redeem a game key from you, on the page or in the launcher. |
| Invite only | The page describes the game. Players get it only from keys or grants you give them. |
You set access with depot game page --access free|key|invite. It applies when you publish and you can change it any time. Players who already own the game keep it. A page can be public (listed on your studio page and indexed by search engines) or unlisted (served by link only). Unlisted means "not listed". It isn't a secret, and it doesn't control access.
Unpublishing takes the page down and stops new free claims. Nobody loses a game they already own.
Game keys
Game keys are single-use codes for a package, like DPT1-XXXX-…. You issue them in batches, and the codes are shown once:
depot game-keys create --game my-game --quantity 100 --label press --out keys.txtA player who redeems a key gets an entitlement. A player who already owns the package keeps the key unused, so they can pass it on. Game keys are different from signing keys. See Keys and access.
Launcher catalog
The Depot launcher has an Available to get list. You can choose to list your game there with depot game page --listed true. A listed game shows only while its page is public and its access is Free or Key only. Invite-only and unpublished games never show. Depot has no global store, ranking or search. Players find your game through the links you share.