Secure origin database access

Hyperdrive needs a network path and credentials to the origin database. Both deserve the same scrutiny you’d give any production credential, because a Hyperdrive configuration is a standing door into your data.

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 confusing connection error that looks like a network problem.

A role that can only do its job

Grant 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 the practice role and remove schema ownership, superuser access, and unrelated database privileges — each of those is a capability waiting for an attacker.

Private databases stay private

If the database lives in a private network, use the currently supported Cloudflare private connectivity path — Cloudflare Tunnel with Access in front of the database port — rather than opening it broadly. Exposing port 5432 to the whole internet 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’ve caused an outage, verify last and you’ve never actually tested the new path. Rotation you’ve rehearsed once in calm conditions is rotation you can do quickly the day a credential leaks.