Secure, test, and operate
Secure origin database access
Use TLS, a narrow database role, secret rotation, and private connectivity when the database should not remain publicly reachable.
Hyperdrive needs a network path and credentials to reach your database. A Hyperdrive configuration is a standing door into your data, so both deserve the same scrutiny as any production credential.
Start with transport. Require TLS in the connection string, so credentials and rows never cross the internet in plain text:
postgres://app_worker:[email protected]:5432/appdb?sslmode=require
One encoding gotcha bites people here. If the password contains characters like @, #, or /, percent-encode them. An unencoded @ in the password makes the parser read everything after it as the hostname, and wrangler hyperdrive create fails with a connection error that looks like a network problem.
A role that can only do its job
Give the database role only the schemas and operations the Worker needs. Create a dedicated role instead of reusing an admin login:
CREATE ROLE app_worker LOGIN PASSWORD 's3cr3t';
GRANT USAGE ON SCHEMA public TO app_worker;
GRANT SELECT, INSERT, UPDATE, DELETE
ON notes, users, sessions TO app_worker;
No SUPERUSER, no ownership, no DROP, no access to tables the application never touches. If the Worker is ever compromised, this list is the entire blast radius. Review your practice role and remove schema ownership, superuser access, and unrelated privileges. Each one is a capability waiting for an attacker.
Private databases stay private
If the database lives in a private network, use Cloudflare’s private connectivity path, a Cloudflare Tunnel with Access in front of the database port, instead of opening the port to the internet. Exposing 5432 to the world so one pooler can reach it trades a firewall rule for a permanent scan target. With a tunnel the database keeps no public IP at all, and Hyperdrive authenticates its way in.
Rotation that never breaks traffic
Rotate credentials by creating a new valid path, updating the configuration, verifying traffic, then revoking the old credential:
CREATE ROLE app_worker_v2 LOGIN PASSWORD 'n3w-s3cr3t';
-- grant it the same narrow privileges
Update the Hyperdrive configuration with wrangler hyperdrive update, watch real queries succeed under the new role, and only then DROP ROLE app_worker.
The order matters. Revoke first and you caused an outage. Verify last and you never tested the new path. Rotation you rehearsed once in calm conditions is rotation you can do quickly the day a credential leaks.
Lesson completed