From ffc68bd99abae8928676728d9511dcaf912f6be1 Mon Sep 17 00:00:00 2001 From: Vic van Gool Date: Wed, 20 May 2026 07:43:05 +0100 Subject: [PATCH 1/8] Add account-owner transfer doc Customers needing to transfer the account-owner role had no self-serve documentation and had to ask support to discover it's a support-only action. Adds a standalone account/change-owner.mdx describing the request procedure and what support needs (written confirmation from the current owner), plus the case where the current owner is unavailable. Cross-links from the existing owner mention in account/team-accounts.mdx. Linear: SUP-1018 Co-Authored-By: Claude Opus 4.7 (1M context) --- account/change-owner.mdx | 29 +++++++++++++++++++++++++++++ account/team-accounts.mdx | 2 +- 2 files changed, 30 insertions(+), 1 deletion(-) create mode 100644 account/change-owner.mdx diff --git a/account/change-owner.mdx b/account/change-owner.mdx new file mode 100644 index 0000000..20e03cd --- /dev/null +++ b/account/change-owner.mdx @@ -0,0 +1,29 @@ +--- +title: Changing the account owner +--- + +## Overview + +Every Cloud 66 account has a single **owner** — the user with maximum permissions on every application in the account ([more on roles](/:product/:version?/account/team-accounts#user-roles-and-permissions)). The owner role can be transferred to another user, but the transfer is **not self-serve** from the Dashboard: it requires a request to Cloud 66 support. + +This is by design — ownership transfer affects billing responsibility and account control, so we ask for explicit confirmation from the current owner before reassigning the role. + +## How to request a transfer + +1. The **current owner** opens a support request — either by [emailing support](mailto:support@cloud66.com) or by using the in-app help widget from the current owner's account. +2. Include the following in the request: + - The Cloud 66 account name (or organization ID) + - The email address of the user who should become the new owner + - Written confirmation that you (the current owner) are authorizing the transfer +3. Cloud 66 support will verify the request from the current owner's address and reassign the owner role. + +The new owner must already have a Cloud 66 user account and be a member of the team. If they aren't, [add them as a team member](/:product/:version?/account/team-accounts) first, then request the transfer. + + +If the current owner has left the company or otherwise cannot make the request themselves, contact support and explain the situation. We will work with you to verify your authority over the account (typically through the registered billing contact or other organizational records) before processing the transfer. This takes longer than a standard transfer. + + +## Related + +- [Managing teams and organizations](/:product/:version?/account/team-accounts) — adding team members and setting roles +- [Service Accounts](/:product/:version?/account/service-accounts) — for API access; not a substitute for user ownership diff --git a/account/team-accounts.mdx b/account/team-accounts.mdx index 0429124..f47711d 100755 --- a/account/team-accounts.mdx +++ b/account/team-accounts.mdx @@ -65,7 +65,7 @@ You can specify the exact access rights you would like to grant a user per appli - Power user - Administrator (has all permissions) -The **owner** of an account always has the maximum permissions for all applications and does not need to be assigned any roles. +The **owner** of an account always has the maximum permissions for all applications and does not need to be assigned any roles. To transfer the owner role to another user, see [Changing the account owner](/:product/:version?/account/change-owner). The Administrator role has permissions to everything and the other default roles have the following permissions: From 6ec5bbe9a1235eb23df51732678bbc1444114440 Mon Sep 17 00:00:00 2001 From: Vic van Gool Date: Wed, 20 May 2026 07:52:49 +0100 Subject: [PATCH 2/8] Correct account-owner change doc: three workarounds, no role-swap primitive MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The first draft claimed support "reassigns the owner role" — but Cloud 66 has no first-class transfer-owner operation. Ownership change is done via one of three approaches, each with constraints: 1. Move applications to another account (self-service; links to the existing application-transfer guide) 2. Rename the account email (support-only; target email must have no apps and no other org membership) 3. Route the account email via a "+" alias (support-only; includes the Terms-of-Service warning against using aliases for extra free accounts) All three still require written confirmation from the current owner. Also softens the team-accounts.mdx cross-link wording ("move account ownership" rather than "transfer the owner role"). Linear: SUP-1018 Co-Authored-By: Claude Opus 4.7 (1M context) --- account/change-owner.mdx | 57 +++++++++++++++++++++++++++++---------- account/team-accounts.mdx | 2 +- 2 files changed, 44 insertions(+), 15 deletions(-) diff --git a/account/change-owner.mdx b/account/change-owner.mdx index 20e03cd..a2e2348 100644 --- a/account/change-owner.mdx +++ b/account/change-owner.mdx @@ -4,26 +4,55 @@ title: Changing the account owner ## Overview -Every Cloud 66 account has a single **owner** — the user with maximum permissions on every application in the account ([more on roles](/:product/:version?/account/team-accounts#user-roles-and-permissions)). The owner role can be transferred to another user, but the transfer is **not self-serve** from the Dashboard: it requires a request to Cloud 66 support. +Every Cloud 66 account has a single **owner** — the user with maximum permissions on every application in the account ([more on roles](/:product/:version?/account/team-accounts#user-roles-and-permissions)). -This is by design — ownership transfer affects billing responsibility and account control, so we ask for explicit confirmation from the current owner before reassigning the role. +There is **no "transfer owner" button** in the Dashboard, and no single one-click action that reassigns ownership. Instead, depending on what you're actually trying to achieve, there are three different approaches. Work out which of the situations below matches yours, then follow the relevant route. -## How to request a transfer +Whichever approach fits, **the current account owner must confirm the change in writing** (a reply on your support thread is enough). The request usually comes from the person who will become the new owner, so we need the current owner to authorize it — this is a privilege change, so the confirmation is required even for friendly, internal handovers. -1. The **current owner** opens a support request — either by [emailing support](mailto:support@cloud66.com) or by using the in-app help widget from the current owner's account. -2. Include the following in the request: - - The Cloud 66 account name (or organization ID) - - The email address of the user who should become the new owner - - Written confirmation that you (the current owner) are authorizing the transfer -3. Cloud 66 support will verify the request from the current owner's address and reassign the owner role. +## Option 1: Move the applications to another account -The new owner must already have a Cloud 66 user account and be a member of the team. If they aren't, [add them as a team member](/:product/:version?/account/team-accounts) first, then request the transfer. +If the new owner already has — or can create — their own Cloud 66 account, you can transfer your applications across to it. This is a **self-service** flow you can run yourself, subject to some account and application criteria (for example, both accounts must have access to the same cloud provider account that hosts the applications). See [Transferring application ownership](/:product/:version?/account/application-transfer) for the full requirements and step-by-step procedure. - -If the current owner has left the company or otherwise cannot make the request themselves, contact support and explain the situation. We will work with you to verify your authority over the account (typically through the registered billing contact or other organizational records) before processing the transfer. This takes longer than a standard transfer. +Each application is transferred individually, so this route is more involved if you have many. Once the transfers are complete, the new account operates the workloads and the original account can be closed if it's no longer needed. + +This is the right choice when the new owner should have their **own distinct account and identity**. + +## Option 2: Rename the account's email address + +If the new owner doesn't yet use Cloud 66, support can change the email address on your existing account to theirs. The account and all of its applications stay exactly as they are — only the login and contact identity changes. + +This is usually the cleanest route, but it only works if **both** of the following are true: + +- The new email address does **not** already have its own applications on Cloud 66, and +- The new email address is **not** already a member of another Cloud 66 organization. + +If the new owner already has their own Cloud 66 setup under that email, a rename would collide with it — use Option 1 instead. + +## Option 3: Route the account's email to the new owner with a "+" alias + +If the new owner mainly needs the account's notifications and invoices to reach their inbox (rather than a brand-new distinct identity), support can relabel the account's email using a "+" alias — for example `newowner+cloud66@example.com` — so mail routes to them while the account itself stays intact. + +This only works if the new owner's mail provider supports "+" sub-addressing. Gmail, Fastmail, and Microsoft 365 do; some corporate mail systems don't. + + +Using "+" sub-addressing to register multiple Cloud 66 accounts under variations of the same email address is a breach of our Terms of Service and may result in account suspension without warning. This approach is only for keeping a single account's mail flowing to the right person — not for creating additional accounts. +## How to request the change + +For **Option 1**, you can run the [application transfer](/:product/:version?/account/application-transfer) yourself. + +For **Option 2 or 3**: + +1. The prospective new owner (or the current owner) contacts [support](mailto:support@cloud66.com). +2. Tell us which of the situations above matches yours, along with the email address involved. +3. The **current owner** confirms the change in writing on the same thread. +4. Support makes the change and confirms once it's done. + +If none of the three options fit cleanly — for example, the new owner needs a separate clean identity but already has applications under the target email — contact support anyway and we'll work through the trade-offs with you. + ## Related -- [Managing teams and organizations](/:product/:version?/account/team-accounts) — adding team members and setting roles -- [Service Accounts](/:product/:version?/account/service-accounts) — for API access; not a substitute for user ownership +- [Transferring application ownership](/:product/:version?/account/application-transfer) — moving individual applications between accounts (Option 1) +- [Managing teams and organizations](/:product/:version?/account/team-accounts) — roles and permissions diff --git a/account/team-accounts.mdx b/account/team-accounts.mdx index f47711d..8df2f03 100755 --- a/account/team-accounts.mdx +++ b/account/team-accounts.mdx @@ -65,7 +65,7 @@ You can specify the exact access rights you would like to grant a user per appli - Power user - Administrator (has all permissions) -The **owner** of an account always has the maximum permissions for all applications and does not need to be assigned any roles. To transfer the owner role to another user, see [Changing the account owner](/:product/:version?/account/change-owner). +The **owner** of an account always has the maximum permissions for all applications and does not need to be assigned any roles. To move account ownership to another user, see [Changing the account owner](/:product/:version?/account/change-owner). The Administrator role has permissions to everything and the other default roles have the following permissions: From 9a11f055bb47e718e2fd7eff4f6b1829d8a74b98 Mon Sep 17 00:00:00 2001 From: Vic van Gool Date: Wed, 20 May 2026 08:05:20 +0100 Subject: [PATCH 3/8] Reframe owner-change as current-owner-driven (review feedback) Per PR review: in all three approaches the action is taken by the current account owner, not requested by the prospective new owner. Removes the "new owner requests, current owner confirms in writing" framing and makes clear the current owner initiates directly (application transfer) or via a support request from the account's own email. A prospective new owner cannot initiate the change. Linear: SUP-1018 Co-Authored-By: Claude Opus 4.7 (1M context) --- account/change-owner.mdx | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/account/change-owner.mdx b/account/change-owner.mdx index a2e2348..ea5e94e 100644 --- a/account/change-owner.mdx +++ b/account/change-owner.mdx @@ -8,7 +8,7 @@ Every Cloud 66 account has a single **owner** — the user with maximum permissi There is **no "transfer owner" button** in the Dashboard, and no single one-click action that reassigns ownership. Instead, depending on what you're actually trying to achieve, there are three different approaches. Work out which of the situations below matches yours, then follow the relevant route. -Whichever approach fits, **the current account owner must confirm the change in writing** (a reply on your support thread is enough). The request usually comes from the person who will become the new owner, so we need the current owner to authorize it — this is a privilege change, so the confirmation is required even for friendly, internal handovers. +In every case, **the change is carried out by the current account owner** — either directly (in the case of an application transfer) or by asking our support team. A prospective new owner can't initiate the change themselves: because account ownership is a privileged position, the action has to be taken by whoever currently holds it. If you're not the current owner, ask them to make the request. ## Option 1: Move the applications to another account @@ -39,18 +39,19 @@ This only works if the new owner's mail provider supports "+" sub-addressing. Gm Using "+" sub-addressing to register multiple Cloud 66 accounts under variations of the same email address is a breach of our Terms of Service and may result in account suspension without warning. This approach is only for keeping a single account's mail flowing to the right person — not for creating additional accounts. -## How to request the change +## How to make the change -For **Option 1**, you can run the [application transfer](/:product/:version?/account/application-transfer) yourself. +These actions are always taken by the **current account owner**. + +For **Option 1**, the current owner runs the [application transfer](/:product/:version?/account/application-transfer) from the Dashboard — no support request needed. For **Option 2 or 3**: -1. The prospective new owner (or the current owner) contacts [support](mailto:support@cloud66.com). -2. Tell us which of the situations above matches yours, along with the email address involved. -3. The **current owner** confirms the change in writing on the same thread. -4. Support makes the change and confirms once it's done. +1. The **current owner** contacts [support](mailto:support@cloud66.com) from the email address on the account. +2. Tell us which of the situations above matches, along with the email address involved. +3. Support makes the change and confirms once it's done. -If none of the three options fit cleanly — for example, the new owner needs a separate clean identity but already has applications under the target email — contact support anyway and we'll work through the trade-offs with you. +If you're not the current owner, ask them to start the process — support can only act on an ownership change at the current owner's request. If none of the three options fit cleanly (for example, the new owner needs a separate clean identity but already has applications under the target email), contact support and we'll work through the trade-offs with you. ## Related From 55cf9cac9db89df41b49dab8560ec118769d7887 Mon Sep 17 00:00:00 2001 From: Vic van Gool Date: Wed, 20 May 2026 08:09:48 +0100 Subject: [PATCH 4/8] Reorder owner-change options; demote application transfer to last resort MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Matches the preference order used in the HS #33567 reply: email-based approaches first (rename, then "+" alias), application transfer last. The application-transfer option now leads with "last resort" framing and explains why (it touches billing, DNS/failover groups, backups, server agents, and cloud-credential mappings, with a same-cloud-credentials restriction) without fear-mongering — it's positioned as more involved, not unsafe. Linear: SUP-1018 Co-Authored-By: Claude Opus 4.7 (1M context) --- account/change-owner.mdx | 40 +++++++++++++++++++--------------------- 1 file changed, 19 insertions(+), 21 deletions(-) diff --git a/account/change-owner.mdx b/account/change-owner.mdx index ea5e94e..fe2d21d 100644 --- a/account/change-owner.mdx +++ b/account/change-owner.mdx @@ -6,32 +6,24 @@ title: Changing the account owner Every Cloud 66 account has a single **owner** — the user with maximum permissions on every application in the account ([more on roles](/:product/:version?/account/team-accounts#user-roles-and-permissions)). -There is **no "transfer owner" button** in the Dashboard, and no single one-click action that reassigns ownership. Instead, depending on what you're actually trying to achieve, there are three different approaches. Work out which of the situations below matches yours, then follow the relevant route. +There is **no "transfer owner" button** in the Dashboard, and no single one-click action that reassigns ownership. Instead, depending on what you're trying to achieve, there are three approaches. The first two simply change the email and login identity on the existing account and are the simplest; the third — transferring your applications to a different account — is far more involved and is best kept as a last resort. Work through them in order and use the first one that fits. In every case, **the change is carried out by the current account owner** — either directly (in the case of an application transfer) or by asking our support team. A prospective new owner can't initiate the change themselves: because account ownership is a privileged position, the action has to be taken by whoever currently holds it. If you're not the current owner, ask them to make the request. -## Option 1: Move the applications to another account +## Option 1: Rename the account's email address -If the new owner already has — or can create — their own Cloud 66 account, you can transfer your applications across to it. This is a **self-service** flow you can run yourself, subject to some account and application criteria (for example, both accounts must have access to the same cloud provider account that hosts the applications). See [Transferring application ownership](/:product/:version?/account/application-transfer) for the full requirements and step-by-step procedure. +If the new owner doesn't yet have their own Cloud 66 presence, support can change the email address on the existing account to theirs. The account and all of its applications stay exactly as they are — only the login and contact identity changes. This is usually the simplest path and the one we'd suggest first, when it fits. -Each application is transferred individually, so this route is more involved if you have many. Once the transfers are complete, the new account operates the workloads and the original account can be closed if it's no longer needed. - -This is the right choice when the new owner should have their **own distinct account and identity**. - -## Option 2: Rename the account's email address - -If the new owner doesn't yet use Cloud 66, support can change the email address on your existing account to theirs. The account and all of its applications stay exactly as they are — only the login and contact identity changes. - -This is usually the cleanest route, but it only works if **both** of the following are true: +It only works if **both** of the following are true: - The new email address does **not** already have its own applications on Cloud 66, and - The new email address is **not** already a member of another Cloud 66 organization. -If the new owner already has their own Cloud 66 setup under that email, a rename would collide with it — use Option 1 instead. +If the intended new owner already has Cloud 66 history under that email (their own apps, or membership of other organizations), a rename would either collide with it or risk losing that history — use Option 2 instead. -## Option 3: Route the account's email to the new owner with a "+" alias +## Option 2: Route the account's email to the new owner with a "+" alias -If the new owner mainly needs the account's notifications and invoices to reach their inbox (rather than a brand-new distinct identity), support can relabel the account's email using a "+" alias — for example `newowner+cloud66@example.com` — so mail routes to them while the account itself stays intact. +If the new owner already has Cloud 66 history under their email (so Option 1 doesn't fit), support can relabel the account's email using a "+" alias — for example `newowner+evovia@example.com` — so mail still routes to their main inbox while the account itself stays intact. Ownership stays where it is; the new owner logs into the owner account only when an ownership-level action is needed, and uses their normal account for everything else. This only works if the new owner's mail provider supports "+" sub-addressing. Gmail, Fastmail, and Microsoft 365 do; some corporate mail systems don't. @@ -39,21 +31,27 @@ This only works if the new owner's mail provider supports "+" sub-addressing. Gm Using "+" sub-addressing to register multiple Cloud 66 accounts under variations of the same email address is a breach of our Terms of Service and may result in account suspension without warning. This approach is only for keeping a single account's mail flowing to the right person — not for creating additional accounts. +## Option 3: Transfer the applications to another account + +This is the last-resort option: reach for it only when neither of the email-based approaches above works for your situation — for example, when the new owner genuinely needs a separate account and identity of their own. The applications are transferred one by one from the current account to the new owner's account. It's a **self-service** flow; see [Transferring application ownership](/:product/:version?/account/application-transfer) for the requirements and steps. + +It's worth understanding why we keep this as a last resort. Moving applications between accounts touches a lot of moving parts — billing, DNS and failover groups, backups, server agents, and cloud-credential mappings — and carries restrictions (for example, the target account must have access to the same cloud credentials used by the existing servers, otherwise later operations such as load balancer changes can fail). None of that makes it unsafe, but it's enough extra complexity that the email-based options are almost always the better choice when they're available. + ## How to make the change These actions are always taken by the **current account owner**. -For **Option 1**, the current owner runs the [application transfer](/:product/:version?/account/application-transfer) from the Dashboard — no support request needed. - -For **Option 2 or 3**: +For **Option 1 or 2**: 1. The **current owner** contacts [support](mailto:support@cloud66.com) from the email address on the account. -2. Tell us which of the situations above matches, along with the email address involved. +2. Tell us which approach fits your situation, along with the email address involved. 3. Support makes the change and confirms once it's done. -If you're not the current owner, ask them to start the process — support can only act on an ownership change at the current owner's request. If none of the three options fit cleanly (for example, the new owner needs a separate clean identity but already has applications under the target email), contact support and we'll work through the trade-offs with you. +For **Option 3**, the current owner runs the [application transfer](/:product/:version?/account/application-transfer) from the Dashboard. + +If you're not the current owner, ask them to start the process — support can only act on an ownership change at the current owner's request. If you're not sure which approach fits, contact support and we'll help you choose. ## Related -- [Transferring application ownership](/:product/:version?/account/application-transfer) — moving individual applications between accounts (Option 1) +- [Transferring application ownership](/:product/:version?/account/application-transfer) — moving individual applications between accounts (Option 3) - [Managing teams and organizations](/:product/:version?/account/team-accounts) — roles and permissions From e47c7b2e3f8f30a97e0b2c4f4e64586308238438 Mon Sep 17 00:00:00 2001 From: Vic van Gool Date: Wed, 20 May 2026 08:19:55 +0100 Subject: [PATCH 5/8] Apply PR review: self-service framing, soften tone, reframe Option 2 Addresses review comments on change-owner.mdx: - Email-based changes are self-service via Account Settings; drop the "contact support is required" framing (support now optional). - Soften the "+" alias warning from a ToS-breach Callout to an info note, clarifying the unique-email rule only exists to prevent multiple free accounts. - Soften the "last resort" language on the application-transfer option (now "a few more steps; try the email options first" rather than scary). - Retitle Option 2 to "Use another email under your control" and fold the "+" alias in as a trick within it. - Correct Option 1 constraint to the real rule (email must be unique across Cloud 66) rather than the old delete-and-rename/lose-history framing. Linear: SUP-1018 Co-Authored-By: Claude Opus 4.7 (1M context) --- account/change-owner.mdx | 41 ++++++++++++++++------------------------ 1 file changed, 16 insertions(+), 25 deletions(-) diff --git a/account/change-owner.mdx b/account/change-owner.mdx index fe2d21d..e51ab47 100644 --- a/account/change-owner.mdx +++ b/account/change-owner.mdx @@ -6,52 +6,43 @@ title: Changing the account owner Every Cloud 66 account has a single **owner** — the user with maximum permissions on every application in the account ([more on roles](/:product/:version?/account/team-accounts#user-roles-and-permissions)). -There is **no "transfer owner" button** in the Dashboard, and no single one-click action that reassigns ownership. Instead, depending on what you're trying to achieve, there are three approaches. The first two simply change the email and login identity on the existing account and are the simplest; the third — transferring your applications to a different account — is far more involved and is best kept as a last resort. Work through them in order and use the first one that fits. +There's no dedicated "transfer owner" button in the Dashboard, but you can achieve the same result in one of three ways. The first two simply change the email and login identity on the existing account and take a moment to do yourself; the third moves your applications to a separate account and is mainly useful when the new owner wants a completely separate account of their own. Work through them in order and use the first one that fits. -In every case, **the change is carried out by the current account owner** — either directly (in the case of an application transfer) or by asking our support team. A prospective new owner can't initiate the change themselves: because account ownership is a privileged position, the action has to be taken by whoever currently holds it. If you're not the current owner, ask them to make the request. +In every case the change is made by the **current account owner**, and there's no support ticket required for the email-based options. A prospective new owner can't initiate the change themselves, since it's tied to whoever currently controls the account — so if you're not the current owner, ask them to make the change. ## Option 1: Rename the account's email address -If the new owner doesn't yet have their own Cloud 66 presence, support can change the email address on the existing account to theirs. The account and all of its applications stay exactly as they are — only the login and contact identity changes. This is usually the simplest path and the one we'd suggest first, when it fits. +If the email the new owner wants to use isn't already registered with Cloud 66, the current owner can simply change the account's email address to it under *Account Settings* (click your avatar, top-right → *Account Settings*). The account and all of its applications stay exactly as they are — only the login and contact identity changes. This is the simplest option, so try it first. -It only works if **both** of the following are true: +The only requirement is that the new email address isn't **already in use by another Cloud 66 account** — each account needs its own unique email address. This restriction exists purely to stop a single person quietly running several free accounts; for a genuine ownership handover it's not a problem. If the new owner's preferred email is already registered with Cloud 66, use Option 2 instead. -- The new email address does **not** already have its own applications on Cloud 66, and -- The new email address is **not** already a member of another Cloud 66 organization. +## Option 2: Use another email under your control -If the intended new owner already has Cloud 66 history under that email (their own apps, or membership of other organizations), a rename would either collide with it or risk losing that history — use Option 2 instead. +If the new owner's main email is already registered with Cloud 66 (so Option 1 won't work), use a **different email address they control** instead. Any address that reaches them works — and the current owner changes the account's email to it under *Account Settings*, exactly as in Option 1. -## Option 2: Route the account's email to the new owner with a "+" alias +If they don't have a spare mailbox to hand, there's a handy trick: most mail providers support "+" sub-addressing, so an address like `newowner+evovia@example.com` still lands in the `newowner@example.com` inbox while counting as a distinct address on Cloud 66. Gmail, Fastmail, and Microsoft 365 support this; some corporate mail systems don't. -If the new owner already has Cloud 66 history under their email (so Option 1 doesn't fit), support can relabel the account's email using a "+" alias — for example `newowner+evovia@example.com` — so mail still routes to their main inbox while the account itself stays intact. Ownership stays where it is; the new owner logs into the owner account only when an ownership-level action is needed, and uses their normal account for everything else. - -This only works if the new owner's mail provider supports "+" sub-addressing. Gmail, Fastmail, and Microsoft 365 do; some corporate mail systems don't. - - -Using "+" sub-addressing to register multiple Cloud 66 accounts under variations of the same email address is a breach of our Terms of Service and may result in account suspension without warning. This approach is only for keeping a single account's mail flowing to the right person — not for creating additional accounts. + +Each Cloud 66 account needs its own unique email address. This is only to prevent one person running multiple free accounts under variations of the same address — using a separate or "+" address for a genuine ownership change is completely fine. ## Option 3: Transfer the applications to another account -This is the last-resort option: reach for it only when neither of the email-based approaches above works for your situation — for example, when the new owner genuinely needs a separate account and identity of their own. The applications are transferred one by one from the current account to the new owner's account. It's a **self-service** flow; see [Transferring application ownership](/:product/:version?/account/application-transfer) for the requirements and steps. +If the new owner would rather have a completely separate account of their own, you can transfer your applications across to it instead, one at a time. This is a self-service flow — see [Transferring application ownership](/:product/:version?/account/application-transfer) for the requirements and steps. -It's worth understanding why we keep this as a last resort. Moving applications between accounts touches a lot of moving parts — billing, DNS and failover groups, backups, server agents, and cloud-credential mappings — and carries restrictions (for example, the target account must have access to the same cloud credentials used by the existing servers, otherwise later operations such as load balancer changes can fail). None of that makes it unsafe, but it's enough extra complexity that the email-based options are almost always the better choice when they're available. +It involves a few more steps than the email options, because moving applications between accounts also moves things like billing, DNS and failover groups, backups, server agents, and cloud-credential mappings (for example, the destination account needs access to the same cloud credentials as the existing servers). It's a well-trodden, safe process — just a little more hands-on — so it's usually worth trying the email options first. ## How to make the change -These actions are always taken by the **current account owner**. - -For **Option 1 or 2**: - -1. The **current owner** contacts [support](mailto:support@cloud66.com) from the email address on the account. -2. Tell us which approach fits your situation, along with the email address involved. -3. Support makes the change and confirms once it's done. +All of these are done by the **current account owner**: -For **Option 3**, the current owner runs the [application transfer](/:product/:version?/account/application-transfer) from the Dashboard. +- **Options 1 and 2** — change the account's email address under *Account Settings* (click your avatar, top-right → *Account Settings*). +- **Option 3** — run the [application transfer](/:product/:version?/account/application-transfer) from the Dashboard. -If you're not the current owner, ask them to start the process — support can only act on an ownership change at the current owner's request. If you're not sure which approach fits, contact support and we'll help you choose. +If you're not the current owner, ask them to make the change. And if you're unsure which option fits, or you'd like us to handle it for you, [contact support](mailto:support@cloud66.com) and we'll help. ## Related - [Transferring application ownership](/:product/:version?/account/application-transfer) — moving individual applications between accounts (Option 3) +- [Manage your account](/:product/:version?/account/account-management) — changing your account email and other settings - [Managing teams and organizations](/:product/:version?/account/team-accounts) — roles and permissions From 3c26468f2bda5b066554d76a56d14337d18c6ccd Mon Sep 17 00:00:00 2001 From: Vic van Gool Date: Wed, 20 May 2026 08:29:12 +0100 Subject: [PATCH 6/8] Apply PR review round 3: trim Option 1, generic alias example, abuse callout - Remove the free-accounts rationale and Option 2 pointer from the Option 1 body (the abuse rationale now lives only in the callout). - Change the alias example from the customer-specific newowner+evovia to a generic newowner+project. - Retitle the callout to "Preventing abuse" and restore the firmer anti-abuse content (reworded), while reassuring legitimate handovers. Linear: SUP-1018 Co-Authored-By: Claude Opus 4.7 (1M context) --- account/change-owner.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/account/change-owner.mdx b/account/change-owner.mdx index e51ab47..d92ec05 100644 --- a/account/change-owner.mdx +++ b/account/change-owner.mdx @@ -14,16 +14,16 @@ In every case the change is made by the **current account owner**, and there's n If the email the new owner wants to use isn't already registered with Cloud 66, the current owner can simply change the account's email address to it under *Account Settings* (click your avatar, top-right → *Account Settings*). The account and all of its applications stay exactly as they are — only the login and contact identity changes. This is the simplest option, so try it first. -The only requirement is that the new email address isn't **already in use by another Cloud 66 account** — each account needs its own unique email address. This restriction exists purely to stop a single person quietly running several free accounts; for a genuine ownership handover it's not a problem. If the new owner's preferred email is already registered with Cloud 66, use Option 2 instead. +The only requirement is that the new email address isn't **already in use by another Cloud 66 account** — each account needs its own unique email address. ## Option 2: Use another email under your control If the new owner's main email is already registered with Cloud 66 (so Option 1 won't work), use a **different email address they control** instead. Any address that reaches them works — and the current owner changes the account's email to it under *Account Settings*, exactly as in Option 1. -If they don't have a spare mailbox to hand, there's a handy trick: most mail providers support "+" sub-addressing, so an address like `newowner+evovia@example.com` still lands in the `newowner@example.com` inbox while counting as a distinct address on Cloud 66. Gmail, Fastmail, and Microsoft 365 support this; some corporate mail systems don't. +If they don't have a spare mailbox to hand, there's a handy trick: most mail providers support "+" sub-addressing, so an address like `newowner+project@example.com` still lands in the `newowner@example.com` inbox while counting as a distinct address on Cloud 66. Gmail, Fastmail, and Microsoft 365 support this; some corporate mail systems don't. - -Each Cloud 66 account needs its own unique email address. This is only to prevent one person running multiple free accounts under variations of the same address — using a separate or "+" address for a genuine ownership change is completely fine. + +The unique-email requirement, and the "+" alias approach above, are only intended for a genuine ownership change on a single account. Using "+" sub-addressing to register multiple Cloud 66 accounts under variations of the same address isn't permitted — it's treated as abuse and can lead to account suspension. For a legitimate handover you have nothing to worry about. ## Option 3: Transfer the applications to another account From 5692448269869996242f1b06835ef33bd25713e7 Mon Sep 17 00:00:00 2001 From: Vic van Gool Date: Wed, 20 May 2026 09:15:43 +0100 Subject: [PATCH 7/8] Apply PR review round 4: delete-disposable-account path, abuse wording, humanize MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Drop the "no support ticket required" clause from the overview. - Option 1: add the path for when the target email exists but has nothing worth keeping — log in as that user, delete the account, then rename. - Option 2: scope it to the case where the existing email has applications or history worth keeping. - Rewrite the "Preventing abuse" callout per reviewer wording (multiple emails per user is for genuine management on paying accounts; free-account multiplication is abuse and can lead to suspension without warning). - Humanize the Option 3 closing sentence (drop "well-trodden, safe process" and the double em-dash). Linear: SUP-1018 Co-Authored-By: Claude Opus 4.7 (1M context) --- account/change-owner.mdx | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/account/change-owner.mdx b/account/change-owner.mdx index d92ec05..9336f86 100644 --- a/account/change-owner.mdx +++ b/account/change-owner.mdx @@ -8,29 +8,29 @@ Every Cloud 66 account has a single **owner** — the user with maximum permissi There's no dedicated "transfer owner" button in the Dashboard, but you can achieve the same result in one of three ways. The first two simply change the email and login identity on the existing account and take a moment to do yourself; the third moves your applications to a separate account and is mainly useful when the new owner wants a completely separate account of their own. Work through them in order and use the first one that fits. -In every case the change is made by the **current account owner**, and there's no support ticket required for the email-based options. A prospective new owner can't initiate the change themselves, since it's tied to whoever currently controls the account — so if you're not the current owner, ask them to make the change. +In every case the change is made by the **current account owner**. A prospective new owner can't initiate the change themselves, since it's tied to whoever currently controls the account — so if you're not the current owner, ask them to make the change. ## Option 1: Rename the account's email address If the email the new owner wants to use isn't already registered with Cloud 66, the current owner can simply change the account's email address to it under *Account Settings* (click your avatar, top-right → *Account Settings*). The account and all of its applications stay exactly as they are — only the login and contact identity changes. This is the simplest option, so try it first. -The only requirement is that the new email address isn't **already in use by another Cloud 66 account** — each account needs its own unique email address. +The only requirement is that the new email address isn't **already in use by another Cloud 66 account** — each account needs its own unique email address. If that email already exists as a Cloud 66 account but doesn't have any applications or history worth keeping, you can log in as that user and [delete the account](/:product/:version?/account/account-management#closing-your-account), which frees the email up for the rename. ## Option 2: Use another email under your control -If the new owner's main email is already registered with Cloud 66 (so Option 1 won't work), use a **different email address they control** instead. Any address that reaches them works — and the current owner changes the account's email to it under *Account Settings*, exactly as in Option 1. +If the new owner's main email is already registered with Cloud 66 and includes applications or history you want to keep (so Option 1 won't work), use a **different email address they control** instead. Any address that reaches them works — and the current owner changes the account's email to it under *Account Settings*, exactly as in Option 1. If they don't have a spare mailbox to hand, there's a handy trick: most mail providers support "+" sub-addressing, so an address like `newowner+project@example.com` still lands in the `newowner@example.com` inbox while counting as a distinct address on Cloud 66. Gmail, Fastmail, and Microsoft 365 support this; some corporate mail systems don't. -The unique-email requirement, and the "+" alias approach above, are only intended for a genuine ownership change on a single account. Using "+" sub-addressing to register multiple Cloud 66 accounts under variations of the same address isn't permitted — it's treated as abuse and can lead to account suspension. For a legitimate handover you have nothing to worry about. +Having multiple emails owned by the same user is intended for genuine ownership management on paying accounts. Registering multiple free Cloud 66 accounts via different email variations isn't permitted — it's treated as abuse and can lead to account suspension without warning. ## Option 3: Transfer the applications to another account If the new owner would rather have a completely separate account of their own, you can transfer your applications across to it instead, one at a time. This is a self-service flow — see [Transferring application ownership](/:product/:version?/account/application-transfer) for the requirements and steps. -It involves a few more steps than the email options, because moving applications between accounts also moves things like billing, DNS and failover groups, backups, server agents, and cloud-credential mappings (for example, the destination account needs access to the same cloud credentials as the existing servers). It's a well-trodden, safe process — just a little more hands-on — so it's usually worth trying the email options first. +It involves a few more steps than the email options, because moving applications between accounts also moves things like billing, DNS and failover groups, backups, server agents, and cloud-credential mappings (for example, the destination account needs access to the same cloud credentials as the existing servers). Plenty of people do this without trouble; there are just more moving parts, so the email options are usually the easier place to start. ## How to make the change From 15bd79d12a05692bbfd3ad44ddf4d73cdcb0a5cf Mon Sep 17 00:00:00 2001 From: Vic van Gool Date: Wed, 20 May 2026 09:22:37 +0100 Subject: [PATCH 8/8] Apply PR review round 5: note plan match, simplify Option 3 closing - Add "and the account plans need to match too" to the application-transfer constraints. - Reword the closing line to the reviewer's phrasing. Linear: SUP-1018 Co-Authored-By: Claude Opus 4.7 (1M context) --- account/change-owner.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/account/change-owner.mdx b/account/change-owner.mdx index 9336f86..49297d8 100644 --- a/account/change-owner.mdx +++ b/account/change-owner.mdx @@ -30,7 +30,7 @@ Having multiple emails owned by the same user is intended for genuine ownership If the new owner would rather have a completely separate account of their own, you can transfer your applications across to it instead, one at a time. This is a self-service flow — see [Transferring application ownership](/:product/:version?/account/application-transfer) for the requirements and steps. -It involves a few more steps than the email options, because moving applications between accounts also moves things like billing, DNS and failover groups, backups, server agents, and cloud-credential mappings (for example, the destination account needs access to the same cloud credentials as the existing servers). Plenty of people do this without trouble; there are just more moving parts, so the email options are usually the easier place to start. +It involves a few more steps than the email options, because moving applications between accounts also moves things like billing, DNS and failover groups, backups, server agents, and cloud-credential mappings (for example, the destination account needs access to the same cloud credentials as the existing servers, and the account plans need to match too). There are a number of moving parts with this process, so the above email options are usually the easier place to start. ## How to make the change