Kinsta Account and Domain Management Guide

MyKinsta is two control planes stacked on top of each other: a per-user side that handles your login, 2FA, and notifications, and a per-company side that handles billing, ownership, domains, and DNS. Most account and domain problems on Kinsta come from confusing the two, or from the free Cloudflare integration colliding with a Cloudflare account you already had. This guide covers the account, security, and domain decisions in the order they come up, with links to the step-by-step how-tos for each one. Most of the account decisions in this guide land easier if you have already finished a clean handover; the setup and migration guide walks the cutover and the post-launch checks that determine whether the account-level cleanup below is straightforward or messy.

What This Guide Covers

This is the account and domain management hub for Kinsta on Hoos Hosting. It explains how MyKinsta splits user settings from company settings, how to harden access with 2FA, how all five user roles work, how to move company ownership to a different person, how to add and verify a domain (including the Cloudflare integration quirks), and how Kinsta DNS works alongside your registrar. For the full host overview (plans, pricing, support, performance tools) start with the parent Kinsta hosting guide. For caching, CDN, Redis, and APM, the sibling Kinsta WordPress optimization guide picks up where this one stops.

How MyKinsta Splits User, Company, and Site Settings

Three tabs in the MyKinsta sidebar drive everything in this hub:

• User Settings. Your personal login, password, email address, two-factor authentication, and notification preferences. Every user in a Kinsta account has their own User Settings, even if they only have read-only access to one site.
• Company Settings. The legal entity: billing, tax details, payment methods, and the single Company Owner. Only the owner can close the account or transfer ownership. Administrators can do everything else, including adding and removing users, but they cannot delete the company.
• Site / Domains. Per-site domain configuration, the Cloudflare integration toggle, and the DNS records for each domain hosted through Kinsta DNS.

Why the Split Matters for Agencies

Agencies that bill clients through the client's Kinsta account usually want the client to be Company Owner (so billing follows them) and the agency to be Administrator (so the agency can manage sites without owning the bill). Getting this wrong on day one is the most common reason for a messy handover six months later. The three-panel split makes it possible to give each party exactly the access they need without overlap or gaps.

Understanding All Five MyKinsta User Roles

Kinsta has five distinct user roles, and the differences between them matter more than most hosting panels. Picking the wrong role when onboarding a contractor or client is a common mistake that either gives too much access or blocks someone from doing their job.

• Company Owner. The sole user who can close the account, transfer ownership, and take final control of billing. There is always exactly one owner per company.
• Administrator. Can manage every site, add and remove users, and change billing details. The only thing administrators cannot do is close the company or transfer ownership. For most agency setups, the agency's senior account manager holds this role.
• Developer. Can deploy, clone, and manage sites (including staging environments), run SSH commands, and view logs. Cannot touch billing, company settings, or user management. The right role for a freelance developer or contractor who should only see what they're building.
• Analyst. Read-only access to site analytics, uptime reports, and resource usage. Cannot make any changes. Useful for clients or stakeholders who want to monitor performance without touching settings.
• Billing. Can update payment methods, download invoices, and manage billing details. Cannot manage sites, users, or company settings. Useful when a finance team member handles invoices but should not have access to production environments.

Plan user limits apply per role tier. Entry-level plans cover a smaller number of users across all roles combined; check your plan details in Company Settings if you hit an unexpected limit when adding a new team member.

Matching Roles to Real-World Team Structures

Most teams fall into one of three patterns. An agency model typically has the agency holding Administrator access and Developer roles for individual engineers, while the client holds Company Owner and optionally an Analyst role for visibility. A solo operator or small business usually has a single Company Owner who handles everything. A SaaS team tends to assign one Administrator per product line, a Developer role for each engineer working on that product, and a dedicated Billing role for whoever handles finance, so no developer ever touches payment details. Whatever the structure, the rule is the same: assign the least-privileged role that lets each person do their actual job.

Securing Your MyKinsta Account with Two-Factor Authentication

Two-factor authentication on Kinsta is set per user, not per company, which catches new admins off guard. The owner enabling 2FA on their own account does not enable it on anyone else's. Every administrator and team member should turn it on individually from their User Settings. Kinsta supports authenticator apps (Authy, Google Authenticator, 1Password, Bitwarden) and the standard time-based one-time password format, so any TOTP app or password manager works. The full walkthrough lives in how to enable two-factor authentication on MyKinsta.

If your team uses an identity provider, Kinsta also offers SAML single sign-on on enterprise plans, which lets you manage MyKinsta access through Okta, Microsoft Entra ID, Google Workspace, OneLogin, Auth0, Duo, or JumpCloud. SSO replaces individual 2FA enrolment with whatever MFA your IdP enforces, which is the cleaner pattern once a team is more than a handful of people.

TOTP Apps vs SSO: Which to Use

For small teams and solo operators, a TOTP authenticator app is the right choice. It adds strong second-factor protection with no infrastructure to maintain, works with any compatible app or password manager, and takes about two minutes to set up per user. For teams of ten or more, or any organisation that already runs an identity provider, SSO is worth the setup cost. SSO centralises access control so that when someone leaves the company, revoking their IdP account automatically removes their MyKinsta access too. You do not have to remember to remove them from Kinsta separately. If you are between those sizes, a practical rule is to use TOTP until you find yourself manually offboarding more than two or three people per quarter.

Transferring Company Ownership and Managing Users

The Company Owner role has exactly one exclusive permission that administrators do not get: the ability to close the company account. Everything else, including adding users, changing roles, and updating billing, is also available to administrators. That makes ownership transfer relatively safe, but the transfer has to happen through the right path: the new owner must already exist as an administrator in the company, the current owner triggers the transfer from Company Settings, and the change takes effect immediately. The detailed steps and the gotchas (the new owner cannot have pending invitations, for example) are in how to transfer company ownership on Kinsta.

Safe Agency-to-Client Handover Sequence

For client handovers where the agency built the site and is handing it back, the safest sequence is: add the client as administrator, verify they can log in and access MyKinsta, then transfer ownership to them. This keeps the agency's user account active for any future maintenance the client buys, while moving billing and final control to the client.

Removing a Team Member or Contractor from MyKinsta

Removing a user from MyKinsta is fast and permanent. There is no suspension or deactivation state, so it is worth preparing before you click Remove rather than after.

Steps to Remove a User

Go to Company Settings, open the Users tab, find the user's row, click the three-dot menu on the right, and select Remove. Access is revoked immediately with no grace period. If the user held a Developer role, their SSH key is revoked at the same time. If they held the Billing role, make sure another user with billing access is already in place before removing them, or you will lose the ability to update payment details until a replacement is added. One important constraint: the Company Owner cannot be removed. You must transfer ownership to another administrator first, which makes that administrator the new owner, then remove the former owner's account if needed.

Offboarding Contractors Safely

Before removing a developer, take a few steps to close the access paths they may have opened during their engagement. Rotate any API keys or SSH keys they created directly, since removing their MyKinsta user does not automatically invalidate credentials generated outside the panel. Check any Git integrations linked to their personal tokens and revoke or replace those tokens. If they had SSH access to a site, regenerate the Kinsta-managed SSH key in that site's Application Settings to invalidate the old key pair. Change the wp-admin password on every WordPress site they had access to. Finally, review the MyKinsta activity log for recent deployments and configuration changes before revoking access, so you have a clear picture of the last state they touched. Doing this review before removal is easier than reconstructing it after, since the activity log is tied to the user account.

Managing Billing and Invoices in MyKinsta

Billing lives in Company Settings under the Billing tab, and only the Company Owner and users with the Billing role can access it. Four things most site owners need to do at some point:

• Updating the payment method. Add a new credit card under Payment Methods and set it as the default before removing the old one. Deleting the only card without adding a replacement will trigger a payment failure on the next billing cycle.
• Downloading invoices. Invoices are available under Billing History as PDFs. Each invoice shows the plan cost, any usage overages (bandwidth, visits above plan limits), and prorated charges from mid-cycle upgrades.
• Adding a VAT or tax ID. Kinsta accepts VAT numbers for EU businesses and other regional tax IDs. Adding your tax ID before the billing date ensures it appears on the invoice; retroactive updates require contacting support.
• Understanding overage charges. If your site exceeds its plan's monthly visit limit, Kinsta charges per 1,000 additional visits. The Billing tab shows a running estimate partway through the month. If overages are frequent, upgrading the plan is almost always cheaper than paying per-visit fees.

Billing emails (receipts, failed-payment notices, and dunning emails) go to the Company Owner's registered email regardless of notification preferences. This is the one notification category that cannot be rerouted to a Billing-role user; make sure the owner address is actively monitored.

Understanding Overage Charges

Overage pricing on Kinsta runs roughly $1 per 1,000 visits above your plan's monthly limit, though the exact rate varies by plan tier. The Billing tab shows a running total of estimated overages partway through the billing cycle, so you can catch a spike before it compounds. If you upgrade your plan mid-cycle, Kinsta prorates the cost for the remaining days, which typically makes upgrading cheaper than absorbing a full month of per-visit fees. As a concrete example: 100,000 overage visits would add around $100 to your invoice. Most mid-tier plan upgrades cost less than that difference on a prorated basis, so if overages are happening two months in a row, the math usually favors upgrading rather than absorbing them.

Adding a Domain to Kinsta (and the Cloudflare Wrinkle)

Adding a domain in MyKinsta is straightforward on a clean slate: Domains, Add Domain, paste in the hostname, and Kinsta generates a kinstavalidation TXT record you add at your registrar to prove ownership. Once the TXT propagates, Kinsta verifies the domain and the free Cloudflare integration turns on automatically, proxying the domain through Cloudflare's enterprise network for CDN, DDoS protection, and free SSL with wildcard support.

The Verification TXT Record Process

The kinstavalidation TXT record must be placed on the exact hostname being verified. For an apex domain like example.com, the record belongs at the root (@ or blank host field at your registrar), not on a prefixed subdomain. For a subdomain like blog.example.com, the record belongs on blog, not on _kinstavalidation.blog. Getting the placement wrong is the most common reason domain verification stalls. After adding the record, propagation typically takes a few minutes but can take up to an hour. You can check whether the record is visible using dig TXT example.com before triggering the verify step in MyKinsta. Once verified, the TXT record can be safely removed; Kinsta does not re-check it after the initial pass.

When Existing Cloudflare Accounts Interfere

The complication shows up when the domain is already proxied through a separate Cloudflare account (the orange-cloud icon at Cloudflare). Two Cloudflare proxy layers on the same hostname create a DNS loop and the Kinsta integration silently fails to take over. The fix is to either move the proxy from your Cloudflare account to Kinsta's (set DNS-only / grey cloud at your account first) or use the bring-your-own-Cloudflare option Kinsta supports on enterprise plans. The full step-by-step for the first path is in how to enable Kinsta's Cloudflare integration on an existing domain, including how to verify the integration is live (look for the Cloudflare badge in the MyKinsta Domains tab) and when it is safe to remove the verification TXT record.

Connecting a Domain with Multiple IP Addresses

Most Kinsta sites point a single A record at a single Kinsta IP, but multi-region setups, geo-failover, and wildcard A records all need the domain to resolve to more than one IP. Kinsta supports this, but the domain verification path is different because the standard Cloudflare-based check expects a single A record. The workaround uses CNAME flattening and a slightly different add-domain sequence so verification passes before the multi-IP DNS goes live. The detailed steps, including how to confirm both IPs are serving traffic, are in how to add a domain pointing to multiple IP addresses on Kinsta.

The same approach also handles the case where you want a wildcard A record (*.example.com) covering arbitrary subdomains, which is common for SaaS apps that route by subdomain. Kinsta does not document the multi-IP and wildcard paths together in their knowledge base, so the how-to fills that gap.

Choosing Between Kinsta DNS and Your Registrar's Nameservers

Every Kinsta plan includes Kinsta DNS, a managed DNS service running on Amazon Route 53 with global anycast resolution. You get it free, you can manage all standard record types (A, AAAA, CNAME, MX, TXT, SRV, CAA, NS), and the resolver speed is competitive with any premium DNS service. The trade-off is whether to point your registrar's nameservers at Kinsta or keep your existing DNS host (Cloudflare DNS, Route 53 directly, Google Domains DNS, etc.).

When to Use Kinsta DNS

Kinsta DNS is the right choice when you want a single place to manage both hosting and DNS, when the site lives entirely on Kinsta, or when you do not have a strong reason to keep DNS elsewhere. If you are migrating to Kinsta from another host and the domain has no complex DNS dependencies (no MX records for an email service, no records managed by an external tool), moving to Kinsta DNS simplifies the setup and reduces the number of dashboards you need to check when troubleshooting. If you do migrate, copy every existing record into Kinsta DNS first, then change nameservers at the registrar. Doing it in reverse causes downtime because the new nameservers go live with empty zones.

When to Keep Your Own Nameservers

Keep your existing nameservers when you have email at the same domain that depends on MX records you do not want to migrate, when you run multiple sites across different hosts and prefer one DNS provider for all of them, or when an automated system at your DNS host (a Terraform pipeline, an SaaS that manages DNS, a TXT-based verification system) would break if records moved. The Kinsta Cloudflare integration works whether your nameservers are at Kinsta or elsewhere, so this decision is purely about operational convenience rather than performance or features.

Notifications, Billing Alerts, and Who Gets What Email

MyKinsta sends several distinct categories of email: site uptime and resource alerts, security warnings, billing receipts and dunning notices, weekly performance summaries, and product update announcements. The notification preferences are per user, so the Company Owner is not automatically opted into the same notifications as administrators or developers. For a single-operator account this rarely matters; for an agency, it means the person who needs to know a client's site is down might not get the alert unless they enable that category on their own user. The settings tab and the rules for routing each category are walked through in how to manage MyKinsta notifications.

Billing notifications are the exception: dunning emails (failed payment, expiring card) go to the Company Owner's email address regardless of their notification preferences. Make sure the owner's email is one that gets read every day, not a shared inbox or a forwarding address that might bounce.

Per-User vs Company-Wide Alerts

Most notification categories in MyKinsta are opt-in and scoped to the individual user. This means a Developer who wants uptime alerts for their sites must enable them separately from the Administrator who also wants those alerts. There is no company-wide "broadcast all alerts to all users" toggle. For agencies managing multiple client sites, the practical approach is to decide which role should own each alert category, then make sure every person in that role has enabled the relevant notifications during onboarding. A quick checklist in your onboarding docs saves you from discovering a missed alert only after an incident.

Common Account and Domain Problems and Their Fixes

A few patterns come up repeatedly in support tickets:

Cloudflare Integration Issues

• "My Cloudflare integration is not working." Almost always because the domain is still proxied through a separate Cloudflare account. Set DNS-only (grey cloud) there, wait for DNS propagation, then re-verify in MyKinsta.
• "Domain verification keeps failing." The kinstavalidation TXT record was added at the wrong host. It belongs on the apex (or the exact subdomain being verified), not on _kinstavalidation or any prefixed host. Check with dig TXT example.com.
• "DNS changes are not taking effect." Check whether the record is in Kinsta DNS or at your old DNS host; once you change nameservers, edits at the old host stop having any effect even though the dashboard still lets you make them.

2FA and Login Problems

• "My 2FA codes do not work." The device clock has drifted. TOTP relies on synchronised time; resync the authenticator app or use the password-manager TOTP that pulls from network time.
• "I lost access to my authenticator." Use the recovery codes generated when 2FA was enabled. If those are also lost, Kinsta support can disable 2FA after identity verification, but that path is slow on purpose.

DNS and Role Issues

• "I cannot transfer ownership." The intended new owner has not accepted their administrator invitation yet, or they still have a pending invitation that needs to be revoked and re-sent after acceptance.
• "A team member says their role is wrong." Role changes take effect immediately after saving in Company Settings. If someone still sees the wrong permissions after a role change, have them log out and back in to refresh their session token.

Cancelling a Kinsta Plan

Cancelling a Kinsta plan is straightforward, but there are preparation steps worth taking before you trigger the cancellation to avoid losing data or leaving visitors with a broken site.

What Happens to Your Sites on Cancellation

Kinsta retains your site data for a short period after cancellation, typically around 30 days, but do not rely on that window as a backup strategy. Export a full backup of every site before cancelling, including both the files and the database. Cancellation does not migrate your site automatically. You need to move the files and database to your new host before shutting down Kinsta, not after. If your domain points to Kinsta's Cloudflare integration, update the A record or nameservers to point at your new host before cancelling. If you cancel first and update DNS after, visitors will hit a dead endpoint until propagation completes, and depending on TTL that gap can last several hours.

How to Cancel

Only the Company Owner can cancel a Kinsta plan. Go to Company Settings, open the Billing tab, and select Cancel Subscription. Kinsta will prompt for a cancellation reason before confirming. Cancellation takes effect at the end of the current billing cycle, so you retain access to your sites and backups until that date. If you are still within the 30-day money-back guarantee window, cancellation triggers an immediate refund rather than access continuing until period end. After the cancellation date, your account moves to read-only mode, which means you can still log in to MyKinsta and download your backups, but you cannot make changes to sites or settings.

If you are still evaluating Kinsta before committing, the Kinsta review covers the broader pros and cons (price, support quality, the Google Cloud Platform infrastructure, the trade-off versus other managed WordPress hosts). For a quick start, the Kinsta plans page has the current pricing and a 30-day money-back guarantee on all tiers.