FreeBSD.software
Home/Guides/How to Set Up Redis on FreeBSD
tutorial·2026-03-29·20 min read

How to Set Up Redis on FreeBSD

Complete guide to setting up Redis on FreeBSD. Covers installation, redis.conf configuration, persistence (RDB and AOF), Sentinel for HA, security, monitoring, and use cases.

How to Set Up Redis on FreeBSD

Redis is the in-memory data structure store that powers caching, session management, message queues, and real-time analytics across thousands of production systems. FreeBSD is the operating system built for exactly this kind of workload -- stable under sustained load, predictable memory management, clean service administration. Running Redis on FreeBSD gives you a combination that just works, without the ceremony and surprises that come with other platforms.

This guide covers a full production setup: installation, configuration walkthrough, persistence strategies, security hardening, Sentinel-based high availability, monitoring, common use cases, ZFS tuning, and performance optimization. Every command targets FreeBSD 14.x with Redis 7.x. Every path is FreeBSD-native.

Table of Contents

  1. Why Redis on FreeBSD
  2. Installation
  3. redis.conf Walkthrough
  4. Persistence: RDB, AOF, and Hybrid
  5. Security
  6. Redis Sentinel for High Availability
  7. Monitoring
  8. Common Use Cases on FreeBSD
  9. ZFS Tuning for Redis
  10. Performance Tuning
  11. FAQ

Why Redis on FreeBSD

Redis is single-threaded by design for its core operations. Every command runs in a tight event loop. This means latency depends almost entirely on the operating system's ability to deliver network packets and manage memory without stalling. FreeBSD excels at both.

Predictable memory behavior. Redis lives and dies by memory. FreeBSD's virtual memory system handles large allocations cleanly. There is no OOM killer silently murdering your Redis process at 3 AM. FreeBSD gives you direct control over memory limits through resource controls (rctl) and jails, without the kernel second-guessing you.

Network stack maturity. Redis serves thousands of concurrent connections through a single event loop. FreeBSD's kqueue event notification mechanism is the gold standard for this pattern -- it is what Redis's event library was designed around. The network stack handles high connection counts without tuning battles.

ZFS snapshots for backups. Redis persistence (RDB dumps, AOF files) sits on disk. ZFS gives you instant atomic snapshots of that data. You can take a consistent backup of your Redis persistence files in milliseconds, without stopping the server. More on this in the ZFS tuning section.

Service management simplicity. One line in rc.conf enables Redis at boot. One service command starts, stops, or restarts it. No systemd unit files, no socket activation complexity, no dependency chains. If you are evaluating data store options, see our best database guide for FreeBSD. For relational workloads, PostgreSQL on FreeBSD is the better choice. Redis complements a relational database -- it does not replace one.


Installation

FreeBSD provides Redis as a binary package. Installation takes one command.

Install Redis

bash
pkg install redis

This installs the Redis server (redis-server), the command-line client (redis-cli), and the Sentinel binary (redis-sentinel). On FreeBSD 14.x, this delivers Redis 7.2.x.

Verify Installation

bash
redis-server --version
shell
Redis server v=7.2.7 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64 build=...

Note that FreeBSD's Redis uses jemalloc by default -- the same allocator FreeBSD itself uses. This is the right choice for production. It handles fragmentation better than libc malloc under Redis's allocation patterns.

Enable and Start the Service

bash
sysrc redis_enable="YES" service redis start

Redis is now running on 127.0.0.1:6379 with default settings. Verify with:

bash
redis-cli ping
shell
PONG

The default configuration is functional but not production-ready. The next section fixes that.


redis.conf Walkthrough

The main configuration file lives at /usr/local/etc/redis.conf. Before editing, make a backup:

bash
cp /usr/local/etc/redis.conf /usr/local/etc/redis.conf.bak

Here is a complete production-oriented redis.conf with explanations for each decision. This replaces the defaults -- read through it and adjust values for your hardware.

ini
# /usr/local/etc/redis.conf -- Production configuration for FreeBSD # --- NETWORK --- # Bind to localhost only. Never bind to 0.0.0.0 unless behind a firewall. bind 127.0.0.1 ::1 # Default port. Change only if running multiple instances. port 6379 # Accept up to 511 connections waiting in the TCP backlog queue. # Must match or be lower than kern.ipc.somaxconn (see Performance Tuning). tcp-backlog 511 # Close idle connections after 300 seconds. 0 = never. timeout 300 # Send TCP keepalive packets every 60 seconds. tcp-keepalive 60 # --- GENERAL --- # Run as a daemon. FreeBSD rc script expects this. daemonize yes # Supervised mode. Set to "no" on FreeBSD -- rc.d handles supervision. supervised no # PID file location (FreeBSD convention). pidfile /var/run/redis/redis.pid # Log level: debug, verbose, notice, warning. loglevel notice # Log file path. Empty string = stdout (not useful for daemon mode). logfile /var/log/redis/redis.log # Number of databases. Default 16, rarely need more. databases 16 # --- MEMORY --- # Set a hard memory limit. Adjust to your server's RAM. # Leave at least 25% of RAM for the OS, ZFS ARC, and fork overhead. # Example: 4GB server -> 2GB for Redis, rest for OS + ARC. maxmemory 2gb # Eviction policy when maxmemory is reached. # allkeys-lru: evict any key using LRU. Best for caching workloads. # volatile-lru: evict only keys with an expiry set. Best for mixed workloads. # noeviction: return errors on writes. Best for persistent data stores. maxmemory-policy allkeys-lru # LRU sample size. Higher = more accurate eviction, slight CPU cost. maxmemory-samples 10 # --- SNAPSHOTTING (RDB) --- # Save an RDB snapshot: # after 3600 seconds if at least 1 key changed # after 300 seconds if at least 100 keys changed # after 60 seconds if at least 10000 keys changed save 3600 1 save 300 100 save 60 10000 # Stop accepting writes if the background save fails. stop-writes-on-bgsave-error yes # Compress RDB files with LZF. Small CPU cost, large disk savings. rdbcompression yes # Include a CRC64 checksum in RDB files. rdbchecksum yes # RDB filename and directory. dbfilename dump.rdb dir /var/db/redis/ # --- APPEND ONLY FILE (AOF) --- # Enable AOF for durability. See the Persistence section below. appendonly yes # AOF filename. appendfilename "appendonly.aof" # fsync policy: # always -- fsync after every write. Safest, slowest. # everysec -- fsync once per second. Good balance. # no -- let the OS decide when to flush. Fastest, least safe. appendfsync everysec # Do not fsync during BGSAVE or BGREWRITEAOF. Reduces latency spikes. no-appendfsync-on-rewrite yes # Trigger AOF rewrite when AOF file is 100% larger than last rewrite. auto-aof-rewrite-percentage 100 # Minimum AOF size before auto-rewrite triggers. auto-aof-rewrite-min-size 64mb # --- HYBRID PERSISTENCE (Redis 7+) --- # Use RDB preamble in AOF files. Faster restarts, smaller AOF. aof-use-rdb-preamble yes # --- SECURITY --- # Require password. Generate a strong one: openssl rand -hex 32 requirepass YOUR_STRONG_PASSWORD_HERE # Disable dangerous commands by renaming them to empty string. rename-command FLUSHDB "" rename-command FLUSHALL "" rename-command DEBUG "" rename-command CONFIG "REDIS_CONFIG_a8f3e2" # --- SLOW LOG --- # Log commands slower than 10 milliseconds. slowlog-log-slower-than 10000 # Keep 128 slow log entries. slowlog-max-len 128 # --- CLIENTS --- # Maximum simultaneous client connections. maxclients 10000 # --- LATENCY MONITOR --- # Track operations slower than 5ms. latency-monitor-threshold 5

After editing, restart Redis and verify the configuration loaded cleanly:

bash
service redis restart redis-cli -a YOUR_STRONG_PASSWORD_HERE ping

Check the log for any warnings:

bash
tail -20 /var/log/redis/redis.log

Persistence: RDB, AOF, and Hybrid

Redis offers three persistence strategies. Understanding them is critical -- the wrong choice means either data loss or unnecessary latency.

RDB Snapshots

RDB takes point-in-time snapshots of the entire dataset. Redis forks a child process that writes the dataset to a temporary file, then atomically renames it to dump.rdb.

Pros: Compact files. Fast restarts (loading an RDB file is faster than replaying an AOF). Low runtime overhead -- the fork happens in the background.

Cons: You lose data between snapshots. If Redis crashes 4 minutes into a 5-minute snapshot interval, those 4 minutes of writes are gone.

RDB is configured with save directives in redis.conf (shown above).

AOF (Append Only File)

AOF logs every write operation to a file. On restart, Redis replays the log to reconstruct the dataset.

Pros: Much less data loss. With appendfsync everysec, you lose at most one second of writes.

Cons: AOF files are larger than RDB. Replaying a large AOF on restart is slower. The file grows continuously and requires periodic rewriting.

Enable AOF with appendonly yes in redis.conf.

Redis 7 combines both strategies. When AOF rewrite triggers, Redis writes an RDB snapshot as the preamble of the new AOF file, followed by AOF entries accumulated since the snapshot. This gives you:

  • Fast restarts (RDB preamble loads instantly)
  • Minimal data loss (AOF entries cover the gap)
  • Compact files (RDB preamble is smaller than equivalent AOF entries)

Enable with:

ini
appendonly yes aof-use-rdb-preamble yes

This is the default in Redis 7 and the recommended approach for any production deployment.

Persistence Directory

On FreeBSD, Redis stores persistence files in /var/db/redis/ by default. Ensure this directory has correct ownership:

bash
chown redis:redis /var/db/redis chmod 750 /var/db/redis

Security

An unsecured Redis instance is a breach waiting to happen. Redis was designed for trusted networks, but production reality demands defense in depth.

Require a Password

Generate a strong password and set it in redis.conf:

bash
openssl rand -hex 32
ini
requirepass 7a3b9f1e4c8d2a6b5e0f3c7d9a1b4e8f2c6d0a5b3e7f1c9d4a8b2e6f0c3a7d

All clients must authenticate with AUTH before issuing commands. This includes redis-cli:

bash
redis-cli -a 7a3b9f1e4c8d2a6b5e0f3c7d9a1b4e8f2c6d0a5b3e7f1c9d4a8b2e6f0c3a7d

Bind to Localhost

Never bind Redis to a public interface without additional protection. The default bind 127.0.0.1 ::1 restricts access to the local machine. If other servers need access, bind to a private network interface and combine with firewall rules.

PF Firewall Rules

If Redis must accept remote connections, use FreeBSD's PF firewall to restrict access to known clients:

shell
# /etc/pf.conf # Define trusted Redis clients redis_clients = "{ 10.0.1.10, 10.0.1.11, 10.0.1.12 }" # Block all Redis traffic by default, allow only trusted clients block in on egress proto tcp to port 6379 pass in on egress proto tcp from $redis_clients to port 6379

Reload PF:

bash
pfctl -f /etc/pf.conf

Disable Dangerous Commands

Rename or disable commands that should never be used in production:

ini
rename-command FLUSHDB "" rename-command FLUSHALL "" rename-command DEBUG "" rename-command KEYS "" rename-command CONFIG "REDIS_CONFIG_a8f3e2"

The KEYS command is particularly dangerous -- it blocks the event loop while scanning the entire keyspace. Use SCAN instead. CONFIG is renamed (not disabled) so administrators can still use it with the secret name.

TLS Encryption

Redis 6+ supports native TLS. On FreeBSD, Redis is built with OpenSSL support. To enable TLS:

ini
tls-port 6380 port 0 tls-cert-file /usr/local/etc/redis/redis.crt tls-key-file /usr/local/etc/redis/redis.key tls-ca-cert-file /usr/local/etc/redis/ca.crt

Generate certificates with OpenSSL or use your existing PKI. Setting port 0 disables the unencrypted listener entirely.


Redis Sentinel for High Availability

Redis Sentinel provides automatic failover, monitoring, and service discovery for Redis deployments. If a master node goes down, Sentinel promotes a replica to master without human intervention.

Architecture

A minimal Sentinel deployment requires:

  • 1 Redis master
  • 1 or 2 Redis replicas
  • 3 Sentinel instances (odd number to achieve quorum)

Sentinel instances can run on the same machines as Redis, or on separate hosts. Three Sentinels are the minimum for reliable quorum decisions.

Configure Redis Replication

On the replica servers, add to redis.conf:

ini
# Point to the master replicaof 10.0.1.1 6379 # Master password (must match master's requirepass) masterauth 7a3b9f1e4c8d2a6b5e0f3c7d9a1b4e8f2c6d0a5b3e7f1c9d4a8b2e6f0c3a7d # Replica serves stale data during sync. Set "no" for strict consistency. replica-serve-stale-data yes # Replica is read-only. replica-read-only yes

Install and Configure Sentinel

Sentinel ships with Redis on FreeBSD. Create the configuration file:

ini
# /usr/local/etc/sentinel.conf # Port for this Sentinel instance. port 26379 # Daemonize. daemonize yes pidfile /var/run/redis/sentinel.pid logfile /var/log/redis/sentinel.log # Monitor the master. "mymaster" is an arbitrary name. # 2 = quorum -- number of Sentinels that must agree on failure. sentinel monitor mymaster 10.0.1.1 6379 2 # Master password. sentinel auth-pass mymaster 7a3b9f1e4c8d2a6b5e0f3c7d9a1b4e8f2c6d0a5b3e7f1c9d4a8b2e6f0c3a7d # Consider master down after 5 seconds of no response. sentinel down-after-milliseconds mymaster 5000 # Allow only 1 replica to sync from new master at a time during failover. sentinel parallel-syncs mymaster 1 # Failover timeout: 60 seconds. sentinel failover-timeout mymaster 60000 # Deny access to Sentinel commands from scripts. sentinel deny-scripts-reconfig yes

Enable Sentinel in rc.conf

FreeBSD's Redis package includes a Sentinel rc script:

bash
sysrc redis_sentinel_enable="YES" service redis-sentinel start

Verify Sentinel

bash
redis-cli -p 26379 sentinel master mymaster

This returns the master's IP, port, and status. To see all known replicas:

bash
redis-cli -p 26379 sentinel replicas mymaster

Failover Test

Simulate a master failure by stopping the master Redis instance:

bash
service redis stop # on the master

Watch the Sentinel log on any Sentinel node:

bash
tail -f /var/log/redis/sentinel.log

Within down-after-milliseconds plus failover time, Sentinel promotes a replica to master. Clients connected through Sentinel discover the new master automatically.


Monitoring

Redis provides built-in monitoring tools. No external agent is required for basic operational visibility.

redis-cli INFO

The INFO command returns everything about the running Redis instance:

bash
redis-cli -a YOUR_PASSWORD INFO

Key sections to watch:

bash
# Memory usage redis-cli -a YOUR_PASSWORD INFO memory
shell
used_memory_human:1.23G used_memory_rss_human:1.45G used_memory_peak_human:1.50G mem_fragmentation_ratio:1.18

A mem_fragmentation_ratio above 1.5 indicates significant fragmentation. Below 1.0 means Redis is swapping -- an emergency situation.

bash
# Keyspace stats redis-cli -a YOUR_PASSWORD INFO keyspace
shell
db0:keys=1523400,expires=1200000,avg_ttl=3600000
bash
# Replication status redis-cli -a YOUR_PASSWORD INFO replication

Verify connected_slaves matches your expected replica count and master_link_status shows up on replicas.

MONITOR Command

MONITOR streams every command processed by Redis in real time:

bash
redis-cli -a YOUR_PASSWORD MONITOR

This is invaluable for debugging but has significant overhead. Never leave it running in production. Use it briefly, then disconnect.

Latency Monitoring

Redis tracks latency spikes internally. Enable it in redis.conf:

ini
latency-monitor-threshold 5

Then query:

bash
redis-cli -a YOUR_PASSWORD LATENCY LATEST redis-cli -a YOUR_PASSWORD LATENCY HISTORY command

Slow Log

The slow log captures commands that exceed a time threshold:

bash
redis-cli -a YOUR_PASSWORD SLOWLOG GET 10

This shows the 10 most recent slow commands, including the command itself, execution time, and timestamp. Review this regularly -- a single KEYS * or SMEMBERS on a large set can block the event loop for seconds.

External Monitoring

For long-term metrics, export Redis stats to Prometheus using redis_exporter:

bash
pkg install redis_exporter sysrc redis_exporter_enable="YES" sysrc redis_exporter_args="--redis.addr=redis://127.0.0.1:6379 --redis.password=YOUR_PASSWORD" service redis_exporter start

This exposes metrics at http://localhost:9121/metrics for Prometheus to scrape.


Common Use Cases on FreeBSD

Redis is not a general-purpose database. It is a specialized tool for specific problems. Here are the most common production use cases on FreeBSD servers.

PHP Session Store

Storing PHP sessions in Redis eliminates filesystem session locking issues and enables session sharing across multiple web servers. Install the PHP Redis extension:

bash
pkg install php83-pecl-redis

Configure PHP (/usr/local/etc/php.ini):

ini
session.save_handler = redis session.save_path = "tcp://127.0.0.1:6379?auth=YOUR_PASSWORD"

Restart PHP-FPM:

bash
service php-fpm restart

Sessions are now stored in Redis with automatic expiration. No cron job needed to clean stale sessions.

Nextcloud Caching

Nextcloud benefits enormously from Redis for file locking and memory caching. If you have already followed our Nextcloud setup guide, add Redis caching by editing config.php:

php
'memcache.local' => '\OC\Memcache\Redis', 'memcache.distributed' => '\OC\Memcache\Redis', 'memcache.locking' => '\OC\Memcache\Redis', 'redis' => [ 'host' => '127.0.0.1', 'port' => 6379, 'password' => 'YOUR_PASSWORD', 'dbindex' => 0, 'timeout' => 1.5, ],

This replaces the default APCu cache for distributed caching and adds Redis-based file locking, which prevents database corruption during concurrent file operations.

Application Cache

Any application that repeatedly queries a database for the same data benefits from a Redis cache layer. The pattern is simple:

  1. Check Redis for the cached result
  2. If found (cache hit), return it
  3. If not found (cache miss), query the database, store the result in Redis with a TTL, return it

With Redis running on the same machine as your application and PostgreSQL, cache lookups take sub-millisecond time compared to multi-millisecond database queries.

Message Queue

Redis lists and streams provide lightweight message queue functionality. For background job processing (sending emails, resizing images, generating reports), Redis queues are simpler to operate than a full message broker like RabbitMQ. Tools like Sidekiq (Ruby), Laravel Horizon (PHP), and Celery (Python) all support Redis as a backend.

Rate Limiting

Redis's atomic increment and expiry operations make it ideal for rate limiting. Store a counter per IP address with a TTL matching your rate window. The INCR command is atomic and O(1), handling thousands of rate-limit checks per second without breaking a sweat.


ZFS Tuning for Redis

If your FreeBSD server runs ZFS (and it should), create a dedicated dataset for Redis data with settings tuned for its I/O patterns.

Create a ZFS Dataset

bash
zfs create -o mountpoint=/var/db/redis zroot/redis zfs set recordsize=64K zroot/redis zfs set compression=lz4 zroot/redis zfs set atime=off zroot/redis zfs set primarycache=metadata zroot/redis zfs set sync=disabled zroot/redis

Why these settings:

  • recordsize=64K: Redis writes RDB and AOF files sequentially. A 64K recordsize is optimal for sequential writes and reduces metadata overhead compared to the default 128K. Some operators prefer 128K for very large datasets -- benchmark both.
  • compression=lz4: RDB files compress well. LZ4 adds negligible CPU overhead for measurable space savings.
  • atime=off: Redis never needs access time tracking. Disabling it eliminates unnecessary write amplification.
  • primarycache=metadata: Redis manages its own data in memory. Caching Redis's data files in ZFS ARC is redundant and wastes RAM. Cache only metadata (block pointers, directory entries).
  • sync=disabled: This is the most controversial setting. Redis handles its own durability through RDB and AOF. ZFS's synchronous writes (sync=standard) add latency to every AOF fsync without providing additional safety -- Redis already fsyncs the AOF file itself. Disabling ZFS sync avoids double-fsyncing. Only do this if AOF is enabled. If you rely solely on RDB snapshots, keep sync=standard.

Set ownership after creating the dataset:

bash
chown redis:redis /var/db/redis

ZFS Snapshots for Backups

Take atomic snapshots of Redis data:

bash
zfs snapshot zroot/redis@backup-$(date +%Y%m%d-%H%M%S)

This completes in milliseconds regardless of dataset size. Schedule it with cron:

bash
# /etc/crontab -- snapshot Redis data every hour 0 * * * * root zfs snapshot zroot/redis@auto-$(date +\%Y\%m\%d-\%H\%M\%S)

Clean old snapshots with:

bash
# Keep only the last 48 hourly snapshots zfs list -t snapshot -o name -s creation | grep zroot/redis@ | head -n -48 | xargs -n1 zfs destroy

Performance Tuning

Redis is fast out of the box, but FreeBSD-specific tuning squeezes out the last bit of latency and throughput.

TCP Backlog

Redis defaults to a TCP backlog of 511. FreeBSD's default kern.ipc.somaxconn is 128, which silently truncates Redis's backlog setting. Increase it:

bash
sysctl kern.ipc.somaxconn=1024

Make it persistent:

shell
# /etc/sysctl.conf kern.ipc.somaxconn=1024

Memory Overcommit Equivalent

Linux has vm.overcommit_memory, which Redis documentation recommends setting to 1. FreeBSD does not have this setting. FreeBSD's virtual memory system handles overcommit differently -- it allows overcommit by default and manages it through its page daemon. No sysctl change is needed.

However, you must ensure enough free memory exists for Redis to fork during RDB saves and AOF rewrites. The fork creates a copy-on-write child process. If the dataset is 2GB and the workload modifies many keys during the save, the child may need up to 2GB of additional memory pages. Size your maxmemory accordingly -- leave headroom equal to maxmemory for fork safety on write-heavy workloads.

Transparent Huge Pages

This is a Linux-specific issue. FreeBSD does not use transparent huge pages and does not require the tuning that Redis warns about on Linux systems. One less thing to worry about.

File Descriptor Limits

Redis needs file descriptors for client connections and persistence files. Increase the limit for the redis user:

shell
# /etc/login.conf -- add or modify the redis class redis:\ :openfiles-cur=65536:\ :openfiles-max=65536:\ :tc=daemon:

Rebuild the login database:

bash
cap_mkdb /etc/login.conf

Ensure the redis user uses this class. Alternatively, set the limit in /usr/local/etc/rc.d/redis or use limits in the rc script.

CPU Affinity

On multi-core systems, pin Redis to a specific CPU to avoid cache invalidation from process migration:

bash
cpuset -l 0 service redis start

This pins the Redis process to CPU 0. On NUMA systems, ensure the chosen CPU is on the same NUMA node as Redis's memory allocation.

Network Tuning

For high-throughput Redis instances handling many small packets, increase socket buffer sizes:

shell
# /etc/sysctl.conf net.inet.tcp.recvbuf_max=2097152 net.inet.tcp.sendbuf_max=2097152 kern.ipc.maxsockbuf=8388608

FAQ

How much RAM does Redis need?

Redis stores all data in memory. Your RAM requirement equals your dataset size plus overhead. Redis overhead is roughly 50-100 bytes per key for bookkeeping, plus the actual key and value sizes. Use redis-cli INFO memory to monitor used_memory and used_memory_rss. Also reserve RAM equal to your dataset size for fork operations during RDB saves.

Can Redis persist data to disk?

Yes. Redis supports RDB snapshots, AOF logging, and a hybrid of both. With hybrid persistence (the recommended approach), you get fast restarts from the RDB preamble and minimal data loss from AOF. Redis is not purely in-memory -- persistence is a core feature, not an afterthought.

Should I use Redis or Memcached?

Redis. Memcached is a pure key-value cache with no persistence, no data structures, no pub/sub, no scripting, and no replication. Redis does everything Memcached does, plus much more. The only edge case for Memcached is multi-threaded caching of very large values, and even that gap has narrowed with Redis 7's I/O threading. On FreeBSD, Redis is the standard choice.

How do I run multiple Redis instances on one server?

Create separate configuration files with different ports, PID files, log files, and data directories. Then use FreeBSD's rc.conf profiles:

bash
sysrc redis_profiles="cache sessions" sysrc redis_cache_conf="/usr/local/etc/redis-cache.conf" sysrc redis_sessions_conf="/usr/local/etc/redis-sessions.conf"

Each profile runs as an independent Redis instance with its own configuration.

Is Redis Sentinel enough for production HA, or do I need Redis Cluster?

Sentinel is sufficient for most deployments. It provides automatic failover for a single master with replicas. Redis Cluster is needed only when your dataset exceeds the memory of a single server and you need to shard data across multiple masters. For a typical FreeBSD server with 32-128GB RAM, Sentinel handles the vast majority of workloads without the operational complexity of Cluster.

How do I upgrade Redis on FreeBSD?

bash
pkg update pkg upgrade redis service redis restart

Redis is backward-compatible with RDB and AOF files across minor versions. For major version upgrades (e.g., 6.x to 7.x), read the release notes for breaking changes, test in staging, and take a ZFS snapshot before upgrading.

How do I monitor Redis memory fragmentation?

Check mem_fragmentation_ratio in redis-cli INFO memory. Values between 1.0 and 1.5 are normal. Above 1.5 means significant fragmentation -- consider restarting Redis during a maintenance window to compact memory. Below 1.0 means Redis is using swap, which destroys performance. Increase available RAM or reduce maxmemory immediately.


Summary

Redis on FreeBSD is a clean, fast, and predictable combination. The installation is one package. The configuration is one file. Persistence, security, and high availability are all built in -- no third-party tools required. Combined with ZFS for backups and FreeBSD's stable kernel for memory management, you get a caching and data structure layer that runs for months without intervention.

Start with the redis.conf example above, adjust maxmemory for your hardware, enable hybrid persistence, set a strong password, and deploy. If you need high availability, add Sentinel. If you need monitoring, INFO and the slow log cover 90% of operational needs.

For the relational database that Redis complements, see our PostgreSQL setup guide. For a broader comparison of data stores available on FreeBSD, see our best database guide.

Get more FreeBSD guides

Weekly tutorials, security advisories, and package updates. No spam.