Redis Deployment and Configuration with Tyk

This page provides an overview of Redis deployment options and configuration settings for Tyk components

Introduction

Redis serves as the primary data store for various components across the Tyk Stack, handling critical functions such as key management, analytics storage, distributed rate limiting, and inter-node communication.

Redis is a requirement for the proper functioning of Tyk components. For your Tyk deployments to be highly available and reliable, Tyk recommends using persistent and recoverable Redis deployments.

Components Using Redis

Component	Redis Usage
Tyk Gateway	Session Management, Rate Limiting, Cache, Analytics, Cluster Synchronization
Tyk Dashboard	Session Management, API Configuration, Developer Portal, Cluster Notifications
Tyk Pump	Analytics Processing, Uptime Data
Tyk Identity Broker	Profile Storage, Token Caching
MDCB	Configuration Synchronization, Analytics Aggregation

Supported Redis Versions

Tyk components are regularly updated to maintain compatibility with the latest Redis versions.

To check the specific Redis versions supported by each Tyk component, please refer to the release notes of your specific Tyk component and version.

• Tyk Gateway
• Tyk Dashboard
• Tyk Pump
• Tyk Identity Broker
• MDCB

Redis Sizing Guidelines

The average single request analytics record (without detailed logging turned on) is around 1KB.

In terms of Redis, in addition to key storage itself, it should be able to hold the last 10 seconds of analytics data, preferably more, in the case of a Tyk Pump failure. So if you have 100 requests per second, you will need approximately 6MB for storing 60 seconds of data. Be aware that if detailed logging is turned on, this can grow by a magnitude of 10.

MDCB and Multi-Cloud clients - the Gateways write the data to a temporary Redis list and periodically send the analytics directly to the MDCB server, which, similar to Pump, processes them for purging to MongoDB or PostgreSQL.

Redis RAM Calculator

You can calculate your Redis RAM requirements by entering your known values in the middle section of the calculator settings below:

Redis RAM Calculator

Use this calculator to estimate the RAM requirements for your Redis instance when using Tyk. This tool helps you plan your infrastructure by calculating memory needs based on your expected API traffic, caching requirements, and analytics storage. The calculator considers factors like requests per second, cache hit rates, number of API keys, and analytics settings. Results show the total RAM per host accounting for your specified utilization threshold.

Redis Deployment Options

Tyk supports various Redis deployment configurations to meet different scalability and availability requirements:

This section provides architectural guidance for Redis deployment in Tyk Data Plane environments within Multi Data Center Bridge (MDCB) configurations.

This section is written with the MDCB data plane in mind, but the same principles apply to standalone Tyk deployments.

Standalone Redis (Basic)

A single Redis instance provides the simplest deployment model suitable for development, testing, or low-criticality environments.

Characteristics

• RTO: 5-15 minutes (manual intervention required)
• RPO: 0-5 minutes (depending on persistence configuration)
• Availability: ~99.5%
• Complexity: Low
• Cost: Lowest

Pros

• Simple to deploy and manage
• Minimal resource requirements
• No coordination overhead
• Suitable for containerized environments

Cons

• Single point of failure
• Manual recovery required
• Not suitable for production workloads
• Limited scalability

Redis Sentinel (High Availability)

Redis Sentinel provides automated failover capabilities with a master-replica setup, offering a good balance between availability and complexity.

Characteristics

• RTO: 30-60 seconds (automatic failover)
• RPO: 1 minute (asynchronous replication)
• Availability: ~99.9%
• Complexity: Medium
• Cost: Medium

Deployment Considerations

• Deploy 3 or 5 Sentinel instances (odd numbers recommended)
• Enable Redis persistence for data durability
• Monitor Sentinel logs for failover events

Pros

• Automatic failover
• High availability without sharding complexity
• Supports 16 logical databases
• Cost-effective for medium-scale deployments

Cons

• Still limited by single-threaded Redis performance
• Asynchronous replication can lead to data loss
• Requires careful network partition handling

To configure Tyk to work with Redis Sentinel, see the Redis Sentinel configuration section below.

Redis Cluster (Horizontal Scaling)

Redis Cluster offers horizontal scaling capabilities through automatic sharding, making it suitable for high-throughput environments that require linear scalability.

Characteristics

• RTO: 10-30 seconds (automatic failover)
• RPO: 30 seconds (asynchronous replication)
• Availability: ~99.95%
• Complexity: High
• Cost: High

Deployment Considerations

• Minimum six nodes (3 masters, three replicas) for production
• Only database 0 is available (no multiple logical databases)

Pros

• Linear horizontal scaling up to 1000 nodes
• Automatic sharding and rebalancing
• High throughput capabilities
• Automatic failover and recovery

Cons

• High operational complexity
• Limited multi-key operations
• No support for multiple databases
• Higher infrastructure costs
• Complex monitoring and troubleshooting

To configure Tyk to work with Redis Cluster, see the Redis Cluster configuration section below.

Characteristics

• RTO: <10 seconds (instant failover)
• RPO: <10 seconds (active-active replication)
• Availability: 99.999%+
• Complexity: Medium (managed service)
• Cost: Highest

Features

• Active-Active Geo-Distribution
• Automatic scaling and sharding
• Built-in monitoring and alerting
• Multi-model database support
• Enterprise security features

Pros

• Highest availability and performance
• Global distribution capabilities
• Comprehensive enterprise features
• Managed service reduces operational overhead
• Strong consistency options available

Cons

• Highest cost
• Vendor lock-in
• May be overkill for smaller deployments

Decision Matrix

The following table summarizes the key characteristics of each Redis deployment option:

Architecture	RTO	RPO	Availability	Complexity	Use Case
Single Redis	5–15 min	0–5 min	99.5%	Low	Development/Testing
Redis with Sentinel	30–60 sec	<1 min	99.9%	Medium	Production (Standard)
Redis Cluster	10–30 sec	<30 sec	99.95%	High	High-throughput Production

Configuration Options

Redis Configuration Best Practices

Split out Your Databases

This is a no-brainer, but keep Redis and MongoDB off the system running the Gateway, they both use lots of RAM, and with Redis and the Gateway constantly communicating you will be facing resource contention on the CPU for a marginal decrease in latency.

So in our setup, we recommend that Redis and MongoDB/PostgreSQL live on their own systems, separate from your Tyk Gateway. If you like, run them together on the same box, that’s up to you.

The network topology we like to use is:

• Two or more Tyk Gateway nodes (load balanced, each Gateway installed on separate machines).
• A separate MongoDB or PostgreSQL cluster
• A separate Redis server with fail-over or cluster
• One Tyk Dashboard node installed on a separate machine
• One Tyk Pump node installed on a separate machine that handles data transitions

If you are making use of the Tyk Caching feature, then it is possible to use a secondary Redis server or Redis cluster to store cache data. This can be very useful in high-traffic APIs where latency is at a premium.

Make sure you have enough Redis connections

Tyk makes heavy use of Redis in order to provide a fast and reliable service, in order to do so effectively, it keeps a passive connection pool ready. For high-performance setups, this pool needs to be expanded to handle more simultaneous connections, otherwise you may run out of Redis connections.

Tyk also lets you set a maximum number of open connections so that you don’t over-commit connections to the server.

To set your maximums and minimums, edit your tyk.conf and tyk_analytics.conf files to include:

"storage": {
  ...
  "optimisation_max_idle": 2000,
  "optimisation_max_active": 4000,
  ...
},

Set the max_idle value to something large, we usually leave it at around 2000 for HA deployments, and then set your max_active to your upper limit (as in, how many additional connections over the idle pool should be used).

Protection of Redis data

Tyk uses Redis to store API tokens and OAuth clients, so it is advisable to not treat Redis instances as ephemeral. The exception to this is when you are using Tyk Multi Data Center Bridge, but you will still need to retain the master Redis instance.

You must ensure that Redis is persisted, or at least in a configuration where it is easy to restore or failover. So, for example, with Elasticache, making sure there are many read-replicas and regular snapshots can ensure that your data survives a failure.

Redis Encryption

Redis supports SSL/TLS encryption from version 6 as an optional feature, enhancing the security of data in transit. To configure TLS or mTLS connections between an application and Redis, consider the following settings in Tyk’s configuration files:

• storage.use_ssl: Set this to true to enable TLS encryption for the connection.

• storage.ssl_insecure_skip_verify: A flag that, when set to true, instructs the application not to verify the Redis server’s TLS certificate. This is not recommended for production due to the risk of man-in-the-middle attacks.

From Tyk 5.3, additional options are available for more granular control:

• storage.ca_file: Path to the Certificate Authority (CA) file for verifying the Redis server’s certificate.

• storage.cert_file and storage.key_file: Paths to your application’s certificate and private key files, necessary for mTLS where both parties verify each other’s identity.

• storage.max_version and storage.min_version: Define the acceptable range of TLS versions, enhancing security by restricting connections to secure TLS protocols (1.2 or 1.3).

Setting up an Insecure TLS Connection

• Enable TLS: By setting "use_ssl": true, you encrypt the connection.
• Skip Certificate Verification: Setting "ssl_insecure_skip_verify": true bypasses the server’s certificate verification, suitable only for non-production environments.

Setting up a Secure TLS Connection

• Ensure use_ssl is set to true.
• Set ssl_insecure_skip_verify to false to enforce certificate verification against the CA specified in ca_file.
• Specify the path to the CA file in ca_file for server certificate verification.
• Adjust min_version and max_version to secure TLS versions, ideally 1.2 and 1.3.

Setting up a Mutual TLS (mTLS) Connection

• Follow the steps for a secure TLS connection.
• Provide paths for cert_file and key_file for your application’s TLS certificate and private key, enabling Redis server to verify your application’s identity.

Example Gateway Configuration

"storage": {
  "type": "redis",
  "host": "server1",
  "port": 6379,
  "use_ssl": true,
  "ssl_insecure_skip_verify": false,
  "ca_file": "/path/to/ca.crt",
  "cert_file": "/path/to/client.crt",
  "key_file": "/path/to/client.key",
  "max_version": "1.3",
  "min_version": "1.2"
}

Capping Analytics

Tyk Gateways can generate a lot of analytics data. Be sure to read about capping your Dashboard analytics

Configure Redis with TLS

If you are using TLS for Redis connections, set use_ssl to true for Gateway and Pump, and redis_use_ssl to true for the dashboard. Redis supports SSL/TLS encryption as of version 6, making it an optional feature that enhances the security of data in transit. Similarly, Amazon ElastiCache offers encryption in transit and at rest. To configure TLS or mTLS connections between an application and Redis, consider the following settings in Tyk’s configuration files:

• storage.use_ssl: Set this to true to enable TLS encryption for the connection.

• storage.ssl_insecure_skip_verify: A flag that, when set to true, instructs the application not to verify the Redis server’s TLS certificate. This is not recommended for production due to the risk of man-in-the-middle attacks.

From Tyk 5.3, additional options are available for more granular control:

• storage.ca_file: Path to the Certificate Authority (CA) file for verifying the Redis server’s certificate.

• storage.cert_file and storage.key_file: Paths to your application’s certificate and private key files, necessary for mTLS where both parties verify each other’s identity.

• storage.max_version and storage.min_version: Define the acceptable range of TLS versions, enhancing security by restricting connections to secure TLS protocols (1.2 or 1.3).

Setting up an Insecure TLS Connection

• Enable TLS: By setting "use_ssl": true, you encrypt the connection.
• Skip Certificate Verification: Setting "ssl_insecure_skip_verify": true bypasses the server’s certificate verification, suitable only for non-production environments.

Setting up a Secure TLS Connection

• Ensure use_ssl is set to true.
• Set ssl_insecure_skip_verify to false to enforce certificate verification against the CA specified in ca_file.
• Specify the path to the CA file in ca_file for server certificate verification.
• Adjust min_version and max_version to secure TLS versions, ideally 1.2 and 1.3.

Setting up a Mutual TLS (mTLS) Connection

• Follow the steps for a secure TLS connection.
• Provide paths for cert_file and key_file for your application’s TLS certificate and private key, enabling the Redis server to verify your application’s identity.

Example Gateway Configuration

"storage": {
  "type": "redis",
  "addrs": [
    "server1:6379",
    "server2:6380",
    "server3:6381"
  ],
  "use_ssl": true,
  "ssl_insecure_skip_verify": false,
  "ca_file": "/path/to/ca.crt",
  "cert_file": "/path/to/client.crt",
  "key_file": "/path/to/client.key",
  "max_version": "1.3",
  "min_version": "1.2",
  "enable_cluster": true,
  "optimisation_max_idle": 2000,
  "optimisation_max_active": 4000
}

Configure Redis Cluster

Our Gateway, Dashboard, and Pump all support integration with Redis Cluster. Redis Cluster allows data to be automatically sharded across multiple Redis Nodes. To set up Redis Cluster correctly, we recommend reading the Redis Cluster Tutorial. You must use the same settings across the Gateway, Dashboard, and Pump.

Note

A Redis Cluster operates differently from a standard Redis setup, where one instance serves as the primary and others as replicas.

Gateway

To configure the Tyk Gateway to work with your Redis Cluster, set enable_cluster to true and list your servers under addrs in your tyk.conf file.

Note

addrs is new in v2.9.3, and replaces hosts, which is now deprecated.

If you are using TLS for Redis connections, set use_ssl to true.

"storage": {
  "type": "redis",
  "enable_cluster": true,
  "addrs": [
    "server1:6379",
    "server2:6380",
    "server3:6381"
  ],
  "username": "",
  "password": "",
  "database": 0,
  "optimisation_max_idle": 2000,
  "optimisation_max_active": 4000,
  "use_ssl": false
},

Redis Cluster with Docker

For Redis clustered mode to work with Tyk using Docker and Amazon ElastiCache, follow these two steps:

1. Make sure cluster mode is enabled

Set the environment variable TYK_GW_STORAGE_ENABLECLUSTER to true.

2. Add all cluster endpoints to the config

Add all the Redis Cluster endpoints into Tyk, not just the primary. If Tyk can’t see the whole cluster, then it will not work.

For ElastiCache Redis, you can bypass having to list all your nodes, and instead use the configuration endpoint, This allows read and write operations, and the endpoint determines the correct node to target.

If this does not work, you can still list out the hosts using an environment variable. To do so, set the environment variable:

TYK_GW_STORAGE_ADDRS="redis_primary1:port,redis_replica1:port,redis_primary2:port,redis_replica2:port,redis_primary3:port,redis_replica3:port"

It is essential that Tyk can connect to all primary and replica instances.

It is recommended to ensure that the connection pool is big enough. To do so, set the following environment variables:

TYK_GW_STORAGE_MAXIDLE=6000
TYK_GW_STORAGE_MAXACTIVE=10000

These are suggested settings; please verify them by load testing.

Configure Redis Sentinel

From v2.9.3, Redis Sentinel is supported.

Similar to Redis Cluster, our Gateway, Dashboard, and Pump all support integration with Redis Sentinel.

To configure Tyk to work with Redis Sentinel, list your servers under addrs and set the master name in your Gateway, Dashboard, Pump, and MDCB config. Unlike Redis Cluster, enable_cluster should not be set. Indicative config snippets as follows:

Gateway

"storage": {
  "type": "redis",
  "addrs": [
    "server1:26379",
    "server2:26379",
    "server3:26379"
  ],
  "master_name": "mymaster",
  "username": "",
  "password": "",
  "database": 0,
  "optimisation_max_idle": 2000,
  "optimisation_max_active": 4000,
  "use_ssl": false
},

Support for Redis Sentinel AUTH

To support the use of Redis Sentinel AUTH (introduced in Redis 5.0.1), we have added the following global config settings in Tyk v3.0.2:

• In the Tyk Gateway config file - sentinel_password
• In the Tyk Dashboard config file - redis_sentinel_password
• In the Tyk Pump config file - sentinel_password
• In the Tyk Identity Broker config file - SentinelPassword
• In the Tyk Synk config file - sentinel_password

These settings allow you to support Sentinel password-only authentication in Redis version 5.0.1 and above.

See the Redis and Sentinel authentication section of the Redis Sentinel docs for more details.