
The Silent Memory Tax: What Launcher Overhead Actually Costs While Idle
Discover how much RAM Steam, Epic, and Ubisoft silently consume in the background and why your PC feels sluggish even when you aren't gaming.
I replaced the Epic Games Launcher with GOG Galaxy 2.0 and custom scripts to reclaim RAM, but the manual cloud save management nearly cost me my *Satisfactory* progress.

Editorial image illustrating I Ditched the Epic Launcher for 30 Days and Here’s How My Cloud Sync Suffered
March 1st, 2026, marked the end of my patience with background processes. After benchmarking my rig for a new modlist, I realized the Epic Games Launcher—sitting minimized, doing nothing—was hogging roughly 450MB of RAM and intermittently spiking my CPU. I decided right then to uninstall it. I wasn't deleting my games; I just wanted to launch them directly or through a unified interface without the overhead.
I knew I would lose the storefront, the social features, and the achievements. I accepted that. The one feature I underestimated was the cloud synchronization. I assumed replicating a "save game backup" system would be trivial. It wasn't. What followed was a month of fighting directory permissions, version conflicts, and the realization that modern launchers provide a specific glue that keeps our digital lives coherent across devices.
My goal was simple: run Alan Wake 2, Satisfactory, and Rocket League directly from their executables, managed by GOG Galaxy 2.0. For cloud saves, I planned to use a combination of Syncthing and a custom Robocopy script. I use a desktop in my office and a high-end laptop in the living room; keeping my progress in sync is non-negotiable.
The first three days were euphoric. My boot times felt snappier, and the launcher overhead vanished completely. I imported my Epic titles into GOG Galaxy, which scraped the metadata and gave me a pretty, unified library. I could double-click Rocket League, and it would launch immediately without the five-second "Checking for Updates" dance that the Epic client forces on you every single time.
However, the illusion shattered when I took my laptop to the couch on day four. I fired up Satisfactory to continue building my mega-factory in the northern desert. The main menu loaded. I clicked "Continue."
The game started a new tutorial.
Panic set in. I Alt-Tabbed and checked the save path: %LOCALAPPDATA%\FactoryGame\Saved\SaveGames. The folder was empty. My 20 hours of progress on the desktop were sitting in a different folder, or rather, they were sitting on the desktop, entirely unaware that the laptop existed. Epic’s cloud service had been silently shuffling these .sav files back and forth for years. Without it, I was just two isolated computers.
I refused to reinstall the launcher. This was now a matter of principle. I set out to build my own cloud infrastructure. I decided on Syncthing, a peer-to-peer continuous file synchronization tool. It’s lightweight, open-source, and doesn’t rely on a central server—you just point Device A at Device B, and it syncs.

I installed Syncthing on both machines and pointed it to the Saved Games directory where most Epic titles store their data. I hit sync, watched the green bars fly across the screen, and assumed I had solved the problem. I was wrong.
The issue wasn't the transfer speed; it was the timing and file locking. When Satisfactory runs, it keeps the save files locked to prevent corruption. Syncthing detects these locked files and waits for them to be released. One evening, I played on the desktop until 2:00 AM, put the PC to sleep without closing the game properly, and woke up the laptop to play before the desktop had fully synced.
The result was a "Sync Conflict." Syncthing created duplicate files: savefile.sav and savefile.conflict.2026-03-15-094512.sav. One had my base. The other had two hours of progress from a previous session. Merging binary save files is impossible; you have to pick one. I lost the progress from the night before because the timestamps were misleading. The Epic Launcher handles this by checking file headers and last-server-acknowledged states. My DIY setup just looked at the clock.
The situation worsened when I dove into Alan Wake 2. Remedy’s games often save in a variety of locations, sometimes nesting deeply in AppData or Documents. I found that while some files were syncing, others—specifically the user profile configuration and graphics settings—were not being pulled from the root Documents folder.
I spent an entire Saturday mapping the exact save locations for my library. I had to create a "Master Save" folder on my NAS and use symbolic links (mklink in Command Prompt) to trick the games into thinking they were saving to Documents, when they were actually writing to a synced network drive.
This is high-risk behavior. If your network hiccups, or if the symbolic link breaks, the game might crash or fail to save entirely. I recall a moment in Alan Wake 2 where I sat through a ten-minute cutscene, reached a checkpoint save, and the game froze for a second. I checked the logs: "Write Delay Failed." The sync couldn't keep up with the write speed. I hadn't just lost cloud sync; I had actively compromised the local save stability.
I tried to refine the process. I ditched the continuous sync for a scheduled batch script using Robocopy. The idea was that every time I launched a game via GOG Galaxy, it would trigger a script to pull the latest saves from the NAS first, then launch the executable. When I closed the game, it would push the changes back.
Getting GOG Galaxy to run a pre-launch script for a non-GOG game is hacky at best. I ended up creating custom shortcuts for every game. My "Play Satisfactory" button was no longer a simple click; it was a batch file that ran a command line sequence:
robocopy "\\NAS\Saves" "C:\Users\Lucas\Saved Games" /MIRFactoryGame.exe.robocopy "C:\Users\Lucas\Saved Games" "\\NAS\Saves" /MIR.It worked, technically. But it introduced a 30-second lag every time I wanted to play. Moreover, if a game crashed (which happens, especially with unoptimized launchers or mods), the "Wait for process exit" command might not trigger properly, leaving the sync hanging in limbo.
I realized I had become a sysadmin for my own gaming hobby. I was troubleshooting version conflicts, managing IP addresses for Syncthing, and debugging batch files instead of playing games. The time I "saved" by not waiting for the Epic Launcher to update was immediately swallowed by the time I spent maintaining my save data integrity.
After 30 days, I reinstalled the Epic Launcher. The moment it logged in, it recognized my cloud saves, downloaded the most recent versions without user intervention, and unified everything.
The experiment taught me that the "bloat" of launchers includes a lot of necessary error handling. When a cloud service handles your saves, it manages the conflict resolution, the file locking, and the versioning. When you offload that to generic third-party tools, you are responsible for edge cases. What happens if you edit an INI file on one PC and it doesn't sync? What happens if a game updates and changes its save format?
I still use GOG Galaxy as my primary interface because I hate the fragmented nature of PC gaming. I will continue to launch my games from there. But I have stopped trying to bypass the underlying infrastructure. I let the Epic Launcher sit in the background now. I treat it like a utility—like a driver or a firewall—rather than a storefront. It costs me 400MB of RAM, but it buys me peace of mind. The DIY route is a fascinating project for tech enthusiasts, but for the actual gameplay experience, the "walled garden" walls are actually safety railings.
If you are considering doing this, be prepared for the fact that "Cloud Sync" is not just file storage; it's a state management system. Replicating it requires more than a Dropbox folder; it requires a strategy for handling human error. Unless you enjoy debugging batch files more than playing video games, the convenience of the major launchers is a price worth paying.