redis/redis

Getting started

This page walks through cloning, building, running, and testing Redis from source. The full build instructions for every supported Linux/macOS distribution are in README.md; the commands here are the minimum you need to get the binary running.

Prerequisites

You need a C compiler (gcc 7+ or clang), GNU Make, and Tcl 8.6+ if you want to run the tests. Installing the right packages is OS-specific:

Platform	Packages
Ubuntu / Debian	`build-essential pkg-config tcl tcl-dev libssl-dev`
AlmaLinux / Rocky	`gcc make pkgconfig tcl tcl-devel openssl-devel`
macOS (Homebrew)	`xcode-select --install` then `brew install pkg-config openssl tcl-tk`

OpenSSL is only needed for TLS support. Tcl is needed for the integration test suite (Redis itself does not depend on Tcl at runtime).

Build

git clone https://github.com/redis/redis.git
cd redis
make

That produces six binaries in src/:

redis-server
redis-sentinel (a hard link to redis-server that starts in Sentinel mode)
redis-cli
redis-benchmark
redis-check-rdb and redis-check-aof (also links to redis-server)

The top-level Makefile is a thin wrapper around src/Makefile. The build dependencies in deps/ (jemalloc, Lua, hiredis, hdr_histogram, fpconv, xxhash) are built first into static archives, then linked into the final binaries.

Common build flags

make BUILD_TLS=yes              # link OpenSSL into redis-server (TLS available out of the box)
make BUILD_TLS=module           # build TLS as a loadable module (redis-tls.so)
make MALLOC=jemalloc            # default on Linux; explicit on other systems
make MALLOC=libc                # use the system allocator
make MALLOC=tcmalloc            # use Google's tcmalloc
make USE_SYSTEMD=yes            # link libsystemd for sd_notify support
make 32bit                      # 32-bit build with 4-byte pointers
make BUILD_WITH_MODULES=yes     # also build the optional in-tree module set under modules/
make V=1                        # verbose: show every gcc invocation
make OPTIMIZATION="-O0"         # debug build with no LTO

The default optimisation level is -O3 -flto[=auto] -fno-omit-frame-pointer.

Vector sets

Vector set support is built into redis-server automatically when the compiler advertises C11 atomics (the default for any modern toolchain). The implementation lives in modules/vector-sets/ and is compiled directly into the server binary; you only need BUILD_WITH_MODULES=yes to build the external module stubs that download additional modules from upstream.

Cleaning up

make clean            # remove .o files and binaries; keep deps/ build artifacts
make distclean        # also clean deps/

If the build picks up cached configuration (e.g. you switched between TLS on and off), make distclean is the safest way to force a full rebuild.

Run

cd src
./redis-server                    # uses an empty default configuration
./redis-server ../redis.conf      # production-ish defaults
./redis-server --port 7000 --save ""   # CLI overrides the config file

In another shell:

cd src
./redis-cli
redis> ping
PONG
redis> set foo bar
OK
redis> get foo
"bar"

Sentinel mode:

./redis-sentinel ../sentinel.conf      # or ./redis-server --sentinel

Cluster mode (three masters, three replicas, all on localhost):

cd utils/create-cluster
./create-cluster start
./create-cluster create
./create-cluster stop
./create-cluster clean

utils/create-cluster/create-cluster is the canonical scripted way to spin a six-node cluster for development.

Test

The unit + integration suite is driven by a Tcl harness:

./runtest                           # full unit suite
./runtest --single unit/scripting   # only one file
./runtest --tags slow               # restrict by tag
./runtest --accurate                # run more iterations of probabilistic tests
./runtest --tls                     # enable TLS in the test framework
./runtest-cluster                   # cluster integration suite
./runtest-sentinel                  # sentinel integration suite
./runtest-moduleapi                 # module API tests, builds module .so files first

Module API tests live in tests/unit/moduleapi/ and tests/modules/. The runtest-moduleapi wrapper builds the helper modules (tests/modules/*.c) before invoking the harness.

The C unit tests embedded in the server (e.g. dict, sds, ziplist, listpack, t-digest, bloom, vset) are reachable via:

./redis-server test all              # run every embedded test
./redis-server test dict --accurate  # one test, more iterations

These are compiled in only if make REDIS_CFLAGS=-DREDIS_TEST was used.

Lint and validation

There is no traditional C linter in the repository, but several validators are run in CI:

Tool	Purpose	Where
`utils/generate-command-code.py`	Regenerates `src/commands.def` from `src/commands/*.json` and verifies the result.	CI: `.github/workflows/reply-schemas-linter.yml`.
`utils/req-res-log-validator.py`	Validates that command reply schemas match real replies captured during tests.	`daily.yml`.
`utils/reply_schema_linter.js`	JSON-Schema linter for the reply schemas embedded in `src/commands/*.json`.	`reply-schemas-linter.yml`.
`cppcheck`, `clang-tidy`, Coverity	Static analysis.	`coverity.yml`, `daily.yml`.
`codespell` (config in `.codespell/`)	Spelling.	`spell-check.yml`.
`CodeQL`	Security analysis.	`codeql-analysis.yml`.

To regenerate the command table after editing JSON files:

cd src
make commands.def         # invokes utils/generate-command-code.py