hristostaykov-del 7716edb651 Verify the TLS server identity by default in redis-cli, redis-benchmark and Sentinel (#16033)
Followup #15492

## Verify the TLS server identity by default in redis-cli,
redis-benchmark and Sentinel - Breaking change for TLS users of these
tools - see "Impact on existing deployments"

## What this PR contains

1. **Verify the TLS server identity by default** in the three tools (the
change).
2. **Reject IP addresses in `tls-expected-peer-name`.** The server
option is
defined as DNS names only; an IP address configured there matched
nothing
and rejected every peer, so it is now refused when the configuration is
   loaded or set.
3. **Share the TLS peer identity primitive.** `tls.c`, `cli_common.c`
and
`sentinel.c` each had a copy of the OpenSSL calls that bind an expected
identity; they are consolidated into `tlshelpers.h`. No behavior change.
4. **Sentinel: retry the Pub/Sub link when TLS setup fails.**
Pre-existing: a
   failed TLS setup left the Pub/Sub link dead until restart.
5. **Add a positive control to the cluster-bus impersonation test**, so
its
   log-absence assertion cannot pass vacuously.

## Background

A TLS client checks two things about a server certificate: that a
trusted CA
issued it (the "chain"), and that it was issued for the server being
contacted (the "identity": the host name or IP in the certificate's
Subject
Alternative Name). `redis-cli`, `redis-benchmark` and Sentinel's
connections
to the instances it monitors checked only the chain. So anyone holding
any
certificate from the same CA — under a shared or public CA — could
impersonate
a Redis server to them and receive the `AUTH` credentials they send.
Sentinel
makes these connections on its own, continuously, for every master,
replica
and sentinel it monitors.

## What changes

The three tools now also verify the identity, as a browser or `curl`
would.
The identity they expect is, in order of preference:

1. **An explicitly configured name**: `--tls-expected-peer-name` for the
tools (DNS names, or a single IP address), `tls-expected-peer-name` for
   Sentinel (DNS names only, as for the rest of the server). Meant for
   deployments where every node's certificate carries one shared name,
including cluster mode, where node addresses come from the cluster
itself.
2. **The name given to `--sni`**, which is now both sent to the server
and
   verified (before, it was only sent).
3. **The host that was dialed**: an IP is matched against the IP entries
of
   the certificate, a DNS name against its DNS entries.

A dialed DNS name is also sent as SNI by default. Redis itself serves
one
certificate and ignores SNI; this is for a TLS proxy or load balancer in
front
of it that routes by SNI or presents the certificate for that name.

Two opt-outs: `--no-verify-hostname` keeps the chain check but skips the
identity check; `--insecure` skips both, as before. Neither may be
combined
with an explicit expected name, as it could not be honored. A rejected
certificate produces a message naming the identity that was expected and
these remedies, instead of OpenSSL's `certificate verify failed`.

## Sentinel

New option `sentinel tls-verify-hostnames yes|no` (default `yes`;
changeable
at runtime with `SENTINEL CONFIG SET`, applying to links made
afterwards).
Sentinel verifies the address it knows an instance by, and sends it as
the
server name when it is a DNS name. The option governs only that address
check: when `tls-expected-peer-name` is configured, that name is
verified
instead, on every link, whatever the option says. A mismatch is logged
as a
WARNING event, `-tls-identity-mismatch`, that names the expected
identity and
the remedies; a link failing at DEBUG level only would otherwise leave a
Sentinel that lost every link with nothing visible in its log.

## Impact on existing deployments

This is a breaking change for TLS users of these tools, to be listed as
such
in the release notes. Affected are `redis-cli` and `redis-benchmark` run
with
`--tls`, and Sentinel with `tls-replication yes`; plaintext connections
are
untouched.

Certificates must now carry the identity these tools dial. Most Redis
deployments connect by IP — Sentinel always does unless
`resolve-hostnames`
is enabled — and an IP is matched only against the certificate's `IP
Address`
SAN entries: DNS entries are not consulted and there is no fallback to
the
Common Name. A certificate whose SAN lists only DNS names, or that has
no SAN
and relies on its Common Name, is therefore rejected when the tool
connects by
IP, even though it is accepted when the tool connects by a DNS name it
carries. Operators must reissue certificates with the IP in the SAN, pin
a
shared DNS name with `tls-expected-peer-name`, or set the opt-out
`--no-verify-hostname` for `redis-cli` and `redis-benchmark`, 
`sentinel tls-verify-hostnames no` for Sentinel.

`tls-expected-peer-name` now refuses IP addresses, from the config file
and
from `CONFIG SET`. This also affects replication, the cluster bus and
`MIGRATE`. Such a value never matched a certificate, so any deployment
that
had one was already failing every connection with only `certificate
verify failed`
to show for it; it now fails to load with a message that says why.

The test certificates change accordingly: `server.crt` now carries
`127.0.0.1`, `::1` and `localhost`, so `utils/gen-test-certs.sh` must be
re-run; `redis.crt` keeps no identity on purpose, as the fixture for the
negative tests.

## Unchanged on purpose

Connections between servers (replication, cluster bus, `MIGRATE`) keep
the
existing behaviour: chain check by default, identity only with
`tls-expected-peer-name`. Their peer addresses are learned from other
nodes,
so pinning a configured name fits them better than trusting the dialed
address. The only change on that path is the IP rejection above. The
bundled
hiredis library is also untouched; these tools do not use its TLS
context
API.

## Also fixed

As the new failure mode exposed them:

- `redis-benchmark` looped forever on a fatal TLS error on a
non-blocking
  connection (the error was reported as "try again").
- `redis-cli` printed a TLS failure twice because its silent probe
connection
  did not honor the quiet flag.
- Sentinel never retried its Pub/Sub link after a TLS setup failure: the
dead
  context stayed in place and counted as connected, so the instance lost
Hello traffic until restart. The command link already closed its context
in
  that case; the Pub/Sub link now does the same.

## Build

The check uses OpenSSL's `X509_VERIFY_PARAM` API (OpenSSL 1.0.2+). The
availability test and the one function that binds an expected identity
to a
connection (`tlsVerifyParamAddIdentity()`) live in the new
`src/tlshelpers.h`,
shared by `tls.c`, `sentinel.c` and the tools, so OpenSSL's subtleties —
IP
versus DNS matching, explicit lengths for BoringSSL, wildcard flags —
are in
one place. Building against an older OpenSSL fails unless
`TLS_NO_PEER_NAME_VERIFICATION` is defined, which compiles the check
out; the
tools then verify the chain only and say so once, and an explicit
expected
name is refused rather than ignored.

## Tests

- `tests/unit/tls.tcl`: the default by IP and by DNS name, `--sni`,
expected-name precedence, rejection of a trusted certificate lacking the
address, both opt-outs, invalid and conflicting options, the check
running
before `AUTH` is sent, `redis-benchmark`, and the config-time rejection
of
  IP addresses in `tls-expected-peer-name`.
- `tests/sentinel/tests/17-tls-verify-hostnames.tcl`: the default,
rejection
and its WARNING event, the runtime opt-out and its persistence, and the
  `tls-expected-peer-name` override.
- `tests/unit/cluster/tls-peer-impersonation.tcl`: a positive control
that
replays the forged FAIL through a certificate carrying the cluster SAN
and
  sees it processed, so the negative test's log-absence assertion is
  meaningful.
2026-10-26 14:40:46 +02:00
2019-03-18 15:49:52 +01:00

codecov

This document serves as both a quick start guide to Redis and a detailed resource for building it from source.

Table of contents

What is Redis?

For developers, who are building real-time data-driven applications, Redis is the preferred, fastest, and most feature-rich cache, data structure server, and document and vector query engine.

Key use cases

Redis excels in various applications, including:

  • Caching: Supports multiple eviction policies, key expiration, and hash-field expiration.
  • Distributed Session Store: Offers flexible session data modeling (string, JSON, hash).
  • Data Structure Server: Provides low-level data structures (strings, lists, sets, hashes, sorted sets, JSON, etc.) with high-level semantics (counters, queues, leaderboards, rate limiters) and supports transactions & scripting.
  • NoSQL Data Store: Key-value, document, and time series data storage.
  • Search and Query Engine: Indexing for hash/JSON documents, supporting vector search, full-text search, geospatial queries, ranking, and aggregations via Redis Search.
  • Event Store & Message Broker: Implements queues (lists), priority queues (sorted sets), event deduplication (sets), streams, and pub/sub with probabilistic stream processing capabilities.
  • Vector Store for GenAI: Integrates with AI applications (e.g. LangGraph, mem0) for short-term memory, long-term memory, LLM response caching (semantic caching), and retrieval augmented generation (RAG).
  • Real-Time Analytics: Powers personalization, recommendations, fraud detection, and risk assessment.

Why choose Redis?

Redis is a popular choice for developers worldwide due to its combination of speed, flexibility, and rich feature set. Here's why people choose Redis for:

  • Performance: Because Redis keeps data primarily in memory and uses efficient data structures, it achieves extremely low latency (often sub-millisecond) for both read and write operations. This makes it ideal for applications demanding real-time responsiveness.
  • Flexibility: Redis isn't just a key-value store, it provides native support for a wide range of data structures and capabilities listed in What is Redis?
  • Extensibility: Redis is not limited to the built-in data structures, it has a modules API that makes it possible to extend Redis functionality and rapidly implement new Redis commands
  • Simplicity: Redis has a simple, text-based protocol and well-documented command set
  • Ubiquity: Redis is battle tested in production workloads at a massive scale. There is a good chance you indirectly interact with Redis several times daily
  • Versatility: Redis is the de facto standard for use cases such as:
    • Caching: quickly access frequently used data without needing to query your primary database
    • Session management: read and write user session data without hurting user experience or slowing down every API call
    • Querying, sorting, and analytics: perform deduplication, full text search, and secondary indexing on in-memory data as fast as possible
    • Messaging and interservice communication: job queues, message brokering, pub/sub, and streams for communicating between services
    • Vector operations: Long-term and short-term LLM memory, RAG content retrieval, semantic caching, semantic routing, and vector similarity search

In summary, Redis provides a powerful, fast, and flexible toolkit for solving a wide variety of data management challenges. If you want to know more, here is a list of starting points:

What is Redis Open Source?

Redis Community Edition (Redis CE) was renamed Redis Open Source with the v8.0 release.

Redis Ltd. also offers Redis Software, a self-managed software with additional compliance, reliability, and resiliency for enterprise scaling, and Redis Cloud, a fully managed service integrated with Google Cloud, Azure, and AWS for production-ready apps.

Read more about the differences between Redis Open Source and Redis here.

Getting started

If you want to get up and running with Redis quickly without needing to build from source, use one of the following methods:

If you prefer to build Redis from source - see instructions below.

Redis starter projects

To get started as quickly as possible in your language of choice, use one of the following starter projects:

Using Redis with client libraries

To connect your application to Redis, you will need a client library. Redis has documented client libraries in most popular languages, with community-supported client libraries in additional languages.

Using Redis with redis-cli

redis-cli is Redis' command line interface. It is available as part of all the binary distributions and when you build Redis from source.

You can start a redis-server instance, and then, in another terminal try the following:

cd src
./redis-cli
redis> ping
PONG
redis> set foo bar
OK
redis> get foo
"bar"
redis> incr mycounter
(integer) 1
redis> incr mycounter
(integer) 2
redis>

Using Redis with Redis Insight

For a more visual and user-friendly experience, use Redis Insight - a tool that lets you explore data, design, develop, and optimize your applications while also serving as a platform for Redis education and onboarding. Redis Insight integrates Redis Copilot, a natural language AI assistant that improves the experience when working with data and commands.

Redis data types, processing engines, and capabilities

Redis provides a variety of data types, processing engines, and capabilities to support a wide range of use cases:

  • String: Sequences of bytes, including text, serialized objects, and binary arrays used for caching, counters, and bitwise operations.
  • JSON: Nested JSON documents that are indexed and searchable using JSONPath expressions and with Redis Search
  • Array: Sparse, index-addressable collection of string values
  • Hash: Field-value maps used to represent basic objects and store groupings of key-value pairs with support for hash field expiration (TTL)
  • Redis Search: Use Redis as a document database, a vector database, a secondary index, and a search engine. Define indexes for hash and JSON documents and then use a rich query language for vector search, full-text search, geospatial queries, and aggregations.
  • List: Linked lists of string values used as stacks, queues, and for queue management.
  • Set: Unordered collection of unique strings used for tracking unique items, relations, and common set operations (intersections, unions, differences).
  • Sorted set: Collection of unique strings ordered by an associated score used for leaderboards and rate limiters.
  • Vector set (beta): Collection of vector embeddings used for semantic similarity search, semantic caching, semantic routing, and Retrieval Augmented Generation (RAG).
  • Geospatial indexes: Coordinates used for finding nearby points within a given radius or bounding box.
  • Bitmap: A set of bit-oriented operations defined on the string type used for efficient set representations and object permissions.
  • Bitfield: Binary-encoded strings that let you set, increment, and get integer values of arbitrary bit length used for limited-range counters, numeric values, and multi-level object permissions such as role-based access control (RBAC)
  • Hyperloglog: A probabilistic data structure for approximating the cardinality of a set used for analytics such as counting unique visits, form fills, etc.
  • *Bloom filter: A probabilistic data structure to check if a given value is present in a set. Used for fraud detection, ad placement, and unique column (i.e. username/email/slug) checks.
  • *Cuckoo filter: A probabilistic data structure for checking if a given value is present in a set while also allowing limited counting and deletions used in targeted advertising and coupon code validation.
  • *t-digest: A probabilistic data structure used for estimating the percentile of a large dataset without having to store and order all the data points. Used for hardware/software monitoring, online gaming, network traffic monitoring, and predictive maintenance.
  • *Top-k: A probabilistic data structure for finding the most frequent values in a data stream used for trend discovery.
  • *Count-min sketch: A probabilistic data structure for estimating how many times a given value appears in a data stream used for sales volume calculations.
  • Time series: Data points indexed in time order used for monitoring sensor data, asset tracking, and predictive analytics
  • Pub/sub: A lightweight messaging capability. Publishers send messages to a channel, and subscribers receive messages from that channel.
  • Stream: An append-only log with random access capabilities and complex consumption strategies such as consumer groups. Used for event sourcing, sensor monitoring, and notifications.
  • Transaction: Allows the execution of a group of commands in a single step. A request sent by another client will never be served in the middle of the execution of a transaction. This guarantees that the commands are executed as a single isolated operation.
  • Programmability: Upload and execute Lua scripts on the server. Scripts can employ programmatic control structures and use most of the commands while executing to access the database. Because scripts are executed on the server, reading and writing data from scripts is very efficient.

Cloud hosted Redis

Fully-managed Redis with real-time performance at scale.

Redis Cloud

Community

Redis Community Resources

Build Redis from source

This section refers to building Redis from source. If you want to get up and running with Redis quickly without needing to build from source see the Getting started section.

These instructions apply to Redis 8.10 and above. For versions lower than 8.10, see the 8.8 build instructions.

Configuration files: the build steps below tell you to run ./src/redis-server redis.conf. Release tarballs bake the bundled modules' loadmodule lines and per-module settings directly into redis.conf during packaging, so an extracted release tarball is ready to run as-is. When building from a git checkout instead, that module config lives in the auto-generated redis-full.conf produced by make modules-update (and regenerated by make sync-redis-conf) — run ./src/redis-server redis-full.conf there. Edit Redis-core settings in redis.conf. See modules/MODULES.md for the full config flow.

Install dependencies and build

Building Redis with all data structures (JSON, time series, Bloom / cuckoo / count-min / top-k, t-digest, and the Query Engine) needs a build toolchain plus a few version-sensitive dependencies — GCC/Clang, LLVM 21, CMake 3.25–3.31.6, Rust 1.94, OpenSSL, Python 3, and assorted -dev libraries. Instead of a per-OS package list, the repo installs them for you with make bootstrap, which detects your OS and installs each bundled module's prerequisites.

CMake version range matters. The modules require 3.25 ≤ CMake ≤ 3.31.6 — CMake 4.x is not supported and the build will fail with it. On distros that ship CMake 4.x by default (e.g. Ubuntu 26.04), pin a supported version, e.g. pip3 install 'cmake==3.31.6'. Note make bootstrap only installs CMake when it's missing or too old; it won't downgrade a pre-installed 4.x, so remove/pin that yourself.

1. Get the source

Either works — the release tarball already bundles the module sources; a git checkout needs one extra step to fetch them:

# A) Release tarball (recommended for building/running a release).
#    Replace <version> with the release tag — extracts into redis-<version>/:
wget https://github.com/redis/redis/releases/download/<version>/redis-full-<version>.tar.gz
tar xvf redis-full-<version>.tar.gz && cd redis-<version>

# B) git checkout — clone the bundled modules once:
git clone https://github.com/redis/redis.git && cd redis
make modules-update

Check the release page's Assets for the bundle filename. Older releases, including 8.10.0 and 8.10.2, provide redis-full.tar.gz instead of the versioned filename. For those releases, replace the wget command above with the following; the extraction command stays the same:

wget -O redis-full-<version>.tar.gz https://github.com/redis/redis/releases/download/<version>/redis-full.tar.gz

2. Install the build dependencies

Pick whichever option fits your environment:

  1. Build inside the Docker build environment — recommended. The repo ships docker/Dockerfile.noble (Ubuntu 24.04) with every prerequisite baked in, so you build inside the container and never touch your host toolchain:

    docker build -f docker/Dockerfile.noble -t redis-build:noble .
    
    # Multi-arch (requires `docker buildx` configured):
    docker buildx build --platform linux/amd64,linux/arm64 \
        -f docker/Dockerfile.noble -t redis-build:noble .
    
    # Build with the working tree mounted:
    docker run --rm -it -v "$PWD":/workspace -w /workspace redis-build:noble \
        bash -lc 'make -j"$(nproc)" && make run'
    
  2. Install everything on a fresh machine or container. On a clean environment (for example a throwaway ubuntu:24.04 container), let bootstrap install every prerequisite for Redis core and all cloned modules:

    make bootstrap
    

    ⚠️ make bootstrap installs system packages and may override existing versions of shared tools (compiler, CMake, LLVM, …). Prefer option 1, or run it in a disposable container, if that matters on your machine.

  3. See only what's missing. To inspect which prerequisites are absent before installing anything, print one deduped list across Redis core and all modules:

    make bootstrap list
    

    Then install just the reported packages yourself. (Version-gated deps are shown as name (>= X); optional test/coverage deps are listed separately and don't fail the check.)

  4. Get the exact install commands to copy-paste. To run exactly what make bootstrap would, but only for the missing dependencies, use dry-run — it prints the precise install command for each missing dependency and installs nothing:

    make bootstrap dry-run
    

    The commands are printed per module, so a dependency shared by several modules appears once for each. Work through them iteratively:

    1. Copy-paste the commands for a module to install its dependencies.
    2. Re-run make bootstrap dry-run — the deps you just installed no longer show, so you now see only what's still missing for the remaining modules.
    3. Repeat until make bootstrap dry-run prints no install commands.

Manual, per-OS install (no Docker, and you'd rather not let make bootstrap touch your host): follow the per-OS dependency instructions in the 8.8 README, which still lists them explicitly — https://github.com/redis/redis/tree/8.8#readme.

3. Build and run

export BUILD_TLS=yes            # optional — TLS support (needs OpenSSL dev libs)
make -j "$(nproc)"

# Release tarball (module config is baked into redis.conf):
./src/redis-server redis.conf
# From a git checkout, use the auto-generated module config instead:
./src/redis-server redis-full.conf

make (same as make build / make all) builds whatever is cloned under modules/*/src alongside Redis core. To build just the core data structures — even with modules cloned — use make build redis.

redis-server won't start: "Error loading the extension" / can't open a .so. The config still lists modules that weren't built successfully — a release tarball's redis.conf carries loadmodule lines for every bundled module, and a module whose build failed leaves no .so behind. Either build them (make bootstrap && make, or make build <name> for the one that failed), or comment out everything that isn't Redis core in the config you pass: the loadmodule <path> lines and that module's own settings below them (e.g. search-*, ts-*, bf-*, json-*). Core-only alternative: ./src/redis-server with no config file, or make build redis && ./src/redis-server redis.conf from a git checkout, where redis.conf has no module block at all.

4. Install

make install PREFIX=/usr/local          # core binaries + every built module
sudo make install                       # same, into the default /usr/local
make uninstall PREFIX=/usr/local        # removes exactly what install placed

install is an alias for deploy: it builds first (nothing already up to date is recompiled), copies redis-server, redis-cli and redis-benchmark plus the three redis-server symlinks to $PREFIX/bin, each module's .so to $PREFIX/lib/redis/modules, and rewrites the loadmodule paths in the generated config to point there. DESTDIR=<path> stages the files for packaging without changing the paths written to the config, and PROG_SUFFIX=<suffix> installs suffixed program names (redis-server-alt, …).

To install without building at all, use SKIP_BUILD=1: sudo make install SKIP_BUILD=1

Building Redis - flags and general notes

Redis can be compiled and used on Linux, OSX, OpenBSD, NetBSD, FreeBSD. We support big endian and little endian architectures, and both 32 bit and 64-bit systems.

It may compile on Solaris derived systems (for instance SmartOS) but our support for this platform is best effort and Redis is not guaranteed to work as well as on Linux, OSX, and *BSD.

To build Redis with all the data structures (including JSON, time series, Bloom filter, cuckoo filter, count-min sketch, top-k, and t-digest) and with Redis Query Engine, make sure first that all the prerequisites are installed (see Install dependencies and build above), then clone the bundled modules once and build:

make modules-update
make

make (same as make build / make all) always builds whatever's cloned under modules/*/src alongside Redis core — there's no separate flag to opt in. If nothing is cloned yet, you get a core-only build.

To build Redis with just the core data structures — even if modules are already cloned — use:

make build redis

To build with TLS support, you need OpenSSL development libraries (e.g. libssl-dev on Debian/Ubuntu) and the following flag in the make command:

make BUILD_TLS=yes

To build with systemd support, you need systemd development libraries (such as libsystemd-dev on Debian/Ubuntu or systemd-devel on CentOS), and the following flag:

make USE_SYSTEMD=yes

To append a suffix to Redis program names, add the following flag:

make PROG_SUFFIX="-alt"

You can build a 32 bit Redis binary using:

make 32bit

After building Redis, it is a good idea to test it using:

make test

If TLS is built, running the tests with TLS enabled (you will need tcl-tls installed):

./utils/gen-test-certs.sh
./runtest --tls

Redis supports compression of replication stream via zstd as of 8.10. To build with compression support you have to install zstd development libraries (e.g libzstd-dev on Debian/Ubuntu) and use the following flag when invoking the make command:

make BUILD_COMPRESSION=yes

Fixing build problems with dependencies or cached build options

Redis has some dependencies which are included in the deps directory. make does not automatically rebuild dependencies even if something in the source code of dependencies changes.

When you update the source code with git pull or when code inside the dependencies tree is modified in any other way, make sure to use the following command in order to really clean everything and rebuild from scratch:

make distclean

This will clean: jemalloc, lua, hiredis, linenoise and other dependencies.

Also, if you force certain build options like 32bit target, no C compiler optimizations (for debugging purposes), and other similar build time options, those options are cached indefinitely until you issue a make distclean command.

Fixing problems building 32 bit binaries

If after building Redis with a 32 bit target you need to rebuild it with a 64 bit target, or the other way around, you need to perform a make distclean in the root directory of the Redis distribution.

In case of build errors when trying to build a 32 bit binary of Redis, try the following steps:

  • Install the package libc6-dev-i386 (also try g++-multilib).
  • Try using the following command line instead of make 32bit: make CFLAGS="-m32 -march=native" LDFLAGS="-m32"

Allocator

Selecting a non-default memory allocator when building Redis is done by setting the MALLOC environment variable. Redis is compiled and linked against libc malloc by default, except for jemalloc being the default on Linux systems. This default was picked because jemalloc has proven to have fewer fragmentation problems than libc malloc.

To force compiling against libc malloc, use:

make MALLOC=libc

To compile against jemalloc on Mac OS X systems, use:

make MALLOC=jemalloc

Monotonic clock

By default, Redis will build using the POSIX clock_gettime function as the monotonic clock source. On most modern systems, the internal processor clock can be used to improve performance. Cautions can be found here: http://oliveryang.net/2015/09/pitfalls-of-TSC-usage/

On ARM aarch64 systems, the hardware clock is enabled by default because the ARM Generic Timer is architecturally guaranteed to be available and monotonic on all ARMv8-A processors (see the “The Generic Timer in AArch64 state” section of the Arm Architecture Reference Manual for Armv8-A).

To build with support for the processor's internal instruction clock on other architectures, use:

make CFLAGS="-DUSE_PROCESSOR_CLOCK"

Verbose build

Redis will build with a user-friendly colorized output by default. If you want to see a more verbose output, use the following:

make V=1

Running Redis with TLS

Please consult the TLS.md file for more information on how to use Redis with TLS.

Running Redis with the Query Engine and optional proprietary Intel SVS-VAMANA optimisations

License Disclaimer If you are using Redis Open Source under AGPLv3 or SSPLv1, you cannot use it together with the Intel Optimizations (Leanvec and LVQ binaries). The reason is that the Intel SVS license is not compatible with those licenses. The Leanvec and LVQ techniques are closed source and are only available for use with Redis Open Source when distributed under the RSALv2 license. For more details, please refer to the information provided by Intel here.

By default, Redis with the Redis Query Engine supports SVS-VAMANA index with global 8-bit quantisation. To compile Redis with the Intel SVS-VAMANA optimisations, LeanVec and LVQ, use the following:

make BUILD_INTEL_SVS_OPT=yes

Alternatively, you can export the variable before running the build step for your platform:

export BUILD_INTEL_SVS_OPT=yes
make

Code contributions

By contributing code to the Redis project in any form, including sending a pull request via GitHub, a code fragment or patch via private email or public discussion groups, you agree to release your code under the terms of the Redis Software Grant and Contributor License Agreement. Please see the CONTRIBUTING.md file in this source distribution for more information. For security bugs and vulnerabilities, please see SECURITY.md and the description of the ability of users to backport security patches under Redis Open Source 7.4+ under BSDv3. Open Source Redis releases are subject to the following licenses:

  1. Version 7.2.x and prior releases are subject to BSDv3. These contributions to the original Redis core project are owned by their contributors and licensed under the 3BSDv3 license as referenced in the REDISCONTRIBUTIONS.txt file. Any copy of that license in this repository applies only to those contributions;

  2. Versions 7.4.x to 7.8.x are subject to your choice of RSALv2 or SSPLv1; and

  3. Version 8.0.x and subsequent releases are subject to the tri-license RSALv2/SSPLv1/AGPLv3 at your option as referenced in the LICENSE.txt file.

Redis Trademarks

The purpose of a trademark is to identify the goods and services of a person or company without causing confusion. As the registered owner of its name and logo, Redis accepts certain limited uses of its trademarks, but it has requirements that must be followed as described in its Trademark Guidelines available at: https://redis.io/legal/trademark-policy/.

Languages
C 66.6%
Tcl 30.4%
Python 1.7%
Shell 0.7%
Makefile 0.3%
Other 0.2%