Concurrency
Exclusive lock, TTL, heartbeat and optimistic concurrency through baseVersion.
Stop asking “which save was the good one?”
The backend keeps one source of truth. Every host must prove it started from the right version before it can publish progress.
1 · status + lock
2 · download if needed
3 · game server + heartbeat
4 · cleanly stop writer
5 · ZIP + SHA-256
6 · upload with baseVersion
Designed to fail without silently overwriting progress
The difficult part is not uploading a folder. It is preserving ownership and history when hosts, networks or processes fail.
Identity
Every adapter supplies a canonical saveIdentity: Palworld uses worldGuid; experimental Valheim uses worldUid.
Atomic publication
Temporary ZIP, defensive validation, SHA-256 and transactional SQLite authority changes.
Recovery
Version history, restore-as-new-version, pending upload recovery and rollback procedures.
Durable backup
SQLite queue and a supervisor independent from Gunicorn, with timeout, retry and crash-safe retention.
Secrets
Bearer hashes on the backend and DPAPI on Windows. Runtime data stays out of source and release assets.
One backend, explicit responsibilities
The Flask application remains one deployable service, but critical responsibilities are separated so lock/publication invariants stay reviewable.
Sessions
sessions.py owns lock, heartbeat, unlock and managed-host revalidation.
Publication
publications.py owns upload staging, ZIP validation, atomic publish and two-phase historical restore.
Persistence
database.py owns schema/migrations; retention.py and backup_supervisor.py preserve backup and cleanup safety.
Capabilities
game_config.py keeps game identity/capabilities declarative; game-specific save parsing stays in client adapters.
Experimental Valheim support on main
After v2.2.2, the development tree gained a Valheim 1.0 adapter and opt-in managed-computer authorization. This is a preview, not a stable-release promise.
Folder-based worlds
The adapter validates complete Valheim 1.0 generations and uses the intrinsic signed 64-bit worldUid as save identity.
Managed computers
Each registered PC gets a stable ClientId and its own host-bound sync token. Palworld keeps its existing unmanaged flow.
Controlled shutdown
The client starts valheim_server.exe, maintains the lease, sends CTRL+C, waits for a committed final generation and only then publishes.
Fail closed
Heartbeat safety reserves enough lease time for clean shutdown; uncertain uploads and unexpected exits preserve recovery state instead of guessing.
Do not use the only valid copy of a real Valheim world for testing. Follow the four-host acceptance checklist and keep Palworld/Valheim databases and storage isolated. TTL expiry by itself is not proof that a failed old server process has stopped.
Self-hosted backend + Windows client
Use client and backend from the same stable product release.
Backend v2.2.2
git clone --branch v2.2.2 --depth 1 https://github.com/Ayerdi/dedicated-server-save-sync.git cd dedicated-server-save-sync config/deploy.sh --init-env config/deploy.sh
Requires Docker Compose, HTTPS and private storage.
Windows client v2.2.2
1. Download the ZIP and .sha256.
2. Verify the checksum.
3. Configure config.json.
4. Run Configure-Secrets.cmd and Test-Connection.cmd.
5. Start with Start-PalworldSync.cmd.
Palworld's local REST API must listen on localhost only. Do not expose that port through your router.
Stable release, active safety work
The Palworld v2.2.2 reference remains maintained for bugs, security, dependencies and compatibility. Experimental Valheim work on main is documented and tested separately; the broader general multi-game and device/cloud-sync product remains outside this repository.