(opens in a new tab)

Memurai: Running Redis on Windows in 2026

September 21, 2026 by Chat2DB Team

Redis has never had an official Windows build. Microsoft maintained a port for a while, but it was abandoned around Redis 3.2 in 2016 — and that abandoned port is still, frustratingly, the first result many people find when they search for "download Redis for Windows". Installing it in 2026 means running software that is a decade out of date and missing every feature and security fix since.

There are four real options for Redis on Windows today: Memurai, WSL2, Docker Desktop, and a managed cloud instance. This guide covers Memurai in depth and then explains honestly when one of the others is the better choice.

What Memurai is

Memurai is a native Windows port of Redis, maintained commercially by Janea Systems — the same engineers who worked on the original Microsoft port. It is built from the Redis source and tracks upstream releases, so it speaks the same RESP protocol, supports the same commands and data structures, and works with every Redis client library unchanged.

The key point is that it is a native Windows service. There is no virtual machine, no Linux subsystem, no container runtime. It installs as a Windows service, starts with the machine, writes to the Windows Event Log, and can be managed with sc and Get-Service like any other service.

Memurai comes in three editions:

• Developer Edition — free, intended for development and testing. Full feature set, not licensed for production.
• Integrated Edition — commercial, for embedding Memurai in your own product.
• Enterprise Edition — commercial, production use, with replication, high availability and support.

For local development against a Redis-backed application on a Windows machine, the free Developer Edition is what you want.

Installing

Download the MSI from memurai.com and run it, or use a package manager:

# Chocolatey
choco install memurai-developer
 
# winget
winget install Memurai.MemuraiDeveloper

The installer registers a Windows service and starts it. Verify:

Get-Service Memurai
 
# Status   Name       DisplayName
# ------   ----       -----------
# Running  Memurai    Memurai

Memurai ships its own CLI, memurai-cli, which is the Redis CLI under a different name:

memurai-cli ping
# PONG
 
memurai-cli INFO server
memurai-cli --version

If memurai-cli is not on your PATH, it lives under C:\Program Files\Memurai\. Add that directory to PATH so it is available from any shell.

A quick functional check across the main data structures:

memurai-cli

127.0.0.1:6379> SET greeting "hello"
OK
127.0.0.1:6379> GET greeting
"hello"
127.0.0.1:6379> LPUSH tasks "build" "test" "deploy"
(integer) 3
127.0.0.1:6379> LRANGE tasks 0 -1
1) "deploy"
2) "test"
3) "build"
127.0.0.1:6379> HSET user:1 name "Alice" email "alice@example.com"
(integer) 2
127.0.0.1:6379> HGETALL user:1
1) "name"
2) "Alice"
3) "email"
4) "alice@example.com"
127.0.0.1:6379> ZADD leaderboard 100 "alice" 85 "bob" 120 "carol"
(integer) 3
127.0.0.1:6379> ZREVRANGE leaderboard 0 -1 WITHSCORES
1) "carol"
2) "120"
3) "alice"
4) "100"
5) "bob"
6) "85"
127.0.0.1:6379> EXPIRE greeting 60
(integer) 1
127.0.0.1:6379> TTL greeting
(integer) 57

Everything behaves exactly as Redis does, because it is Redis.

Configuration

The config file is memurai.conf, typically at C:\Program Files\Memurai\memurai.conf. It uses standard Redis configuration syntax, so any redis.conf guidance applies directly.

# Network
bind 127.0.0.1
port 6379
timeout 0
tcp-keepalive 300
 
# Memory
maxmemory 2gb
maxmemory-policy allkeys-lru
 
# Persistence — RDB snapshots
save 900 1        # after 900s if at least 1 key changed
save 300 10
save 60 10000
dbfilename dump.rdb
dir C:\\ProgramData\\Memurai
 
# Persistence — AOF
appendonly yes
appendfsync everysec
 
# Security
requirepass your-strong-password-here
 
# Logging
logfile C:\\ProgramData\\Memurai\\memurai.log
loglevel notice
 
# Windows-specific: maximum heap the process may use
maxheap 4gb

Two settings deserve comment.

maxheap is Memurai-specific and does not exist in Redis on Linux. Because Windows has no fork(), Memurai emulates copy-on-write snapshotting using a memory-mapped file, and maxheap bounds that mapping. It should be larger than maxmemory — a common guideline is roughly 1.5x — to leave room for snapshotting.

maxmemory-policy matters as soon as you set maxmemory. The default noeviction makes writes fail with an OOM error once the limit is reached, which is correct for a durable store and wrong for a cache. For caching, allkeys-lru is almost always what you want.

After editing the config, restart the service:

Restart-Service Memurai
 
# or
net stop Memurai
net start Memurai

Many settings can also be changed at runtime without a restart:

memurai-cli CONFIG SET maxmemory 4gb
memurai-cli CONFIG SET maxmemory-policy allkeys-lru
memurai-cli CONFIG GET maxmemory*
memurai-cli CONFIG REWRITE    # persist runtime changes back to the file

CONFIG REWRITE is the step people forget — without it, runtime changes are lost on restart.

Persistence

Memurai supports both Redis persistence mechanisms.

RDB takes point-in-time snapshots. Compact, fast to load, but you lose everything written since the last snapshot if the process dies.

AOF appends every write command to a log and replays it on startup. Far better durability; larger files and slightly slower writes.

For development, RDB alone is fine. For anything where losing data matters, enable both — Redis will use the AOF to restore, with the RDB as a fallback:

appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

appendfsync everysec is the standard compromise: at most one second of writes lost on a crash, without the throughput cost of always.

Force a snapshot and check persistence state:

memurai-cli BGSAVE
memurai-cli LASTSAVE
memurai-cli INFO persistence

Because Windows lacks fork(), background saves on Memurai behave differently from Linux Redis internally. In practice they work, but snapshotting a very large dataset is more expensive than the equivalent on Linux. This is one of the reasons Memurai is a better fit for development and modest production workloads than for very large ones.

Security

The defaults are permissive, as they are in Redis. Before Memurai is reachable by anything but your own machine, do three things.

Set a password:

requirepass a-long-random-string

memurai-cli -a a-long-random-string ping

Keep the bind address local unless you genuinely need remote access:

bind 127.0.0.1
protected-mode yes

Rename or disable dangerous commands if the instance is shared:

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG "CONFIG_a8f3e91b"

If you do expose the port, add a Windows Firewall rule scoped to the hosts that need it rather than opening it broadly:

New-NetFirewallRule -DisplayName "Memurai 6379" `
  -Direction Inbound -Protocol TCP -LocalPort 6379 `
  -RemoteAddress 10.0.1.0/24 -Action Allow

An unauthenticated Redis instance reachable from the internet is one of the most reliably exploited misconfigurations there is. Do not skip the password.

Connecting from applications

Every Redis client works unchanged, because the protocol is identical. There is no Memurai-specific driver.

C# / .NET (StackExchange.Redis):

using StackExchange.Redis;
 
var muxer = await ConnectionMultiplexer.ConnectAsync(
    "localhost:6379,password=your-password,abortConnect=false");
var db = muxer.GetDatabase();
 
await db.StringSetAsync("greeting", "hello", TimeSpan.FromMinutes(5));
var value = await db.StringGetAsync("greeting");
Console.WriteLine(value);

In ASP.NET Core, the distributed cache provider wires up the same way:

builder.Services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = builder.Configuration.GetConnectionString("Redis");
    options.InstanceName = "myapp:";
});

Python:

import redis
 
r = redis.Redis(host="localhost", port=6379, password="your-password",
                decode_responses=True)
r.set("greeting", "hello", ex=300)
print(r.get("greeting"))

Node.js:

import { createClient } from "redis";
 
const client = await createClient({
  url: "redis://:your-password@localhost:6379",
}).connect();
 
await client.set("greeting", "hello", { EX: 300 });
console.log(await client.get("greeting"));

Monitoring

memurai-cli INFO                   # everything
memurai-cli INFO memory
memurai-cli INFO stats
memurai-cli INFO replication
memurai-cli DBSIZE                 # number of keys
memurai-cli --stat                 # rolling stats, one line per second
memurai-cli --bigkeys              # find the largest keys
memurai-cli MONITOR                # live command stream — development only
memurai-cli SLOWLOG GET 10         # slowest recent commands
memurai-cli CLIENT LIST            # connected clients

--bigkeys is the first thing to run when memory usage is higher than expected. MONITOR is invaluable for debugging but degrades throughput significantly, so never leave it running in production.

The metrics that matter most:

memurai-cli INFO stats | Select-String "keyspace_hits|keyspace_misses|evicted_keys|expired_keys"
memurai-cli INFO memory | Select-String "used_memory_human|maxmemory_human|mem_fragmentation_ratio"

A low hit rate means your cache is not earning its keep. Rising evicted_keys means maxmemory is too low for the working set. A mem_fragmentation_ratio well above 1.5 suggests fragmentation worth investigating.

Memurai versus the alternatives

WSL2

Running real Redis inside WSL2 gives you the genuine upstream article, current version, at no cost:

wsl --install -d Ubuntu
# inside WSL
sudo apt update && sudo apt install redis-server
sudo service redis-server start
redis-cli ping

localhost:6379 from Windows reaches it, so applications connect normally.

Advantages: real Redis, latest version, free, full feature parity including modules. Drawbacks: WSL2 must be running; it is a separate environment with its own filesystem and memory allocation; it does not start as a Windows service without extra work; startup adds friction.

For a solo developer comfortable with WSL, this is often the best option.

Docker Desktop

docker run -d --name redis -p 6379:6379 \
  -v redis-data:/data \
  redis:7-alpine redis-server --appendonly yes

Advantages: real Redis, trivially reproducible, matches your production container image, easy to run several versions side by side. Drawbacks: Docker Desktop requires a paid licence for larger organisations; it consumes noticeable resources; another moving part to keep running.

If your team already uses Docker, this is usually the path of least resistance and gives the closest match to production.

Managed Redis in the cloud

For production, this is normally the right answer regardless of your development environment. AWS ElastiCache, Azure Cache for Redis, Google Memorystore and Redis Cloud all handle replication, failover, patching and backups for you.

Valkey

Valkey is the Linux Foundation fork of Redis, created after Redis changed its licence in 2024, and it is what AWS, Google and Oracle now build on. It is a drop-in replacement and fully open source under BSD. It has no native Windows build either, so on Windows you would run it under WSL2 or Docker — but it is worth knowing about when choosing what your production deployment runs.

Choosing

Use Memurai when you need Redis to behave like a normal Windows service — starting with the machine, managed by Get-Service, monitored by the same tooling as everything else on the box. This matters most on Windows Server, in shops with strict policies about what may be installed, and for .NET teams who do not otherwise use Linux tooling.

Use WSL2 when you are a developer who wants exactly upstream Redis at no cost and does not mind starting it yourself.

Use Docker when your team already runs Docker and you want development to mirror production containers.

Use managed Redis for production, in nearly all cases.

Summary

The abandoned Microsoft Redis port should not be used in 2026 under any circumstances — it is nine years stale and carries unpatched vulnerabilities. Memurai is the credible native Windows option: a maintained port that tracks upstream, installs as a real Windows service, speaks the standard protocol, and is free for development use.

Configure it deliberately rather than accepting defaults. Set maxmemory with an eviction policy that matches whether you are using it as a cache or a store, set maxheap above maxmemory to leave headroom for snapshotting, enable AOF if the data matters, and always set requirepass. With those in place, it is an unremarkable Redis instance that happens to run on Windows — which is exactly what you want from it.