cf-worker/) owns the custom domain and forwards every request to the ASP.NET Core container through a .
The pieces
Secrets and variables
Plain settings live invars in wrangler.jsonc. Secrets are set on the Worker with wrangler secret put by the deploy workflow, from GitHub Actions secrets. The names it configures:
SUPABASE_URL, SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY, JWT_SECRET, GROQ_API_KEY, GOOGLE_API_KEY, TELEGRAM_BOT_TOKEN, CLOUDFLARE_AI_GATEWAY_ACCOUNT_ID, CLOUDFLARE_AI_GATEWAY_ID, CLOUDFLARE_AI_GATEWAY_TOKEN, CLOUDFLARE_WORKERS_AI_API_TOKEN.
The workflow itself also needs CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID to run wrangler.
Names differ between the Worker and the API. The Worker reads
TELEGRAM_BOT_TOKEN to set the webhook, while the API’s bot reads Telegram__BotToken, and Telegram session encryption reads APP_SECRET. When you enable the bot in an environment, check that the API itself receives Telegram__BotToken and APP_SECRET; the bot stays off without a token.Scaling
1
13 August 2026: lazy multi-instance
The Worker switched to spreading requests across three instances with a random selector, and
/health started returning instanceId (the Durable Object ID) so load tests could see which instance answered.2
14 August 2026: back to one instance
The Worker went back to the single
default container the next day. instanceId stayed in /health.cf-worker/src/index.js (13 Aug, reverted 14 Aug)
getContainer(…, "default").
Which instance answered?
Operate it
Before Cloudflare: Azure
Until August 2026 the API ran on Azure App Service, deployed by an Azure publish-profile workflow. That pipeline was removed when the Cloudflare deploy went live. Older notes that mention Azure,master_dualmind-arena.yml or Bytez are out of date.