Skip to content

Migrate the publisher account

This page describes how to move the publisher assets from one GitHub account to another — for example, from the personal suchahit account to a company-owned organization. Customers and their repositories are not affected by this migration; only the publisher-owned production plumbing moves.

Read this first. GitMCloud and GitM have hard-coded references to the current publisher account (suchahit) and domain (gojain.com) in several places. Missing one will silently break sign-in, the access gate, or supplier downloads. Work the checklist in order and verify at the end.

What moves (and what breaks if you skip it)

Asset Where it lives now Breaks if not migrated
Code repos GitM, GitMCloud github.com/suchahit/* Nothing immediately; future builds/deploys still point at the old repo
Vercel project Vercel account/team The whole web app
Firebase project (Firestore + RTDB) Google account Supplier Exchange + live icon refresh
GitHub OAuth App suchahit developer settings "Sign in with GitHub" button
Supplier Exchange GitHub App suchahit developer settings Supplier downloads from private repos — customers must re-install the new App
ALLOWED_OWNERS allowlist Vercel env var Onboarding gate (fail-closed → nobody connects)
Custom domain gojain.com DNS provider Public URL + all baked-in links
Installer publisher URLs GitM.iss Cosmetic, but "Publisher" + update links point at the old account

Migration checklist

1. Transfer (or re-create) the code repositories

  • Transfer suchahit/GitM and suchahit/GitMCloud to the new organization, or create fresh repos under the org and push.
  • Update every local clone's git remote set-url origin ….
  • Decide whether GitHub should keep redirects from the old paths (transfers do; re-creates don't).

2. Re-point the installer

In GitM.Installer/GitM.iss update the publisher URLs to the new org:

  • AppPublisherURL → https://github.com/<new-org>/GitM
  • AppSupportURL → https://github.com/<new-org>/GitM/issues
  • AppUpdatesURL → https://github.com/<new-org>/GitM/releases

Then rebuild the installer — see Create the installer exe.

3. Move the Vercel project

  • Either transfer the project to the new org's Vercel team, or import the (now org-owned) GitMCloud repo into a Vercel project under the org.
  • Re-create all environment variables (they do not transfer with a fresh import): ALLOWED_OWNERS, FIREBASE_SERVICE_ACCOUNT, VITE_GITHUB_CLIENT_ID, VITE_FIREBASE_RTDB_URL, and (if used) APS_CLIENT_ID / APS_CLIENT_SECRET.
  • See Deploy GitMCloud for the full variable reference.

4. Migrate Firebase

You can either transfer the existing Firebase project to a new Google account/organization (simplest — keeps all data and URLs), or create a new project and migrate data:

  • If creating new: enable Firestore (Native mode) and Realtime Database, generate a new service account key, and set FIREBASE_SERVICE_ACCOUNT + VITE_FIREBASE_RTDB_URL in Vercel.
  • Migrate Firestore collections:
  • exchangeInstalls — GitHub App installation IDs keyed by owner. Critical — if this is lost, all supplier share links stop resolving until each customer re-installs the App.
  • exchangeTokens — legacy per-repo service tokens (old model, kept as fallback). Safe to migrate or leave behind; the GitHub App path takes precedence.
  • config/allowlist — the allowlist, if you moved it to Firestore (otherwise it's the env var).
  • shareThrottle — brute-force throttle (transient; safe to drop, but re-add the TTL policy on field deleteAt in the new project).
  • Re-publish the Realtime Database rules from database.rules.json.

If exchangeInstalls is lost, customers must re-install the GitMCloud Exchange GitHub App once (Settings → Exchange → Install). Their share links resume working immediately after.

5. Re-register the GitHub OAuth App

OAuth Apps cannot be transferred between accounts — register a new one under the org:

  • Follow Register the GitHub apps → OAuth App.
  • Set the new Client ID as VITE_GITHUB_CLIENT_ID in Vercel and redeploy (it's baked in at build time).

6. Re-register the Supplier Exchange GitHub App

GitHub Apps also don't transfer between accounts — re-create one under the new org:

  • Follow Register the GitHub apps → Supplier Exchange GitHub App.
  • Set the new Setup URL to https://<new-domain>/api/exchange-setup (only differs if the domain changes) and check Redirect on update.
  • Generate a new private key and update GITHUB_APP_ID, GITHUB_APP_CLIENT_ID, and GITHUB_APP_PRIVATE_KEY in Vercel (no redeploy needed — runtime variables).
  • Every existing customer must re-install the new App once (Settings → Exchange → Install). The old exchangeInstalls IDs belong to the old App and won't work with the new App's key.

This is the one migration step that requires action from each customer, not just the publisher. Plan to notify customers: until they re-install, their supplier share links return "Supplier exchange is not active." Re-installing takes one click and fixes it immediately.

7. Move the domain

  • Point gitmcloud.gojain.com (or a new domain) at the new Vercel project: add the domain in Vercel → Settings → Domains and update the CNAME at your DNS provider.
  • If the domain itself changes, update the deployment URLs. They are centralized — you do not hunt through the code:
What Where How
GitMCloud post-install redirect — Automatic — derived from the request host; no change needed
GitMCloud Help link VITE_DOCS_URL env var in Vercel Set it, then redeploy (baked into bundle)
GitM add-in URLs (cloud, docs, RTDB) GitM.Core/Configuration/DeploymentConfig.cs Edit the constants, rebuild the add-in + installer
Docs site URL mkdocs.yml → site_url Edit and rebuild the docs
OAuth App + Exchange App URLs GitHub App/OAuth settings Update Homepage / callback / Setup URL

8. Update hard-coded account references

Search both repos for the old account/domain and update as needed:

  • suchahit — installer publisher URLs (GitM.iss), ALLOWED_OWNERS examples in docs, sample links.
  • gojain.com — the items in the table above; the .md docs (which intentionally name the live domain) can be left or find/replaced for accuracy.

Note: ALLOWED_OWNERS lists customer Owners, not the publisher. Migrating the publisher account does not change which customers are allowed — but double-check the value carried over.

Verify after migration

  • https://gitmcloud.gojain.com (or the new domain) loads the app.
  • "Sign in with GitHub" appears and completes (new OAuth client ID is live).
  • An allowlisted customer can connect; a non-listed owner is blocked (fail-closed).
  • A supplier share link resolves and downloads (Firestore data + token present).
  • The GitM add-in's first-run wizard reaches the access check (add-in GitMCloudBaseUrl correct).
  • A freshly built installer shows the new publisher and update URLs.

Notes

  • VITE_* variables are compiled into the bundle — always redeploy after changing them.
  • The allowlist is fail-closed: an empty/missing ALLOWED_OWNERS locks everyone out, including you. Set it before announcing the new deployment.
  • Keep the old deployment running until the new one is verified, then cut DNS over last.