Cloud sync Pro
Requires ReadyTab Pro
Cloud sync is a Pro feature.
ReadyTab cloud sync works at the whole dashboard level, not per individual space. When you sync, ReadyTab pushes or pulls a single encrypted snapshot that contains your local workspace set.
That means the cloud model is:
one local dashboard snapshot ↔ one active cloud dashboard
What gets synced
A cloud dashboard snapshot includes the local dashboard state needed to recreate what you see in ReadyTab, including:
- all spaces / workspaces
- workspace order
- workspace names
- the active workspace
- workspace visual settings
- workspace backgrounds
- protected workspace backup blobs when available
- the default workspace name metadata
What auto-sync actually does
Auto-sync watches for meaningful local dashboard changes, waits for the selected sync delay, checks whether the active cloud dashboard changed elsewhere, and then either:
- pushes the current local snapshot to cloud, or
- stops and asks you to resolve a conflict
ReadyTab does not continuously stream changes to the backend in real time. It uses a delayed push model to reduce unnecessary requests while you are still editing.
Where the controls live
General tab
Automatic sync behavior is configured in Settings → General:
- Auto-sync to cloud
- Auto-pull newer cloud state
- Cloud sync delay
- Cloud check interval
Account tab
Manual cloud actions and dashboard selection live in Settings → Account:
- connect / activate Pro cloud access
- choose the active cloud dashboard
- push current local dashboard
- pull cloud dashboard to local
- review version history
- restore an older cloud version
- delete a cloud dashboard
Automatic sync flow
1. Local change happens
When you add, remove, move, rename, or restyle dashboard content, ReadyTab:
- saves the dashboard locally first
- marks local cloud state as dirty
- stores a persistent timestamp for the latest unsynced local change
- schedules the delayed auto-push if auto-sync is enabled
That persistent dirty marker is important: if you close the tab before the delay finishes, ReadyTab still knows on the next open that cloud sync is still owed.
2. Delay window
ReadyTab waits for the configured delay before attempting a push. This gives you time to make several edits without spamming cloud updates.
Available delay options are currently:
- 30 seconds
- 1 minute
- 2 minutes
- 5 minutes
3. Freshness check before pushing
Before any auto-push, ReadyTab checks whether the active cloud dashboard became newer than the last cloud version this device already knows about.
If the cloud is not newer, the local snapshot is pushed.
If the cloud is newer, ReadyTab does not silently overwrite it. Instead it moves into conflict handling.
4. Success clears dirty state
A successful cloud push or pull clears the local unsynced marker and updates the known remote baseline for future comparisons.
Startup recovery after a short session
This is an important edge case and is now handled explicitly.
Example
- You add a link
- ReadyTab saves it locally
- auto-sync is configured for 2 minutes
- you close the tab after 10 seconds
Without recovery logic, the delayed timer would disappear with the page and the cloud push would never happen.
Current behavior
ReadyTab now stores the timestamp of the most recent unsynced local change in local storage. On the next app startup it:
- restores the dirty state from storage
- resumes the delayed auto-push if auto-sync is enabled
- still performs the usual cloud freshness check before pushing
This makes auto-sync resilient to short tab sessions.
Auto-pull behavior
Auto-pull is intentionally conservative.
If Auto-pull newer cloud state is enabled, ReadyTab only pulls automatically when:
- the active cloud dashboard is newer, and
- local state is not dirty
If local changes are pending, ReadyTab will not auto-pull over them. Instead it shows a resolution prompt.
Conflict handling
If the cloud changed on another device and this device also has unsynced local changes, ReadyTab treats that as a conflict.
You will be offered actions to:
- Review diff
- Pull cloud
- Overwrite cloud
- Not now
Review diff
Opens the diff viewer comparing the cloud snapshot against your local state without changing anything.
Pull cloud
Replaces the local dashboard with the newer cloud version after confirmation.
Overwrite cloud
Pushes your current local dashboard over the active cloud dashboard after confirmation.
Not now
Leaves things as they are so you can decide later.
The diff viewer
Every confirmation that changes a dashboard — Pull, Overwrite, an Update push, and restoring an older version — first shows a diff so you can see exactly what will change before committing.
It reads as a single top-to-bottom diff rather than two columns:
- A summary line counts what's added, changed, and removed.
- Each space lists its changes grouped into Added, Changed, and Removed, with a colored marker per row.
- Every element is covered — not just groups, but shortcuts, clipboard and launcher buttons, and section blocks (headings, text, callouts, dividers, and the rest). Groups show their item count; a changed group shows its count before → after.
- Unchanged elements are summarized quietly so the rows that matter stand out.
The direction is always phrased against the side being replaced (e.g. "Added to cloud" when pushing, "Added to local" when pulling).
Remote freshness checks
ReadyTab checks for newer cloud state in several situations:
- on startup
- on window focus
- when the tab becomes visible again
- on the configured periodic poll interval
- before an auto-push
- after license / Pro status changes
Available poll interval options are currently:
- 1 minute
- 3 minutes
- 5 minutes
- 10 minutes
Edge cases and safeguards
Closing the tab before the delay expires
Handled by the persisted local dirty timestamp. The pending cloud push can be resumed on the next open.
Local changes exist but auto-sync is off
ReadyTab still remembers that the local dashboard is dirty. It will not silently auto-pull over those changes. You can either:
- turn auto-sync back on
- manually push
- manually pull
- resolve the conflict prompt if the cloud changed elsewhere
No active cloud dashboard selected
ReadyTab can keep local dirty state even when there is no active dashboard to push to yet. Once a dashboard is selected again, auto-sync can schedule the pending push if auto-sync is enabled.
License / Pro access changes while dirty
If Pro status is restored while local changes are still pending, ReadyTab re-checks cloud freshness and can re-schedule the delayed push.
Protected workspaces from older snapshots
If you pull an older cloud snapshot that predates protected-workspace backup support, ReadyTab restores the workspace tabs but may not be able to restore the protected contents themselves. In that case ReadyTab warns you to re-push from the original device if you still need those contents.
Dashboard updated on another device
Freshness checks compare the active remote dashboard against the last known remote baseline for that dashboard. If the remote version is newer, ReadyTab surfaces that instead of overwriting it silently.
Local-first vs cloud-first behavior
ReadyTab is deliberately local-first:
- edits are saved locally first
- auto-sync is a delayed follow-up action
- cloud never silently wins over known unsynced local changes
- automatic pull only happens when local state is clean
This design reduces accidental data loss during multi-device use.
Manual actions still matter
Even with automatic sync enabled, manual actions remain useful:
- use Push when you want an immediate cloud update
- use Pull when you want to replace local state with the cloud version now
- use Version history when you need to inspect or restore older snapshots
Troubleshooting
"Why didn't my last edit reach the cloud immediately?"
Auto-sync is delayed by design. Check:
- whether Auto-sync to cloud is enabled
- which delay is selected
- whether an active cloud dashboard is selected
- whether a conflict prompt appeared because the cloud changed elsewhere
"I changed something, closed the tab, and reopened later"
That is supported. ReadyTab persists the unsynced-local marker and can resume cloud sync on the next open.
"Why didn't auto-pull run?"
Auto-pull only runs when local state is clean. If you made local edits that have not been confirmed in cloud yet, ReadyTab will protect them and ask you to resolve the situation instead.
"Can two devices overwrite each other silently?"
ReadyTab tries to prevent that by checking remote freshness before auto-push and by refusing to auto-pull over dirty local state.
Summary
The important mental model is:
- local edits save first
- local edits mark cloud sync dirty
- delayed auto-push happens later
- cloud freshness is checked before pushing
- unsynced local changes survive tab close / reopen
- conflicts require an explicit user choice instead of silent overwrite