Satisfactory Save Files: Where They Are and How to Back Them Up

A hundred-hour factory lives in a file on your machine, and the game’s own protections are thinner than most people assume. This is the shortest page on this site with the highest consequence for ignoring it.

Where saves live

On PC, under your local application data:

%LOCALAPPDATA%\FactoryGame\Saved\SaveGames\

Inside that, saves sit in a folder per account, and blueprints sit in a separate blueprints folder organised by world name. Those are two different things — copying only the save does not copy your blueprint library.

On console, saves are not accessible to you as files. Each platform has its own cloud backup through PSN or Xbox, but there is no transfer between platforms and no cross-progression, so a console save stays within that platform’s ecosystem.

On a dedicated server, saves live in a separate server subfolder rather than in a per-account ID folder. On a managed host this is usually behind a control panel and you will not need the raw path.

What the game already does for you

Two protections exist before you lift a finger, and knowing their limits is the point.

Rotating autosaves. Runs on a timer and keeps several slots. This covers a crash.

A backup on overwrite. When you save over an existing file, the game keeps a copy of the previous version in a SaveGames_backup folder alongside the main one. Worth knowing because it is the one protection against an overwrite you regret.

That second protection does not apply to autosaves. An autosave writing over a slot does not create a backup copy unless you overwrote it manually. So the automatic protection covers the case you are least likely to cause and not the one you are most likely to.

What autosave does not protect you from

That leaves the things that actually lose factories:

Deliberate destruction you regret. Dismantling a working line to rebuild it, then realising the rebuild is worse. Autosave has probably already overwritten the state you wanted.

A change you notice hours later. Ratios you altered, a belt you rerouted, a recipe you switched. By the time the consequence appears, every autosave slot is post-change.

File corruption. Rare, and it takes everything in the folder with it.

The two-minute habit

Make a named manual save before anything drastic, and copy the folder somewhere else occasionally.

“Drastic” means: large demolitions, restructuring a working production line, switching a chain to a different recipe, or the start of any session where you plan to experiment.

A named save costs seconds and sits outside the autosave rotation, so it does not get overwritten. This single habit prevents most situations where people go looking for a save editor.

For the folder copy — anywhere off the machine is better than nowhere. The whole SaveGames directory is small.

Cloud sync is not a backup

Steam and Epic both sync saves across machines, and it is easy to mistake that for protection. It is not.

Sync mirrors your current files. A corrupted save, or one you overwrote by accident, propagates to every machine rather than being contained on one. The thing that makes cloud sync convenient is exactly what makes it useless as a backup.

A specific case to watch: the sync prompt that appears when you switch between the experimental and stable branches, or copy a save between platforms. It asks whether to upload your local file or download the cloud one. Unless you are deliberately playing across several PCs, upload is the safe answer — downloading can replace newer local progress with an older cloud copy.

A copy of the folder somewhere the sync does not reach is what actually protects you.

Save editors exist, and they are not what you want first

Third-party save editors are established community tools, used mainly for recovering broken saves rather than for cheating. Notably, using one does not disable achievements — only Creative Mode does, which is the reverse of most games.

But reaching for one is a recovery step, and recovery is always worse than a backup. If you are reading this before you have a problem, the backup is the answer.

They are PC-only. Console has no equivalent.

Multiplayer changes where the risk sits

In a hosted session the world lives on the host’s machine. Everyone else’s hundred hours depend on one person’s hard drive and one person’s willingness to keep playing.

Two consequences worth raising with a group early:

The host should back up. It is not only their save.

A dedicated server moves the file, but it does not create backups. The server keeps save files; nothing automatically copies them somewhere safe. Pulling a copy down periodically costs a minute.

Blueprints need their own backup

Worth stating separately because it catches people who do back up their saves.

Blueprints are files in a different folder, organised by world name. And deleting a blueprint in game removes the file permanently — loading an older save does not bring it back, because the design does not live in the save.

So a blueprint you spent an hour refining has exactly one protection: a copy of that folder.

Moving a save to another machine

Copy the folder. Saves are not tied to hardware, and a save from one PC loads on another with the same game version.

Version matters. A save from a newer build may not load on an older one, so if you are moving between machines, update both first.

A backup routine that people actually follow

Elaborate schemes get abandoned. The version that survives contact with a real playthrough:

One named save at the start of each session. Name it something you will recognise — “before oil rework” beats “save 3”. This costs ten seconds and gives you a rollback point for the thing you are about to do.

One folder copy per week of real time, or after any session where you built something substantial. Drag the SaveGames folder somewhere else. That is the whole procedure.

Keep three or four generations. Not because you will need the oldest, but because the failure you are protecting against is sometimes “I broke it two sessions ago and only just noticed”.

That is it. There is no need for automation, versioning tools, or anything clever. The common failure is not an inadequate backup system, it is not having one at all.

What a corrupted save looks like

Rare, and worth recognising because the symptoms are specific.

A save that will not appear in the load list, or one that loads to a black screen or crashes partway through loading, is usually corrupt rather than incompatible. A save that loads but is missing structures is a different and much rarer problem.

The first thing to try is a different save slot — autosave keeps a rotation, so the previous one is often intact. If every slot in a world is affected, that is when the folder copy you made becomes the difference between continuing and starting over.

Session length and autosave interval

The autosave interval is adjustable in the game’s options, and the default is reasonable for ordinary play.

Two situations where shortening it helps: long building sessions where you are placing a lot and would rather not repeat twenty minutes of foundation work, and unstable hardware, where a crash is a live possibility rather than a theoretical one.

The trade is a brief pause when it writes, which on a very large factory becomes noticeable. If your autosaves are causing a visible hitch, lengthening the interval and making named saves manually is the better arrangement.

Common mistakes

Trusting autosave for anything but crashes. It rotates, so it overwrites the state you wanted — and unlike a manual overwrite, it leaves no backup copy behind.

Treating cloud sync as a backup. It mirrors corruption to every machine you own.

Backing up saves and forgetting blueprints. Different folder, and blueprint deletion is irreversible.

Assuming a dedicated server backs itself up. It stores files; it does not copy them anywhere.

Reaching for a save editor before making backups a habit. Recovery is worse than prevention.

Expecting cross-platform save transfer. There is none, in either direction.