Skip to main content

Redis best practices (Docker on Linux)

Informer uses Redis as a temporary memory exchange for importing and exporting content and a few internal functions:

  • Importing files (CSV, JSON packages, or Bundles)
  • Exporting files
  • Running sample queries
  • Flow steps (Percent of Total, Flush)
  • UI logs
  • Progress monitors
  • OAuth

These processes load data into Redis (its memory assets are called keys) and remove it when finished. Informer does not use all of Redis's features, so a few configuration changes help get the most from it.

Redis version​

Early deployments used Redis 3. For Informer 5.9 and higher, the recommended Redis version is 7.

To patch to Redis 7, edit the Informer docker-compose.yml and update the Redis image tag:

image: redis:7

Then add this line to the Linux host's /etc/sysctl.conf if it is not already present:

vm.overcommit_memory = 1

Apply it, then recycle Informer:

sudo sysctl -p

Run stop.sh then start.sh to pick up the change.

Redis tuning​

Disable save-to-disk snapshotting (reduces disk I/O) and let Redis continue when a background save fails (since Informer uses Redis only as a temporary exchange). Add this command to the Redis container in docker-compose.yml:

command: redis-server --save "" --stop-writes-on-bgsave-error no

Save the file, then run stop.sh and start.sh to apply.

Vulnerabilities​

All known Redis vulnerabilities require remote execution. By default Redis only accepts connections from the local loopback address, so it is not exposed to remote-execution attacks. If your Redis allows remote connections, contact Support to confirm only the Informer server may reach redis-cli. As a best practice, even on the loopback, consider enabling Redis authentication.

Optional advanced tuning​

Most deployments need no advanced tuning. By default, Redis on Docker has no memory limit. On systems with heavy, high-frequency exports, capping memory with an eviction policy can make the system more reliable. Redis memory values here are in bytes.

This example sets max memory to 2 GB with the recommended volatile-lru eviction policy, alongside the performance changes above:

command: redis-server --maxmemory 2048000000 --maxmemory-policy volatile-lru --save "" --stop-writes-on-bgsave-error no

Save the file, then run stop.sh and start.sh to apply.

Maxmemory guidelines​

Setting maxmemory too low can evict active keys and cause out-of-memory errors in Informer; too high wastes resources. Start in the middle of the range for your server memory, then test in 2 GB increments (values in bytes, assuming all components run on the same server):

16 GB server: maxmemory 1024000000 - 4096000000
32 GB server: maxmemory 4096000000 - 8192000000
64 GB server: maxmemory 8192000000 - 24576000000

Testing may take weeks, since most demand comes from Jobs and not every Job runs daily. Use a long enough sample period to capture most unique Jobs.