ConnectLocal/Docs/Troubleshooting

THE CONNECTION MANUAL

Troubleshooting

Work through installation, SSH, API, and transfer problems.

On this page

The add-on does not appear

Confirm you installed a .tgz add-on package using Add-ons → Install from disk, enabled it, and restarted Local. Then open a site and look under Tools → [host]. Check your Local version against compatibility.

API authentication fails

Confirm the credential belongs to the intended hosting account and has permission to see the target site. For Cloudways, use a current access token, not an expired legacy API key. For Kinsta, check the key's company and user role. Never paste credentials into this website or a public issue.

No sites or environments are listed

Check account access and provider permissions. Cloudways API discovery depends on the server listing endpoint used by the current add-on; provider endpoint changes can affect it. Kinsta lists environments within the key's company. If available, try the add-on's manual SSH mode using verified connection details.

SSH login is refused or times out

  • Enable SSH/Shell Access at your host; SFTP availability alone may not imply shell access.
  • Check the host, username and port. Kinsta environments use their own ports.
  • Add the add-on's displayed public key to the right user/account. Each host add-on has its own key.
  • Check IP allowlists, firewalls and your current network. Kinsta may require your public IP to be allowlisted.
  • On Windows, use key authentication; password login is unsupported.
  • For Bluehost shared hosting, use the server IP and SSH username from SSH Details. For Cloud, use the site's SSH user and host.

WordPress cannot be found

Verify the remote path points to the intended WordPress webroot rather than the account's home folder. Bluehost Cloud/SSH supports a manual path when discovery fails. Kinsta's normal layout uses public/ under the site directory. Confirm rsync and PHP are available. Where documented, add-ons can install a private copy of the official WP-CLI build if needed.

A backup fails before push

Check your provider dashboard, API permissions, backup quota and the reported operation error. Kinsta's manual backups have a fixed per-environment limit. Resolve the backup failure and maintain a verified independent backup before retrying. Disabling a backup option removes that layer of protection.

A database import fails

Read the failure message and verify whether automatic restoration completed. Avoid retrying repeatedly without inspecting the destination. Preserve the previous backup before another run. Check disk space, permissions, database compatibility and WP-CLI availability. See backups and recovery.

The site still shows old content

Confirm the intended site/environment was updated. Check the cache-purge result and clear provider caches from its dashboard when needed. Kinsta's edge can continue serving old static content briefly after a purge. Password protection can prevent Kinsta's HTTP-based WP-CLI cache purge even when the API cache clear works.

Comparison misses an edit

Enable Compare file contents (slower) to use checksums. The default size-and-time comparison cannot detect every edit with unchanged size and timestamp. Check custom ignore patterns and host-protected files too.

Safe information for a support request

Include your Local version, operating system, add-on version, host type, connection mode, operation, and a redacted error message. Describe whether the issue affects staging or live. Remove keys, passwords, database content, IPs and identifying paths from shared logs.

For project contact details, visit Marcus Burnette's website.