michaelkremenetsky/valkey-wasm: Real Valkey (BSD Redis fork) compiled to WASM, networking bridged to node:net — an in-process, Redis-compatible server for Node. PGlite for Redis.

Real Valkey (BSD Redis fork) compiled to WASM, networking bridged to node:net — an in-process, Redis-compatible server for Node. PGlite for Redis. - michaelkremenetsky/valkey-wasm

Summary

valkey-wasm packages the actual Valkey engine (the BSD-licensed fork of Redis) compiled to WebAssembly, with its networking bridged into Node's net module. The result is a real redis://127.0.0.1:6379 server running inside a Node process — no native Redis install and no Docker required. The README frames it as the Redis counterpart to PGlite.

What it is useful for

It fits the moments when you need Redis but a running server is overkill or impractical: local development without Docker, CI jobs that shouldn't need to stand up a service container, test suites that want a clean database on every run, offline demos, and environments where a long-lived daemon cannot stay alive.

The project also positions itself as an alternative to JavaScript reimplementations such as ioredis-mock. Because valkey-wasm is the real engine, scripting, EVALSHA, blocking commands like BLPOP, streams, pub/sub, and transactions behave the same as on any standard Redis server. Unlike a single-process JS mock, the embedded server is reachable across forked workers, since the listener and state live in the parent Node process rather than inside one worker's memory.

How engineers can use it

Install the package with npm install valkey-wasm, start the server from your code, and point any Redis-compatible client at it. The README's flow diagram shows ioredis and BullMQ as the example clients. The README does not include a code snippet inline and directs readers to docs/usage.md for the example and the API, so that file is the first place to look for the exact start-up call and configuration options.

Under the hood, two layers of Valkey are swapped for WASM-friendly equivalents: ae_wasi.c replaces the event-loop poll (epoll/select) with a call into the host, and the socket read/write/accept paths route to host functions backed by node:net. The README calls out a few real limitations worth knowing before adoption: there is no fork, so persistence is off; there are no threads, so background jobs run inline and io-threads are pinned to 1; and the module is a reactor that boots once and stays resident while the bridge steps the event loop on each socket event and a timer. The repository metadata lists the license as NOASSERTION, so anyone planning to ship it should confirm the terms before distribution.