Overview

Standards and SOPs for reaching Adventive’s MySQL and Aurora databases from Cloudflare Workers through Hyperdrive. Hyperdrive fronts every Worker-to-database connection: it pools connections at the edge and presents an Access service-token credential that cloudflared proxies through the tunnel to the private RDS/Aurora endpoint. Time-bounded rollout work lives in projects/, not here.

Current state (2026-07): the per-role rollout is live across dev, staging, and production — eighteen adv-hd-<db>-<role>-<env> connectors backed by hd_<db>_<role> users. The three legacy full-access connectors (adv-svc-public-api-console-dev, -aggregate-dev, -billing-dev) have been retired, and the public API Worker now binds the read-only connectors.

Chapters

#	Topic	Status
01	Connection & credential naming standard, users, passwords, secrets, hostnames, Hyperdrive configs, bindings	Active SOP
02	Credential provisioning, creating RO/RW users, secrets, and Hyperdrive configs	Active SOP

Why this exists

Every database a Worker touches is reached through a Hyperdrive config, and each Hyperdrive config bakes in exactly one MySQL user and password. Splitting each database into a read-only and a read-write role therefore multiplies out across users, Secrets Manager entries, tunnel hostnames, Hyperdrive configs, and Worker bindings. This standard fixes one name for each of those so the whole chain is predictable: given a database, an environment, and an access mode, every name in the path is derivable.

Convention

The database access chain, and the segment that carries each distinction:

Worker binding      DB_<DB>_<MODE>          access mode
   -> Hyperdrive     adv-hd-<db>-<mode>-<env>
   -> origin host    db-<db>[-<endpoint>]-<env>.adventive.<zone>   endpoint (writer/reader)
   -> MySQL user     hd_<db>_<mode>            access mode
   -> secret (SM)    adventive-db-<db>-<mode>-<env>

See Connection & credential naming standard for the full matrix and Credential provisioning for the procedure that creates it.