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 · PalServer + heartbeat
4 · save + shutdown
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
Palworld uses worldGuid so a different world cannot be published accidentally.
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.
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.
Feature-complete, not abandoned
The Palworld reference is maintained for bugs, security, dependencies and compatibility. The broader multi-game and device/cloud-sync product will live separately.