git / moonbite-network / deploy/LAUNCH_CHECKLIST.md · raw

# MoonBite Launch ChecklistLiving launch tracker. Update the status boxes as work lands. Companion docs:`RUNBOOK.md` (VPS route), `railway-node/DEPLOY.md` (Railway route)._Last updated: 2026-07-16_---## Launch readiness (RAG)| Workstream | Status | Notes ||---|---|---|| Website | 🔴 Not live | `moonbite.org` A record → 192.64.117.55 (Namecheap Stellar) serves an unrelated parked site. Must repoint DNS → DO VPS and deploy `web_app` (see "moonbite.org hosting" below). || Deploy tooling (Railway kit) | 🟢 Done | `deploy/railway-node/` on `main` || Qt / client rebrand | 🟡 Amber | Committed in source; not yet in shipped binaries || Live seed node | 🔴 Red | No node exists yet || Chain liveness | 🔴 Red | Height 0 until a miner runs |> **Perception risk:** the website is live, so visitors will assume the network> is live. Closing the node/liveness gap is the critical path.---## Definition of Done — "MoonBite is live"- [ ] Node reachable on public P2P 9444, block height increasing- [ ] A second machine syncs from the seed (`bigcoin-cli addnode <ip>:9444 onetry`)- [ ] Explorer serves real chain data (no demo banner)- [ ] Website links to the live explorer- [ ] **Owner-only:** minisign release-signing key ceremony done and `deploy/moonbite-release.pub` replaced (see BRANCH-PROTECTION.md / RELEASE-SIGNING.md) — still OPEN; never generated by automation---## Critical path (risk-first sequence)Highest-uncertainty item is scheduled first: the node blocks everything else andis the least-proven piece.### 1. Node spike (timeboxed) — 🔴 not started- [ ] Deploy `moonbite-node` on Railway (Root `/`, Dockerfile `deploy/railway-node/Dockerfile`)- [ ] Attach Volume mounted at `/data`- [ ] Set `BIGCOIN_RPC_USER`, `BIGCOIN_RPC_PASSWORD`, `MINE=1`- [ ] Enable TCP Proxy on **9444 only**- [ ] **Success gate:** deploy logs show height rising- [ ] **Fail gate:** if the Railway container can't sustain it → pivot to VPS (`RUNBOOK.md`)### 2. Explorer wiring — 🔴 blocked on #1- [ ] Deploy `moonbite-explorer` (Root `explorer`)- [ ] Vars: `BIGCOIN_RPC_HOST=moonbite-node.railway.internal`, port 9445, same creds- [ ] Vars: `BIGCOIN_NAME=MoonBite`, `BIGCOIN_TICKER=MBITE`- [ ] Generate public domain- [ ] **Success gate:** real block/tx/search data, no demo banner### 3. Network durability — 🔴 blocked on #1- [ ] Stand up a **second** seed node (removes single point of failure)- [ ] Confirm cross-node sync### 4. Finalize (fast-follow, NOT critical path) — ⚪ deferred- [ ] Bake seed(s) into `vSeeds`/`vFixedSeeds` (`src/chainparams.cpp`)- [ ] Rebuild `moon1` binaries; refresh `release/SHA256SUMS`- [ ] Add live explorer link to the website---## Risk register| # | Risk | Prob | Impact | Mitigation | Owner ||---|---|---|---|---|---|| R1 | Railway node can't sustain P2P / CPU load | High | High | VPS is real home; Railway = bootstrap only | You || R2 | Volume not mounted → chain wiped on redeploy | Med | High | `/data` volume is step 1, not optional | You || R3 | RPC 9445 exposed publicly | Low | Critical | Only 9444 gets the TCP proxy | You || R4 | `big1` binary shows old address prefixes | High | Low | Cosmetic; rebuild `moon1` in step 4 | You || R5 | Single seed = single point of failure | High | Med | Add 2nd seed before public promotion (step 3) | You |---## Scope guardrailDo **not** pull the `moon1` binary rebuild (step 4) into the launch criticalpath. It is cosmetic (address-prefix display only) and network-compatible withthe shipped `big1` build. Bundling it in just delays a reachable network for nofunctional gain — ship it as a fast-follow.---## moonbite.org hosting (marketing site / dashboard)Target: serve `web_app:app` (Flask) from the DigitalOcean VPS behind nginx +Let's Encrypt. The Railway service stays the **node/explorer**; only thewebsite moves here.**Prerequisite — get the new code onto GitHub.** The deploy `git clone`s from`moonbitecoin/moonbite-network`. The local repo shares **no history** with`origin/main` (9 remote commits vs 7 local, no merge-base), so a plain push isrejected and force-push would destroy the remote. Reconcile deliberately (e.g.graft local work onto a branch off `origin/main`, or open a fresh branch/PR).**Never force-push `main`.** Until this lands, the VPS clone serves old code.1. **DNS (Namecheap → Advanced DNS):** change the `@` A record for   `moonbite.org` from `192.64.117.55` → **the DO droplet's public IP**; add a   `www` A record to the same IP (or CNAME `www` → `moonbite.org`). Drop the   Namecheap Stellar/parking records. TTL low (5 min) during cutover.2. **Deploy the app (root on the VPS):**   `curl -fsSL https://moonbite.org/git/moonbite-network/raw/deploy/setup-dashboard.sh | bash`   (installs venv from `requirements-web.txt`, gunicorn `web_app:app` on   127.0.0.1:8050, nginx :80). Verify: `curl -sf http://127.0.0.1:8050/`.3. **HTTPS (after DNS resolves to the VPS):**   `DOMAIN=moonbite.org bash deploy/setup-https.sh` — issues a cert for both   `moonbite.org` and `www.moonbite.org` and forces the HTTPS redirect.4. **Verify live:** `https://moonbite.org/` shows the cinematic home;   `/mine` offers the Reactor download; `/downloads/...zip` serves the real file.