Audit of all 144 Cloudflare Workers, 5 zones, 12 KV namespaces, 4 D1 databases, and 2 R2 buckets — with a phased restructure plan for tenant-isolated hubs, durable auth, global navigation, full-text search, an AI help chatbot, and continuous auto-indexing of every deliverable produced in our daily work.
The Cloudflare estate has grown to 144 Workers across 5 zones in roughly 90 days. There is no access control on any of it — every worker, including the BOSSTORQUE Internal financial files (P&L, Mercury CLI, Quicken cleanup), the master Sperry rules, and unreleased GiftCue commercialization work, is reachable by anyone who guesses or stumbles onto the URL. The single hub at bosstorque-hub.jason-8ce.workers.dev lists everything on one public page. Individual cards open standalone pages with no global nav, no back-link, no search, and no relationship to the rest of the system. Nothing auto-indexes the work we produce daily, so the hub drifts the moment we stop hand-updating it.
Recommendation: approve the Phase 1–3 plan first (auth + index + new BT hub on a custom subdomain). Defer Phases 4–9 until Phase 3 is validated. This protects the most sensitive IP within ~3–4 hours of work and proves the pattern before extending it to client tenants.
One Cloudflare account, ID 8cef3a20d2c22491d2bbbc594cf4865d, with 5 active zones — all on the free plan, all created since Feb 2026.
| Zone | Created | Plan | Use today |
|---|---|---|---|
bosstorque.ai | Feb 22 | Free | Primary marketing site + email DNS. Currently nothing pointed at the hubs. |
getgiftcue.com | May 11 | Free | GiftCue landing zone |
giftcue.ai | May 11 | Free | GiftCue (reserved, parked) |
giftcue.app | May 11 | Free | GiftCue (reserved, parked) |
giftcue.org | May 11 | Free | GiftCue (reserved, parked) |
*.jason-8ce.workers.dev subdomain. No worker is routed through a custom hostname on a zone we control, which means we can't put Cloudflare Access in front of them without first attaching custom routes. This is fixable on the free plan.Of 144 workers, naming convention sorts them cleanly into 7 buckets. Counts are by prefix and contextual inference (e.g. jobber-webhook is a Sperry asset; fancy-frog-c42e is a CF-default placeholder that should be deleted).
| Tenant | Count | Examples | Sensitivity |
|---|---|---|---|
| Sperry | ~63 | sperry-hub, sperry-requests-apr2026, sperry-meta-approval-may2026, sperry-jobber-proxy, jobber-webhook, sperry-q2-status-apr2026, sperry-wp-setup-may2026 (contains WP credentials reference) |
HIGH — reveals client strategy, ad copy under approval, internal financials, WP setup with credential paths |
| BT Internal | ~42 | bosstorque-pnl-2026-04, bosstorque-pnl-2026-03, bosstorque-mercury-cli-apr2026, bt-quicken-cleanup-may2026, bosstorque-legal, bt-pipedrive-setup-apr2026, bt-fitness-look-may2026, bosstorque-hub, bt-ai-operator-spec |
CRITICAL — P&L, banking workflows, legal docs, business strategy, hiring (Lazar ICP), pricing |
| GiftCue | ~10 | giftcue-may2026, giftcue-business-plan-may2026, giftcue-marketing-may2026, getgiftcue-landing-may2026, giftcue-relay, giftcue-magilla-may2026 |
HIGH — pre-launch product IP, business plan, commercialization plans |
| Trnka | ~5 | trnka-master-archive-may2026, trnka-citizenship-timeline-may2026, trnka-passport-acceleration-may2026, czech-friction-may2026 |
HIGH — personal immigration data, PII |
| MDP / Mother's Day | ~4 | mdp-api-proxy-may2026, mdp-build-report-may2026, mothers-day-picker-may2026, mdp-commercialization-memo-may2026 |
MEDIUM — this contains the live API proxy token (the deploy relay). Already partially gated by Bearer token, but the build/memo docs leak strategy. |
| Personal | ~7 | jason-personal, concert-watcher, jazzfest-hotel-watcher, seated-relay, aaa-auto-report-apr2026 |
LOW-MEDIUM — mostly hobby utilities, but aaa-auto-report may reveal vehicle/account info |
| Infra / Plumbing | ~13 | bt-notify, bt-email-monitor, bt-email-monitor-auth, mdp-api-proxy-may2026 (deploy relay), bosstorque-rules, seated-relay, giftcue-relay, fancy-frog-c42e (CF placeholder), sperry-photo-validator |
MIXED — some already token-gated (bt-notify, mdp-api-proxy). Some are stale/unused. |
giftcue-waitlist, jobber-request-counts, REFERRAL_LOG, giftcue-sessions, JOBBER_TOKENS, SPERRY_AD_IMAGES, giftcue-hugo-context, concert-watcher-CONCERT_KV, jazzfest-hotel-watcher-JAZZFEST_KV, bosstorque-survey-submissions, bt-notify-logs, BOSSTORQUE_CONFIG
sperry-assets, sperry-image-library — both Sperry-only. Nothing for BT internal asset storage, GiftCue, or Trnka.
bt-email-monitor (1.3 MB, 0 tables — new), bt-tree-care-copilot (160 KB, 0 tables — new), powerleak-submissions (20 KB, 0 tables), torquecheck-submissions (20 KB, 0 tables)
mdp-api-proxy-may2026 (deploy relay) and bt-notify. Everything else is open URL.
The hub is a single static HTML page that lists everything by section: BT Internal (40), Personal (9), GiftCue (11), Sperry (37). The header says 69 total — that number is already stale (it's really ~97 by my count, and 144 across the whole account). Each card is a hyperlink to a separate worker URL that opens in its own tab. The destination has no shared header, no breadcrumb, no search, no way back to the hub. There is also a separate sperry-hub at the same access level — meant for client viewing but currently just as public as everything else.
| Risk | Severity | What they'd see |
|---|---|---|
| Financial data leak | Critical | Monthly P&L workers (bosstorque-pnl-2026-04, -03) expose revenue, cost structure, and margins to anyone with the URL. Search engines could already have indexed them. |
| Banking workflow paths | Critical | bosstorque-mercury-cli-apr2026 and bt-quicken-cleanup-may2026 document live banking automation. Even if no secrets are embedded, the workflow is a roadmap for an attacker. |
| Credential references | Critical | sperry-wp-setup-may2026 references the WordPress Application Password and curl pattern. The token itself may already be in the rendered HTML. |
| Client strategy disclosure | High | Sperry SOW, pricing, brand strategy, ad copy in review, friction reports — all public. Sperry expects this is their data; a competitor finding it is a relationship-ending event. |
| Pre-launch product IP | High | GiftCue business plan, marketing plan, commercialization memos all live and reachable before product launch. Anyone watching CF subdomain enumeration discovers the entire product strategy. |
| PII (Trnka) | High | Citizenship timelines and passport acceleration docs are personal data we hold on a contact's behalf. Public exposure here is also a contractual/ethical issue. |
| Cross-tenant blast radius | High | Today the same hub page leaks all tenants at once — a single discovered URL exposes every project we run. The remedy is per-tenant boundaries, not "harder to guess" URLs. |
| Drift & hallucinated state | Medium | The hub already shows 69 / 26 / 7 / 11 / 40 stats that don't match reality (~97 cards rendered, 144 workers in the account). Every day without auto-indexing, my own knowledge of what's live gets less reliable. |
| Search-engine indexing | Medium | None of these workers serve a robots.txt or X-Robots-Tag. Crawlers can index everything they reach via any inbound link. |
The cleanest model is one custom subdomain per tenant on the bosstorque.ai zone (we already own and control it). Each tenant subdomain is fronted by its own Cloudflare Access application with a tenant-specific email allowlist. Individual deliverable Workers move from *.jason-8ce.workers.dev to *.<tenant>.bosstorque.ai via Worker Custom Domains, so they inherit the tenant's Access policy automatically.
jason@bosstorque.ai only.jason@bosstorque.ai + rob@sperrytreecare.com + michele@sperrytreecare.com + designated delegates.hub.giftcue.ai if we want it on the GiftCue zone) — GiftCue tenant. Access policy: founders + investors as approved.| Service | Hostname | Purpose |
|---|---|---|
| Worker registry | registry.bosstorque.ai | The single D1-backed source of truth for every Worker, document, asset. All hubs read from this; deploys write to it. |
| Asset CDN | assets.bosstorque.ai | Shared CSS, JS, fonts, logos for the global nav header so every Worker gets a consistent shell. |
| Deploy relay | deploy.bosstorque.ai | Existing mdp-api-proxy-may2026 renamed and hardened. Auto-registers each deploy in the registry. |
| AI chatbot | per-tenant /chat | One Worker, tenant scoping via CF Access JWT claims. RAG over the registry. |
Cloudflare Access is the right tool here, and the cost is zero on the Free Zero Trust plan (50 users included). It puts a Google/email-OTP login gate in front of any hostname before a request reaches the Worker, so the protection lives at the edge — not in worker code we have to maintain.
| Application | Hostname | Identity provider | Allowlist |
|---|---|---|---|
| BT Internal | *.bt.bosstorque.ai | Google OAuth (jason@bosstorque.ai) + email OTP fallback | jason@bosstorque.ai only |
| Sperry | *.sperry.bosstorque.ai | Email OTP | jason@, rob@sperrytreecare.com, michele@sperrytreecare.com, + delegates |
| GiftCue | *.giftcue.bosstorque.ai | Email OTP | jason@ + named co-founders |
| Trnka | *.trnka.bosstorque.ai | Email OTP | jason@ + Lukas's email |
| Personal | *.me.bosstorque.ai | Google OAuth | jason@bosstorque.ai only |
| Public marketing | www.bosstorque.ai | None (public) | Anyone |
Three things still need to reach workers without a human login: the deploy relay, the bt-notify pings from Cowork, and any inbound webhooks (Jobber, Stripe, Slack). Each gets a CF Access service token (or stays on the existing Bearer token pattern if simpler). Service tokens are revocable and don't share trust with human users.
X-Robots-Tag: noindex, nofollow headers on all migrated workers and submit a Search Console removal for any URLs we find indexed.One D1 database (registry) on the shared service account holds every artifact's metadata. This is the canonical truth. Every hub, every search query, every chatbot prompt reads from it. There is no "list of workers maintained by hand" anywhere.
SQLite FTS5 inside D1 handles full-text search natively. Each tenant hub queries artifacts_fts with a WHERE tenant = ? filter sourced from the Access JWT (cf-access-authenticated-user-email header maps to allowed tenants). Sub-50ms typical query time at this volume.
Once registry-backed, every Worker page can include a tiny header script that calls GET /api/breadcrumb?id=<worker_name> on the registry and renders the right context without the worker itself having to know anything. Adding or moving categories never requires editing individual workers.
One Worker handles /chat on every tenant hub. It uses the user's CF Access identity to determine tenant scope, then runs a retrieval step against the registry's body_snapshot column (and optionally a Cloudflare Vectorize index for semantic recall), then calls a generation model. Three model options:
| Option | Cost | Quality | Notes |
|---|---|---|---|
| Cloudflare Workers AI (Llama 3.3 70B) | $0.0027/1k tokens | Good | Stays on Cloudflare, easy to wire, free 10k tokens/day. Best for simple lookup chatbots. |
| Anthropic API (Haiku 4.5) | ~$1/1M input tokens | Better | What we already use elsewhere. Cheap at this volume. Requires API key in Worker secrets. |
| Anthropic API (Sonnet 4.6) | ~$3/1M input tokens | Best | Use for BT internal hub where reasoning matters more. Overkill for Sperry team Q&A. |
Recommendation: Haiku 4.5 for client tenants, Sonnet 4.6 for BT internal. Total monthly cost projected under $5 at current usage rates.
artifact_linksEvery deploy through the BT Deploy Relay automatically POSTs to registry.bosstorque.ai/api/register with the worker name, deploy timestamp, file size, and a fetched snapshot of the rendered HTML. The relay is already the only sanctioned deploy path, so this captures 100% of new deploys with no extra step from the Cowork session.
A scheduled Worker runs once a day at 06:00 PT. It calls workers_list, compares against the registry, and:
unclassified and a Dispatch ping for triage)brokenstale for cleanup reviewEvery Cowork session that produces a deliverable should write a small "context blob" to the registry: what the task was, what we decided, what artifacts were produced. A single skill (publish-to-hub exists already) can be extended to also write this. The chatbot then has not just the artifact, but the reasoning that produced it.
Drive is fine for live document editing but bad as a source of truth: links rot, folders get reorganized, search is shallow, and Drive's permission model doesn't fit a multi-tenant business. The R2 + registry combination gives us: cheap durable storage, full-text search across all assets, tenant-scoped permissions, and ability to render assets at custom URLs without exposing the raw bucket.
| Bucket | Tenant | Contents |
|---|---|---|
bt-library | BT Internal | P&Ls (PDF + raw), bank statements, contracts, internal decks, hire docs, brand assets, code archives |
sperry-library (R2: sperry-assets + sperry-image-library already exist) | Sperry | SOWs, approvals, ad creative, image library, photo archive, jobber exports, weekly reports |
giftcue-library | GiftCue | Business plan, marketing plan, brand kit, pitch decks, founder docs |
trnka-library | Trnka | Citizenship records, passport timelines, scanned IDs (encrypted) |
shared-library | Shared | Templates, brand kit, reusable assets, master skills, master glossary, market research |
One-time migration: a Worker walks the existing Drive folder tree via the Drive API, copies every file into the appropriate R2 bucket, and writes registry rows with tenant, category, original Drive path, and a snapshot of the file's text content for search. After that, Drive becomes a write-only inbox — new files dropped into a "to-archive" folder are picked up nightly and absorbed. The registry tells you what's where; you stop relying on Drive folder memory.
Right now, when we produce a strong piece of work for one client, the methodology dies in that client's folder. The registry's artifact_links table plus a "redact and template" workflow lets us:
shared-library as a templateYou approve this doc. I add four subdomain CNAMEs to bosstorque.ai: bt., sperry., giftcue., trnka., me., assets., registry., deploy.. No traffic moves yet.
Enable CF Zero Trust on the account. Create one Access application per tenant subdomain with the policy table from section 5.1. Configure Google OAuth as primary IdP, email OTP as fallback. Test with a dummy worker to confirm the gate works.
Create registry D1, deploy schema, build registry.bosstorque.ai Worker with two endpoints: POST /api/register (deploy-relay calls here) and GET /api/list?tenant=&q= (hubs query here). Initial backfill from workers_list with hand-tagged tenants — once.
Deploy a new hub worker at bt.bosstorque.ai, with auth in front. Migrate all ~42 BT internal workers to *.bt.bosstorque.ai via Worker Custom Domains. Add X-Robots-Tag: noindex on all of them. Old URLs 301 to new URLs through a redirect worker so links don't die. BT internal IP is now protected.
New Sperry hub at sperry.bosstorque.ai with Access policy allowing jason@ + Rob/Michele. Migrate ~63 sperry-* workers to subdomain. Notify Rob/Michele with a one-pager on how the new login works. Old URLs 301-redirect.
Build assets.bosstorque.ai/nav.js. Add the include to every migrated worker via a scripted patch over the relay. Validate breadcrumbs work via registry lookup.
Repeat phases 3–5 for the remaining tenants. Lower urgency, same pattern.
Wire FTS5 search endpoint into each tenant hub. Build /chat worker with tenant-scoped RAG. Pick Haiku 4.5 default model.
Modify the deploy relay to POST to registry on every deploy. Stand up the daily reconciliation cron. Build the Drive ingest worker for the one-time absorption of the canonical Drive folder tree.
With the registry live and the daily cron flagging stale workers, you approve a list of candidates for deletion (the CF-default fancy-frog-c42e, the -temp suffix workers, the email-ws2-03-temp, etc.). Nothing deletes without your explicit OK.
The current names are mostly OK but inconsistent: sperry-meta-approval-may2026 vs sperryphonecomparison. Adopt and enforce: <tenant>-<category>-<slug>-<mmmYYYY>. The deploy relay can reject anything that doesn't match. Five categories: report, hub, doc, tool, landing.
Each hub has a "What changed this week" feed at the top, generated from the deployments table. Sperry-team sees only Sperry deployments. Helps them stay current without you having to write a weekly update.
When we ship "Q2 status report v2," the v1 worker should be marked superseded, not deleted. The hub shows only current; artifact_links traversal lets you find history. Replaces our current pattern of leaving stale dated workers around.
Some deliverables we want public — landing pages, the rules doc, the public BOSSTORQUE marketing site. The registry has a tenant = 'public' bucket that maps to www.bosstorque.ai with no Access policy. Same plumbing, deliberate exposure.
The registry D1 is now a single point of failure. Add a nightly export to R2 (shared-library/registry/<date>.sql) and a once-weekly Drive copy for tertiary backup.
You and clients check this on phones constantly. Spend extra time on mobile in Phase 3 — the current hub renders OK but doesn't feel like a native mobile experience. Bottom-nav for tablet/phone, swipe between categories.
When something gets deployed to a client tenant (e.g. a new Sperry approval card), the registry can optionally trigger an email or Slack DM to the client tenant's owners. Currently they only know if you tell them. Configurable per tenant.
Before migration, run a Google search for site:jason-8ce.workers.dev to find any already-indexed pages. Submit removal requests via Search Console for anything sensitive. Add X-Robots-Tag: noindex, nofollow as a default header on the new shell.
The existing sperry-hub at the workers.dev URL was meant to be a client-facing view. We keep that same content/intent on sperry.bosstorque.ai behind Access — same hub for Rob/Michele, just protected and properly indexed.
You own four GiftCue domains (.com, .ai, .app, .org). Decide which is the canonical product domain before Phase 6, since it influences whether the GiftCue internal hub lives at giftcue.bosstorque.ai (clean separation) or hub.<canonical>. Recommendation: keep internal hub at giftcue.bosstorque.ai — product domain stays clean for actual product, internal IP stays on the BT account, easier to add investor-only sections later.
| Risk | Likelihood | Mitigation |
|---|---|---|
| Old URL bookmarks break for Sperry team | High | Run the legacy *.jason-8ce.workers.dev workers as 301-redirectors for 90 days. Send Rob/Michele the new URLs once. |
| CF Access login friction for clients | Medium | Email OTP — no password required. Send the first one in a calendar invite with a "click here, enter the code, you're in" walkthrough. |
| Bots / Cowork sessions blocked by Access | Medium | Service tokens for every programmatic caller. Test bt-notify and deploy relay end-to-end before flipping enforcement. |
| Registry becomes the single point of failure | Low-Medium | Daily R2 backups + weekly Drive copy. Hubs cache responses locally for 5 minutes so a brief D1 outage doesn't blank them. |
| Migration breaks Worker Custom Domain limits | Low | Free plan allows 500 custom hostnames per zone. We're at 144 workers total, well under cap. |
| Cost creep from Zero Trust seat growth | Low | Stay under 50 users for free tier. Sperry + GiftCue tenants combined < 10 users for the foreseeable future. |
Each phase is independent and reversible: Phase 1 (Access setup) can be disabled per-app in one click. Phase 3 (BT hub migration) leaves the old hub intact at the workers.dev URL during migration — if the new hub breaks, point yourself back at the old URL. Phase 8 (Drive ingest) is read-only on Drive — we copy, we don't move.
giftcue.bosstorque.ai (my recommendation) or hub.giftcue.ai?fancy-frog-c42e) without asking, or every delete needs sign-off?