phpRedisAdmin: a plain PHP web console for Redis

One PHP file per operation, no framework underneath

The layout tells you what this project is. The top level of the repository is a list of small PHP entry points: index.php for the overview, view.php, edit.php, save.php, delete.php, rename.php, ttl.php, info.php, import.php, export.php, flush.php, plus login.php and logout.php for the session handling. Alongside them sit an includes directory, a js directory, a css directory and an images directory.

There is no application framework, no router, no ORM and no front-end build. Each file handles one operation and links to the others. That structure has obvious consequences. It is easy to read, easy to patch and easy to host anywhere PHP runs, and it is also easy to misjudge what a project of this shape can do.

The functional surface is a Redis browser: list the databases on a server, see the keys, look at a value, edit it, rename it, set or read a time to live, read server information, import and export data, and flush. A live example database is published by the author, so you can see the interface before installing anything.

The project is described as a simple web interface to manage Redis databases, developed and maintained by Erik Dubbelboer, and the author invites comments, patches and questions on the issue tracker or by email.

Three ways to install, and one of them is a source clone

The Composer route is the documented default, and it installs the project from the dev branch of the package:

curl -s http://getcomposer.org/installer | php
php composer.phar create-project -s dev erik-dubbelboer/php-redis-admin path/to/install

After that you are told to copy the sample configuration into place and edit it with your own Redis details, in other words to copy includes/config.sample.inc.php to includes/config.inc.php.

The manual route exists for people without Composer, and it has a quirk worth knowing about: the Redis client is a separate repository cloned into a vendor directory by hand.

git clone https://github.com/ErikDubbelboer/phpRedisAdmin.git
cd phpRedisAdmin
git clone https://github.com/nrk/predis.git vendor

The third route is Docker, and there is a public image built from the latest tag.

docker run --rm -it \
  -e ADMIN_USER=myuser \
  -e ADMIN_PASS=mysecretpassword \
  -e REDIS_1_HOST=myredis.host \
  -e REDIS_1_NAME=MyRedis \
  -p 80:80 erikdubbelboer/phpredisadmin

A compose file ships as well, and it refuses to start without credentials:

ADMIN_USER=myuser ADMIN_PASS=mysecretpassword docker-compose up --build

The container runs the PHP development server

The Dockerfile is short and tells you a lot about the intended deployment. It starts from the composer 2.2 image, adds tini and tzdata with apk, copies the project into a work directory and installs the dependencies, then copies the environment oriented configuration over the sample one.

FROM composer:2.2

RUN apk add --no-cache tini tzdata

WORKDIR /src/app

COPY . .

RUN set -xe; \
    composer install; \
    cp includes/config.environment.inc.php includes/config.inc.php

ENV PORT 80
EXPOSE 80
ENTRYPOINT [ "sh", "-c", "tini -- php -S 0.0.0.0:$PORT" ]

The entry point is the PHP built-in web server bound to port 80, with tini as the init process so that signals reach the server rather than the shell. The PORT environment variable is honoured, and the compose file maps 80 to the host.

The built-in server is a development server. It is what makes the image work with no extra process supervision, and it is also what makes the container a poor choice for a long lived internal tool that has to survive traffic. Behind a real web server with TLS in front of it, the same code serves the same pages.

The compose file adds one more thing worth copying: it wires a Redis service into the same stack, with the admin pointing at the redis host on the default port and a verbose log level on the Redis side, so you get a working pair rather than a half-configured admin.

Authentication is required, and the escape hatch is named

The security posture is stated more clearly than in most tools of this age. The documentation says authentication is required and that you must set ADMIN_USER and ADMIN_PASS before exposing the container. If you intentionally need unauthenticated access, there is a flag for it:

ALLOW_NO_AUTH=true

The documentation annotates that setting as not recommended outside isolated local development, and the same advice appears for source installations, where a login or a login_as_acl_auth entry is required, with an allow_no_auth option in includes/config.inc.php for an intentionally isolated instance.

Two details are worth attention. The compose file uses a required variable syntax for both credentials, so starting it without them is an error rather than a surprise empty password. And the Redis password can be supplied through a file rather than an environment variable, which keeps the secret out of the process listing.

What is not here is any form of fine grained authorisation. The login is a single gate in front of every server the console is configured with, so anyone who passes it can edit, delete and flush any key on any configured instance. That is the single most important fact to know before you put this behind a shared network.

There is also a SECURITY.md in the repository root, which is where to look for the reporting process before you file anything through the issue tracker.

One environment variable prefix per configured server

The configuration surface is a flat set of environment variables, all prefixed with REDIS_1 for the first server. The list is short and each entry has one job.

REDIS_1_HOST sets the host of the Redis server and REDIS_1_NAME is the display name. REDIS_1_PORT sets the port, REDIS_1_SCHEME chooses between tcp and tls, and REDIS_1_AUTH holds the password while REDIS_1_AUTH_FILE points at a file containing it. REDIS_1_DATABASES is listed with a one-line note that you can modify the configuration to prevent phpRedisAdmin from using the CONFIG command.

That last one is the most useful entry in the list. The CONFIG command can change server settings at runtime, which means a browser console that can issue it has a lot more power over a Redis instance than a key browser needs. Changing the configuration is how you narrow that surface on a shared server.

For the HTTP side, ADMIN_USER and ADMIN_PASS define the credentials for the browser interface and ALLOW_NO_AUTH opts into unauthenticated access. The environment oriented configuration lives in includes/config.environment.inc.php and is what the container copies over the sample file at build time, so anything you set in the environment overrides the file based configuration.

The task list shows the unfinished edges

The project publishes its own list of things it has not done, and reading it tells you what to expect.

The first item is encoding support for editing, which means a value containing characters outside the assumed encoding is not handled gracefully in the editor. The second is JavaScript sorting of tables, so key lists come back in whatever order the server gives them. The third is better error handling, which is the item that matters most in practice, since a failure inside a small PHP script is more likely to surface as a blank page or a warning than as a considered message. The fourth is moving or copying a key to a different server, which is the feature you would reach for during a migration and cannot find here.

The last two are about data interchange. Importing JSON is not supported, and JSON export does not produce separate objects based on a separator, so exporting gives you one blob rather than a stream of records.

Set against that, the release history is steady: v1.25.0 on 2025-11-23, v1.26.0 on 2025-12-22 and v1.27.0 on 2026-10-19, with the last push on 2026-10-19 and no archival. The README states the project is released under the Creative Commons Attribution 3.0 licence, and the repository root also carries a separate file named LICENSE.redis-stringmatch, which suggests bundled third-party code, in this case the string matching logic, keeps its own terms. If you plan to redistribute the code inside a product, read both files rather than relying on the licence named in the README.

Editorial conclusion

phpRedisAdmin is a good fit for a developer or small team that needs read and write access to a Redis instance from a browser without standing up a full administration suite, and for people who prefer a handful of PHP files to a JavaScript front end. It is a poor fit as a shared production console, because it offers no per-key authorisation, its own task list still includes better error handling, and it will happily talk to whatever Redis you point it at. Before you expose it, set ADMIN_USER and ADMIN_PASS, keep it off the public internet, and confirm that the Redis instance it reaches is one whose data you are allowed to edit.

Frequently asked questions

Official sources

1. erikdubbelboer/phpRedisAdmin on GitHub
2. Issues
3. Project website
4. README
5. Releases