The QDay ecosystem's community wiki — guides for users and developers, covering QDay and the QDay Aevum launch. Built with Docusaurus (migrated from VitePress) so pages can embed live, interactive web3 widgets (add-network, faucet, balances) alongside normal Markdown.
npm install
npm start # dev server at http://localhost:3000
npm run build # static build -> ./build
npm run serve # preview the production builddocs/
intro.md landing intro
start/ get started (add network, faucet - interactive)
guide/ user guides (metamask, staking, swap, bridge, wallet, whitepaper)
migration/ QDay -> QDay Aevum migration (interactive)
reference/ chain params, token list, contract addresses
src/
pages/index.tsx branded landing hero
components/QDay/ interactive widgets (AddNetworkButton, FaucetWidget, BalancePanel, LiveChainStatus)
static/ images + assets (served at site root)
Most pages are plain Markdown (.md) - same as before. Only pages that embed an interactive
widget use .mdx (Markdown + a React component import). Search is local/offline (no Algolia).
How to add pages, nested sidebar categories, _category_.json, and English / 繁體中文: AUTHORING.md. PM / Ops GitHub-web editing: CONTENT-GUIDE.md.
- Add a page: drop a
.mdfile underdocs/<section>/- it appears in the sidebar automatically. - Add an interactive widget: name the file
.mdx,importthe component, drop<Component />in. - Images: put them under
static/and reference with an absolute path (/qday/...).
Two environments:
| Environment | Host | How |
|---|---|---|
| Test / staging | Docker on our server | GHCR image ghcr.io/qday-io/qday-wiki + deploy/ (compose + redeploy.sh). Built on push to main by .github/workflows/publish-image.yml; the server pulls + recreates. |
| Production | Cloudflare Pages (project qday-community) |
GitHub Actions builds the Docusaurus site and publishes it via cloudflare/pages-action (.github/workflows/deploy.yml). |
ci.yml build-checks every PR and push to main, so both paths start from a green build.
- Create the Pages project — Cloudflare dashboard → Workers & Pages → Create →
Pages → Direct Upload, name it exactly
qday-community(must matchprojectNameindeploy.yml). - Create an API token — My Profile → API Tokens → Create Token → template Edit Cloudflare Workers, or a custom token with Account → Cloudflare Pages → Edit. Copy it.
- Get the Account ID — any account/domain overview page → Account ID.
- Add both as GitHub repo secrets — Settings → Secrets and variables → Actions:
CLOUDFLARE_API_TOKENCLOUDFLARE_ACCOUNT_ID
Once the secrets exist, uncomment the push trigger in
.github/workflows/deploy.yml:
on:
workflow_dispatch: {}
push:
branches: [main]After that, every push / merge to main builds and deploys automatically — no
server, no Docker, no manual step, and it never goes stale.
GitHub → Actions → Deploy to Cloudflare Pages → Run workflow (branch
main). Uses workflow_dispatch; needs the two secrets above.
npm ci && npm run build → output dir build → Node 20+ (CI uses 24).
Pages project → Custom domains → add the wiki hostname (e.g. community.qday.io),
then point that hostname's DNS (CNAME) at the Pages project in Cloudflare DNS.
The staging site runs the GHCR image on our server via deploy/compose.yml.
publish-image.yml rebuilds ghcr.io/qday-io/qday-wiki:latest on every push to
main; the server then pulls and recreates:
# on the server, in the folder that holds compose.yml
./deploy/redeploy.sh # pulls :latest, recreates only if the image changed
# or manually:
docker compose pull && docker compose up -dNotes:
redeploy.shexpectscompose.ymlin the same directory as the script, and abashshebang (run under bash, notsh/dash).- To keep staging current automatically, install
deploy/crontab.examplesoredeploy.shruns on a schedule. - Staging is the manual/pull path; production is fully rebuilt from source by Pages and never serves a stale build.
src/components/QDay/ holds the live web3 components used in docs: AddNetworkButton (one-click add
network), FaucetWidget (claim testnet QDAY), BalancePanel (live balances), LiveChainStatus (live
block height). They call window.ethereum directly for demo simplicity; production hardening reuses
the portal's wagmi/viem setup for multi-wallet support.