Redis
Synopsis
Creates a Pub/Sub subscriber that connects to Redis servers and processes messages from specified channels. Supports authentication, TLS encryption, and multiple workers with automatic message handling.
For details, see Appendix.
Schema
- id: <numeric>
name: <string>
description: <string>
type: redis
tags: <string[]>
pipelines: <pipeline[]>
status: <boolean>
properties:
address: <string>
port: <numeric>
username: <string>
password: <string>
channel: <string>
reuse: <boolean>
workers: <numeric>
tls:
status: <boolean>
cert_name: <string>
key_name: <string>
passphrase: <string>
ca_name: <string>
server_name: <string>
min_tls_version: <string>
max_tls_version: <string>
insecure_skip_verify: <boolean>
Configuration
The following fields are used to define the device:
Device
| Field | Required | Default | Description |
|---|---|---|---|
id | Y | - | Unique numeric identifier |
name | Y | - | Device name |
description | N | - | Optional description |
type | Y | - | Must be redis |
tags | N | - | Optional tags |
pipelines | N | - | Optional pre-processor pipelines |
status | N | true | Enable/disable the device |
Connection
| Field | Required | Default | Description |
|---|---|---|---|
address | N | "0.0.0.0" | Redis server address |
port | Y | - | Redis server port |
username | N | - | Authentication username |
password | N | - | Authentication password |
channel | Y | - | Channel pattern to subscribe to (supports * wildcard, e.g. logs.*) |
TLS
| Field | Required | Default | Description |
|---|---|---|---|
tls.status | N | false | Enable TLS encryption |
tls.cert_name | Y* | cert.pem | Client certificate for mutual TLS |
tls.key_name | Y* | key.pem | Client private key for mutual TLS |
tls.passphrase | N | - | Passphrase for an encrypted private key |
tls.ca_name | N | - | CA bundle used to verify the server certificate. When unset, the host trust store is used; when set, it replaces the host trust store rather than adding to it. |
tls.server_name | N | - | SNI hostname override for the TLS handshake |
tls.min_tls_version | N | tls1.2 | Minimum accepted TLS version (tls1.0, tls1.1, tls1.2, tls1.3) |
tls.max_tls_version | N | - | Maximum accepted TLS version. When unset, the highest mutually supported version is negotiated. |
tls.insecure_skip_verify | N | false | Skip server certificate verification. Use only for testing. |
* = Required when tls.status is true.
TLS material fields (cert_name, key_name, ca_name, client_ca_name) accept any of the following:
- File name — resolved relative to the service root directory. Nested paths such as
certs/prod/server.pemare supported. - Absolute path — honored only if it resolves inside the service root. Any path that escapes the root is refused.
- Inline PEM content — used verbatim when the value contains
-----BEGIN. - Environment variable —
${ENV_VAR}. - Vault reference —
$secret{id=...}or$secret{store=...,ref=...}.
Performance
| Field | Required | Default | Description |
|---|---|---|---|
reuse | N | false | Enable multi-worker mode |
workers | N | 4 | Number of worker processes when reuse enabled (capped at the number of available CPU cores) |
max_buffer_size | N | 128MB | Ingest buffer admission cap. Also sets this listener's eager heap reservation |
max_buffer_size is the ingest-buffer admission cap, and is distinct from any buffer_size field above, which sizes the network read buffer. Left unset it is 128MB, which commits 384 MiB of heap per listener worker before any data arrives — and with reuse: true a device runs one worker per listener. Size strings are binary, and 32MB and 32MiB are exact synonyms.
See Listener Memory Sizing for the arithmetic, the sizing table, and what happens when the cap is exhausted.
Examples
Basic
Creating a simple Redis Pub/Sub subscriber on a single channel... | |
Secure
Connecting with authentication and TLS encryption... | |
High-Volume
Multi-worker mode for high-throughput consumption... | |
Pattern Subscription
Pattern-based subscription using a wildcard channel... | |
Redis channel patterns support the * wildcard character for matching multiple channels.
Pipelines
Applying custom processing to messages... | |
Pipelines are processed sequentially, and can modify or drop messages before ingestion.