Steam Cloud is Valve’s remote file storage for games. It stores the files a developer opts in — usually save data, but occasionally settings or other state — on Steam’s servers so a player who signs into Steam on a different computer can pick up the same progress. Valve’s own overview summarizes the feature in one sentence: Steam Cloud automatically stores files from a game on Steam’s servers so players can log into Steam and access their saved games from any computer.
The first thing to understand is that Steam Cloud is not a blanket backup of everything on a machine. It only synchronizes the files a developer has explicitly configured or written through the Steamworks API, and it operates under per-game quotas and file-size rules that most players never see until something goes wrong. Understanding those mechanics matters for two practical reasons: cloud saves fail in ways that look like data loss when a game’s configuration is incomplete, and the limits and the sync order explain most of the behavior players actually report, such as slow shutdowns, a stale save re-downloading over a newer one, or a save that exists on one machine but not another.
What Steam Cloud actually does
The core behavior is a before-and-after sync cycle. Valve’s Steam Cloud documentation states that files specified in the Auto-Cloud configuration, or written to disk through the Cloud API, are automatically replicated to the Steam servers after the game exits. If the user changes computers, the files are automatically downloaded to the new computer prior to the game launching. In other words, the upload happens at session end and the download happens before the next session begins on a different machine. That ordering is why a player who force-quits a game or kills Steam immediately after closing it can sometimes find the newest progress missing on a second device: the post-exit upload did not finish.
Valve also warns that the sync is not free. Because Steam synchronizes a game’s Cloud files before and after every session, and uploads any matching files that changed during the session immediately afterward, a game that writes very large files, or many small files, can create a noticeable impact on the user’s internet bandwidth and delay their ability to shut down Steam or relaunch the game. The documentation’s stated guidance is that smaller files will work better, and it recommends splitting a game’s saved state into files that change frequently and files that change rarely, so the unchanged state is not re-uploaded after every session.
Steam also gives players two independent off-switches, both described in the same overview. Synchronization can be disabled globally in Steam Settings under Cloud by unchecking the option to enable Steam Cloud synchronization for applications that support it, or it can be disabled per game in each title’s Properties. Because those two switches are independent, a game can silently stop syncing on a machine even when the game itself runs normally, and the culprit is usually one of the toggles rather than the game’s own code.
Two ways games use Steam Cloud
Games can use Steam Cloud in one of two ways, and the choice is invisible to players but explains a lot of the inconsistency between titles. The first is Steam Auto-Cloud, which requires only configuration and no game code. A developer sets root paths, subdirectories, file patterns with wildcards, and operating-system restrictions on the Steamworks website, and Steam handles the rest. Auto-Cloud supports variables that insert the current user’s Steam identifier into the path, specifically {64BitSteamID} and {Steam3AccountID}, so a shared or family computer can keep save files for each Steam user in a separate folder instead of overwriting one another.
The second path is the Steam Cloud API, exposed through the ISteamRemoteStorage interface. Valve’s API reference describes it as providing functions for reading, writing, and accessing files which can be stored remotely in the Steam Cloud. Games using the API call functions such as FileWrite and FileRead to move save data, FileDelete to remove a file both from the local disk and from the cloud, and FileForget to remove a file from remote storage while leaving it on the local disk. That FileForget distinction matters for quota management: a developer running out of cloud space can forget older files rather than asking the player to choose what to delete. Valve explicitly discourages prompting players with a question like which file they would like to delete, because it removes a significant advantage of using the Cloud in the first place — its transparency.
A related set of functions exists for diagnostics and cross-device behavior. GetQuota returns the total amount of bytes the user has access to and the number of bytes available, while IsCloudEnabledForAccount reports whether the account-wide Steam Cloud setting is enabled. GetSyncPlatforms and SetSyncPlatforms control which platforms a given file synchronizes to. BeginFileWriteBatch and EndFileWriteBatch let a game wrap several file writes into one logical state change, so updating a main save and a companion metadata file together does not leave the cloud holding half of a new state if the game crashes between writes.
Quotas and file-size limits
Steam Cloud is not unlimited, and its limits are per game and per user rather than per machine. To set up the feature, a developer must set the byte quota per user and the number of files allowed per user on the Steam Cloud Settings page in the Steamworks admin panel. Valve states that this quota is enforced on each Cloud-enabled game, on a per-user-per-game basis. A game whose developer configured a small quota will simply stop storing additional cloud files once that quota is reached, regardless of how much free space the player’s own machine has.
There are also two hard file-size thresholds in the API documentation. The maximum size for a single call to FileWrite or FileWriteStreamWriteChunk is 100 MB. Files around 256 MB may result in a non-optimal storage endpoint choice for the user’s location, negatively impacting upload and download performance. Those two numbers are the reason behind the practical advice to keep individual save files modest: one bloated save file can push a game into the slower endpoint tier even when the total quota has room to spare.
The consequences are mostly invisible until they are not. A game that stores every autosave in one ever-growing file, or that never separates frequently changing state from rarely changing state, uploads more bytes on every session and hits its ceiling sooner. Players usually cannot fix this from the client; the remedy sits on the developer’s side, which is why deleting your save data is almost never the correct response to a sync problem.
Conflicts, and what Steam Cloud is not
Sync conflicts are the part Valve’s documentation describes least directly, but the sync ordering explains how they arise. Steam uploads at session end and downloads before the next launch. If a player ends a session on one machine and then ends a session on a second machine before the first upload has propagated, or plays the same title offline on two machines between syncs, the two machines can hold different versions of the same file. Valve’s tooling for this situation is the local-change machinery in ISteamRemoteStorage — the RemoteStorageLocalFileChange callback and GetLocalFileChange functions — which let a game detect that local files changed during a session and react. For most games, the observable outcome is that the most recently uploaded version wins, and the safe habit is to avoid playing the same title on two machines back-to-back without letting the post-exit sync finish.
It is worth being precise about what Steam Cloud is not. It is not a general-purpose backup: it only stores files the developer opted in, and only up to the configured quota and count. It is not a version-history system, a save editor, or a way to recover a save that was deleted days ago. Valve’s documentation also advises developers to avoid machine-specific configurations such as video settings in cloud-synced files, which is a reminder that what a game chooses to sync is a design decision, and players should not assume graphics settings or key bindings travel with a save.
Cross-platform saves
Steam Cloud can carry saves across operating systems when a game is configured for it, but the capability is not automatic. For Auto-Cloud, a developer sets Root Overrides so a path on Windows maps to the correct location on macOS and Linux or SteamOS. Valve’s guidance is that a developer should only specify an OS restriction if a game does not and will not support cross-platform saves, because restricting a file to one OS means a customer with devices across multiple platforms will never have their progress saved across those devices. In practice, whether a specific game’s save transfers between, say, a Windows PC and a Steam Deck depends entirely on that game’s Auto-Cloud or API configuration, and there is no universal setting a player can flip to force it.
Steam Deck and Dynamic Cloud Sync
The Steam Deck introduced a behavior called Dynamic Cloud Sync. Standard Steam Cloud only synchronizes at session boundaries, but Dynamic Cloud Sync lets changes that appear in the cloud be downloaded to a local machine during an application session. The canonical scenario is a suspended game on the Steam Deck: at suspend time, Steam uploads the current files; the player can then run the game on another device, whose changes are uploaded when that session exits; and when the Deck is awakened, Steam synchronizes the changes back down and posts a notification to the application that local files have changed. The feature supports games whether they use the ISteamRemoteStorage API to manage files or Auto-Cloud.
The suspend flow is also where Valve’s hardware documentation adds a caution. The Steam Deck FAQ notes that the device will disconnect from Wi-Fi while suspended, so Valve recommends backing up save files before suspending, and states that it planned to provide APIs to help. Even with Dynamic Cloud Sync, a Deck suspended mid-session and then left offline depends on the upload-at-suspend having completed before the network dropped. The reliable habit when a handoff between devices matters is to let the game save and exit cleanly rather than relying on suspension alone.
The practical consequence for players is that both devices must be able to reach Steam’s servers for a cross-device handoff to work. Dynamic Cloud Sync does not create a direct Deck-to-PC connection; it routes changes through the cloud, so both the suspend-time upload and the wake-time download depend on connectivity and on the game actually handling the local-change notification Valve describes.
What to do when sync misbehaves
When a Steam Cloud problem appears, a few checks resolve most cases, and they follow directly from the documented mechanics. First, confirm the game supports cloud saves at all: look for the cloud icon in the Steam library and check the title’s Properties for the per-game cloud toggle, since the global and per-game switches are independent. Second, confirm the account-wide setting in Steam Settings under Cloud is still enabled; this is the single most common reason a game silently stops syncing after a settings change or a fresh install. Third, if a specific save is stale or missing on one machine, let the game exit normally and wait for Steam’s post-exit upload to finish before shutting down Steam, because synchronization happens at session end rather than continuously.
Where the documentation is silent, treat your own testing as the authority. Cloud storage is per game and per user, so a title with a small quota can hold far less than another title even though both show the same cloud icon. If you rely on a save you cannot afford to lose, make a manual copy of the local save files before reinstalling the operating system or moving machines. Steam Cloud is a synchronization feature, and its own documentation frames it as such rather than as a durable backup service. The distinction is the difference between a save that follows you between computers and a save that survives a deleted account or a developer-side outage.
