# Tiny RDM: a lightweight Redis GUI that ships as a desktop app and a Docker web client

> Tiny RDM is a Wails-based Redis desktop manager for Mac, Windows and Linux, with a browser version deployed through Docker. The desktop build avoids an embedded Chromium, and the web build puts an nginx front end in front of a Go backend.

**tiny-craft/tiny-rdm** — Tiny RDM (Tiny Redis Desktop Manager) - A modern, colorful, super lightweight Redis GUI client for Mac, Windows, and Linux. It also provides a web version that can be deployed via Docker.

- Repository: https://github.com/tiny-craft/tiny-rdm
- Website: https://tinyrdm.com
- Stars: 13,121 · Forks: 659
- Language: Vue
- License: GPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/tiny-craft-tiny-rdm

## What Tiny RDM replaces, and for whom

Redis ships with redis-cli, and that is enough until you need to inspect a hash with a thousand fields, compare two environments, or hand a database to someone who does not want to type commands. Tiny RDM targets that gap. It is a graphical client for Redis, built for developers and operators who already run Redis and want a local window onto it rather than another service to deploy.

The README describes it as "a modern lightweight cross-platform Redis desktop manager available for Mac, Windows, and Linux" and adds that a web version can be deployed via Docker. The desktop build is the primary artifact. The web build exists for the case where the machine holding the Redis credentials is not the machine you are sitting at, which is common when Redis lives inside a private network.

The feature list is broad but conventional for this category: connection management with SSH tunnel, SSL, Sentinel mode, Cluster mode, HTTP proxy and SOCKS5 proxy; CRUD across Strings, Lists, Hashes, Sets, Sorted Sets and Streams; multiple viewing formats with decode and decompression; a command-line mode; slow log and command history lists; publish/subscribe; import and export of both data and connection profiles. Nothing here is exotic. The interesting decisions are in how it is built and what it does not do.

## How the Wails build avoids shipping a browser engine

The repository layout tells most of the story. There is a frontend/ directory, a backend/ directory, main.go and main_web.go at the root, a wails.json, and a go.mod that requires github.com/wailsapp/wails/v2 and github.com/redis/go-redis/v9. The frontend is Vue, judged by the topics list and the package layout, and the Go side talks to Redis through go-redis.

Wails is the reason the desktop binary stays small. Instead of bundling Chromium, a Wails application renders its frontend in the operating system's own webview, which on Windows means Webview2. The README is explicit about this: "Super lightweight, built on Webview2, without embedded browsers." That is a real trade-off rather than a free win. You get a smaller download and lower memory use, but your rendering behaviour and your minimum OS version now depend on the webview the platform provides. On Windows that means Webview2 has to be present, which modern Windows installs include but older managed images may not.

Two entry points exist because the app has two delivery modes. main.go builds the Wails desktop application. main_web.go builds a server binary, and the Dockerfile compiles it with the web build tag: go build -tags web. The web mode is not the desktop app wrapped in a browser tab. It is a separate Go server using gin, with the compiled Vue assets served by nginx and the backend handling Redis connections on behalf of the browser.

## Installing the desktop client and connecting to a first database

The README points to the releases page for downloads rather than a package manager: "Available to download for free from here," with the link going to github.com/tiny-craft/tiny-rdm/releases. There is no documented Homebrew formula or Arch package in the README, so treat any such command you see elsewhere as unverified.

On macOS the README warns that the app may refuse to open after installation and gives one command to clear the quarantine flag:

```bash
sudo xattr -d com.apple.quarantine /Applications/Tiny\ RDM.app
```

Run that, then reopen the app. The same note appears in the installation section, which suggests it is a recurring support question rather than a one-off.

Building from source is documented and short. You need Go, Node.js 20 or newer, and npm 9 or newer, then Wails itself:

```bash
go install github.com/wailsapp/wails/v2/cmd/wails@latest
```

Clone the repository shallowly, install the frontend dependencies, and start the dev build:

```bash
git clone https://github.com/tiny-craft/tiny-rdm --depth=1
npm install --prefix ./frontend
wails dev
```

The README offers an alternative of changing into frontend/ and running npm install there. After wails dev, a desktop window opens with the connection list. From there you create a connection with host, port, and whichever of the SSH, SSL, Sentinel or Cluster options your deployment needs. Keys are listed through SCAN in segments, so opening a database with millions of keys does not block on a full KEYS call.

## Deploying the web version with Docker Compose

The web version is the part most likely to be misconfigured, because the port story has two layers. The README's compose example maps 8086:8086 and sets ADMIN_USERNAME and ADMIN_PASSWORD:

```yaml
services:
  tinyrdm:
    image: ghcr.io/tiny-craft/tiny-rdm:latest
    container_name: tinyrdm
    restart: unless-stopped
    ports:
      - "8086:8086"
    environment:
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=tinyrdm
    volumes:
      - ./data:/app/tinyrdm
```

Start it with docker compose up -d and visit http://localhost:8086. The single-command form in the README is equivalent:

```bash
docker run -d --name tinyrdm \
  -p 8086:8086 \
  -e ADMIN_USERNAME=admin \
  -e ADMIN_PASSWORD=tinyrdm \
  -v ./data:/app/tinyrdm \
  ghcr.io/tiny-craft/tiny-rdm:latest
```

The repository's own docker-compose.yml differs from the README snippet. It adds PORT=8088 and GIN_MODE=release, and comments out SESSION_TTL=24h. The Dockerfile confirms the internal default with ENV PORT=8088 and EXPOSE 8086, and the runtime image runs nginx in front of the Go binary. So the container listens on 8088 internally while the image declares 8086 and the compose file publishes 8086. If you change the environment variables, check which port nginx is actually proxying to before you conclude the container is broken.

The image is built in three stages: Node 22 Alpine compiles the frontend with VITE_WEB=true, golang:1.25-alpine builds the web-tagged binary, and alpine:3.21 runs nginx plus the server. The volume mount at /app/tinyrdm is where connection profiles and settings persist, and XDG_CONFIG_HOME=/app is set in the image so the app writes its config inside that mount rather than to a home directory that does not survive a restart.

## Scanning instead of KEYS, and the cost of that choice

The README states that Tiny RDM uses SCAN for segmented loading "making it easy to list millions of keys," and that List, Hash, Set and Sorted Set values load and query in segments too. That is the right call. KEYS blocks the server, and a GUI that runs it against a production instance is a liability. SCAN gives you a cursor and a batch, and the client keeps fetching as you scroll.

The trade-off is that SCAN does not guarantee a stable snapshot. Keys added or removed during iteration may or may not appear, and the same key can in principle be returned more than once. For browsing this rarely matters. For anyone who treats the key list as an inventory to be exported and diffed, it matters a great deal, and the README does not discuss it. Export is listed as a feature, but the README does not say whether export walks the keyspace with SCAN or with something else, so do not assume an export is a point-in-time snapshot.

The segmented loading of collection values has a similar shape. It keeps a million-element hash from locking up the UI, but it means the view you see is a window onto a moving structure. If your workflow depends on reading a consistent copy of a large collection, this client is the wrong instrument and a server-side script is the right one.

## Where Tiny RDM is the wrong tool

The Docker deployment is a single-admin web console, not a shared service. The only documented environment variables for access control are ADMIN_USERNAME and ADMIN_PASSWORD, with the compose file defaulting to admin and tinyrdm. There is no mention of multiple users, roles, per-connection permissions, or an audit trail of who ran which command. If you put this behind a reverse proxy on a network your whole team can reach, everyone shares one identity, and the command history list is per-session rather than an access record.

That single credential also means the browser session is the security boundary. SESSION_TTL appears commented out in the repository's compose file, which implies the session lifetime is configurable, but the README's environment variable table lists only ADMIN_USERNAME and ADMIN_PASSWORD. Anyone deploying the web version should read the compose file and the entrypoint script rather than relying on the README table alone.

Memory is the other boundary. Because the desktop app renders in the system webview and the backend is a Go process talking to Redis, the client's footprint scales with what you ask it to display. The segmented loading keeps that in check for browsing, but a value decode or decompression step on a very large payload still has to hold the result somewhere. The README lists decode and decompression support without stating a size ceiling, and it does not document a streaming path for large values.

Finally, the licence. Tiny RDM is GPL-3.0. That is fine for internal use and for anyone who is not distributing a derivative work. It is a different conversation if you plan to embed the client in a commercial product.

## How it compares with RedisInsight and the older Redis Desktop Manager

The obvious alternative is RedisInsight, which is also a graphical Redis client and is the tool most people land on when they search for a Redis GUI. The approaches differ in packaging and in what the vendor relationship implies. RedisInsight comes from Redis Ltd., the company behind Redis itself, and is distributed as its own application and as a Docker image. Tiny RDM comes from an independent project and is built on Wails with a Vue frontend, which is why its desktop binary avoids an embedded browser and stays small.

The older Redis Desktop Manager is the other name that comes up. It is the tool Tiny RDM is implicitly positioned against, and the README's emphasis on being lightweight and cross-platform reads as a direct response to how that client aged. If you are migrating from it, the connection profile import and export feature in Tiny RDM is the relevant one, though the README does not state which formats are accepted.

The practical difference between Tiny RDM and RedisInsight is not a feature checklist. It is that Tiny RDM's web mode is a straightforward nginx-plus-Go container you can read end to end from the Dockerfile, while RedisInsight's deployment model is set by its vendor. If you want to audit exactly what runs in your cluster, the three-stage Dockerfile here is short enough to read in a few minutes, and that is a real reason to choose it.

## Conclusion

Adopt Tiny RDM if you want a small desktop Redis client that handles SSH tunnels, Sentinel, Cluster, and multi-million-key databases through SCAN paging, and if the GPL-3.0 licence fits how you distribute software. Do not adopt it expecting a hosted, multi-tenant web console: the Docker image ships with one admin username and password set through environment variables, and the repository documents no per-user accounts, no RBAC and no audit logging. Before rolling it out, verify that your Redis deployment accepts the connection mode you need (Sentinel, Cluster, TLS, or an HTTP/SOCKS5 proxy), then confirm the Docker build actually serves on the port you expect, because the compose file maps 8086:8086 while the container itself sets PORT=8088.

## FAQ

### What is the best Redis GUI tool?

There is no single answer, but Tiny RDM is one candidate: a lightweight cross-platform Redis desktop manager built on Wails, with a Docker-deployable web version. The README lists SSH tunnel, SSL, Sentinel, Cluster, HTTP proxy and SOCKS5 proxy support among its connection options.

### How do I download Redis Desktop Manager?

For Tiny RDM, the README directs you to the project's GitHub releases page for the Mac, Windows and Linux builds. The README does not document a package manager command.

### Does Tiny RDM work with Redis Sentinel and Cluster?

Yes. The README lists Sentinel Mode and Cluster Mode among the supported connection options, alongside SSH Tunnel, SSL, HTTP proxy and SOCKS5 proxy.

## Sources

- [License: GPL-3.0](https://github.com/tiny-craft/tiny-rdm/blob/main/LICENSE)
- [Project website](https://tinyrdm.com)
- [README](https://github.com/tiny-craft/tiny-rdm/blob/main/README.md)
- [Releases](https://github.com/tiny-craft/tiny-rdm/releases)
- [tiny-craft/tiny-rdm on GitHub](https://github.com/tiny-craft/tiny-rdm)

---

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