Plan — finishing the cloudbase.foundation rebrand (mail + web redirect)

Date: 2026-06-25 · Owner: Both (Jonathan = Admin console + Cloudflare DNS; Claude = repo edits + DNS drafting + verification) · Status: New — supersedes the open items in the 06-09 rebrand docs Companions: 2026-06-09-workspace-domain-rebrand-design.md, 2026-06-09-workspace-domain-rebrand-dns-records.md

Why this doc

The CRM is now live in production (Phase 2 integration). The Google Workspace mail rebrand to cloudbase.foundation is partly done but unfinished. This reconciles the 06-09 plan against verified live state on 2026-06-25 and sequences only what remains. Decision from this session: we are not building the GAM / Workspace-admin tooling to finish this — the email setup is completed with plain DNS + repo edits + a few manual Admin-console clicks. The 2026-06-09-workspace-admin-audit-design.md (GAM-on-cbf-dev, blocked on 2SV) is a separate track, formally set aside here; nothing below depends on it.

Verified live state (DNS, 2026-06-25)

New domain cloudbase.foundation — mail is fully live (Phase 1 complete):

The golden rule (new-domain mail stood up before the flip) is satisfied — @cloudbase.foundation addresses already send and receive today.

Old domain thecloudbasefoundation.org — §B gap-fill was never applied:

DNS hosting (verified 2026-06-25, corrects the 06-09 docs):

• cloudbase.foundation → Cloudflare (coen/edna.ns.cloudflare.com). Web served via Cloudflare (the OpenNext Worker).
• thecloudbasefoundation.org → Namecheap (dns1/dns2.registrar-servers.com); old website is on Squarespace (apex → Squarespace IPs, www → ext-cust.squarespace.com). The 06-09 docs assumed the old domain was on Cloudflare — it is not. All old-domain DNS edits (§A) happen at Namecheap, not Cloudflare.

Primary-domain flip: ❌ not yet done (confirmed 2026-06-25). The org is still on thecloudbasefoundation.org as primary.

Outstanding work, sequenced

A. Old-domain DNS gap-fill — at Namecheap (Jonathan, ~10 min)

Independent of the flip; closes a real deliverability gap on a domain that still carries live mail. Apply in Namecheap's Advanced DNS for thecloudbasefoundation.org (the zone is on Namecheap, not Cloudflare). Records were drafted in the companion DNS doc §B — restated:

TXT  thecloudbasefoundation.org         v=spf1 include:_spf.google.com ~all
TXT  _dmarc.thecloudbasefoundation.org  v=DMARC1; p=none; rua=mailto:dmarc@cloudbase.foundation; fo=1

Keep the existing google-site-verification=7CC_… TXT alongside the new SPF. DKIM (§B-3) optional — generate in Admin console and publish google._domainkey.thecloudbasefoundation.org if we want it. Claude verifies with dig after Jonathan applies.

Sequencing note: if we take the §E Cloudflare-migration redirect option (move the old domain's nameservers to Cloudflare), don't add these at Namecheap first — recreate the full record set (Google MX, SPF, DKIM, DMARC, google-site-verification) in Cloudflare during that migration, adding SPF + DMARC there once. If we keep the old domain on Namecheap (§E Namecheap or Squarespace option), apply A now.

B. Primary-domain flip — Jonathan, when ready

Admin Console → Account → Domains → Manage domains → Change to a different primary domain → cloudbase.foundation. ~24 h propagation; each user re-signs-in once; old address auto-becomes a lifelong alias. Do A first (and ideally the kan/OAuth dual-domain prep in C) so no one is locked out mid-flip.

C. Downstream string/config updates — re-scoped (the 06-09 doc mis-framed these)

A grep proves none of the remaining old-domain references are mailbox addresses. They split into three real, separate decisions:

1. CBF-site outbound legacy-site links (6 refs) — www.thecloudbasefoundation.org/{bod, documents, start-a-project, current-projects-3} in Footer, contact, about, get-involved, past-projects. These point out to the old Squarespace site. Decided 2026-06-25: the old domain is being redirected to the new site (see §E), so the legacy site is going away. Once §E is live these links still resolve (via 301), but they should be re-pointed directly to the new-site equivalents to avoid a redirect hop to a path the new site doesn't have. The new site has no exact match for these paths, so this needs a small mapping decision — proposed: /bod→/about (or /contact), /start-a-project→/get-involved, /current-projects-3→/past-projects, /documents→TBD (the future board.cloudbase.foundation space, or drop). Claude does this CBF-site branch once the mapping is confirmed. Dependent on §E, not on the mail flip.
2. CBF-site contact web-address display (1 ref) — <span>thecloudbasefoundation.org</span>. Clean rebrand → cloudbase.foundation. Safe; bundle into the same CBF-site branch as (1) once decided. (The 8 root *.html files are the pre-migration static site — ignore per CBF-site CLAUDE.md.)
3. kan prod hostname + docs (kan repo + 4 doc files) — kan.thecloudbasefoundation.org in CBF-kanban/.env.example, README.md, nginx/kan.conf, and the descriptive prose in documents/tech/{domain-map,roadmap}.html + CBF-crm/docs/strategy/*. These encode the kan prod URL host and the OAuth allowed-domain, both Phase 3 decisions (does kan prod become kan.cloudbase.foundation, and does the Better-Auth allowed-domain move to cloudbase.foundation?). The docs prose updates only after the actual config/OAuth change lands. Recommend allowing both auth domains during the transition window.

Also in Phase 3, independent of strings: Google Cloud OAuth consent screen + kan client authorized-domain/redirect-URI updates (Jonathan). Twenty CRM: sign-in stays email/password for now (decided 2026-06-25) — so the primary-domain flip does not require touching workspace-member emails; revisit only if Google SSO is enabled later.

D. Comms & cleanup — after the flip (Phase 4)

Team notice (new primary, one-time re-sign-in, update signatures); update sender addresses on GiveLively / Donorbox / social (old still works as alias). Keep thecloudbasefoundation.org as a permanent alias — never remove.

E. Web redirect — old Squarespace site → new site (Jonathan)

Decided 2026-06-25: thecloudbasefoundation.org (apex + www) will 301-redirect to https://cloudbase.foundation, retiring the old Squarespace site. The old domain stays a permanent mail alias, so this is an HTTP/host-record change only.

⚠️ Do NOT touch the mail records. Leave the Google MX (smtp.google.com), the new SPF/DMARC from §A, any DKIM, and the google-site-verification TXT exactly in place. The redirect only changes the apex A / www web host — email must keep flowing to Google.

Option 1 — Namecheap URL Redirect (recommended; free, no Squarespace, no NS move). In Namecheap → Domain List → thecloudbasefoundation.org → Advanced DNS:

1. Remove the Squarespace web records — the four apex A records (198.49.23.144/145, 198.185.159.144/145) and the www CNAME → ext-cust.squarespace.com. Leave every MX/TXT record.
2. Add a URL Redirect Record: Host @ → https://cloudbase.foundation, type Permanent (301), Unmasked. Add a second for Host www → same target.
3. Namecheap forwarding drops the path, so deep links (/bod etc.) land on the new homepage — acceptable; CBF-site's own links get re-pointed to real pages per §C-1.
4. Cancel the Squarespace subscription once the redirect is confirmed live.

Option 2 — Squarespace-native redirect (only if keeping Squarespace). Configure domain forwarding / URL redirects in Squarespace settings. Avoids DNS edits but keeps a paid subscription alive solely to serve a redirect — not recommended.

Option 3 — Move the old domain to Cloudflare + Redirect Rule (heaviest; most control). Repoint nameservers to Cloudflare, recreate the entire record set (MX, SPF, DKIM, DMARC, site-verification — see §A sequencing note), set apex/www to a proxied placeholder, then add a 301 Redirect Rule with optional per-path mapping (/bod→/about, /start-a-project→/get-involved, etc.). Choose this only if we want path-level redirects or want both domains under one Cloudflare account.

Verify (Claude): curl -sI http://thecloudbasefoundation.org and …/www… → expect 301 → https://cloudbase.foundation; re-check dig MX/TXT to confirm mail records survived.

Immediate next actions

• Jonathan: choose the §E redirect option (recommend Option 1) and apply it at Namecheap; apply §A at Namecheap (skip if going §E Option 3 — fold into that); decide flip timing for B.
• Claude: verify A and E once applied (dig / curl -I); on a confirmed §C-1 path mapping, do the CBF-site branch (re-point legacy links + the contact display string cloudbase.foundation together); prep kan dual-domain config when the flip window is set.