# Valkey: Building and Running the Redis Fork Without the Licence Change

> Valkey is a C key-value server forked from Redis before its move to source-available licensing. This covers what the fork changes, how to build it from source, and where the README stops short.

**valkey-io/valkey** — A flexible distributed key-value database that is optimized for caching and other realtime workloads.

- Repository: https://github.com/valkey-io/valkey
- Website: https://valkey.io
- Stars: 27,322 · Forks: 1,334
- Language: C
- License: BSD-3-Clause
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/valkey-io-valkey

## What the fork from Redis actually changes for an operator

The README opens with the reason the project exists: it "was forked from the open source Redis project right before the transition to their new source available licenses." That single sentence is the whole pitch. Valkey is not a rewrite and not a new data model. It is the same data structure server, kept under a licence the repository states as BSD-3-Clause and filed under COPYING and a LICENSES directory. The topics list confirms the framing: cache, database, key-value, nosql, redis.

The audience follows from that. If your application already speaks the Redis wire protocol, the migration question is not about client code but about licence review and about which build you run in production. Operators who need a permissive licence on a key-value server, and who are comfortable compiling C, are the people this is aimed at. Anyone hoping for a different architecture, a new query layer, or a managed control plane will not find it here. The README describes a server binary and a configuration file, nothing more.

## The build system, the allocator, and the clock you get by default

The top-level Makefile is a thin wrapper: its only real content is a default target and an install target that both descend into src with $(MAKE). All build logic lives in src/Makefile, and the README treats make as the entry point.

Three defaults are worth knowing before you compile. First, the allocator: on Linux, jemalloc is the default, chosen, per the README, because it "has proven to have fewer fragmentation problems than libc malloc." Elsewhere libc malloc is the default. Second, the clock: on x86_64 Linux and aarch64 the server uses the processor instruction clock for monotonic time, which the README says is roughly 3x faster than POSIX clock_gettime, with an automatic fallback on unsupported systems. Third, the build is incremental in a way that can surprise you. The README is explicit that make does not rebuild bundled dependencies in deps even when their source changes, and that build options such as a 32bit target are cached indefinitely. The escape hatch is make distclean.

That caching behaviour is the most common source of confusing build failures, and the README addresses it directly rather than leaving it to a wiki. If you switch between 32 bit and 64 bit targets, distclean first.

## Installing Valkey from source and starting a server

The README documents no package repository, no installer script, and no container image. The path it gives is compile and run. On a Debian-like system you need a C toolchain; TLS and RDMA builds add their own development libraries, and the README names libssl-dev, librdmacm-dev and libibverbs-dev as examples.

The default build is one command from the repository root:

```bash
make
```

After it finishes, the README suggests running the test suite before trusting the binary. The main integration tests, plus the unit, module API, sentinel and cluster suites, are separate targets:

```bash
make test
make test-unit
make test-cluster
```

To start a server with the default configuration, change into src and run the binary. The README shows exactly this:

```bash
cd src
./valkey-server
```

To use your own configuration file, pass its path as the first argument. The README also shows that any valkey.conf option can be given on the command line with the same name, which is how you would start a second instance on a different port or point a node at a replica:

```bash
./valkey-server /path/to/valkey.conf
./valkey-server --port 9999 --replicaof 127.0.0.1 6379
```

For TLS there is a manual path. Assuming the sample certificates were generated with utils/gen-test-certs.sh, the README gives a built-in TLS invocation that disables the plaintext port entirely by setting it to 0:

```bash
./src/valkey-server --tls-port 6379 --port 0 \
    --tls-cert-file ./tests/tls/valkey.crt \
    --tls-key-file ./tests/tls/valkey.key
```

The README does not print an expected startup banner, so the thing to check is that the process stays in the foreground and reports the port it bound. If you built TLS as a module rather than built-in, note the README's warning that sentinel mode does not support the TLS module.

## Where the README leaves you on your own

The quick start is genuinely quick, and that is also its limitation. It documents no Windows build. It documents no Docker image, no Helm chart, no Kubernetes operator, and no cloud service, even though people search for those combinations. The repository topics include valkey-client, but the README names no client library and no language binding, so a reader looking for a Python or Node.js driver gets nothing from this document and has to go to valkey.io.

Configuration is the bigger gap. The README points at valkey.conf and states that its options double as command-line flags, but it does not enumerate them, does not describe persistence modes, eviction policy, or cluster topology, and does not document rollback or downgrade. If you are evaluating Valkey for a workload that depends on a specific eviction behaviour or a specific replication guarantee, this README will not answer the question. That is not a defect in the software; it is a boundary of the document, and it is worth being clear about which one you are reading.

There is a maintenance signal worth noting plainly: the last push to the repository was on 2026-09-20, and the release list shows 9.2.0-rc1 on 2026-09-16 alongside 9.0.6 and 9.1.2 on 2026-09-01. The unstable branch is the default branch, which is unusual for a project people deploy. Cloning the repository gives you unstable unless you ask for something else.

## Valkey against Redis, and against a different kind of store

The obvious alternative is Redis, and the difference is not technical behaviour so much as licensing and governance. Valkey's README frames the fork as happening right before Redis moved to source-available licences; Valkey stays BSD-3-Clause. If your organisation can accept the newer Redis licence, staying put costs you nothing in migration effort. If it cannot, the fork is the point.

A less obvious comparison is with a store that is not a data structure server at all. Valkey holds values in memory and exposes structures such as lists, sets and hashes through commands, with an extensible plugin system for adding more. A disk-oriented key-value engine trades that command surface and in-memory speed for datasets that do not fit in RAM. Choosing Valkey means accepting that the working set lives in memory and that your capacity planning is about memory, not disk. The README's allocator discussion, jemalloc versus libc malloc and the fragmentation note, is a reminder that this is the axis that matters.

Within the Redis-compatible family, the practical difference between distributions is packaging. Some come with an installer and a service unit; Valkey's README gives you make, a binary in src, and a configuration file. That is a deliberate trade: fewer moving parts to trust, more work for you.

## Licence, upgrade cost, and what the release list tells you

The repository states BSD-3-Clause, with COPYING and a LICENSES directory at the top level and a REUSE.toml for machine-readable licence metadata. For most users that means permissive redistribution, but the bundled deps directory pulls in jemalloc, Lua, libvalkey, linenoise and others, each with its own terms. If you redistribute a Valkey build, the licence files in that tree are the ones to read. This is a description of what the repository contains, not legal advice.

Upgrade cost is shaped by the release cadence visible in the repository. There are three recent releases in the list: 9.2.0-rc1 from 2026-09-16, and 9.0.6 and 9.1.2 both from 2026-09-01. A release candidate and two patch releases on the same day suggests parallel maintenance lines, so pinning to a patch release rather than tracking the unstable default branch is the lower-risk choice. The README does not document an in-place upgrade procedure or a downgrade path, so the compatibility question has to be answered from the release notes at 00-RELEASENOTES and from valkey.io, not from this document.

Build options are a hidden upgrade cost. Because make caches options such as 32bit and does not rebuild deps, a build that worked last quarter can behave differently after a pull. The README's answer is make distclean, and it is worth running it when you change targets rather than debugging the result.

## Deciding whether to adopt it

The case for Valkey is narrow and clear. You want a Redis-compatible key-value server, you need it under a permissive licence, and you are prepared to build and operate it yourself. The README supports exactly that workflow and nothing beyond it.

The case against is equally clear. If you need a supported Windows build, an official container image, a managed cloud offering, or a client library recommendation, this README will not give you one, and you should check valkey.io before assuming the project lacks them. If you need a documented upgrade and rollback procedure, the README is silent and the release notes are the place to look.

What to verify first, concretely: run make, then make test, then start ./valkey-server from src and confirm the port it binds. Read valkey.conf for the options you intend to set, since the README states that its keys work as command-line flags with the same names. Then decide whether you are tracking the unstable default branch or pinning to 9.0.6 or 9.1.2, because that choice determines how much of the release list you have to read on a regular basis.

## Conclusion

Adopt Valkey if you want a Redis-compatible data structure server under BSD-3-Clause and you are willing to build from source or take a distribution package, since the README documents no installer of its own. Do not adopt it expecting the README to walk you through Windows, container images, or client libraries: none of those appear in it, and the topics list only names valkey-client without naming a language. Before committing, build with make, run make test, and confirm that the command-line options you rely on are documented in valkey.conf, because the README says all valkey.conf options are also command-line options with exactly the same name, and that is the only configuration reference it points to.

## FAQ

### Why Valkey instead of Redis?

Valkey was forked from the open source Redis project right before Redis moved to source-available licences, and the repository states its own licence as BSD-3-Clause. The README does not argue the point beyond that sentence.

### Is Valkey faster than Redis?

The README makes no comparison between the two on performance. The only speed figure it gives is internal to Valkey: using the processor instruction clock for monotonic time is about 3x faster than POSIX clock_gettime on supported architectures.

### What is Valkey used for?

The README describes it as a high-performance data structure server that primarily serves key/value workloads, with native data structures and an extensible plugin system for adding new ones and new access patterns. The repository topics list cache, database, key-value and nosql.

### Is Valkey free?

The repository states its licence as BSD-3-Clause and carries COPYING, a LICENSES directory and REUSE.toml. The README does not discuss pricing or commercial editions.

### How do I install Valkey on Ubuntu?

The README gives no Ubuntu package instructions. It documents building from source with make from the repository root, and notes that TLS builds need OpenSSL development libraries such as libssl-dev on Debian or Ubuntu.

### Does Valkey run on Windows?

The README lists Linux, macOS, OpenBSD, NetBSD and FreeBSD as the supported platforms, with Solaris derivatives described as best effort. Windows is not mentioned.

## Sources

- [License: BSD-3-Clause](https://github.com/valkey-io/valkey/blob/unstable/LICENSE)
- [Project website](https://valkey.io)
- [README](https://github.com/valkey-io/valkey/blob/unstable/README.md)
- [Releases](https://github.com/valkey-io/valkey/releases)
- [valkey-io/valkey on GitHub](https://github.com/valkey-io/valkey)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/valkey-io-valkey