Secrets Management: CI/CD Infrastructure Tokens

Overview

This document details the secrets actually used by the current (2026-07-22) self-deploy architecture — see user-docs/docs/deployment/cicd-pipelines.md for the pipeline topology these secrets support.

CF_API_TOKEN / CF_ACCOUNT_ID

• Purpose: Cloudflare Pages deploy (cloudflare/wrangler-action@v3).
• Scope: A single account-wide token ("UDE CI/CD Deploy") shared across every repository that deploys to Cloudflare Pages (engine, design-docs, user-docs, ude_promotion). Cloudflare does not support scoping an API token to a single Pages project — only to the whole account — so separate per-repo tokens would not provide any real permission isolation, only extra credentials to manage. secrets do not propagate between repositories, so the same value is registered separately on each of the four repos above.
• Rotation: Roll the token in the Cloudflare dashboard (My Profile → API Tokens), then immediately register the new value on all four repos via gh secret set CF_API_TOKEN --repo Sir-Derryk/<repo> (interactive prompt, no --body — the value should never be typed into a shell argument or a file). CF_ACCOUNT_ID is an identifier, not a credential, and does not change on Roll.

TELEGRAM_BOT_TOKEN / TELEGRAM_CHAT_ID

• Purpose: Passed into each repo's local .github/actions/notify composite action for failure alerting.
• Scope: Same bot/chat across all five repositories (Pipeline, engine, design-docs, user-docs, ude_promotion) — again registered separately on each since secrets don't propagate.
• Rotation: Update the secret on all five repos; verify by triggering one workflow per repo and confirming the alert lands in the expected chat before moving to the next.

PIPELINE_DEPLOY_KEY / DESIGN_DOCS_DEPLOY_KEY / USER_DOCS_DEPLOY_KEY

• Purpose: Read-only SSH deploy keys, used only by Pipeline's own bump-submodule.yml/integration_tests.yml/regression.yml to check out engine/design-docs/user-docs together for umbrella-level regression checks. Not used by any product's own deploy workflow (those check out their own repo natively — no deploy key needed for a repo checking out itself).
• Rotation: See RUNBOOK.md §2 for the full procedure.

Dead secrets — do not reference these in new workflows

PIPELINE_GITHUB_TOKEN, ENGINE_PAT, and DOCS_TRIGGER_TOKEN authenticated a cross-repository repository_dispatch orchestration mechanism that was fully removed 2026-07-21/22 (see restructure/restructure_plan_claude.md, Section 12, in the Pipeline repo). None of the workflows catalogued in .github/AGENTS.md use any of these three. Cleaning up the orphaned secret registrations themselves (as opposed to just no longer using them) is tracked separately in that same plan's Section 15.

Related Docs

(Paths below are repository-root-relative.)

• user-docs/docs/admin-deployment.md — deployment architecture these secrets support
• RUNBOOK.md — rotation procedures, Pipeline-side detail
• .github/AGENTS.md — workflows that consume these secrets