Design · c49

Fix the Cloudflare Pages Deploy

blockedblocked — 2 Cloudflare secrets, ~2 monthscreated 2026-06-11· last activity 2026-09-11

Make `push to main` reliably deploy the design site to Cloudflare Pages

Why

The design site (design.internal.qpoint.io) stopped reflecting pushes to main, and the live site drifted into a stale state (component directory updated, but new q-nuxt-layer demo pages hang on click — JS-chunk 404s).

The site is a Cloudflare Pages Direct-Upload project (qpoint-design, not Git-connected), so a push only deploys via the GitHub Action .github/workflows/deploy.yml (npm ci → npm run generate → wrangler pages deploy). That Action was created 2026-04-13 and has failed all 8 runs, never once reaching the Cloudflare step. With auto-deploy broken, deploys happened via manual/partial wrangler pages deploy, which is what left the live site with mismatched assets.

We initially suspected qpixel introduced the break. The evidence disproves that — the Action failed on its first run (2026-04-13) with an npm-auth 401, three days before qpixel was added (2026-04-16). It was three independent misconfigurations stacked, each hiding the next:

#	Misconfiguration	Introduced	Status
1	npm auth: `.npmrc` reads `${GITHUB_TOKEN}` but the Action fed the auto repo token (can't read sibling `@qpoint-io/*` packages) → 401	2026-04-13	✅ Fixed (`6f41e1d`, `5e31670`)
2	qpixel dep `file:../qpixel/…tgz` (sibling path absent on CI) → ENOENT	2026-04-16	✅ Fixed — vendored to `design/vendor/` (`97f27d4`)
3	Cloudflare creds (`CLOUDFLARE_API_TOKEN`, `CLOUDFLARE_ACCOUNT_ID`) never set, never tested	never	⛔ Open — the only remaining blocker

Objective

push to main reliably produces a clean, complete Cloudflare Pages deploy — ending the manual/partial deploys that leave the live site with stale, hanging pages. Proven when two consecutive pushes each auto-deploy green and the previously-hanging demo pages load.

Scope

In: Add the two Cloudflare secrets; trigger and verify the never-before-run wrangler step; confirm the clean deploy clears the live stale-asset hang.
In (fallback only): swap cloudflare/wrangler-action@v3 for a direct npx wrangler@4 pages deploy CLI call if the action misbehaves on Node 20.
Out: switching to Cloudflare Git integration (would just relocate the same auth + qpixel problems into Cloudflare's builder). qpixel stays vendored — publishing to GH Packages is deferred. PAT consolidation is optional polish.

Key Changes

Already shipped to main (this cycle's investigation):

97f27d4 — vendored the qpixel tarball into design/vendor/, repointed package.json to file:./vendor/qpoint-io-qpixel-0.1.0.tgz (fixes the ENOENT that broke every build).
6f41e1d, 5e31670 — fixed deploy.yml npm auth (the .npmrc reads ${GITHUB_TOKEN}; it was being fed the wrong variable). Now uses a read:packages PAT.

Pending (the remaining fix):

Add CLOUDFLARE_API_TOKEN + CLOUDFLARE_ACCOUNT_ID repo secrets (admin action — no code change).

⏭️ Next action (start here when you pick this up)

Everything upstream is already fixed and verified. The only remaining blocker is two GitHub repo secrets. Whoever has Cloudflare admin needs to:

Create a Cloudflare API token — dashboard → My Profile → API Tokens → Create Token → custom token, scope Account → Cloudflare Pages → Edit, on the account that owns the qpoint-design Pages project.
Get the Account ID — dashboard → Workers & Pages → right sidebar Account ID.

Add both as repo secrets on qpoint-io/design:

gh secret set CLOUDFLARE_API_TOKEN  --repo qpoint-io/design
gh secret set CLOUDFLARE_ACCOUNT_ID --repo qpoint-io/design

Trigger + watch the deploy (re-run latest deploy.yml, or push a trivial commit). The "Deploy to Cloudflare Pages" step has never run before — watch it authenticate, target qpoint-design, upload, and print a URL. If it fails at that step: project-name typo, wrong account, or token missing Pages:Edit.

Full detail, fallback, and verification → execution-plan.md