Redis connections cannot use an ACL user or a configurable key prefix

[AdzerKI]

Version: 3.2.1

Two limitations make it impossible to run the panel against a Redis/Valkey instance that is shared or access-controlled.

No ACL user. Every connection is built with password only — queue.module.ts, raw-cache.module.ts, cli.ts. On a server where ACL is enabled and the deployment is given its own user, there is no way to send that username, so only the default user can be used. ioredis accepts username natively; the config schema simply does not expose it.

Fixed key prefixes. rmnwv: (cli), ioraw: (raw cache) and the BullMQ default prefix are hardcoded, so two installations pointed at the same instance collide on keys and queues. Separating them currently requires a dedicated instance or a dedicated database number, neither of which helps when the instance is shared with unrelated workloads constrained by ACL key patterns.

Proposed fix: add optional REDIS_USER and REDIS_KEY_PREFIX to the config schema, pass the username to every connection, and prepend the prefix to the existing key prefixes and to the BullMQ prefix option — including the QueueEvents instance created outside the module, which must carry the same prefix or deduplication events stop arriving. Both default to empty, so existing deployments are unaffected. Implemented in #204 against 3.2.1, tsc --noEmit and oxlint pass.

[AdzerKI]

Thanks for adding username — that half is exactly what was needed.

On the key prefix: the assumption behind "one Redis per deployment" doesn't hold when the panel runs as one app among many on a shared platform, where Redis/Valkey is a single system service and every app gets an ACL user instead of its own instance. In that setup the prefix is what makes the ACL possible at all, for two reasons:

1. ACL rules are per key/channel pattern, not per database. A user is granted ~ns:* and &ns:*; the selected REDIS_DB is not part of the permission model, so splitting deployments across database indexes gives no isolation — the same key name is equally allowed in every database. Without a prefix the only way to authorize the panel is to grant it the shared names bull:*, ioraw:*, rmnwv:* and the channels l1:invalidate, ch:node-metrics — which means granting it whatever any other tenant put under those names too.

2. Even ignoring security, the fixed names collide. Two panels on one instance share BullMQ queues (they will consume each other's jobs) and the cache-invalidation channel (one panel evicts the other's cache). Node metrics land on the same channel as well.

What I'm asking for is small and non-breaking: one optional variable, empty by default, so stock deployments serialize byte-for-byte identical key and channel names as today. That's what #204 did — it is running in production on 3.2.1 with a per-tenant ACL user (~ns:*, &ns:*, no relaxations) and needed no other changes.

If the objection is the surface rather than the feature, I'm happy to reshape it: apply the prefix only to the queue prefix and the two channel names (the parts that cannot be separated any other way), or derive it from an existing setting instead of a new variable, or rebase onto current main now that username is in. Just say which shape you'd accept and I'll send it.