> ## Documentation Index > Fetch the complete documentation index at: https://docs.rootly.com/llms.txt > Use this file to discover all available pages before exploring further. # Private Agent for Redis and Valkey (Early Access) > Connect AI SRE to bounded, read-only diagnostics for private Redis and Valkey instances. **Early Preview:** Rootly Private Agent is under active development and available only to approved customers. Features, configuration, limits, and APIs may change before general availability. Confirm the approved agent and backend versions with your Rootly representative before production use. The native providers use the Redis wire protocol directly. Redis and Valkey share the same diagnostic implementation but register under separate provider types, so AI SRE can route to the correct instance. One agent can connect to multiple Redis and Valkey instances alongside its other providers. ## Configure instances Use a dedicated read-only server identity for each instance. Mount credentials as files and give each entry a unique ID that identifies its application, environment, and region: ```yaml theme={null} providers: redis: - id: orders-cache-production-us-east-1 display_name: Orders Redis production mode: standalone addresses: [redis.internal:6379] username_file: /run/secrets/redis/username password_file: /run/secrets/redis/password tls: enabled: true ca_bundle_file: /run/secrets/redis/ca.pem valkey: - id: sessions-cache-production-us-east-1 display_name: Sessions Valkey production mode: sentinel addresses: [sentinel-1.internal:26379, sentinel-2.internal:26379] master_name: sessions username_file: /run/secrets/valkey/username password_file: /run/secrets/valkey/password sentinel_username_file: /run/secrets/valkey/sentinel-username sentinel_password_file: /run/secrets/valkey/sentinel-password tls: enabled: true extraVolumes: - name: redis-credentials secret: secretName: rootly-private-agent-redis defaultMode: 0440 - name: valkey-credentials secret: secretName: rootly-private-agent-valkey defaultMode: 0440 extraVolumeMounts: - name: redis-credentials mountPath: /run/secrets/redis readOnly: true - name: valkey-credentials mountPath: /run/secrets/valkey readOnly: true ``` The agent image runs as UID/GID `65532`; for Secret volumes with mode `0440`, set Pod-level `securityContext.fsGroup: 65532`. Supported modes are `standalone` (default), `sentinel`, and `cluster`. Standalone requires one address. Sentinel requires `master_name`. Cluster uses database zero. Addresses are `host:port` values, never URLs containing credentials. TLS verifies server certificates against the system roots and an optional mounted CA bundle. Client certificate and key files can enable mTLS. For disposable local tests only, `allow_plaintext: true` is available instead of TLS. ## Available tools Each tool has a `redis.` or `valkey.` prefix depending on the configured provider type: | Tool suffix | Modes | Diagnostic | | ------------- | -------------------- | ------------------------------------------------------------------------------------------------------------ | | `health` | Standalone, Sentinel | Ping and bounded availability, client, keyspace-count, and persistence metrics | | `memory` | Standalone, Sentinel | Consumption, limit, eviction policy, and fragmentation metrics | | `replication` | Standalone, Sentinel | Primary/replica status, link health, and replication offsets | | `cluster` | Cluster only | Cluster state, slot counters, and known-node count from `CLUSTER INFO`; no slot topology or per-node details | | `slowlog` | Standalone, Sentinel | A bounded number of slow commands, with arguments and key names redacted | | `latency` | Standalone, Sentinel | Latency statistics and recent events, if server-side monitoring is enabled | All tools are read-only and bounded by local timeout, concurrency, and result limits. They do not issue key-value reads, scan keys, accept arbitrary commands, or change server configuration. `SLOWLOG GET` does return logged command arguments—which may include keys or values—into the agent's memory; the agent discards them before sending results to Rootly. Grant `SLOWLOG GET` only if this transient local access fits your data policy. `slowlog` accepts an optional `limit`, and all tools accept an optional `timeout_seconds`. If slowlog access is not permitted, set `disable_slowlog: true` on that provider and withhold the ACL grant. The agent then omits the slowlog tool and rejects direct calls. An empty latency-event list does not establish that the server had no latency; the monitor may be disabled. For standalone and Sentinel server identities, grant `PING`, `INFO`, `SLOWLOG GET`, and `LATENCY LATEST` to use every advertised diagnostic. Cluster mode exposes only `CLUSTER INFO`, but the Redis client also discovers nodes through `CLUSTER SLOTS` and, on Redis 7 or later and compatible Valkey versions, `CLUSTER SHARDS`; it may query `COMMAND` metadata. Grant `PING`, `CLUSTER INFO`, `CLUSTER SLOTS`, and `COMMAND` to the Cluster identity, plus `CLUSTER SHARDS` only where that command exists. Redis 6.2 does not support `CLUSTER SHARDS`. Cluster mode does not need slowlog or latency permissions. Use subcommand-level grants for `SLOWLOG GET` and `LATENCY LATEST`, including on Redis 6.2. The E2E suite verifies that reset subcommands remain denied. The agent's fixed tool set is an additional boundary, not a substitute for a read-only server identity. Sentinel mode needs a **separate Sentinel identity**, controlled by `sentinel_username_file` and `sentinel_password_file` when Sentinel ACLs are enabled. On the Sentinel nodes, grant `PING`, `SENTINEL GET-MASTER-ADDR-BY-NAME`, `SENTINEL SENTINELS`, and `SUBSCRIBE` to the `+switch-master`, `+slave-reconf-done`, and `+replica-reconf-done` channels. Redis and Valkey publish the `+slave-reconf-done` event, while the Go client also subscribes to `+replica-reconf-done`; grant both channel names. The master/replica identity still needs only the diagnostic commands above. Test both identities after restricting ACLs: discovery and failover notifications use the Sentinel identity, while diagnostics use the server identity. ## Health, routing, and compatibility Each configured instance has a distinct provider ID and independent health status. Standalone and Sentinel modes probe `PING` and bounded `INFO server` so a PING-only ACL does not appear healthy. Cluster mode checks `CLUSTER INFO`. A reachable cluster with `cluster_state:ok` is healthy; a reachable cluster reporting a non-`ok` state is degraded, so its cluster diagnostic remains routable during a slot or failover incident. An unreachable cluster or failed authentication is unhealthy and is not routed. Cluster mode advertises only the cluster-wide `cluster` tool, avoiding misleading node-scoped results from a single cluster connection. Credential and TLS files are checked before probes and tool calls; replacing a mounted file reloads the client without restarting the agent. A failed refresh marks only that instance unhealthy, and upstream error details are not sent to Rootly. The CI compatibility matrix exercises standalone Redis 6.2, 7.2, 7.4, and 8.2 extended-support releases, plus standalone Valkey 7.2, 8.0, 8.1, 9.0, and 9.1, using a disposable Docker instance and read-only ACL user for each version. Separate authenticated Sentinel and Cluster smokes run on Redis 7.4 and Valkey 9.1. Those versions also have a verified mTLS smoke with mounted client certificate rotation. Redis 6.2 Cluster is not part of the tested matrix. See [Private Agent limits](/private-agent-limits) for policy defaults and hard ceilings.