Redis package cache: @redis/client sends no TLS SNI, breaking rediss:// endpoints that route by SNI

[lauraseidler]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

43.251.3

Please tell us more about your question or problem

With RENOVATE_REDIS_URL=rediss://user:pass@privatelink-valkey-...aivencloud.com:9706/1, every run aborts during Redis cache init:

{"err":{"code":"ECONNRESET","host":"privatelink-valkey-...aivencloud.com","port":9706, "message":"Client network socket disconnected before secure TLS connection was established", ... "msg":"Renovate is exiting with a non-zero code due to the following logged errors"}

The endpoint itself is healthy: a Go client (valkey-go, which sets ServerName from the URL host) connects to the same host:port from the same network without issue, and valkey-cli --tls fails with the same mid-handshake EOF unless --sni is passed.

Root cause

Aiven privatelink (and similar setups) exposes multiple hostnames on one shared IP:port and routes connections by TLS SNI; handshakes without SNI are dropped. Renovate's cache client never sends SNI:

• Node's automatic servername-from-host behavior lives in the https agent, not in raw tls.connect — verified empirically on Node v22.18: tls.connect({host: 'valkey.example.com', ...}) produces a ClientHello with no SNI extension (server-side
  SNICallback never fires, socket.servername === false).
• @redis/client 5.12.1 passes its socket options straight into tls.connect without setting servername (socket.ts), and Renovate's createClient call in lib/util/cache/package/impl/redis.ts doesn't set it either — so no SNI is ever sent.
• Setting socket: { servername: '<hostname>' } explicitly makes @redis/client 5.12.1 send SNI and the handshake succeed (verified against a local TLS server with an SNI-logging SNICallback).

Most managed Redis offerings (ElastiCache classic, Azure Cache) give each instance a dedicated endpoint, so the missing SNI goes unnoticed — it only bites SNI-routed frontends, which is presumably why this hasn't come up much.

Proposed fix

In PackageCacheRedis.create, derive servername from the parsed URL for rediss:// schemes:

const parsedUrl = parseUrl(rewrittenUrl);
const config = {
  url: rewrittenUrl,
  socket: {
    reconnectStrategy: (retries: number) => Math.min(retries * 100, 3000),
    ...(parsedUrl?.protocol === 'rediss:' && !isIP(parsedUrl.hostname)
      ? { servername: parsedUrl.hostname }
      : {}),
  },
  pingInterval: 30000,
};

This matches what every HTTPS client already does, is a no-op for existing non-TLS/dedicated-endpoint users, and needs no new configuration option. The same applies to the createCluster root nodes. Happy to submit a PR if the approach sounds right.

Logs (if relevant)

Logs

{"err":{"code":"ECONNRESET","host":"privatelink-valkey-...aivencloud.com","port":9706, "message":"Client network socket disconnected before secure TLS connection was established", ... "msg":"Renovate is exiting with a non-zero code due to the following logged errors"}

[RahulGautamSingh]

Issue Created: #44461

PR welcome