Private Redis (Container) can connect while Private Redis (Managed) does not

Hi team,

I have been pulling my hair on this all afternoon :slight_smile: I am trying to get my app to connect to my REDIS managed by AWS

I have an environment that needs a REDIS database, managed by AWS

Scenario 1, this one works:
I add a REDIS 7, container mode, private, and create an alias QOVERY_REDIS_XXXXXXXX_DATABASE_URL_INTERNAL as “REDIS_URL”, and connects using nodejs’s ioredis new IORedis(process.env.REDIS_URL, {})

Scenario 2, this one does not work:
I add a REDIS 7, managed mode (on AWS), private, and create an alias QOVERY_REDIS_XXXXXXX_DATABASE_URL_INTERNAL as “REDIS_URL”, and connects using nodejs’s ioredis new IORedis(process.env.REDIS_URL, {})

I also tried to re-create the REDIS_URL like this


Not working as well

Do you know what could be the issue ?

Hello @CBaptiste,

I just tried to connect to a newly spawned redis cache, and I don’t have any issue with ioredis.

I use this script

// Import ioredis.
// You can also use `import { Redis } from "ioredis"`
// if your project is a TypeScript project,
// Note that `import Redis from "ioredis"` is still supported,
// but will be deprecated in the next major version.
const Redis = require("ioredis");

// Create a Redis instance.
// By default, it will connect to localhost:6379.
// We are going to cover how to specify connection options soon.
const redis = new Redis(process.env.QOVERY_REDIS_Z273BD3CC_DATABASE_URL_INTERNAL);

redis.set("mykey", "value"); // Returns a promise which resolves to "OK" when the command succeeds.

// ioredis supports the node.js callback style
redis.get("mykey", (err, result) => {
  if (err) {
  } else {
    console.log(result); // Prints "value"

// Or ioredis returns a promise if the last argument isn't a function
redis.get("mykey").then((result) => {
  console.log(result); // Prints "value"

redis.zadd("sortedSet", 1, "one", 2, "dos", 4, "quatro", 3, "three");
redis.zrange("sortedSet", 0, 2, "WITHSCORES").then((elements) => {
  // ["one", "1", "dos", "2", "three", "3"] as if the command was `redis> ZRANGE sortedSet 0 2 WITHSCORES`

// All arguments are passed directly to the redis server,
// so technically ioredis supports all Redis commands.
// so the following statement is equivalent to the CLI: `redis> SET mykey hello EX 10`
redis.set("mykey", "hello", "EX", 10);

and after an npm start, I correctly get

root@container-zea6c2fb4-f5784498-fm6jn:/test# npm start

> test@1.0.0 start
> node index.js

[ 'one', '1', 'dos', '2', 'three', '3' ]

the version used.

# npm --version
# node --version
# cat test/package.json
  "name": "test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "ioredis": "^5.3.2"

Can you let me know what kind of base image are you using ?
And the error message you are getting ?

Thank you @Erebe

For your test, the redis instance your spawned is managed on AWS ? Just to confirm :slight_smile: I don’t have issue with IORedis, my issue is that when the REDIS is managed by AWS (instead of a Qovery container), it stops working

Indeed it is not working out of the box for managed redis on AWS, they use TLS by default now.

You need to enable TLS on your lib and disable certificate checks.
For IoRedis, I managed to connect with the following option

const redis = new Redis(
   tls: {  rejectUnauthorized: false  }

I am going to look into fixing the URL_INTERNAL to include rediss:// instead of redis:// for forcing to disable certifcate check, there is no quick fix for that, as long as we use qovery domain instead of the cloud provider one.

We are going to look into that.

Ok - I am trying this right now and will let you know!

it works :sob: :sob: :sob: :sob: :sob: :sob:
Can I contribute to the documentation anywhere ? this needs to be documented (or maybe it is but I could not find it)

thank you @Erebe

1 Like

Thank you for your willingness to help :pray:
We are going to fix the issue in the incoming days, so there should not be anything to document.

I will keep this post as reference in the meantime.
Thank you for reporting.

Hello Batiste,

This is fixed, if you re-deploy your managed redis you should have your cloud provider hostname in the environment variable, so there is no more need to disable tls certificate checks.

Beware, that it will only change the hostname, the url prefix redis:// will not be changed to rediss:// as it might break other people code. So you may need to specify IORedis to use TLS.

If you want the new prefix, delete and re-create your managed DB. It will be created with rediss:// prefix directly.

The hostname in the env variable will be update after the first deployment of the DB.

Let me know if I am not clear.