A backup before a big change
Keep an independent, restorable backup before pushing or pulling. Confirm the site and environment, the direction, the selected scope, and all deletion settings. Avoid a database push to a live store or busy site without a plan for new data created since your Local copy was made.
Database backups
- Before a remote database push: each add-on exports the current remote database outside the public webroot. A failed import triggers an attempt to restore that export. This is a recovery mechanism, not a guarantee against every failure.
- Cloudways API connections: can request a Cloudways application backup before pushing.
- Kinsta API connections: request a manual environment backup before pushing when enabled (on by default). Backup quota or operation errors stop the push. Resolve the issue in MyKinsta before retrying.
- Bluehost: no public hosting API backup trigger; the pre-push database export is not a full Bluehost site backup.
- Before a pull: keep the Local database backup option enabled. The backup is saved at
app/sql/local-backup-before-pull.sql. Restoration after a failed local import depends on that backup being present.
Backup filenames may be reused by later transfers. Copy a recovery dump to a safe location before starting another transfer.
Local file recovery
Bluehost moves files replaced or deleted by a pull into app/bluehost-backups/pull-<time>/. Kinsta uses app/kinsta-backups/pull-<time>/. The last three sets are kept. To recover a file, stop syncing and copy it back to the corresponding path under app/public/.
Cloudways' README does not document equivalent retained file backups. Back up your Local files yourself before a pull.
Files that stay in their own environment
The add-ons exclude environment-specific configuration and cache state. Typical examples include wp-config.php, .htaccess, cache drop-ins, cache directories, VCS files and root SQL dumps. Host-specific protected paths differ. Consult the Cloudways, Bluehost, and Kinsta guides for the exact reference lists.
Excluded paths are also protected from deletion. Must-use plugins present only on the receiving side are protected from deletion by the Bluehost and Kinsta reference implementations.
Custom ignore files
Place one rsync pattern per line in the matching file under your Local site's app/public/:
| Host | Push patterns | Pull patterns |
|---|---|---|
| Cloudways | .cloudways-push-ignore | .cloudways-pull-ignore |
| Bluehost | .bluehost-push-ignore | .bluehost-pull-ignore |
| Kinsta | .kinsta-push-ignore | .kinsta-pull-ignore |
Review patterns carefully and confirm their effect in the comparison screen before transferring.
Database URL rewriting
Transfers use WP-CLI search-replace to adapt site URLs, including serialized data and JSON-escaped forms, while skipping GUIDs. MySQL/MariaDB collation normalization helps imports across engines. This does not make every custom database structure compatible: multisite domain columns are not rewritten.
Symlinked development folders
Themes and plugins symlinked from outside your Local site are pushed as real files. Pulls leave those external symlinks and their targets untouched. Internal symlinks stay symlinks; broken symlinks are skipped and logged.
Credentials and SSH trust
Reference add-ons encrypt saved secrets with Electron safeStorage, keep their own SSH keys, and pin remote host keys on first connection. Use credentials with only the required permissions. Do not share passwords, API keys, full connection logs, private keys, database dumps, or settings files in support requests.
If you see an SSH host-key change, verify the new server fingerprint with your host before changing trust settings. Never disable host-key checking just to get a connection working.