Self-managed Redis Agent Memory prerequisites

Review software, Redis, network, Secret, image, and sizing prerequisites for self-managed Redis Agent Memory.

Redis Agent Memory is distributed as container images on Docker Hub plus a Helm chart in the Redis AI Helm repository. The chart deploys the Redis Agent Memory Data Plane, Redis Agent Memory workers, and the Redis Agent Memory Control Plane. Install Identity Service separately with the iris-identity-service chart 0.10.0 before connecting Memory chart 0.8.0.

You provide the Redis databases, provider credentials, Kubernetes exposure, and license material used by the deployment.

What you need

Required software

Redis databases

The Helm chart does not deploy Redis databases. Provision the Redis databases outside the Redis Agent Memory chart and pass their URLs in the overlay Secret. The Data Plane and the Control Plane both read the overlay, so they use the same Metadata Redis and Store Redis.

Store Redis must support Search and JSON capabilities because Redis Agent Memory creates JSON and vector search indexes for memory data. Job Redis and Metadata Redis do not need those capabilities when they are deployed as separate Redis databases.

The Identity Service reads its Metadata Redis from metadata.urls in its own metadata Secret and keeps agent-key records there. The Data Plane checks agent keys by calling the Identity Service.

For a lab deployment, the Redis roles can point to the same Redis endpoint if it has the required modules and capacity. For production, separate Store Redis, Job Redis, and Metadata Redis when possible so memory data, background work, and control metadata can be scaled, backed up, and operated independently.

For Job Redis, use a non-evicting policy such as noeviction or volatile-ttl.

Metadata Redis durability

Metadata Redis is small compared with Store Redis, but it is operationally critical. Use persistent storage, Redis authentication, network isolation, and TLS where required.

In FIPS-oriented deployments, Redis URLs covered by the posture must use rediss://. The Identity Service and Control Plane also need https:// endpoints that your hosting environment provides. See FIPS-oriented posture. Avoid eviction of metadata keys. Losing Metadata Redis removes Control Plane store records, and losing the Identity Service Metadata Redis removes agent-key records.

Network access

• Connected install: the cluster must be able to pull images from docker.io and reach the Redis AI Helm repository.
• Air-gapped install: mirror the images into an internal registry and use a chart package or locally downloaded chart.
• Runtime access: Redis Agent Memory pods must reach the Redis databases and any embedding or LLM provider endpoints used by the deployment.
• Identity Service: the Data Plane must reach its runtime endpoint. Identity Service must reach the Memory Control Plane's grant validator and its own Metadata Redis. Provide TLS endpoints and trust for both service hops; see Deploy.
• Data Plane exposure: use NetworkPolicy, ingress, gateway, service mesh, private load balancer, or equivalent controls to restrict API access.

Credentials and Secrets

When config.render: true is set, as in the walkthrough, the chart renders configuration from Helm values. This option defaults to false. Credentials stay in an overlay Secret. Create the following Secrets for the two-release installation:

Also create memory-dp-credential and memory-internal-token, shared by both releases, and ids-control-token, read only by Identity Service. The walkthrough supplies a ram-ca certificate bundle for service trust. Memory generates its Control Plane admin token unless you provide one. See Credentials.

To supply a complete configuration file in your own Secret instead, see Bring-your-own (BYO) configuration.

Release artifacts and image tags

The published Memory chart 0.8.0 defaults image.tag and controlplane.image.tag to 0.8.0. Identity Service chart 0.10.0 defaults its image to its own application version, 0.10.0. Set tags explicitly when pinning images or using a mirror. The releases have independent versions.

Both charts are published at https://helm.ff-tr1-ir.amirz.org/ai as redis-ai/redis-agent-memory and redis-ai/iris-identity-service. Their standard images are redislabs/agent-memory:0.8.0, redislabs/agent-memory-control-plane:0.8.0, and redislabs/iris-identity-service:0.10.0.

Air-gapped and private registry installs

Mirror these images into your internal registry:

For this release, <ram-version> is 0.8.0 and <ids-version> is 0.10.0. Inspect each package with helm show chart redis-ai/redis-agent-memory --version 0.8.0 and helm show chart redis-ai/iris-identity-service --version 0.10.0. Memory does not pin or install the Identity Service chart.

docker pull redislabs/agent-memory:<ram-version>
docker tag redislabs/agent-memory:<ram-version> \
  registry.example.com/redislabs/agent-memory:<ram-version>
docker push registry.example.com/redislabs/agent-memory:<ram-version>

docker pull redislabs/agent-memory-control-plane:<ram-version>
docker tag redislabs/agent-memory-control-plane:<ram-version> \
  registry.example.com/redislabs/agent-memory-control-plane:<ram-version>
docker push registry.example.com/redislabs/agent-memory-control-plane:<ram-version>

docker pull redislabs/iris-identity-service:<ids-version>
docker tag redislabs/iris-identity-service:<ids-version> \
  registry.example.com/redislabs/iris-identity-service:<ids-version>
docker push registry.example.com/redislabs/iris-identity-service:<ids-version>

If the registry requires authentication, create an image pull Secret:

kubectl -n <namespace-name> create secret docker-registry ram-registry \
  --docker-server=registry.example.com \
  --docker-username=<username> \
  --docker-password=<password>

Add the registry settings to ram-values.yaml:

image:
  repository: registry.example.com/redislabs/agent-memory

controlplane:
  image:
    repository: registry.example.com/redislabs/agent-memory-control-plane

global:
  imagePullSecrets:
    - name: ram-registry

Configure the separate Identity Service release in values-ids.yaml:

image:
  repository: registry.example.com/redislabs/iris-identity-service
  tag: "0.10.0"
tests:
  image: registry.example.com/curlimages/curl:8.17.0
global:
  imagePullSecrets:
    - name: ram-registry

Each release reads its own imagePullSecrets, falling back to global.imagePullSecrets. Values passed to Memory do not configure Identity Service. Omit pull Secrets if the registry does not require authentication.

For air-gapped deployments, also set:

airgap:
  enabled: true

Memory's airgap.enabled: true checks Memory's own image repositories. It does not validate the separate Identity Service release. Mirror that release's image and chart dependencies separately, and confirm that every configured repository is reachable from the cluster.

System requirements

Default values for Memory and the separate Identity Service chart:

During a rolling update, Kubernetes may temporarily run old and new pods at the same time. A small two-node test cluster can run out of CPU during install or upgrade.

For realistic validation, use at least three nodes or enough CPU headroom for the maximum rolling-update overlap.

For a constrained lab cluster, reduce replicas and autoscaling explicitly:

server:
  replicaCount: 1
  autoscaling:
    enabled: false

worker:
  replicaCount: 1
  autoscaling:
    enabled: false

Do not use reduced replica counts as the production HA recommendation.

Helm values to review

The walkthroughs use redis-agent-memory as the Helm release name. Resource names are fixed to redis-agent-memory* by fullnameOverride, whatever the release name, so install one release per namespace.

Do not use floating image tags in production.