The Problem

Organizations building real-time applications need a data layer that handles caching, session storage, structured data, search, and vector queries without stitching together multiple services. Redis addresses this by providing a single in-memory data structure server with a rich command set, but running it at scale requires understanding its build system, module ecosystem, and operational constraints.

What This Does

This repository is the Redis source tree, forked from redis/redis. It contains the core server (src/, 647 files), bundled dependencies (deps/, 681 files), and a modules/ directory with 61 files including a vector-sets module for similarity search. The codebase is predominantly C (453 files) with supporting Lua scripts for server-side logic and Python tooling.

The src/ directory holds the server implementation, while deps/ vendors third-party libraries like hiredis (C client), jemalloc (allocator), and hdr_histogram (latency tracking). The modules/ directory contains loadable extensions, with vector-sets being the most substantial—it provides vector similarity search capabilities on top of Redis data structures.

How It Is Wired

The repository is a collection of self-contained projects rather than a single codebase. The core server builds via the root Makefile and deps/Makefile. Execution starts with the redis-server binary compiled from src/, which initializes the event loop, loads configuration, and accepts client connections on port 6379. The redis-cli client connects to it, and modules like vector-sets are loaded at runtime via the MODULE LOAD command.

The static analysis mapped 898 code files with zero import edges between internal modules—each component is isolated. The most connected modules (by import count) are all in deps/jemalloc/scripts/ and modules/vector-sets/examples/, none of which participate in circular dependencies. The vector-sets CLI tool at modules/vector-sets/examples/cli-tool/cli.py is a Python entry point for exercising the module.

How To Use It

# Build from source (requires make and a C compiler)
git clone https://github.com/moses-y/redis
cd redis
make

# Start the server
./src/redis-server

# Connect and test
./src/redis-cli ping

The Makefile handles the full build including dependencies in deps/. Configuration lives in redis.conf (not present in this structure—you'll need to create it or use defaults). TLS support requires building with make BUILD_TLS=yes, documented in TLS.md.

For the vector module, build it separately and load at runtime:

make -C modules/vector-sets
./src/redis-cli MODULE LOAD modules/vector-sets/vector-sets.so

Real-World Use

A typical deployment runs Redis as a cache in front of a primary database, with the vector-sets module enabling semantic search over embeddings. For example, a recommendation service stores user embeddings as vectors and queries for nearest neighbors:

-- Server-side Lua script for atomic vector operations
local result = redis.call('VSIM', 'user_embeddings', 'QUERY', KEYS[1], 'TOP', 10)
return result

The CLI tool at modules/vector-sets/examples/cli-tool/cli.py demonstrates the workflow: it indexes vectors from a file and runs recall tests against known datasets like GloVe-100.

Code Health & Issues

Static analysis found 383 issues (198 high, 183 medium, 2 low), all of one kind: deep nesting. The worst case is deps/hiredis/async.c with max indentation depth of 13, making control flow hard to follow. The fix is flattening with early returns and extracting inner blocks.

The SDLC audit found four issues, all in GitHub Actions workflows:

  • Medium - No least-privilege GITHUB_TOKEN permissions declared in .github/workflows/ci.yml (4 workflows affected). An injected step could push commits.
  • Medium - No dependency vulnerability scan in CI. Add dependency-review-action or osv-scanner.
  • Medium - persist-credentials: false missing in .github/workflows/reply-schemas-linter.yml; the checkout token remains available to later steps.
  • Low - No timeout-minutes on workflow jobs; a wedged step runs to the six-hour default.

Tests are present (575 files) and CI runs via Travis. No lockfile exists for Python dependencies, and no Dockerfile is provided.

The Bottom Line

This is the Redis codebase with an added vector-sets module—production-grade core, but the module is the differentiator here. The C code is mature and battle-tested; the workflow hygiene issues are minor but worth fixing before relying on CI. Use this if you need Redis with built-in vector search and are comfortable building from source and managing modules yourself.