Cloudberrie Studio India LLP

Cloudberrie Wiki

Setup & Reference Guide — one-time setup, plus what comes later
WHERE IDEAS TAKE SHAPE

How to Use This Wiki

Read top to bottom — each section builds on the one before it.

Follow the order

Sequence matters

Each numbered step depends on the one before it — Workspace and domain first, then GitHub, then Cloudflare.

Staging only, for now

Nothing goes public yet

Everything in Part One creates a private staging environment. Nothing here touches your live domain.

One login to start

Shared alias, not a person

Use the accounts@cloudberrie.com alias for every new signup unless a step says otherwise — keeps ownership with the business.

Prerequisites

Three things need to already exist before any new account gets created.

+ its aliases

Google Workspace

A working Workspace account with alias addresses already configured, all routing to one shared inbox at admin@cloudberrie.com.

registered domain

cloudberrie.com

The domain is owned and its DNS is currently tied to Workspace email. Nothing in Part One changes that.

India LLP

Cloudberrie Studio

The registered legal entity. Its full name belongs on invoices, contracts, and legal pages — not shorthand.

Workspace Alias Roster

Every alias routing into admin@cloudberrie.com, and what it's for.

AliasPurpose
admin@Primary inbox — everything else routes here
hello@ / info@General / public contact
support@Client support
social@Social platform management
accounts@Third-party service signups — GitHub, Cloudflare, etc.
compliance@LLP / regulatory correspondence (MCA, GST, filings)
privacy@Data-request contact referenced in Privacy Policy pages
security@Vulnerability / security reports
postmaster@Reserved word — Google handles this automatically, no alias needed
Splitting an alias into its own mailbox Only worth doing once a specific role or person owns it independently — e.g. a CA managing compliance@ directly. Free as an alias; a real Workspace seat once split off. Do it when the trigger happens, not ahead of it.

Send Mail As — Alias Reply Setup

So a reply from hello@ actually looks like it came from hello@ — not admin@.

Every alias above correctly routes incoming mail into the admin@ inbox. Without this setting, the outgoing side has a gap: if a client emails hello@cloudberrie.com and you reply from that inbox, Gmail shows the reply as coming from admin@cloudberrie.com by default — an internal address the client never actually emailed.

What "Send mail as" actually does A client emails hello@cloudberrie.com → it lands in admin@'s inbox → your reply goes back out as hello@cloudberrie.com. The client only ever sees the address they emailed — admin@ stays invisible the whole time.

Setup — for each client-facing alias (hello@, support@, social@ at minimum):

  • Gmail → Settings → See all settings → Accounts and Import → "Send mail as"
  • Add each alias — since these are genuine Workspace aliases of the same account, Gmail adds them without needing SMTP verification
  • Enable "When replying to a message, reply from the same address it was sent to" — this is what makes it automatic, otherwise you'd pick the From address manually every time
Which aliases actually need this Worth doing for anything a client or outside party might email — hello@, support@, social@. Less urgent for internal-only aliases (accounts@, compliance@, privacy@, security@), though no harm in doing all of them for consistency.

What We're Setting Up

One shared login feeds three new accounts — each with a distinct job.

✉ accounts@cloudberrie.com

GitHub

Organization + private repo

Holds the Studio Board source code and version history.

Cloudflare

Pages + Access

Hosting for the staging site, plus Access to keep the staging URL private.

Firebase

Firestore + Auth

Already in use. Security rules deploy here — separately from Cloudflare.

Why this mattersEvery account traces back to the same Workspace alias — so ownership stays with Cloudberrie, not any one person's personal login.
1

Create the GitHub Account

github.com/signup — using the shared alias
  • Go to github.com/signup
  • Email: accounts@cloudberrie.com
  • Username: cb-engops — not cloudberrie-studio, that name is reserved for the org
  • Verify the email when it arrives
  • Immediately turn on 2FA: Settings → Password and authentication → Enable two-factor authentication
Why not name it after the studioUsernames and organization names share one namespace — this account can't be cloudberrie-studio if the org is. Keep this account role-labeled (cb-engops), not personal.
Heads upMail to the alias lands in your normal shared inbox — verification works exactly like a normal signup.
2

Create a GitHub Organization

Keeps Cloudberrie's repos separate from any personal account
  • Go to github.com/account/organizations/new
  • Choose the Free plan
  • Name it cloudberrie-studio (or similar — this becomes part of every repo URL)
  • Contact email: accounts@cloudberrie.com
Why an organization, not just your accountRepos live under github.com/cloudberrie-studio instead of a personal username — clean to hand off or add teammates to later, without sharing a personal login.
3

Create the Repository

Inside the new organization
  • github.com/organizations/cloudberrie-studio/repositories/new
  • Name: cloudberrie-studio-board
  • Visibility: Private
  • Leave README, .gitignore, and license unchecked
  • Click Create repository
Why leave those uncheckedYou already have files locally. Starting the GitHub repo empty avoids a merge conflict on the very first push.
4

Push the Code

From a terminal, inside the project folder
git init
git add .
git commit -m "Initial commit: Cloudberrie Studio Board"
git branch -M main
# swap in your actual org/repo URL
git remote add origin https://github.com/cloudberrie-studio/cloudberrie-studio-board.git
git push -u origin main
First pushIt'll prompt for authentication — a browser popup is the easiest path. If git isn't recognized at all, install it from git-scm.com first.
5

Create the Cloudflare Account

dash.cloudflare.com/sign-up
  • Go to dash.cloudflare.com/sign-up
  • Email: accounts@cloudberrie.com
  • Verify the email
  • Turn on 2FA: My Profile → Authentication → 2FA
One account, not twoIf a Cloudflare account for the public site is ever created later, this should be the same account — one dashboard, one shared DNS zone, simpler billing.
6

Deploy to Cloudflare Pages

This becomes the staging URL
  • Workers & Pages → Create → Pages → Connect to Git
  • Authorize Cloudflare's GitHub App
  • Select the organization, then cloudberrie-studio-board
Build settingValue
Framework presetNone
Build command(leave blank)
Output directory/
ResultCloudflare gives you a working URL immediately — cloudberrie-studio-board.pages.dev. No domain, no DNS, nothing that can touch Workspace email.
7

Lock the Staging URL

The .pages.dev link is public by default — this closes it
  • Pages project → Settings → General → Access policy (or Zero Trust → Access → Applications)
  • Add a rule: only allow emails ending in @cloudberrie.com
  • Free for up to 50 users
Why bother for stagingAnyone with the link can open an unprotected .pages.dev URL. This adds a second gate — real email + one-time code — in front of the app's own login.
8

Deploy the Firestore Rules

A separate step — Cloudflare never touches this
  • Open Firebase Console → your project → Firestore Database → Rules
  • Paste the contents of firestore.rules from the repo
  • Publish
Easy to forgetCloudflare Pages only ships the static site — it has no idea firestore.rules exists. Security rules only take effect once pasted into Firebase directly.

Studio Board: Staging Now, Production in ~10 Days

Everything above only creates the staging environment. Nothing here is public.

Live today

Staging Environment

  • GitHub organization + private repo
  • Cloudflare Pages deployment (.pages.dev URL)
  • Cloudflare Access — @cloudberrie.com only
  • Firestore security rules published
  • Full app, real data model, isolated from the public
In ~10 days

Production Go-Live

  • Bring cloudberrie.com's DNS into Cloudflare (see Part Two — this unlocks subdomains)
  • Add board.cloudberrie.com as this project's Custom Domain
  • Walk DNS through carefully — Workspace email must not break
  • Re-check whether the Access policy stays on for production

Studio Board — Quick Reference Checklist

Tick these off as you go — this list is interactive. The finish line for the one-time setup.

Ongoing — What Comes Later

The Multi-Property Roadmap

cloudberrie.com · Studio Board · EventLumi · NeedleNeeds · AIFA · Khushi Marriage Bureau

Where Everything Actually Deploys

One Cloudflare account. One DNS zone per domain. Studio Board is not on the root domain.

🌐 cloudberrie.com

Public marketing site — fully open, no Access gate

🛡 board.cloudberrie.com

Studio Board — gated by Cloudflare Access, @cloudberrie.com only

Same DNS zone · Two Pages projects · Different access posture

The dependency this createsboard.cloudberrie.com can only exist once cloudberrie.com's DNS lives in Cloudflare. That migration is step one, technically — not just first by priority.

The same pattern repeats for every property: one Cloudflare account, one Pages project per site, its own DNS zone once its domain is added.

Properties Register

Every Cloudberrie-owned property, in one place — update this table as things change.

PropertyDomainStatusDomain Risk
cloudberrie.comcloudberrie.comLive, v2.16High — live Workspace email
Studio Boardboard.cloudberrie.comIn progress (this guide)Depends on cloudberrie.com
EventLumiseparate domainPrototype completeUnknown — TBD
NeedleNeedsneedleneeds.comLive, mature businessHighest — live email + trademark
AIFATBDEarly basicsUnknown
Khushi Marriage Bureaukhushimarriagebureau.comDomain onlyLow — newly registered

Deployment Sequence & Dependencies

Priority order — with the one real technical dependency called out.

1
cloudberrie.com
Highest-risk DNS migration first — live email on the line. Full record export before anything else.
2
Studio Board
Unlocked once cloudberrie.com's DNS lands in Cloudflare — board.cloudberrie.com becomes addable.
3
EventLumi
Prototype-ready. Provisioning (repo, Pages project) can start now; domain go-live waits its turn.
4
NeedleNeeds
Mature, live, trademarked — needs its own careful plan before this slot arrives. See DNS Migration Checklist.
5
AIFA
Early basics only — sequence has room to firm up before this becomes urgent.
6
Khushi Marriage Bureau + rest
Later batch. Newly registered domain — lowest migration risk of the group.

DNS Migration — Do This Every Time

Before any domain's nameservers move to Cloudflare, in this order.

  • Export MX records — email delivery breaks first and silently if missed
  • Export SPF, DKIM, DMARC — email authentication; missing these hurts deliverability even if MX is right
  • Export every TXT verification record — Search Console, Formspree, other third-party tools
  • Export existing A/CNAME records — anything currently pointing subdomains elsewhere
  • Only then change nameservers at the registrar
Highest risk in this list

NeedleNeeds — long-standing live email, a trademarked logo, and likely an existing payment/vendor setup. Treat this as the most delicate migration in the whole roadmap.

Lowest risk — safe to go first for practice

Khushi Marriage Bureau — newly registered, no email or traffic history yet to protect.

Tech Stack by Property

What's confirmed, and what's still an open question.

PropertyFrontendHostingBackend
Studio BoardVanilla JS + TailwindCloudflare PagesFirebase (Firestore + Auth)
cloudberrie.comStatic HTML/CSS/JSCloudflare Pages—
EventLumiNext.jsCF Pages + next-on-pages adapterFirebase
AIFANext.jsCF Pages + next-on-pages adapterFirebase
NeedleNeedsOPEN QUESTIONOPEN QUESTIONOPEN QUESTION
Khushi Marriage BureauNot yet decidedNot yet decidedNot yet decided
NeedleNeeds — the real open questionIt's live and mature, so it's already running on something. Whether that means bringing its DNS into Cloudflare as-is, or a full Next.js rebuild, is an unresolved, materially different decision — not yet made.

One Shared Account, One Shared Blast Radius

Whoever controls the Cloudflare account controls DNS for every property in it — not just one.

  • cloudberrie.com's DNS
  • Studio Board's staging/production access
  • EventLumi's DNS, once added
  • NeedleNeeds's DNS — a live, revenue-generating business
  • Every future property added to this account
2FA on this account is the single most important checkbox in this entire guide.

Open Decisions & Known Risks

Named on purpose, so nothing here gets assumed later.

Open decisions
NeedleNeeds: infra-only DNS move, or full Next.js rebuild? Materially different projects.
EventLumi's domain history — newly registered, or does it carry existing email/traffic?
AIFA's domain — not yet identified.
Registrar login access — who can actually change nameservers, per domain?
Known risks
Studio Board still has no data-layer Firestore enforcement, no scheduled backups, no automated tests — more consequential now that real money and more properties sit on the same foundation.
Bus-factor: everything currently routes through one person's control of the Workspace admin inbox.
Provisioning ahead of readiness — half-set-up properties are their own risk.
Per-project usage alerts needed once multiple Firebase projects share one billing account.