MyKinsta team access: roles, staging and a clean client handover

Separate hosting access from WordPress access

MyKinsta controls hosting operations. WordPress controls the publication and its application-level permissions. A billing contact does not need to edit posts; an author does not usually need to change a hosting plan. Start by recording which system each person actually needs.

WordPress’s role documentation distinguishes roles such as Administrator, Editor, Author and Contributor by capabilities. Choose the role appropriate to the person’s publishing responsibility. A WordPress Editor role should not be treated as a substitute for a hosting role, and a hosting invitation should not be treated as a complete WordPress access policy.

For a fictional three-person publication, the owner handles hosting and spending, a contractor fixes a theme on staging, and an editor manages articles in WordPress. Giving all three the owner’s credentials would make an article correction and a billing change equally accessible. Separate named accounts make it easier to grant the required access and remove it later.

Understand the important limits of site roles

The detailed user-management guide says a Site Developer works with the assigned site’s staging environments and cannot push staging to live. It also excludes live access, DNS, user management and company-level activity-log access. A Site Administrator has much broader control of the site and its environments, although it cannot remove the site from the company or manage migration requests.

That makes Site Developer a useful boundary for a staging-only contractor, provided the rest of the arrangement supports it. The same documentation warns that a cloned environment retains the cloned WordPress administrator credentials, even though its database and SFTP/SSH credentials are separate. Review WordPress accounts and the data copied into staging; a hosting role alone does not sanitize a production clone.

Company Developer is also a powerful role, not a harmless read-only option. Kinsta documents technical permissions across sites and the ability to delete certain sites. Read the current permissions chart before assigning it to someone whose task concerns only one project.

Prepare the invitation before sending it

Write an access request containing the person’s email, the named site or company, the work required, the environment and a review date. For the fictional theme contractor, the request could say: “Prepare the approved navigation change on this site’s staging environment; the owner reviews and publishes it.” That describes a bounded task without promising the contractor production access.

Within MyKinsta’s user-management invitation flow, choose Company or Site access, select the relevant scope and role, and verify the recipient before sending. Kinsta documents that Company Owners and Company Administrators can add company-level users, while Company Developers can add site-level users. An invitation is an access grant; use an authorized account and check the scope rather than choosing the largest role to get past a blocked action.

After the recipient accepts, have them confirm the intended site and environment are visible. Do not ask them to prove a restriction by attempting a destructive operation. If a required tool is unavailable, compare the task with the permissions chart. Either keep that action with the owner or deliberately revise the role.

Protect individual logins

Kinsta’s login documentation describes email-based verification and an authenticator-app option in User settings. Each person should configure their own login and recovery arrangements. A shared inbox and shared second factor would undermine the benefit of separate accounts.

Keep an internal owner record for the hosting company and a recovery route that the business can actually maintain. Do not store passwords, authenticator setup secrets or recovery information in a project handover document that every contractor can read. Record who controls recovery, not the credentials themselves.

If your organization uses a supported identity provider, investigate Kinsta’s SAML single-sign-on requirements separately. Do not assume an existing Google login automatically supplies the same company-wide policy, or that an identity-provider change removes independent WordPress accounts.

Use WordPress auto-login with care

The WP Admin guide describes MyKinsta’s Log in to WP Admin control under Sites → the selected site → Info. It matches the MyKinsta email to an existing WordPress user. If no matching user exists, it can offer to create a WordPress administrator account; on multisite, the documented new account receives Super Admin privileges.

This is convenient for a trusted operator, but it is not a reason to create an administrator for every content contributor. Prepare the intended WordPress account and role first. Stop and review an unexpected Create admin prompt instead of approving it reflexively. Kinsta documents a switch for disabling auto-login under the site’s user-management settings, controlled by authorized company roles.

If auto-login opens a blocked pop-up, inspect the browser’s site-specific permission rather than disabling protections for every website. If it signs in with an unexpected role, inspect the matching WordPress user. Resolving the identity mapping is better than sharing a known administrator password.

Agree who approves and publishes staging work

Kinsta’s safe-change guidance recommends using the included staging environment for testing. In the fictional publication, the contractor prepares the navigation, the editor checks the labels and the owner approves the release. Make that division explicit before work starts.

Prepare a release note with the files or settings changed, the pages checked and the expected effect. Test the principal navigation, search, an article and any essential form at representative desktop and mobile widths. Those checks are recommended editorial practice, not a claim that staging automatically validates the site.

Before a push to live, identify what has changed on production since the copy was made. A full database replacement could overwrite newer content, orders or account changes. Ask the authorized publisher to choose the appropriate deployment scope and a recoverable backup; do not make the contractor’s role broader simply because that review is inconvenient.

Use the activity log as one piece of evidence

MyKinsta’s activity-log documentation describes a six-month view of actions, including who initiated them, when and whether they succeeded. Times reflect the viewer’s browser time zone. That is useful when correlating a hosting change with an incident.

It is not a complete substitute for WordPress revision history, your release notes or a separate account inventory. Record a report’s time zone before comparing it with another person’s notes. When a change is unexpected, establish what happened and its scope before removing access or restoring a database.

Choose the right client handover model

There are two different decisions: who manages a site and who owns the hosting company. A client who needs one site should not receive ownership of an agency company containing other clients. Likewise, making someone a Site Administrator does not make them the Company Owner.

Kinsta’s transfer guide distinguishes transferring an entire company from moving one site to another company. Only the Company Owner can transfer company ownership, to a Company Administrator. Company Owners or Administrators can initiate a site transfer to an authorized recipient in the destination company. Verify the target carefully.

Before transferring a site, inspect the receiving plan and add-ons. The guide says PHP, Redis and Premium Staging add-ons move with the site, while other add-ons are disabled. Preserving the existing PHP performance may automatically add capacity charges on the destination plan. Moving a site does not cancel the source hosting plan. The recipient should understand those consequences before accepting.

A handover checklist should also cover the domain registrar, external DNS, email, licenses, backups and analytics. Those services may have owners and accounts outside MyKinsta. Record what is included, what is separate and who handles each renewal; do not declare the business transferred merely because the website appears in a different dashboard.

Remove access without losing the handover

Agree a final review date. Confirm the client can log in, identify the correct site, reach WordPress with the intended role and contact the appropriate support route. Keep a short record of the accepted handover and any maintenance access the client wants retained.

Then review MyKinsta users, WordPress users, SSH/SFTP access and any separately issued integration credentials. Removing a hosting invitation should not be assumed to revoke every credential a person previously knew. Where a secret was shared, arrange its rotation through the responsible owner rather than placing it in an email thread.

Kinsta’s security-responsibility guide assigns user management, account credentials, site resources, content, plugins and themes to the customer. Managed infrastructure helps, but the access decisions remain yours.

When MyKinsta’s team model is worth shortlisting

The practical strengths are named users, different company and site scopes, a staging-oriented developer role and documented client-transfer paths. For a publication or small agency, those can replace the fragile habit of sharing one powerful login. Their value depends on using the boundaries deliberately and retaining clear ownership.

Before choosing Kinsta, write down who needs hosting access, who only needs WordPress and who will pay for the site after handover. Check the current plan and permissions against that list. You can apply the same access checklist to another host; it is the responsibilities that need to be clear.

For the wider operational decision, read shared versus managed WordPress hosting and what hosting plans include. Before larger production changes or handover, use our guide to a WordPress backup you can restore.