# Redis Destination Config Reference

Redis is a key-value store destination. RudderStack writes the traits from each identify event to the user’s key in Redis — user:<userId> — so you can read a user’s latest profile in real time. Redis receives only identify events, and only those with a userId. One without fails.

In a Redis destination spec:

type: redis
definition_version: 1

Sample configuration

yaml

version: rudder/v1
kind: destination
metadata:
  name: redis-prod
spec:
  id: redis-prod
  display_name: Redis Production
  type: redis
  definition_version: 1
  enabled: true
  config:
    address: redis.internal.example.com:6379
    password: "{{ .REDIS_PASSWORD }}"
    cluster_mode: false
    database: "2"
    prefix: rudderstack

    secure: true
    skip_verify: false
    ca_certificate: "{{ .REDIS_CA_CERTIFICATE }}"

    use_json_module: false

    connection_mode:
      web: cloud
      cloud: cloud
    consent_management:
      web:
        - provider: oneTrust
          consents:
            - analytics

The above example connects to a single Redis server over TLS. cluster_mode defaults to true, so a single server needs cluster_mode: false, which also lets it pick a database — see Connection.

Config keys

config accepts only the keys listed below. The shared config key rules cover unknown keys, defaults, and immutability.

Connection

address

Required

Type: string

Description: Address of your Redis server, as host:port. With cluster_mode on, list several cluster nodes separated by commas.

Notes:

At most 100 characters, and must not contain line breaks or .ngrok.io.
A {{ path || fallback }} template is accepted in place of a literal, but RudderStack connects with the value as written, without resolving it.

password

Secret

Type: string

Description: Password RudderStack authenticates to Redis with. Omit it for a server without authentication.

Notes:

Not validated locally.

Supply it as a {{ .VAR }} reference rather than a literal — see Secrets.

cluster_mode

Type: boolean

Default value: true

Description: Connect to a Redis Cluster, with address listing its nodes. Set it to false for a single Redis server.

database

Type: string

Description: Number of the database RudderStack writes to. When it’s omitted, RudderStack uses database 0.

Notes:

Applies when cluster_mode is false. Leave it unset otherwise.
Written as a string, not a number — an unquoted number fails validation.
At most 100 characters, and must not contain line breaks. A value that isn’t a number passes validation, and RudderStack then uses database 0.
A {{ path || fallback }} template is accepted in place of a literal, but RudderStack connects with the value as written, without resolving it.

yaml

cluster_mode: false
database: "2"

prefix

Type: string

Description: Prefix for the keys RudderStack writes: <prefix>:user:<userId> instead of user:<userId>.

Notes:

At most 100 characters, and must not contain line breaks.
A {{ path || fallback }} template is accepted in place of a literal.

See Custom prefix.

TLS

secure

Type: boolean

Default value: false

Description: Connect to Redis over TLS.

skip_verify

Type: boolean

Default value: false

Description: Skip verifying the server’s certificate chain and host name. That leaves the connection open to man-in-the-middle attacks, so use it only for testing, for example against a self-signed certificate.

Notes:

Applies when secure is true.

ca_certificate

Secret

Type: string

Description: PEM-encoded CA certificate RudderStack verifies the server’s certificate against. Omit it when any client can verify the server’s CA, as with Amazon ElastiCache.

Notes:

Applies when secure is true. Leave it unset otherwise.
Not validated locally.

Supply it as a {{ .VAR }} reference rather than a literal — see Secrets for passing its line breaks.

See How do I set up Redis on Docker with TLS support? for a local TLS setup.

Storage format

By default, each user’s key holds a Redis hash. RudderStack merges context.traits and traits into it, with traits winning, flattens nested traits with . — location.city — and stores every value as a string. Fields the event doesn’t carry are left as they were. See Identify for an example.

use_json_module

Type: boolean

Default value: false

Description: Store each user’s traits as a JSON document instead of a hash. RudderStack merges each identify event’s traits into the user’s existing document.

Notes:

Needs the RedisJSON module on your Redis server.
The dashboard shows this setting only to workspaces with the feature turned on.

Per-source keys

Both keys are objects keyed by the local source type — the tokens listed under Source types. A key naming a source type this destination doesn’t support fails validation.

connection_mode

Type: object

Description: Maps each source type you connect to the mode its events reach Redis in, using the modes in Source types.

Notes:

An entry is required for each source type you connect — see Connect a source.

yaml

connection_mode:
  web: cloud
  cloud: cloud

consent_management

Type: object

Description: Consent provider configuration per source type. The entry shape, accepted providers, and the rules on resolution_strategy and consents are shared across all destination types — see Consent management.

Source types

Redis accepts events from these source types in the mentioned connection modes:

Source type	Connection mode
`android`	`cloud`
`android_kotlin`	`cloud`
`ios`	`cloud`
`ios_swift`	`cloud`
`web`	`cloud`
`unity`	`cloud`
`react_native`	`cloud`
`flutter`	`cloud`
`cordova`	`cloud`
`cloud`	`cloud`
`warehouse`	`cloud`

Every source type is cloud only — events reach Redis from RudderStack’s servers, never in device mode.

warehouse is the token a Reverse ETL source resolves to. Rudder CLI manages the destination’s warehouse entry — if the destination is connected to a Reverse ETL source, set connection_mode.warehouse: cloud in its spec, or apply removes it.

Rudder CLI can also declare the Reverse ETL connection itself, for the types listed under Supported destinations — see Manage Reverse ETL Connections using Rudder CLI.

The dashboard additionally offers Redis to AMP and Shopify sources. Rudder CLI doesn’t manage those connections, so amp and shopify are invalid here.

Connect a source

An event stream connection to this destination is checked against two rules at validate time.

The source’s type must be supported. A source’s type resolves to one of the tokens above before the check — a JavaScript source resolves to web, and webhook and server-side SDK sources resolve to cloud. Every type an event stream source can resolve to is supported here, so this check always passes.

The destination config must carry a connection_mode entry for that source type. This lives on the destination spec, not on the connection spec. Without it:

destination 'redis-prod' config has no 'connection_mode' entry for source type 'web'

Redis needs no additional config keys to connect a source of any type.

Secrets

password and ca_certificate are the secret keys. Write each as a {{ .VAR }} reference and supply the value at apply time:

yaml

config:
  password: "{{ .REDIS_PASSWORD }}"
  ca_certificate: "{{ .REDIS_CA_CERTIFICATE }}"

bash

export RUDDER_REDIS_PASSWORD="..."
export RUDDER_REDIS_CA_CERTIFICATE="$(cat ca.pem)"
rudder-cli apply

# or
rudder-cli apply --var-file secrets.vars.yaml

Note that:

rudder-cli import writes only the secrets the API returns, as {{ .VAR }} references, and leaves the others out. Add any secret key it leaves out, then supply the variables before you apply — see Secrets.
ca_certificate spans several lines. Keep its reference quoted and on its own, as above, and supply the certificate with its line breaks — as is from the environment, or as a | block in a var file. A bare reference, or one inside a longer string, breaks the YAML or folds the line breaks into spaces.
A certificate with its line breaks written as \n also works, but only inside a double-quoted reference. A single-quoted reference, like the ones rudder-cli import writes, keeps the \n as literal text.

See How to Use Variable Substitution in Rudder CLI.

Changes by release

No changes since this type became available.

For changes across every destination type, see Destination Type Changes by Release.

See more

Redis Destination for how RudderStack stores traits, custom prefixes, and deleting a user
Destination Type Reference for Rudder CLI for the rules shared across destination types
Destination YAML Reference for the spec envelope