Connecting a cache client

Every instance is delivered over TLS with authentication on by default. The customer receives a single rediss:// connection URI and points any Redis-compatible client at it — no code changes, once the client trusts the instance’s certificate.

1. The connection URI

Connection details are provided as a single URI. A dedicated instance’s looks like this:

rediss://:[email protected]:6380/0

A shared-plan instance’s names its user and uses its own port on the shared server:

rediss://default:[email protected]:16042/0

The rediss:// scheme (note the double “s”) means the connection is TLS-encrypted. The parts are:

Part	Meaning
Scheme	rediss:// — a TLS-encrypted Redis connection.
User	default — the instance’s ACL user. Dedicated URIs leave it out, which means the same user.
Password	The instance’s authentication password (shown after the colon).
Host	The instance’s hostname.
Port	The TLS port: 6380 by default on a dedicated instance (Settings → DNS & TLS → Valkey TLS port); on a shared plan, the port the pool box assigned to that instance. The plaintext port is disabled.
Database	/0 — the default database index.

TLS is mandatory

Because connections are TLS-only, the client must use TLS — the rediss:// scheme handles this in most libraries. A plain redis:// connection will not work.

2. Where the customer finds it

The connection string is revealed from the service page in the client area:

1. Sign in and open the Managed Valkey service. Larger dedicated plans take a few minutes to build; shared plans are usually ready immediately.
2. Once the status shows the service is running, open the Connect & Access tab.
3. Enter the account password and click Reveal Connection String. The password is masked until revealed, and only shown for that page view. An administrator signed in as the client isn’t asked for the customer’s password; the reveal is recorded under the admin account.

The module also stores the connection string (REDIS_URL) in ImpulseCore’s encrypted secret store and contributes REDIS_URL to Core’s unified environment exporter for project-aware apps.

3. Client examples

Managed Valkey speaks the Redis wire protocol, so anything that connects to Redis connects unchanged — once it trusts the instance’s certificate.

The instance’s certificate is self-signed

The server generates the certificate on its Valkey port for its own hostname when it is built (valid for 397 days). It isn’t issued by a public certificate authority, and the client area doesn’t hand out a certificate file. Clients that verify certificates — redis-cli, ioredis, redis-py, and Predis all do by default — refuse the connection until they are told to trust it. Turning verification off in the client also connects, but gives up the protection the certificate check provides.

Save the instance’s certificate from a machine you trust, and give it to the client as its CA. Re-applying the server’s configuration keeps the same certificate, but nothing renews it: after its 397 days, clients that verify certificates reject it, and only a rebuild of the server issues a new one — which the customer then saves again:

openssl s_client -connect your-host.example.com:6380 -servername your-host.example.com </dev/null \
  | openssl x509 -out server.crt

Then connect:

# redis-cli
redis-cli -u rediss://:[email protected]:6380 --cacert server.crt

// Node.js (ioredis)
const fs = require("fs");
const Redis = require("ioredis");
const client = new Redis("rediss://:[email protected]:6380/0", {
  tls: { ca: fs.readFileSync("server.crt") },
});

# Python (redis-py)
import redis
client = redis.from_url("rediss://:[email protected]:6380/0", ssl_ca_certs="server.crt")

// PHP (Predis)
$client = new Predis\Client([
    'scheme'   => 'tls',
    'host'     => 'your-host.example.com',
    'port'     => 6380,
    'password' => 'your-password',
    'ssl'      => ['cafile' => 'server.crt', 'verify_peer' => true],
]);

Drop-in caching backend

WordPress with a Redis object-cache plugin, Laravel’s redis cache/session/queue driver, Symfony, Django’s cache backend, and Rails’ cache store all accept a Redis URL — use the rediss:// URI directly, and give the client the instance’s certificate through its TLS options.

4. Restricting access with an allowlist

Every instance requires TLS and a password, so it is never open to anonymous access, but it is internet-reachable by default. To narrow that further, the customer can add an IP/CIDR allowlist on the Connect & Access tab:

1. Enter an IP address or CIDR range (for example 203.0.113.10 or 203.0.113.0/24) and an optional label.
2. Click Add. The rule is pushed to the instance’s firewall over the Admin Proxy — on a shared plan, as rules for that instance’s port only.

Add the app server first

Add your application server’s IP before narrowing the allowlist — if the list is locked to addresses that don’t include the app, the app can no longer connect.

5. Rotating the password without downtime

The customer can rotate the password at any time from the Overview or Connect & Access tab (operators can also trigger it from the WHMCS service page’s Rotate Password button). A new password is generated and applied immediately, and the connection string is updated to match.

No-downtime rollover

The previous password stays valid for a short grace window (default 30 minutes) after a rotation, giving the application time to pick up the new connection string before the old password stops working. A credential-rotation cron (every 5 minutes) revokes expired grace passwords on the server.

If connections fail right after a rotation, the fix is almost always to re-reveal the connection string and update the application to the current password — the old one is only valid during the grace window.