Add account-owner change doc (three approaches) by lvangool · Pull Request #18 · cloud66/help-content

lvangool · 2026-05-20T06:43:24Z

Summary

Adds a standalone page account/change-owner.mdx documenting how to change who owns a Cloud 66 account.
Adds a cross-link from the owner mention in account/team-accounts.mdx.

Cloud 66 has no "transfer owner" button and no support-side role swap — the change is self-service and always carried out by the current account owner. The doc presents three approaches, in order of preference:

Rename the account's email to the new owner's address (Account Settings) — when that email isn't already registered with Cloud 66. If a disposable account already holds it, delete that account to free the email.
Use another email the new owner controls — when their main email already has applications or history worth keeping; includes the + sub-addressing trick.
Transfer the applications to another account — when the new owner wants a fully separate account of their own; requires matching cloud credentials and plan. Demoted to last as the more involved option.

A "Preventing abuse" note explains the unique-email rule (it exists to stop multiple free accounts; legitimate handovers are fine).

Why

On HS #33567 a customer asked how to change the account owner. The first draft wrongly claimed support "reassigns the owner role" — that operation doesn't exist. The correct self-service, current-owner-driven picture was confirmed by the founder during review (the customer ultimately renamed the owner account to another email they controlled).

Linear

SUP-1018
Originating ticket: HS #33567

Test plan

Note: this content repo has no CI/test suite of its own. Validation is performed by the site repo (help-cloud66-com), which consumes this content as the src/docs submodule and runs these checks in build:with-validation. Run against the PR branch:

validate:mdx — all 372 MDX files pass (change-owner.mdx + team-accounts.mdx parse cleanly: frontmatter, JSX/Callout well-formed)
validate:links --skip-anchors — all internal links valid (after the build's generate:known-paths step, which the new page requires)
validate:smart-links — all placeholders well-formed
Option/constraint accuracy (self-service paths, cloud-credential + plan requirements, abuse rule) confirmed with the founder during review
Optional: visual render check in a deploy preview (Callouts + role table display)

🤖 Generated with Claude Code

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) <noreply@anthropic.com>

linear · 2026-05-20T06:43:27Z

SUP-1018

…mitive 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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

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) <noreply@anthropic.com>

…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) <noreply@anthropic.com>

…g, humanize - 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) <noreply@anthropic.com>

- 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) <noreply@anthropic.com>

lvangool changed the title ~~Add account-owner transfer doc~~ Add account-owner change doc (three approaches) May 20, 2026

lvangool commented May 20, 2026

View reviewed changes