Symptom
Running statusbeam setup for a second StatusBeam instance in a Cloudflare account that already hosts one silently reuses the first instance's resources instead of provisioning new ones.
Root causes (packages/cli/src/lib/wrangler.ts)
lookupD1(w, name) resolves by database_name from the scaffold, which defaults to statusbeam for every project — a second instance finds the first instance's database. (Workaroundable: edit database_name before setup, since lookup honors it.)lookupKv(w) is not workaroundable: it matches title === 'STATUS_KV' || title.endsWith('-STATUS_KV') account-wide, with no per-instance discriminator. Any second instance matches the first instance's namespace, and .find() order decides which one wins. createKv also always creates the binding-titled namespace, so N instances race for the same title patterns.
Real occurrence (2026-07-31)
Deploying chatbot-pf/piuda-status into the account hosting demo.statusbeam.dev: setup would have wired the new page to the demo's statusbeam D1 and statusbeam-STATUS_KV. Worked around by hand-provisioning (wrangler d1 create piuda-status, wrangler kv namespace create STATUS_KV --config …), filling ids into wrangler.*.jsonc, and using statusbeam deploy (which does no lookup). The account now holds both STATUS_KV and statusbeam-STATUS_KV — both match the lookup pattern, so a future setup re-run for either instance is a coin flip.
Suggested fix
Scope both lookups per instance, mirroring D1's by-name behavior: derive the KV title from the worker name (<worker-name>-STATUS_KV), create it with that exact title, and look up by that exact title only. A migration note (or fallback match on the legacy titles when there is exactly one) covers existing deployments.
Symptom
Running
statusbeam setupfor a second StatusBeam instance in a Cloudflare account that already hosts one silently reuses the first instance's resources instead of provisioning new ones.Root causes (packages/cli/src/lib/wrangler.ts)
lookupD1(w, name)resolves bydatabase_namefrom the scaffold, which defaults tostatusbeamfor every project — a second instance finds the first instance's database. (Workaroundable: editdatabase_namebefore setup, since lookup honors it.)lookupKv(w)is not workaroundable: it matchestitle === 'STATUS_KV' || title.endsWith('-STATUS_KV')account-wide, with no per-instance discriminator. Any second instance matches the first instance's namespace, and.find()order decides which one wins.createKvalso always creates the binding-titled namespace, so N instances race for the same title patterns.Real occurrence (2026-07-31)
Deploying
chatbot-pf/piuda-statusinto the account hosting demo.statusbeam.dev: setup would have wired the new page to the demo'sstatusbeamD1 andstatusbeam-STATUS_KV. Worked around by hand-provisioning (wrangler d1 create piuda-status,wrangler kv namespace create STATUS_KV --config …), filling ids intowrangler.*.jsonc, and usingstatusbeam deploy(which does no lookup). The account now holds bothSTATUS_KVandstatusbeam-STATUS_KV— both match the lookup pattern, so a futuresetupre-run for either instance is a coin flip.Suggested fix
Scope both lookups per instance, mirroring D1's by-name behavior: derive the KV title from the worker name (
<worker-name>-STATUS_KV), create it with that exact title, and look up by that exact title only. A migration note (or fallback match on the legacy titles when there is exactly one) covers existing deployments.