does hyperdrive over cloudflared tunnel require dns records?
does hyperdrive over cloudflared tunnel require dns records?
Mno wait, it seems to want SSL. shouldn't the tunnel already be encrypting traffic?
Mcan i use self-signed certs? connection still failing
Mvery little info being provided from the web ui just says 403 forbidden
Mcant see any activity in the 2 cloudflared instance logs
Mversion of cloudflared is
2024.9.1 is that an issue? im using the cloudflare-operator for k8s and unsure how to upgrade the binaryMMwhat the heck is going on. this is the tunnel configuration
ive confirmed multiple boxes in the cluster can access via psql, and im still not seeing anything in the cloudflared logs
ive confirmed multiple boxes in the cluster can access via psql, and im still not seeing anything in the cloudflared logs
Mnone of this has worked:
- enable SSL on postgres
- disable TLS verification for tunnel backend due to self-signed cert
- upgrade version of cloudflared to
2025.2.1
ARun the tunnel with loglevel=debug to see individual connection attempts and responses.
A403 is usually an Access refusal. Check the logs on your access policy too? For service tokens you'll need to query them via API, the tunnel dash doesn't show service access login attempts
AYes it does
AShould be fine with this version
MI had to abandon hyperdrive, I noticed you're limited to 25 db connections which bundles auth and my per-user auth reaches to the db so i'd quickly hit the 25 limit
Mone thought i had while i was prototyping is that it shouldn't require public DNS records
load balancer works without them and provides much more security by not exposing your db endpoint publically
load balancer works without them and provides much more security by not exposing your db endpoint publically
Mthere probably needs to a bigger push to allow any cloudflare service to connect to tunnels without having them exposed publically
AThis is something we're tinkering with. The trick is to still take advantage of Access for security without a hostname.
AHyperdrive is a transaction mode pooler, so those 25 go a lot further than you might imagine. Also the default limit is 60 after last month, with plans to make it adjustable down the road a bit.
Not saying you should reconsider, but just stating for posterity
Not saying you should reconsider, but just stating for posterity
KHi, I am seeing a ton of logs like this:
Error: write CONNECTION_CLOSED <...>.hyperdrive.local:5432
can someone explain what this does
Error: write CONNECTION_CLOSED <...>.hyperdrive.local:5432
can someone explain what this does
Kwe had as high as 20 errors per second and a couple hundred failures over a 10 min period
K
Bi am using neon. i use neon branches for local development. when i set my neon branch connection string in .dev.vars (WRANGLER_HYPERDRIVE_LOCAL_CONNECTIONSTRING<BINDING>=neon branch connection string) and run wrangler dev. it recognizes my environment variable
now when i get the connection string from the binding (BINDING.connectionString), it returns a
what am i doing wrong?
Found a non-empty WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING variable for binding. Hyperdrive will connect to this database during local development.now when i get the connection string from the binding (BINDING.connectionString), it returns a
hyperdrive.local host instead of my neon connection string.what am i doing wrong?
Khas there been an uptick in the number of these
I've been getting tons of these starting yesterday, and even though I've added retry logic, it's still concerning & a waste of CPU time
Error: write CONNECTION_CLOSED <...>.hyperdrive.local:5432 errors?I've been getting tons of these starting yesterday, and even though I've added retry logic, it's still concerning & a waste of CPU time
AThere was an accelerated release yesterday that may have severed some connections. We'll need to investigate that, there shouldn't have been the level of disruption you're describing.
Are you still observing elevated error rates? I'm not seeing any such in our broader monitoring.
Are you still observing elevated error rates? I'm not seeing any such in our broader monitoring.
Kyup, here's our 24hr view
Kwe haven't made any significant code changes before we started seeing errors, except to add retries
AI think you were working with Adrian? Let me touch base with him
Kyes, thank you
Kstill seeing this error... please let me know if there are things that I can try as mitigations or if there are any updates
for now, i'm trying to see what'll happen if i disable hyperdrive caching since i have a separate cache in front of my postgres client
for now, i'm trying to see what'll happen if i disable hyperdrive caching since i have a separate cache in front of my postgres client
AWe're investigating internally. We will share updates as we have them.
IWe are also seeing increased CONNECTION CLOSED errors, although also are dealing with increased traffic so hard to tell if its the same % or not
Asame ID as in our thread?
AWent looking. I do see a bump in disconnects for you, but it's not related to what kchro3 is dealing with.
FHey everyone, I'm testing hyperdrive. These are my results:
/api/test/ ---> 200ms first hit, 3-7ms subsequent calls. Great!
/api/test/:id ---> 200-600ms always.
I see in the Hyperdrive analytics that I have a lot of "Uncacheable" requests. I guess this is the dynamic endpoint.
I'm trying to understand why or how it works? Is there a workaround? Does hyperdrive always relay on caching? I'm wondering for the stale data too.
Thanks!
/api/test/ ---> 200ms first hit, 3-7ms subsequent calls. Great!
/api/test/:id ---> 200-600ms always.
I see in the Hyperdrive analytics that I have a lot of "Uncacheable" requests. I guess this is the dynamic endpoint.
I'm trying to understand why or how it works? Is there a workaround? Does hyperdrive always relay on caching? I'm wondering for the stale data too.
Thanks!
SOnly static SELECT queries qualify for caching.
FThanks. Do you think the 200ms latency is due to me being in Brasil and the DB in Germany?
SYes for sure.
FThanks. Just tested it with a VPN and yes 
SI think smart placement would be something usefull to look at. Saves time in roundtrips in your code
FI was going to ask you that. I have it in smart placement, but it seems like the worker is processed close to the end-user (in this case, me)
SYou'll need more requests to have it kick in then
FInteresting. So when you have a lot of requests it will process the request close to the db?
SYes it needs to analyse your requests: https://developers.cloudflare.com/workers/configuration/smart-placement/#understand-how-smart-placement-works
SAh wait nvm, it does not apply to Hyperdrive. Sorry
FDamn. Would be nice if we could set a base region and maybe some replicas if needed
AIt actually does apply to Hyperdrive
APart of the benefit of the recent pool placement work is that it'll play way nicer with smart placement
AActually we can cache extended protocol queries too, but each different ID in this case will be a cache miss the first time you see it
AIf you re run with the same ID and are seeing misses I'd be curious to poke a bit more. Probably there's something odd with your connection settings that is causing issues for caching. First guess would be a prepare: false setting
FOkay, cool! I will check it later if this is an issue with my settings or code
AFeel free to DM me with specific queries and connections settings and such. Happy to dig a bit, this is a complicated part and it's always useful to me to see how exactly folks are using it
