Connect to Kinsta — ConnectLocal Docs

Install the Kinsta add-on using the installation guide, then follow the setup below.

Requirements

Local 6 or newer. Developed against Local 10.1.2 on macOS.
A Kinsta API key (recommended). In MyKinsta, open your name → Company settings → API Keys and click Create API Key (Kinsta's guide).
- Company owners, administrators and developers can create keys. A key has the same access as the user who creates it.
- Without a key, you can still link a site with the SFTP/SSH details shown in MyKinsta under Sites → your site → Info.
WP-CLI and rsync on the server. Kinsta installs WP-CLI on every server. If wp is missing, the add-on installs its own copy.

Use

Open a site in Local and go to Tools → Kinsta.
Connect in one of two ways:
- Kinsta API (recommended): paste your API key, pick a site and environment (grouped by site, live first) and click Link. The add-on then:
  - reads the environment's SSH host, port and username;
  - turns SFTP/SSH on for the environment if it is off;
  - logs in with Local's SSH key if MyKinsta has it, or else with the environment's SFTP/SSH password from the API;
  - finds the WordPress webroot (public/ in the site folder, or the web root set in MyKinsta).
- SFTP/SSH details: enter the host, port, username and password (or use Local's key) shown in MyKinsta under Sites → your site → Info. Each environment has its own port.
To have Local log in with its own key instead of the password, copy the public key shown in the panel and add it in MyKinsta under your name → User settings → SSH keys. Then link the site again.
Push or pull from the panel's Push to Kinsta / Pull from Kinsta tabs. Once the site is linked, you can also use the Kinsta: Pull / Push buttons in the site header.
- Push options: Files and/or Database; create a Kinsta backup first (API links, on by default); delete files on Kinsta that aren't in Local (on by default, like WP Engine); clear Kinsta caches afterwards.
- Pull options: Files and/or Database; back up the Local database first; delete Local files that aren't on Kinsta (on by default).
- Every pull moves the Local files it replaces or deletes into app/kinsta-backups/pull-<time>/ instead of discarding them. The last 3 are kept.

Progress appears in Local's site overlay. When the transfer finishes, a banner reports success or the error.

Pull a Kinsta site into a new Local site

Click + (Create a site) in Local and choose Pull from Kinsta.
Pick the site and environment, or enter SFTP/SSH details. Name the Local site; it defaults to the Kinsta site's name.
Click Create site & pull. The connection is checked first, so a wrong login never leaves an empty site behind.

Compare & sync files (selective sync)

Go to Tools → Kinsta → Compare & sync files and click Compare with Kinsta. Nothing changes until you choose files. Differing files are listed under Different on each side, Only in Local and Only on Kinsta. Tick files, then click Push selected or Pull selected. A ticked file that exists only on the receiving side is deleted there. The database is never touched.

What a database push does

Exports the Local database and rewrites MySQL 8 utf8mb4_0900_* collations to ones MariaDB accepts.
On Kinsta, saves the current database to local-backup-before-push.sql in a private .kinsta-connect folder outside the webroot (inside the site's private/ folder when it has one). It also reads the current home URL and table_prefix. This is in addition to the Kinsta backup.
Uploads the dump to that folder, then runs wp db reset and wp db import. If the import fails, it restores the backup automatically. The uploaded dump is always deleted afterwards.
Sets table_prefix to match Local if the two differ.
Runs wp search-replace across all tables (--precise, guid skipped) from //site.local to the Kinsta URL, including the JSON-escaped form, plus http:// → https:// when the Kinsta site uses HTTPS.

What a database pull does

On Kinsta, exports the database with --single-transaction (the live site isn't locked), downloads it and deletes the export.
Makes the dump importable by Local's MySQL. It removes the MariaDB "sandbox mode" line and rewrites uca1400 collations.
Saves the Local database to app/sql/local-backup-before-pull.sql (optional).
Imports through Local's own WP-CLI service. If the import fails, it restores the backup.
Matches Local's table_prefix to Kinsta's, then replaces the Kinsta URL and the environment's other domains (such as shop.kinsta.cloud or stg-shop-staging.kinsta.cloud) with the Local URL.

What is never transferred

These are excluded in both directions, and excluded paths are also protected from --delete:

Environment config: wp-config.php, .htaccess, .user.ini, php.ini, wp-cli.yml
Kinsta's must-use plugin: mu-plugins/kinsta-mu-plugins.php and mu-plugins/kinsta-mu-plugins/
Caches and drop-ins: object-cache.php (Kinsta's Redis add-on), advanced-cache.php, wp-content/cache/
Server-specific state: wp-content/jetpack-waf/, wp-content/upgrade/, wp-content/upgrade-temp-backup/
Migration-plugin backups: wp-content/ai1wm-backups/, wp-content/updraft/
Other WordPress installs in subfolders of the webroot
VCS and tool binaries, root-level *.sql dumps, Local's helper files

Must-use plugins that exist only on the receiving side are never deleted.

To skip more, add rsync patterns (one per line) to app/public/.kinsta-push-ignore or .kinsta-pull-ignore. These work like .wpe-push-ignore and .wpe-pull-ignore.

Themes and plugins symlinked from elsewhere

A theme or plugin that you develop in another folder and symlink into the Local site (for example wp-content/themes/mytheme → ~/code/mytheme) is pushed as real files, because the server has no such folder to point to. It is never pulled into: a pull leaves the symlink and the folder it points to untouched. Symlinks within the site stay symlinks, and broken symlinks are skipped (and logged).