v0.5.0

v0.5.0

Released 29 July 2026

The largest release so far, and almost all of it is repair. Three deliberate hunts for defects — one
through the server and console, one through the Steam Deck agent, one through the Windows agent —
turned up 34 problems, including one that was quietly destroying save history. They are all fixed
here.

If you read only one thing: back up /data before upgrading, and note that SaveLocker no longer
pulls automatically when a game launches on Windows.

Before you upgrade

• Back up /data. This release changes the database, and the change runs automatically the first
  time the new container starts. Going back to an older container afterwards is not a clean rollback
  — that is why this is 0.5.0 and not 0.4.2. The nightly backups in /data/backups/ are a reasonable
  starting point, but take a fresh one.
• The console must be redeployed (docker compose pull && docker compose up -d). Previous
  releases only touched the agents; this one changes the server.
• Windows agents update themselves. On Steam Deck, download the newer tarball and re-run
  install.sh.

Changes worth knowing about

• Windows no longer pulls your save automatically when a game launches. This was never safe and
  could not be made safe: Windows only notices a game up to four seconds after it starts, by which
  point the game already has its save files open. What was described as a "pre-launch pull" could
  therefore write over a save that the game then overwrote again when you quit — losing whatever was
  pulled, silently. SaveLocker now refuses to pull while a game is open and tells you why.
  Pull before you play. Launching still checks the game out to your machine, and quitting still
  pushes; only the automatic pull at launch is gone. Steam Deck is unaffected — there the launch
  wrapper genuinely runs before the game does.
• Pointing an agent at a different server now asks you to register again. The machine key, ID and
  certificate fingerprint were issued by the old server and mean nothing to the new one, so they are
  cleared rather than sent on to a server that was never meant to see them.

Fixed — your saves

• Removing a machine no longer deletes its saves. The confirmation dialog promised the version
  history would be kept, and it was not: removing a machine destroyed every save version that machine
  had uploaded. If one of them was the current Latest, the game was left with no Latest at all — its
  saves still on disk, but nothing left to reach them with. Storage totals dropped to match. This
  upgrade preserves existing history; anything already lost this way cannot be recovered from the
  database, though the archive files themselves were never deleted.
• An interrupted upload no longer leaves a broken save on the server. A save sent by a machine
  that lost its connection part-way was written straight to the place a real save lives, and repeated
  failures quietly filled the disk. Saves are now assembled aside and only put in place once
  complete, so what the server keeps is either a whole save or nothing.
• "Set as Latest" now actually reaches your machines. It promised every machine would pull the
  save you chose and then told none of them: the choice was recorded on the server while the machines
  carried on from the save they already had, hitting a conflict on their very next save. The same gap
  applied to rollback and to the automatic conflict settings. All of them now queue a sync for every
  machine that syncs that game — and, as everywhere else, that sync will not overwrite local changes
  you have not pushed. Those machines report the pull as blocked so you can decide.
• Choosing a Latest clears the argument it settles, instead of the console continuing to flag the
  very save you just picked.
• A game can no longer be pointed at a folder that isn't a save folder. A drive root, your user
  profile, C:\Windows, Program Files or SaveLocker's own settings folder are refused outright —
  they could previously be uploaded, and a force-pull would have replaced them. Folders that merely
  look wrong, like a Wine prefix or something suspiciously large, ask for confirmation instead of
  proceeding quietly. The check runs again at the moment of syncing, so a mapping edited by hand or
  sent by the server is caught too.
• Quitting a game always releases its checkout, even if the save fails to upload. It previously
  released only after a successful push, so a failed upload left the game checked out to your PC —
  and every other machine locked out of it — until the checkout expired.
• Two SaveLocker processes can no longer sync the same game at once. When one was busy, the other
  gave up waiting after 30 seconds and proceeded anyway, which is exactly what the wait exists to
  prevent. It now waits as long as the work could legitimately take, and reports that the game is
  busy rather than joining in.
• Deleting a save version cannot leave the server offering one it no longer has, and a file the
  server fails to delete is recorded in the audit log rather than forgotten.
• A save that is too large is refused clearly — "too large", against the configured limit, rather
  than a generic server error.

Fixed — the console

• A Pull, Push, Sync or Scan sent from the dashboard no longer goes missing. If the machine
  dropped off between picking the job up and finishing it — a reboot, a crash, the network going away
  mid-report — the job sat in "Dispatched" forever and nothing ever ran it or said so. Jobs are now
  handed out on a time limit: one that is not confirmed goes back in the queue and the next check-in
  picks it up. The dashboard shows "retried ×2" when that happens, and says whether a job is running
  or waiting to be handed out again.
• Launching the same game on two machines at once no longer errors. Whichever got there first
  takes the checkout and the other is told who holds it, which is what it was always meant to say.
  Previously one of the two got a server error instead — at exactly the moment the checkout is the
  thing protecting your save.
• Enrollment files can no longer be created with an address the new machine cannot use. If you
  opened the console on the server itself, at localhost, the file told the new machine to sync with
  itself, and the only sign was enrollment failing for reasons that pointed nowhere. The console
  now shows the exact address the file will carry before you create it, refuses to create one that
  cannot work, and rejects a mistyped address without spending the single-use token on it. There is a
  new optional Server:PublicBaseUrl setting if you want to pin the address agents should use.
• An enrollment file is never used up without handing back a key. Setting up a machine spent the
  single-use token first and issued its key second, so a failure in between left the file dead and
  the machine still not enrolled.
• A bad SteamGridDB key no longer wipes out your working one. The key was saved first and checked
  afterwards, and the console said "saved" either way — so a mistyped paste quietly replaced a key
  that worked. It is now checked before anything is stored, your existing key is untouched, and what
  you pasted stays in the box so you can fix it. The check itself was also wrong: it asked
  SteamGridDB something that does not need a key, so any text passed.
• Uploading an agent installer can no longer break the update channel. Any file was accepted:
  uploading a text file by mistake replaced the working installer and left every machine being
  offered that as an update. Uploads are now validated before anything is replaced, and the new
  installer is only put in place once it has arrived in full. There is a real size limit again
  (200 MB, configurable).
• A machine that has never checked in says "never reported" rather than "offline since —", which
  read as a machine that had stopped rather than one that had not started.
• Browser Back and Forward work again across Games, Configuration and Audit Log.
• The console uses the fonts it was designed with. A stylesheet ordering mistake meant the
  browser discarded the font import and fell back to system fonts everywhere.
• Saves uploaded by a machine you later removed still say who made them — the machine's name
  followed by (deleted), rather than a blank — and stay downloadable and selectable when resolving
  a conflict.

Fixed — Windows

• Updates are checked before they run. The server publishes a checksum for the installer and the
  agent refuses anything that does not match, or that is not actually a program. Updates from a
  location other than your own server are refused unless a checksum is published for them, and your
  machine key is never sent to a download host. Changing servers discards any update the previous one
  had offered.
• A mistyped server address is rejected instead of saved. It used to be written to disk and then
  crash the agent on every start afterwards.
• The folder holding this machine's credentials is now restricted to the account that set
  SaveLocker up, plus SYSTEM and administrators. %PROGRAMDATA%\SaveLocker holds this machine's
  server key and the token for its local settings API, and it had been inheriting Windows' default
  permissions, which grant every account on the PC read access.
• Games added through the app now know which program to watch for. Only the command line could
  set this, so games added through the window were invisible to launch and exit syncing entirely.
  Where SaveLocker cannot work it out — an installed Steam game, for instance — Settings now says
  "Launch/exit sync not configured" and lets you fill it in, rather than implying it works.
• "Start with Windows" now tells you the truth. The switch reported success whether or not
  Windows accepted the change, so where security software or workplace policy blocks startup entries
  it showed as on while nothing started at login. It now reports the failure and why. It also no
  longer shows as on when the entry points at a copy of SaveLocker that has been moved or uninstalled.
• One unreadable folder no longer empties the whole game search. If SaveLocker met a folder it
  could not read while looking for games, the search failed outright and found nothing — which also
  took away the manual "choose the folder yourself" route you would have used instead. It now skips
  what it cannot read and returns everything else.
• Answering "Yes" to the first-run prompt opens Settings, not the Overview page — on exactly the
  install where there is the most to set up.

Fixed — Steam Deck and Linux

• Changing the server address moves all sync traffic to it. Only some of it moved before: the
  agent kept uploading saves to the old server while talking to the new one about everything else,
  with nothing reporting a problem.
• Removing a game from a device actually removes it. Game Mode said "Removed from this device"
  and the background service quietly added it straight back, usually within a minute. The game stays
  on the server for your other machines — this only stops this device syncing it.
• savelocker remove-game --name "<game>" — a new command, because on a Deck there was no way to
  stop syncing a game without the Game Mode UI.
• Setting a save folder takes effect immediately. The folder was saved but not watched until the
  agent restarted, so a game mapped after setup could sit there never syncing. The choice is also
  reported to the console right away.
• Adding several games at once no longer loses the ones that worked. If a later game failed, or
  the window was closed part-way, the earlier ones were discarded — including the Steam AppID that
  makes launch-time syncing work.
• Adding games no longer crashes the Game Mode window.
• Changing a setting in Game Mode no longer undoes other changes. Toggling interface sounds or
  the sync delay wrote back the whole configuration as the app found it at launch, discarding
  anything that had happened since.
• Turning off "Start on boot" reports the truth. It always claimed success, even where it could
  not work at all — so the service stayed enabled and running while the toggle showed it off.
• savelocker doctor gives correct answers. With a custom config path it reported on the wrong
  folder, and it described an un-enrolled device as "server unreachable", sending people to debug a
  network that was fine. It now separates cannot reach the server, reached it but this device is
  not enrolled, and connected and healthy.

For the curious

Two families of bug account for a surprising share of this list.

The first is a long-lived background process holding the configuration it read at startup and writing
it back later over changes it never saw — which is how removing a game could undo itself, and how one
machine could end up in a save conflict with nobody but itself. The fixes push the rule down into the
storage layer rather than asking every one of seventeen callers to remember it.

The second is a report that describes an intention rather than an outcome: the toggle that said
"enabled" because it had asked, the job that said "dispatched" because it had been handed out, the
key that said "saved" before anyone checked it. Each was individually small and collectively
corrosive, because the interface stops being evidence of anything. Several fixes here do nothing more
than read the state back and say what is actually true.

Known issues

• Windows will not pull a save while the game is running, by design — see above. If you launch a
  game before syncing, quit it first and then pull.
• The Windows credential permissions described above have been verified programmatically but not yet
  by signing in as a second Windows user on a shared PC. If you share a machine and this matters to
  you, treat it as improved rather than proven.