webdis puts an HTTP interface in front of Redis without a scripting language

A C web server with three libraries baked into the tree

The whole idea fits in one sentence from the README: a very simple web server providing an HTTP interface to Redis. The interesting part is what that costs in dependencies. Webdis embeds hiredis for talking to Redis, jansson for JSON, and http-parser for parsing requests, all vendored under `src/`. The one external dependency is libevent, which has to be installed separately because it is a system package rather than a copied library.

That vendoring strategy has a visible consequence in the tree. `src/jansson/` comes with a `WEBDIS-CHANGES.md` describing local modifications to upstream jansson, so you are not running a pristine copy of any of the three libraries. It also means a build needs a C compiler and the jansson headers in the right place, which is why the `Makefile` sets `-Isrc -Isrc/jansson/src -Isrc/http-parser` and builds with `-std=c99`. The language reported for the repository is C, and the license is BSD-2-Clause.

There is a mild tension between the README's word simple and the surrounding repository, which also carries signed container images, a MessagePack build path and a `tests/` directory. Simple describes the idea and the single-binary result rather than the amount of supporting work, which is a fair description but worth recalibrating before you promise anyone a five-minute build. The project page is at webd.is, and GitHub reports the last push on 2026-05-18, roughly 2963 stars, 308 forks and 68 open issues.

Building from source means installing libevent first

The README is direct about the order of operations. On Ubuntu you install the development package, on macOS you install it through Homebrew, and only then do you build:

$ make clean all

$ ./webdis &

$ curl http://127.0.0.1:7379/SET/hello/world
→ {"SET":[true,"OK"]}

$ curl http://127.0.0.1:7379/GET/hello
→ {"GET":"world"}

Run the binary with no arguments and it looks for `webdis.json` in the current directory. There is no daemon management here: the process starts in the foreground unless the config file says otherwise, and port 7379 is the default the examples use throughout the README.

The same commands also work as a POST body, which is the part that matters for scripts that would rather not build a URL:

$ curl -d "GET/hello" http://127.0.0.1:7379/
→ {"GET":"world"}

Either way the reply is JSON keyed by the command name, with a two-element array for replies that carry more than a scalar. `SET` returns `[true,"OK"]` because Redis answers it with a status plus an error flag, and `GET` returns the bare string because that is all Redis sent. Once you have seen that shape, you know what to expect from every other command.

Configuration is a JSON file, and two of them ship with the repository

Webdis takes its whole configuration as a JSON file on the command line:

./webdis /path/to/webdis.json

That is the entire configuration mechanism. There are no command-line flags for tuning, no environment variables mentioned in the README, and no hot reload. A change to the config file means a restart, which is fine for a process this small but worth knowing if you were expecting something closer to a service mesh.

The repository ships both `webdis.json`, described as a sample for local evaluation, and `webdis.prod.json`, described as a starting point for building a production configuration. The README puts a warning on both of them in bold: do not use either in production without reviewing them. For a Redis HTTP front end that is sensible advice rather than boilerplate, because the things most likely to be wrong in a sample are the bind address, the Redis host, and whether the process daemonizes.

Encrypted connections to Redis are configured in the same file. Once Redis itself is running with TLS, you add an object under a root-level key named `ssl`, containing fields such as `enabled` and `ca_cert_bundle`. Building that support is a separate compile step:

$ make SSL=1

which needs OpenSSL headers installed first: `apk-add openssl-dev` on Alpine, `apt-get install libssl-dev` on Ubuntu, or `brew install [email protected]` on macOS. The `Dockerfile` builds the binary twice, producing a plain `webdis` and a separate `webdis-ssl`.

The published Docker image bundles its own Redis server

Running the project with no build step takes one command, and the reply format is visible immediately:

$ docker run --name webdis-test --rm -d -p 127.0.0.1:7379:7379 nicolas/webdis

$ curl http://127.0.0.1:7379/PING
{"PING":[true,"PONG"]}

# To stop it:
$ docker stop webdis-test

The port mapping binds to 127.0.0.1 rather than all interfaces, which is the right default for a quick look and the wrong one if you intend to reach it from another container.

The important detail is what that image contains. The README states plainly that the images published under `nicolas/webdis` include both Webdis and an embedded Redis server, and that they were built that way to make trying it easy without configuring a two-container deployment. It then says this is likely not the best way to run Webdis in production. The `Dockerfile` shows the mechanism: `redis-server` is copied into the final Alpine image, `/etc/redis.conf` is rewritten with a block of local-use overrides including `maxmemory 100mb` and `maxmemory-policy allkeys-lru`, and the `CMD` starts Redis and then execs webdis with `webdis.prod.json`, patched at build time to write its log to `/dev/stderr` and not daemonize.

So the image is a demo environment shaped like a deployment. Production topologies, including an external Redis, Docker Compose, and Compose with SSL, are documented separately under `docs/`, which the README points at for more articles.

Images are signed with cosign and published for two architectures

Container supply chain work is where this repository is more thorough than the word simple suggests. Starting with release 0.1.24, images including `latest` are signed with cosign using the public key `webdis.pub` committed at the repository root. Releases 0.1.12 through 0.1.23 were signed with Docker Content Trust, which the README notes has since been deprecated, so verification instructions for those older tags are historical.

$ docker pull nicolas/webdis:0.1.25
$ cosign verify --key webdis.pub nicolas/webdis:0.1.25

The same command works against Amazon ECR, where images share digests with the Docker Hub counterparts and the signatures are mirrored alongside them. Verification is recursive over the multi-architecture index, so a signature check covers the index and each per-architecture manifest under it rather than just the manifest your platform happened to pull.

Multi-architecture publishing started earlier, at release 0.1.19, when images became manifest lists with an x86-64 and an ARM64v8 variant. That matters most on Apple Silicon and other ARM hosts, where an old image would otherwise mean an emulated or missing binary:

$ docker pull nicolas/webdis:0.1.19 --platform linux/arm64/v8

You can inspect the split yourself with `docker manifest inspect` piped through `jq`, which the README shows as a way to print each architecture next to its digest. The repository root also carries `nicolasff.pub`, and `docs/webdis-cosign-signatures.md` covers the public-key fingerprint and the chain of trust.

MessagePack output is an optional compile-time flag

JSON is the default reply format, and the `Makefile` shows that it is not the only one. Object files include `src/formats/json.o`, `src/formats/raw.o`, `src/formats/common.o` and `src/formats/custom-type.o`, and a fifth format, `src/formats/msgpack.o`, is added when MessagePack support is detected. The detection is done with `pkg-config`, trying the modern package name `msgpack-c` first and the older `msgpack` as a fallback.

You can influence that with make variables. Setting `MSGPACK=1` requires the library to be found, or `MSGPACK_LIBS` supplied by hand, and `MSGPACK=0` skips detection entirely. The link line gains the MessagePack libraries and `CFLAGS` gains `-DMSGPACK=1` plus whatever the detected package reports.

The practical reading of this: a JSON reply over HTTP is human-readable and slightly larger, which is fine for a control plane and wasteful for a high-volume data path. If you end up piping webdis output into something throughput-sensitive, the MessagePack build is the lever the repository offers, and it is a build-time choice rather than a per-request negotiation. Custom Redis types appear in the same list of format objects, which is the place to look if you need to know how webdis represents replies that are not plain strings, integers or arrays.

Where to look when the README runs out

The README covers the build, the configuration file, Docker, image signing and the SSL build, and it does it well because those are exactly the things a new user hits. It says less about how to run the thing well, which is the expected shape for a project of this age and popularity rather than a complaint.

The tree tells you where the rest lives. `docs/` holds the external Redis guide, the two Docker Compose guides including one with SSL, the cosign signature documentation and a `docs/README.md` that indexes further articles. `tests/` is where the test suite lives. `COPYING` carries the BSD 2-Clause license, short and permissive enough that embedding webdis in a larger binary is a realistic option if you would rather not run a separate process.

The honest comparison is not against other Redis HTTP gateways so much as against two obvious alternatives. If you already run Redis, adding webdis gives you a text protocol for free. If you do not, this project is not a datastore choice at all: it is a translator, and the Redis server behind it is doing all the actual work, including the persistence and eviction settings baked into the demo image's config.

Editorial conclusion

webdis earns its place when the caller is a shell script, a browser, a device that speaks HTTP, or any language where adding a Redis driver is more work than adding a curl call. The trade is real and worth naming: you gain a text protocol that anything can speak and lose connection reuse, pipelining and the typed binary clients. What the repository settles is the build, the two configuration files, the cosign verification command and the fact that the published image ships its own Redis. What it leaves to the docs under `docs/` is production topology, running against an external Redis, and Compose with TLS. Start with the one-line Docker run to see the reply format, then read `docs/README.md` before you decide whether one container or two is right for you.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. nicolasff/webdis on GitHub
4. Project website
5. README