The first version of cloud save you build is almost never the one you ship. You wire up Steam Cloud in an afternoon, it syncs your save between your desktop and your laptop, and it feels done. Then someone asks the real question: can a player start on PC and pick up on their PS5? And the afternoon fix quietly turns into a project.
This trips up developers on every engine, because the thing most people call "cloud save" is really two different features wearing the same name. One keeps a player's save synced across their own devices inside a single ecosystem. The other lets a player carry one identity, and one save, across Steam, PlayStation, Xbox, and mobile. The first is close to free. The second is a backend.
Here's the part worth internalizing before you write a line of code: a save file is the easy layer. Serializing progression to JSON and dropping it somewhere is table stakes. The work is everything under it.
Notice which layer everyone reaches for first, and which one actually decides whether cross-platform save is possible. The identity layer is the prerequisite. If a Steam login and a PSN login don't resolve to the same player, there is no "their save" to sync, only two unrelated saves that happen to belong to the same human. We'll come back to that, because it's the thing that quietly kills most cross-platform save plans. First, what each engine actually hands you.
Unity has a first-party answer: Cloud Save, part of Unity Gaming Services. It stores player data as key-value records or as arbitrary Player Files in any format, and it integrates with Cloud Code so you can run server-side logic when data changes. For a Unity team already living in UGS, it's the path of least resistance. You install the SDK, enable the service in the dashboard, authenticate the player, and read and write records.
The catch is the word "authenticate." Cloud Save syncs data for a player identity, and that identity comes from Unity Authentication. Out of the box you get anonymous sign-in tied to a device, which is exactly the thing that doesn't travel across platforms. To make a save follow a human rather than a device, you link real platform logins to that Unity identity, Steam, Google, Apple, and so on. That's the same identity problem from the diagram, just wearing Unity's clothes. Cloud Save handles the storage cleanly. Whether the save is genuinely cross-platform depends entirely on whether you've done the account-linking work underneath it.
There's also the everyday reliability layer, and this is where a lot of Unity teams get bitten. As one Unity save-systems writeup puts it, you want to implement retries and caching to handle network failures, and keep telling the player when their progress won't be saved without a connection. Cloud storage is not magic durability. It's a network call that can fail, mid-write, on a train, right when the player did something they care about.
Unreal's built-in path is the USaveGame object. You define a class, fill it with what you want to persist, serialize it to a slot. It's clean and it works, and it writes to the local disk. That's the whole story until you add a platform, at which point you meet Unreal's per-platform save directories, and the fact that "cross-platform" in the SaveGame world is really "sync my local files across machines" rather than "one save that follows my account."
Steam is the clearest example of what that costs. If you point Steam Auto-Cloud at per-OS root paths, Steam partitions your files by platform, and you get no cross-platform save at all. To make saves cross-platform you define a single root (usually the Windows one) and add Root Overrides for the other operating systems, so files sync across all of them. That's real, documented configuration work, and it only covers the platforms Steam itself reaches. It does nothing for a console.
The common next step is Epic Online Services. EOS Player Data Storage lets you store a save blob per player and pull it back from any device where that player is logged into their Epic account. That genuinely crosses platforms, and it's free. Concede the strength plainly: if you're shipping on Epic's ecosystem and your players have Epic accounts, EOS gives you a lot for zero dollars, and it's a sensible default.
Where it stops is worth knowing before you build on it. Player Data Storage is owner-only, so there's no access control and no data sharing: a player can read their own data and nothing else. There's a per-player storage ceiling (community documentation for the integration kits puts it at 400MB per player), which is generous for a save file and tight for anything media-heavy. And it's the same shape as every first-party option: your save is tied to that platform's account model, so you're building on Epic's identity, not your own. That's fine right up until you need a player who has never touched an Epic account, or you need the server to read and validate a save the player shouldn't be able to forge.
Godot is the honest one, because it doesn't pretend. There's no built-in cloud anything. You get FileAccess and a user:// path, and what you do past that is up to you. For a local save that's liberating. For cloud save it means every layer in that diagram is your job.
The community answer is usually Steam. GodotSteam plus a Remote Storage wrapper gets you Steam Cloud, which syncs a player's save across their Steam devices, and there are open plugins that even surface conflict callbacks so you can reconcile a local and remote file. That's a real, shippable solution for a PC-first game. It is not cross-platform in the sense that matters for consoles, and Steam's own storage caps make it awkward for large or unpredictable save sizes.
The clearest statement of the real cost showed up, of all places, in a player thread about Slay the Spire 2, which moved to Godot. A player asked for cross-platform cloud saves. Another player answered, correctly, that cross-platform saves would require the studio to run their own servers, build their own account system to link devices together, and get every platform holder to sign off on the implementation, and that Steam Cloud is the easier path. That's not a Godot limitation. That's the actual scope of cross-platform save, stated plainly by someone who clearly hit it. Godot just doesn't hide it behind a first-party service, so Godot developers tend to understand the problem earlier than most.
Say a player has your game on their phone and their console. On the train, offline, they clear level 12 and spend 300 gold on the phone. That save never uploads, because there's no signal. That evening at home they play on the console, clear level 11, buy a skin, and the console save uploads fine. Now there are two saves that both believe they're the truth, and they disagree.
The naive fix is "newest timestamp wins." Apply it here and the console save wins because it uploaded last, and the player's train session, the part they actually remember doing, silently vanishes. This is not a hypothetical. It's the single most common cloud-save complaint on Steam forums, and it has a signature: the player swears they made progress, and the game swears they didn't. Steam Deck users hit a sharp version of it, where putting the Deck to sleep mid-session and playing elsewhere lets the older Deck save overwrite the newer cloud one on wake.
Doing it properly means detecting the divergence rather than resolving it blindly. On load, compare local and cloud, and when they've both moved since the last common point, that's a conflict, not a race. Then you either merge (hard, and only safe for data that composes cleanly, like additive unlocks) or you surface it and let the player choose, with enough context that "keep local" versus "keep cloud" means something to them. PlayFab's Game Saves model is instructive here: it groups save data into atomic units and detects conflicts per unit, but still presents the player one clear keep-local-or-keep-cloud choice rather than making them adjudicate every file. The detection is granular; the decision the player sees is simple. That's the balance you're aiming for.
None of this is exotic. It's just work that no engine does for you, because the right answer depends on your save's shape, and getting it wrong is invisible until a player loses a session and tells everyone.
Step back and the pattern across all three engines is the same. Unity's Cloud Save, Unreal's EOS storage, Godot's Steam wrapper, each stores bytes fine. Each is bound to an account model you didn't design. And the moment you want a save to cross from PlayStation to PC, you discover the storage was never the hard part. The identity was.
This is why studios end up building an account system: a store keyed to a player identity you control, that every platform login links into, so the same human is the same player whether they came in through Steam, PSN, or a phone. Once that exists, the save is almost boring, it's just a record hanging off an identity that already spans platforms. Without it, you're back to two unrelated saves for one person.
You can see studios deciding this scope in public. Hades shipped without cross-save between PC and Xbox, the developers citing technical constraints. Vampire Survivors announced cross-save across PlayStation, Xbox, PC, and mobile, then had to walk back the PlayStation piece over a last-minute legal issue involving disclosing partner information. These are not small or inexperienced teams. Cross-platform save is genuinely a project, and the platform-holder approval process is part of why.
If you've reached the point where you need one identity and one save across platforms, and you'd rather not build and run the account system, the storage service, and the platform-linking flows yourself, this is the class of problem a game backend platform is built for. AccelByte is a useful concrete reference for how the pieces fit, because it splits them the way the problem actually splits.
Identity comes first, because it has to. AccelByte Gaming Services (AGS) creates one player account and links third-party logins into it, Steam, PlayStation, Xbox, Nintendo, Epic, Apple, Google, so a headless account made from a Steam login and one made from a PSN login can resolve to the same player. That's the prerequisite layer from the first diagram, handled as its own service rather than inherited from whichever storefront the player happened to launch on. (If you want the build-versus-plug-in version of just this decision, we wrote it up separately.)
Cloud Save then sits on that identity. It stores arbitrary game data as JSON records (recommended under 1MB each) or as binary records for things like images and audio (up to 100MB), and, because the data hangs off an AGS identity rather than a storefront account, the same record is reachable whether the player is on PC or console. It also draws the distinction the first-party options mostly can't: Player Records that the player can read and write, versus Admin and Game Records that only the server can touch. That server-authoritative side is exactly what you need when a save affects something a client shouldn't be trusted to set, currency, entitlements, anti-cheat-relevant state, and it's precisely what EOS Player Data Storage's owner-only model doesn't give you.
The engine story is deliberately unremarkable, which is the point. AGS ships an Unreal Online Subsystem (OSS) implementation and a Unity SDK, both with worked Cloud Save modules in the open-source Byte Wars sample, so SetPlayerRecord / GetPlayerRecord from Unreal and the equivalent Unity calls talk to the same store. Godot isn't a first-party SDK target today, so a Godot studio would go through the REST APIs directly (worth flagging honestly rather than implying a drop-in plugin exists).
And when the default behavior isn't enough, when you need custom validation on a write, or logic that runs when a record changes, AccelByte Extend lets you host that logic (AGS recently added a requester user ID to the Cloud Save override payload specifically so custom rules can allow or reject a write based on who's making it). That's the "detect and validate" side of the conflict problem, run on the server instead of trusted to the client.
The honest tradeoff: adopting a backend is a bigger upfront commitment than dropping in Steam Cloud, and for a PC-only, single-ecosystem game it's more than you need. Steam Cloud or EOS is the right call there, and you should take it. The backend earns its place when "one player, one save, every platform" is a real requirement, and the cost of building that yourself, an account system, a durable store, platform linking, conflict handling, and the on-call to keep it up, is the cost you were actually trying to avoid.