Redis URLs provided by Qovery as env vars start with redis://, the correct one needs to start with rediss:// (SSL connection) for the generated managed instances (haven’t tested container ones).
Qovery team please fix the Redis URL env var protocol 
Hello @s.aranguiz ,
Do you mind giving more details about your config / stack? Do you you an ORM (if yes, which one)?
We had a similar case couple weeks back, adding an option made the trick: Failling to connect to Redis Managed
Thanks,
Hi @bchastanier, we use an ElastiCache Redis 6 cluster (provisioned on the Qovery console). We connect to it using ioredis v5 on Node.js, and redis v4 on Python.
Given that Qovery provides an env var DATABASE_URL_INTERNAL, we expected to be able to connect to it using it without modifications, however, since the cluster only seems to accept SSL connections, this wasn’t possible.
redis://[username]:[password]@[QOVERY_INTERNAL_HOSTNAME]/0
In the end, we had to provide the connection URL manually setting the Redis SSL protocol rediss, and the full cluster hostname:
rediss://[username]:[password]@master.[QOVERY_INTERNAL_HOSTNAME].xxx.use1.cache.amazonaws.com:6379/0
Using the Qovery internal hostname fails with a TLS error using ioredis v5 on Node.js:
Unhandled error event: Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate’s altnames: Host: [QOVERY_INTERNAL_HOSTNAME]. is not in the cert’s altnames: DNS:*.[QOVERY_INTERNAL_HOSTNAME].xxx.use1.cache.amazonaws.com
Hello @s.aranguiz,
Thanks for all the details here.
Actually, it’s a known issue on our end. We have a solution to be implemented and should be prioritised soon.
Sorry for the convenience here.
Cheers
Hi @bchastanier!
We are new to Qovery and have the same issue still (we use Node with the newest ioredis version.
Is there any other workaround or fix available instead of having to read the full URL from the error message?
Hey @pantajoe,
Do you mind sharing the link to your environment so I can have a look?
The workaround I am think of as of now is:
Use variable interpolation Qovery side by creating a new var like QOVERY_REDIS_SSL_URL with a value of rediss://:{{ QOVERY_REDIS_ZXX.._LOGIN }}:{{ QOVERY_REDIS_ZXX.._PASSWORD }}@{{ QOVERY__REDIS_ZXX.._HOSTNAME }}: {{ REDIS_ZXX.._PORT }}/0
Using the public cluster HOST exposed should prevent having you needed the cluster hostname from error message.
Let me know if it helps,
Cheers
Hi @bchastanier ,
here’s a link to our environment: https://console.qovery.com/organization/385453f8-0183-4014-8bf8-445b7c397100/project/0fa966e3-a64c-4862-91d3-c4ec3d45f908/environment/6730198f-eb48-4f48-9a32-9eb1a9fa43f0
Yes, I tried that, unfortunately I got the same error message that @s.aranguiz reported:
Unhandled error event: Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate’s altnames: Host: [QOVERY_INTERNAL_HOSTNAME]. is not in the cert’s altnames: DNS:*.[QOVERY_INTERNAL_HOSTNAME].xxx.use1.cache.amazonaws.com
Arg 
ok …
What about keep using INTERNAL_HOSTNAME but forcing full URL: with .svc.cluster.local
rediss://:{{ QOVERY_REDIS_ZXX.._LOGIN }}:{{ QOVERY_REDIS_ZXX.._PASSWORD }}@{{ QOVERY__REDIS_ZXX.._HOST_INTERNAL }}.{{ QOVERY_KUBERNETES_NAMESPACE_NAME }}.svc.cluster.local:{{ REDIS_ZXX.._PORT }}/0
Let me know if it helps.
Is there a way you can deactivate TLS verification on your lib?
I will check with the team how we can find a proper fix on this one.
I tried to connect to redis with both of your suggestions, but no luck
With the interpolation suggesstion, I get a “connection closed” error (so it seems it just cannot connect to redis this way) and without TLS, the connection is also rejected.
Hello,
Please see my answer here Private Redis (Container) can connect while Private Redis (Managed) does not - #4 by Erebe
But you need to enable TLS and disable certificate checks for now. We are going to look into it
Hi @Erebe,
Thanks for the update! I’ve just re-created the Redis instance, and now no additional option like tls.rejectUnauthorized is necessary with ioredis as the URL has rediss:// as its protocol.
Everything just works!