WDG AI Dev Environment

Appearance

Connect and Sync from Kinsta ​

Kinsta has no vendor CLI. wdg my-site sync kinsta uses the Kinsta API to resolve SSH connection details for a site environment, then runs wp db export over SSH with your own SSH key and imports the dump locally. It can also rsync the uploads directory.

Prerequisites ​

  • ssh, rsync, curl, and jq on your PATH (on macOS install missing tools with brew install; on Debian/Ubuntu use your package manager).
  • A Kinsta API key and your company/workspace ID configured once with wdg kinsta auth.
  • Your SSH public key registered with each environment you sync.

One-time setup ​

Run the authentication command once. It stores the API key and company ID in ~/.wdg/kinsta.env with 0600 permissions (the same ~/.wdg secret pattern used for Figma OAuth and MCP proxy tokens):

bash
wdg kinsta auth

To generate the inputs:

  1. Generate an API key in MyKinsta under Company settings -> API Keys.
  2. Find your company ID in MyKinsta under Company settings -> Billing details.

wdg kinsta auth writes KINSTA_API_KEY and KINSTA_COMPANY_ID to the key file and validates the key against the company when both are present.

Projects in a different Kinsta company ​

A Kinsta API key is issued inside one company, and every API call requires a company ID. A key therefore reaches every site in its own company and nothing outside it: point a company-A key at company B and the API answers HTTP 404 for the company, not an authentication error. There is no endpoint that lists the companies a key belongs to, so covering two companies means storing two keys.

Give a project its own key with --project:

bash
wdg kinsta auth --project=my-site
wdg kinsta status --project=my-site   # reports which source supplied the key
wdg kinsta sites --project=my-site

That writes projects/my-site/.env.hosting at 0600 instead of the global file:

KINSTA_API_KEY=<key issued inside this project's company>
KINSTA_COMPANY_ID=<that company's UUID>

The location is deliberate. projects/ is gitignored at the platform root, and the file sits above the project's own git checkouts in projects/my-site/repositories/, so it cannot reach a client repository either. If a project only needs a different company and your key already covers it, set hosting.company in the manifest and skip the file.

Register your SSH public key ​

The sync authenticates over SSH with your own key, so register your SSH public key with each environment you intend to sync. In MyKinsta, open the site, choose the environment, and add your key under SFTP/SSH credentials (Add SSH key).

Credential resolution ​

The Kinsta API requires a company/workspace ID on every call and cannot list companies, so the ID must always be resolvable. The sync resolves both halves of the credential in this order, highest precedence first.

API key:

  1. KINSTA_API_KEY already exported in the environment (CI and one-off runs).
  2. projects/<project>/.env.hosting.
  3. ~/.wdg/kinsta.env, the global default from wdg kinsta auth.

Company/workspace ID:

  1. The --company=ID flag.
  2. KINSTA_COMPANY_ID already exported in the environment.
  3. projects/<project>/.env.hosting.
  4. The project manifest field hosting.company (in project.yml).
  5. KINSTA_COMPANY_ID in ~/.wdg/kinsta.env.

An exported variable sits above every file on disk in both orders on purpose: it is the escape hatch that needs no file at all. It does not outrank --company, though. A flag you just typed is a more specific statement of intent than a variable exported by a shell profile you may have forgotten about, so the flag wins.

There is no --api-key flag, which is why the key order has one fewer level than the company order. Pass a key for a single run by exporting it: KINSTA_API_KEY=... wdg my-site sync kinsta ....

Set hosting.company in the manifest when your key already covers the project's company. Use wdg kinsta auth --project=NAME when it does not.

Helper commands ​

bash
wdg kinsta status                # validate the stored key and show the configured company
wdg kinsta sites                 # list sites and environments the key can access
wdg kinsta status --project=NAME # same, using that project's credentials
wdg kinsta sites --project=NAME

wdg kinsta sites prints each site with its environments, which is the quickest way to confirm the exact site name to pass to the sync.

Sync command ​

bash
wdg my-site sync kinsta --site=NAME --env=ENV [--media] [--company=ID]

Flags:

  • --site=NAME: the Kinsta site name or display name. If omitted (and not in the manifest), the sync presents an interactive site picker.
  • --env=ENV: the environment name. Defaults to live.
  • --media: also rsync the uploads directory over SSH.
  • --company=ID: the Kinsta company/workspace ID. Highest precedence, so it overrides an exported KINSTA_COMPANY_ID, the project's .env.hosting, the manifest, and the global default. It does not change which API key is used, so point it only at a company the resolved key belongs to.
  • --prod-url=DOMAIN: an additional production domain to search-replace to the local URL.

Example ​

bash
wdg my-site sync kinsta --site=mysite --env=live --media

This resolves SSH details for the live environment, exports the database over SSH, imports it, replaces the Kinsta URL with your local URL, then rsyncs uploads.

Missing company ID

The most common failure is an unresolved company/workspace ID. The API rejects every call without one, and it cannot be discovered automatically. If the sync reports the company ID is not configured, set it any of these ways: pass --company=ID, run wdg kinsta auth --project=NAME (per-project key and company), set hosting.company in the project manifest, or re-run wdg kinsta auth to store a global KINSTA_COMPANY_ID.

💡 TIP

If the database export fails over SSH, confirm your SSH public key is registered with that exact environment in MyKinsta (site -> Environment -> SFTP/SSH credentials -> Add SSH key).

Copyright © 2026 WDG