Redis

Understand the role Redis plays in Infisical, why persistence is required, and how to operate it safely.

Redis serves as both a caching layer and a persistent job queue in Infisical. Unlike typical cache-only use cases, Infisical relies on Redis to durably store background job data, making persistence a hard requirement.

Redis must be configured with persistence enabled (AOF, RDB, or both). Infisical uses Redis-backed queues for background processing. A non-persistent Redis instance that restarts will lose all pending and in-progress jobs.

What it stores

Data	Description
Cache	Frequently accessed data and configurations, reducing load on PostgreSQL
Background Job Queues	Jobs for secret syncs to third-party integrations, secret rotations, scheduled tasks, webhook deliveries, and audit log processing
Job State	Metadata for in-progress, completed, and failed jobs including retry information
Session Data	Active user session tokens and ephemeral authentication state

Supported modes

Mode	Supported
Standalone (Single Node)	Yes
Sentinel (High Availability)	Yes
Cluster	Yes
Active-Active Geo-Replication	No

Redis active-active geo-replication is not supported. If you need multi-region deployments, refer to Infisical’s replication architecture which uses independent Redis instances per region instead.

Configuration

Configure Redis connectivity by setting the following environment variables on your Infisical instance.

Redis Standalone

REDIS_URL · string · default: "none" · required

Redis connection string. For SSL/TLS connections, use the rediss:// protocol (note the double ‘s’).

Examples:

• Without SSL: redis://localhost:6379
• With SSL: rediss://localhost:6379
• With authentication: redis://:password@localhost:6379
• With SSL and authentication: rediss://:password@localhost:6379

Redis Sentinel

REDIS_SENTINEL_HOSTS · string · default: "none" · required

Comma-separated list of Sentinel host:port pairs. 192.168.65.254:26379,192.168.65.254:26380

REDIS_SENTINEL_MASTER_NAME · string · default: "mymaster"

The name of the Redis master set monitored by Sentinel

REDIS_SENTINEL_ENABLE_TLS · bool · default: "false"

Whether to use TLS/SSL for Redis Sentinel connection

REDIS_SENTINEL_USERNAME · string · default: "none"

Authentication username for Redis Sentinel

REDIS_SENTINEL_PASSWORD · string · default: "none"

Authentication password for Redis Sentinel

REDIS_USERNAME · string · default: "none"

Authentication username for Redis Node

REDIS_PASSWORD · string · default: "none"

Authentication password for Redis Node

Redis Cluster

REDIS_CLUSTER_HOSTS · string · default: "none" · required

Comma-separated list of Redis Cluster host:port pairs. 192.168.65.254:26379,192.168.65.254:26380

REDIS_CLUSTER_ENABLE_TLS · boolean · default: "false"

Enable Redis TLS encryption on connection.

REDIS_CLUSTER_AWS_ELASTICACHE_DNS_LOOKUP_MODE · boolean · default: "false"

Enable this if you are using AWS encrypt on transit for Elasticache cluster. For more information refer here.

REDIS_USERNAME · string · default: "none"

Authentication username for Redis Node

REDIS_PASSWORD · string · default: "none"

Authentication password for Redis Node

Redis Read Replica

REDIS_READ_REPLICAS · string · default: "none"

Comma-separated list of Redis read replicas host:port pairs. 192.168.65.254:26379,192.168.65.254:26380

The parameters like username, password, TLS, and Redis type of the primary instance will be inherited.

SSL/TLS

To connect to Redis with SSL/TLS, use the rediss:// protocol (note the double ‘s’) in your connection string.

If your Redis server uses a certificate signed by a private CA or a self-signed certificate, set the NODE_EXTRA_CA_CERTS environment variable to the path of your CA certificate file:

REDIS_URL=rediss://your-redis-host:6379
NODE_EXTRA_CA_CERTS=/path/to/ca.crt

For Redis Sentinel or Cluster mode, use the REDIS_SENTINEL_ENABLE_TLS or REDIS_CLUSTER_ENABLE_TLS environment variables respectively.

Impact of data loss

Redis data loss is disruptive but recoverable. Unlike PostgreSQL, Redis does not hold the source of truth — secrets and configurations remain safe in PostgreSQL. However, the impact depends on what was in Redis at the time:

• Cache loss: No lasting impact. The cache repopulates automatically as read requests come in. You may see a temporary spike in PostgreSQL load until the cache warms up.
• Queue loss: Pending background jobs are lost. In-flight operations such as secret syncs to third-party integrations, pending secret rotations, or scheduled webhook deliveries will not complete. These operations will need to be re-triggered manually or will recover on the next scheduled cycle.

Why persistence is required

Infisical uses Redis to manage background job queues. These queues handle operations that must eventually complete:

• Syncing secrets to external providers (AWS Secrets Manager, GCP Secret Manager, etc.)
• Rotating credentials on a schedule
• Delivering webhooks
• Processing audit logs

If Redis is running without persistence and restarts, all queued and in-progress jobs disappear silently. There is no mechanism to replay these jobs from PostgreSQL. This can result in secrets being out of sync with third-party integrations, missed rotations, or lost webhook deliveries — with no indication that anything went wrong.

Recommendations

• Enable persistence using AOF (appendonly yes) with appendfsync everysec for a good balance between durability and performance. RDB snapshots can be used as an additional safety net.
• Set eviction policy to noeviction to prevent Redis from silently dropping queue data under memory pressure.
• Use Redis 6.2+. Infisical supports Redis versions 6.x and 7.x, with 6.2 as the minimum recommended version.
• High availability: Use Redis Sentinel or a managed Redis service with automatic failover.
• Monitor memory usage. Because noeviction is required, Redis will reject new writes if it runs out of memory rather than evicting data. Ensure sufficient memory is provisioned for your workload.

For hardware sizing, see hardware requirements.