Skip to content

URL: https://mkdocs.justinsforge.com/memory/general/reference_links_publish_live_dev_leak/

Link In Bio publish: dev-to-prod leak hazard

Incident 2026-07-11: build workers verifying the Links publish pipeline dry-ran a publish in their dev servers and it wrote to the LIVE gusthebass.com Cloudflare zone, overwriting the real /links bio page with a test page and adding stray /link /linksy routes + test KV keys. See [[reference_links_module]].

Why it happened

  • creatortrack/lib/secrets.ts loads the prod ~/.forge-secrets/creatortrack-auth.env in every environment (dev included). That file sets LINKS_PUBLISH_LIVE=1 + the real CLOUDFLARE_API_TOKEN.
  • lib/links/cf.ts liveConfig() originally gated live publish on the flag alone, so a dev server had everything it needed to publish live. A "dry run" was not actually a dry run.

The guard (fix, commit 5ed8d4d)

  • liveConfig() now also requires process.env.NODE_ENV === "production". next dev is always development, so dev/worker verification is forced to dry-run and cannot write to Cloudflare. Prod (systemd creatortrack-prod, next start) is production and publishes normally.
  • NEVER treat a dev publish as safe just because it says "dry run." Confirm liveConfig() returns null in dev before exercising publish, or assert the guard first.
  • Prod DB (lifeos) is safe (workers use dev DB clones); the exposure is the shared CF KV/routes.
  • Live-zone cleanup: CF API via ~/.forge-secrets/cloudflare.env token; zone gusthebass.com = 46a7073cb66667b9a835058e26c40230, KV links-map = eaca8ca562c3454885f2c7e3327a4f14.
  • General principle: gate any live/destructive external write on a production-runtime signal (NODE_ENV), never a feature flag alone, since secrets files load everywhere. See LESSONS.md 2026-07-11.