How to Set Up Cloud Save Sync Across Multiple Devices in RetroArch

Current RetroArch documentation includes native Cloud Sync with WebDAV, iCloud, and iCloud Drive backends where supported. That corrects older advice claiming RetroArch has no cloud integration. A general-purpose synced folder remains an alternative for builds without the feature, but native sync understands RetroArch directories and maintains manifests for three-way conflict detection.

Synchronization is not backup. It can propagate deletion, corruption, or an empty save to every device. Create an independent, versioned backup and prove restoration before connecting a second machine.

Step 1: inventory save formats and compatibility

Record each device’s RetroArch version, core names/versions, content hashes, firmware, and paths under Settings → Directory. Normal save files, memory cards, save directories, and save states are different artifacts. Save states may be incompatible across core builds or CPU architectures even when sync transfers them perfectly.

Choose one device as authoritative. Close RetroArch everywhere else. Back up its Save Files, Save States, configuration, core options, playlists if needed, and any multi-file memory-card/NAND directory as a unit.

Step 2: align directory organization before syncing

RetroArch’s native guide warns that every device must match directory organization settings, especially:

Sort Saves into Folders by Core Name;
Sort Save States into Folders by Core Name;
Sort Saves into Folders by Content Directory;
Sort Save States into Folders by Content Directory.

Different values can place equivalent saves at different relative paths, preventing a clean merge. Record the authoritative settings and reproduce them before enabling the backend. Do not move live files while a core or sync client is running.

Step 3: choose the backend and protect credentials

WebDAV works across supported platforms and requires an HTTPS server URL, username, and password. Use a dedicated account or app password limited to a RetroArch directory when the provider supports it. Do not reuse an administrator password, place credentials in screenshots, or paste configuration/logs publicly.

iCloud uses CloudKit; iCloud Drive uses file storage and has different visibility behavior. Use the backend documented for each Apple build and sign in through operating-system settings. Do not install an unknown certificate or disable TLS verification to make a WebDAV endpoint connect.

Step 4: configure the primary device conservatively

Settings → Saving → Cloud Sync

Enable Cloud Sync, choose the backend, and begin with Destructive Cloud Sync off. Enable Sync Saves. Leave Sync Configs, Thumbnails, and System off until save behavior is verified.

System sync can include BIOS/firmware. Those files may be copyrighted, device-derived, large, or inappropriate to upload. Keeping Sync System off is the safe default. Configuration can also contain paths, usernames, service settings, or other private metadata; audit what the installed version includes before enabling it.

For WebDAV, enter the HTTPS URL with the required trailing slash and dedicated credentials. Save the configuration and restart as the official guide directs.

Step 5: wait for and verify the initial upload

Watch RetroArch’s status line until it reports completion. Enable file logging temporarily if the status is ambiguous:

Settings → Logging → Log to File
Settings → Logging → Logging Level → Debug

Cloud Sync messages are prefixed with [CloudSync]. Sanitize the log before sharing: remove URLs containing usernames, tokens, home paths, IP addresses, content names, and server responses that expose account details.

Verify a representative save, memory-card container, and state appears in backend storage or in RetroArch’s next manifest comparison as applicable. iCloud private containers may not be visible in Files.app; the official documentation says that can be intentional.

Step 6: add one secondary device at a time

Close RetroArch on the primary and ensure sync finished. On the secondary, first back up or quarantine any existing save directories; do not let two “authoritative” histories merge without review. Match organization settings and configure the same backend.

Start RetroArch and wait for sync. Launch one game without saving, confirm the expected in-game progress, then quit. If using a state, test only a duplicate after confirming the exact core build is compatible. Create a new in-game save, exit cleanly, and wait for the secondary upload.

Return to the primary only after the secondary is closed and synchronized. Verify the new in-game save. This round trip is the acceptance test before adding more devices.

Step 7: understand non-destructive mode and conflicts

RetroArch uses server and local manifests plus current local files for a three-way merge. When it detects both sides changed, current documentation says it leaves both versions unchanged and reports a conflict. With destructive mode off, files that would be overwritten or deleted are backed up under the core-assets cloud backup location.

When a conflict occurs, stop using all devices. Copy both candidates outside sync, hash them, compare timestamps and actual in-game progress, and decide which is authoritative. Follow the official conflict procedure for the installed version. Do not casually edit manifests: they are synchronization state, and an incorrect hash can make a bad file look authoritative.

Step 8: prevent concurrent writes

Use a simple rule: close content, quit RetroArch normally, wait for “Cloud Sync finished,” then open another device. Sleep, sudden power loss, and background suspension can interrupt save flush or upload. Do not leave a handheld suspended in a game while continuing that same save on desktop.

For memory-card images and NAND-like directories, synchronization during an active write can capture an inconsistent set. Treat the emulator session as a lock even if the backend does not provide one.

Step 9: add independent backup and retention

Keep scheduled, versioned copies outside the sync backend. Include manifests only as diagnostic material, not as the sole route to data. Periodically restore a backup into an isolated RetroArch profile and verify an in-game save survives launch, save, quit, and relaunch.

Use provider-side version history as an extra layer, not the only one. Protect the backend account with multifactor authentication and recovery codes stored separately. Encrypt backup media according to the sensitivity of usernames, play history, and device-derived data.

Step 10: use folder sync only as a documented fallback

If the installed RetroArch lacks native Cloud Sync, a trusted WebDAV mount, Syncthing, Nextcloud, or provider folder can synchronize configured Save Files directories. Use one dedicated folder, exclude firmware and credentials, disable simultaneous access, and keep versioned backups.

Test whether the tool performs atomic replacement and how it represents conflicts. Do not assume “serverless” means no relay or discovery infrastructure; read the sync project’s architecture and privacy documentation. Install clients only from their official source or operating-system repository.

Step 11: maintain a compatibility manifest

For each device, retain RetroArch/core versions, content and firmware hashes, save-directory rules, backend, last successful round trip, and backup restore date. Update one device first and test before rolling a new core to all peers.

The system is working only when an in-game save round-trips across devices, conflicts preserve both candidates, state incompatibility is handled separately, and an offline backup restores without the cloud service.

Related:

Sources: