Adventive Cloudflare Account Inventory
This section is the as-built record of the Adventive Tech, Inc. Cloudflare account, what exists today, how the pieces connect, and where the boundaries of the current configuration lie. It complements the service SOPs in this folder (Workers, Hyperdrive, Tunnel), which describe how things should be built: this section describes how they are.
The inventory is generated read-only from the Cloudflare API. No configuration is created, modified, or deleted when it is produced or refreshed. A companion PDF, Adventive_Cloudflare_Account_Inventory.pdf, is built from the same data by build_pdf.py in this folder and follows the Adventive master document template.
Latest PDF: Adventive_Cloudflare_Account_Inventory.pdf
At a glance
Section titled “At a glance”| Dimension | Count | Notes |
|---|---|---|
| Account | 1 | Adventive Tech, Inc., Enterprise, 46a873…00a7 |
| Members | 4 | 1 Super Admin, 2 Admin, 1 Domain Admin. All with 2FA |
| Zones | 13 | 2 Enterprise (adventive.com, adventivecdn.com), 11 Free |
| Workers | 31 | Platform/API, Marketing/CMS, docs demos, legacy/ad utilities |
| Pages projects | 1 | adventive-engineering-docs → docs.adventive.dev |
| KV namespaces | 8 | cache, session, idempotency, rate-limit, status |
| D1 databases | 3 | status, marketing CMS, Adventive CMS |
| R2 buckets | 8 | assets, gallery, university, CMS media, status artifacts (+replica) |
| Hyperdrive configs | 3 | console, aggregate, billing (dev) |
| Queues | 2 | status alerts + dead-letter queue |
| Access applications | 15 | self-hosted, App Launcher, WARP, Stripe SAML SaaS |
| Identity providers | 3 | JumpCloud SAML (primary), Google Workspace, One-Time PIN |
| Access service tokens | 3 | Hyperdrive, New Relic proxy |
| Cloudflare Tunnels | 2 | both healthy, dev cloudflared + legacy AWS tunnel |
| Notification policies | 4 | origin monitoring, L7 DDoS, analytics (email) |
How to read this section
Section titled “How to read this section”-
Architecture Map: the interactive drill-down view of the whole application. Start here for the big picture.
-
Account & Zones. The account, members and roles, all 13 zones, and the environment-to-zone mapping.
-
DNS & Request Routing, how proxied hostnames on each operational zone reach their origins (AWS, R2, S3, CloudFront, Pages, Workers, HubSpot), with a routing diagram.
-
Workers & Storage. The 31-Worker fleet grouped by purpose, and the KV / D1 / R2 / Queues / Hyperdrive resources they bind, with a bindings map.
-
Zero Trust & Security, Access applications, identity providers, service tokens, the Zero Trust organisation, Gateway, Tunnels, notifications, and the overall security posture against the six Cloudflare design pillars.
-
Change Log. The running record of material changes to the account, updated on each scheduled refresh.
Provenance & coverage
Section titled “Provenance & coverage”The snapshot behind this section was taken on 2026-07-16 (UTC) via the Cloudflare API using a read-only token. The token could read account, members, zones, DNS, Workers and routes, Pages, KV, D1, R2, Hyperdrive, Queues, Access (apps, identity providers, service tokens, groups, organisation), Gateway, Tunnels, and notification policies.
The following areas were not readable with the current token scope and should be confirmed from the dashboard; they are called out again where relevant:
| Area | API result | What to confirm manually |
|---|---|---|
| Zone SSL/TLS & security settings | 9109 Unauthorized | SSL mode, minimum TLS version, Always Use HTTPS, security level per zone |
| Rulesets / WAF | 10000 Authentication error | Custom WAF rules, managed rulesets, rate limiting |
| Logpush | 10000 Authentication error | Whether Access/HTTP logs are shipped (e.g. to R2) |
| Worker cron triggers | not authorised | Scheduled Worker cadences (status worker runs at 60s per its ADR) |
Extending the review token with Zone Settings Read, Account Rulesets Read, and Logs Read would let a future refresh capture these automatically.