Self-Hosted Redis with Docker and a Redis Commander UI

If you want to self-host Redis, you need three things: a container image, a place to store data that survives restarts, and a password so the internet cannot walk in. Self-hosted Redis is the same open-source server that managed vendors resell, running under your own control instead of theirs. This guide shows how to run it with Docker, keep the data on a persistent volume, add a Redis Commander web UI, and connect your application over a private network.

Redis is worth self-hosting when you already run your own containers and want to avoid a second bill for a service you can operate in a few lines of configuration. The tradeoff is honest and simple. You get full control, and you also own the patching, backups, and memory sizing that a managed service would handle for you.

The short answer: To self-host Redis, run the official redis Docker image as a container with a persistent volume mounted at /data, set a password with requirepass, enable AOF persistence, and cap memory with an eviction policy. Add Redis Commander as a second container for a web UI. Never expose an unauthenticated Redis port to the public internet.

When you actually need Redis

Redis is an in-memory data store. It keeps the whole dataset in RAM, which is why reads and writes finish in microseconds instead of milliseconds. That speed is the reason to reach for it, and it is also the reason you should not treat it as your system of record.

Redis is an in-memory data store that keeps its dataset in RAM for microsecond reads and writes. Developers use it for caching, session storage, rate limiting, and job queues, where response time matters more than durable long-term storage on disk.

Four use cases cover most of what teams reach for. Caching stores the result of an expensive query or API call so the next request skips the work. Session storage keeps login state out of your application memory so any instance can serve any user. Rate limiting counts requests per key with atomic increments and short expiry times. Job queues hand background work from a web process to a worker using lists or streams.

If your data must never be lost and needs relational queries, that job belongs in PostgreSQL, not Redis. If you only need one of these caching patterns occasionally, you may not need Redis at all yet. Add it when a real bottleneck appears, not before. For a wider view of running your own services in containers, see our guide on self-hosting apps with Docker.

Self-host Redis with Docker

The official redis image on Docker Hub is the fastest way to start. The important detail is the volume. Redis writes its persistence files to /data inside the container, so you mount a named volume there. Without a volume, every restart wipes the dataset.

docker run -d \
  --name redis \
  -v redis-data:/data \
  redis:7 \
  redis-server --requirepass "a-long-random-password" --appendonly yes

That single command runs Redis with a password and append-only persistence turned on. In practice you will outgrow inline flags quickly, so move the settings into a redis.conf file and mount it. A configuration file is easier to review and version than a long command line.

# redis.conf
requirepass a-long-random-password
appendonly yes
maxmemory 256mb
maxmemory-policy allkeys-lru

docker run -d \
  --name redis \
  -v redis-data:/data \
  -v ./redis.conf:/usr/local/etc/redis/redis.conf \
  redis:7 \
  redis-server /usr/local/etc/redis/redis.conf

A compose-style definition captures the same setup in a form you can commit to a repository. This is close to what you will describe when you deploy Redis as a sibling container to your application.

services:
  redis:
    image: redis:7
    command: >
      redis-server
      --requirepass ${REDIS_PASSWORD}
      --appendonly yes
      --maxmemory 256mb
      --maxmemory-policy allkeys-lru
    volumes:
      - redis-data:/data

volumes:
  redis-data:

Persistence: RDB versus AOF, honestly

Redis is in-memory, but it can write to disk so a restart does not start from an empty dataset. There are two mechanisms, and understanding both prevents a nasty surprise after a crash. The official Redis persistence documentation covers the details, and the summary below is enough to make a decision.

RDB snapshots write the entire dataset to a compact dump.rdb file at intervals you configure, for example every few minutes if a certain number of keys changed. Snapshots restart fast and are small, which makes them good for backups. The cost is that anything written since the last snapshot is lost if the process dies.

RDB persistence saves point-in-time snapshots of the dataset on a schedule. AOF persistence logs every write command to an append-only file and replays it on restart. RDB restarts fast and stays compact; AOF loses less data because it records each change.

AOF (append-only file) logs every write operation and replays the log when Redis starts. With the default everysec fsync policy, you risk losing at most about one second of writes. AOF files grow larger than snapshots and rewrite themselves periodically to stay bounded. For a pure cache you can skip persistence entirely, since a cold cache just refills. For sessions or a job queue you want AOF on, and running both RDB and AOF together is a reasonable default when the data matters.

Set a memory limit and an eviction policy

Redis will use as much memory as its data requires. On a shared host with a fixed plan, an unbounded Redis can consume everything and get killed by the operating system. Set maxmemory to a value that fits your container, then choose what Redis does when it hits that ceiling.

The maxmemory-policy decides which keys leave when memory is full. For a cache, allkeys-lru evicts the least recently used keys and is a safe default. For a workload where every key must survive, such as a job queue you cannot afford to drop, use noeviction so Redis returns an error instead of silently discarding data. Picking the wrong policy here is a common cause of mysterious data loss, so match the policy to whether the data is disposable.

maxmemory 256mb
maxmemory-policy allkeys-lru

Lock it down before anything else

A Redis instance with no password, reachable from the public internet, is one of the most exploited misconfigurations on the web. Attackers scan for open port 6379, and an unauthenticated instance lets them read your data, write keys, or use Redis features to gain a foothold on the host. Treat an exposed, passwordless Redis as already compromised.

Three rules keep you safe. First, always set requirepass with a long random value, or configure Redis ACL users for finer control. Second, never publish the Redis port to the public internet. Keep it on a private network where only your own containers can reach it. Third, follow the hardening steps in the official Redis security documentation, including keeping protected-mode on and renaming or disabling dangerous administrative commands if the workload allows it.

Self-hosted Redis means you run the Redis server yourself as a container or on a machine you control, rather than buying it as a managed service. You own configuration, security, persistence, memory sizing, backups, and version upgrades in exchange for full control.

On a platform where containers share a private network, the correct posture is to give Redis no public route at all. Your application talks to it internally, and nothing outside the network can open a connection. That single decision removes the entire class of internet-facing Redis attacks.

Add a web UI with Redis Commander

Reading and writing keys from the command line works, but a browsable interface makes debugging faster. Redis Commander is a small open-source web UI that connects to one or more Redis instances and lets you inspect keys, view values, and run commands from the browser. You run it as a second container that points at your Redis container.

docker run -d \
  --name redis-commander \
  -e REDIS_HOSTS=local:redis:6379:0:a-long-random-password \
  -e HTTP_USER=admin \
  -e HTTP_PASSWORD=another-long-random-password \
  rediscommander/redis-commander:latest

The REDIS_HOSTS value follows the pattern label:host:port:db:password, where host is the name of your Redis container on the private network. The HTTP_USER and HTTP_PASSWORD variables put HTTP basic auth in front of the UI, which you should always set. The project documentation and configuration options live on the Redis Commander GitHub repository. RedisInsight, the official desktop and web client from the Redis project, is a heavier alternative if you want features like a data browser and slow-log analysis.

Locking down the UI matters as much as locking down Redis itself. If you give Redis Commander a public URL, protect it with the built-in basic auth at minimum, and prefer reaching it only over the private network or through your own authentication layer. A public UI wired to a database with no auth is the same risk as exposing Redis directly, one layer removed. If you do expose it, the public address follows the pattern redis-commander-8081-yourteam.outplane.app, and it must never be the only thing standing between the internet and your keys.

Running self-hosted Redis on Out Plane

Here is the honest product picture. Out Plane's managed database is PostgreSQL only. It ships with automated backups, point-in-time recovery, read replicas, connection pooling, and pgvector for embeddings. There is no managed Redis, no managed MySQL, and no managed MongoDB. If you want Redis on Out Plane, you self-host it as a normal container, exactly as described above.

That path is well supported. You deploy the official redis image with a persistent volume, keep it off any public route, and connect your application to it over the private network that links your containers. Your app reaches Redis by the container name as the hostname, so no public address is involved in the data path. The one job you own is operating it, which means backups, image upgrades, and choosing a memory size that fits your plan.

Your application connects through a single environment variable. The redis client libraries in every major language accept a connection URL, so REDIS_URL is the only value your code needs.

REDIS_URL=redis://default:a-long-random-password@redis:6379/0

import { createClient } from "redis";

const client = createClient({ url: process.env.REDIS_URL });
await client.connect();

await client.set("session:42", JSON.stringify({ userId: 42 }), { EX: 3600 });
const value = await client.get("session:42");

If your actual need is durable structured storage rather than a fast cache, use the managed Postgres instead and skip the operational overhead. See our guide on free PostgreSQL hosting for what the managed option covers. For the broader model of deploying any container image on the platform, read how Docker hosting works, and for the concepts behind the platform itself, what a PaaS is.

Managed Redis versus self-hosted Redis

The decision comes down to who does the operational work. A managed service trades money and control for someone else handling patches and backups. Self-hosting trades your time for lower cost and full access to the configuration. Since Out Plane does not offer managed Redis, the practical comparison is a managed vendor elsewhere against running Redis yourself on the platform where your app already lives.

Data residency and one thing to be clear about

You can pin your Redis container and its volume to an EU region, either Nuremberg or Helsinki. That is a data residency choice, meaning where the bytes physically sit. It is not a legal certification, and it does not change the fact that Out Plane is a US company. If EU data location is a requirement for you, selecting one of those regions keeps your Redis data there. Do not read anything beyond location into it.

Compute on the platform is CPU-based, which is exactly what Redis wants. Redis is an in-memory data store and does not need a GPU, so it runs well on standard container compute. If your project also involves large local machine-learning models, note that those need a GPU host the platform does not provide, but that is a separate concern from running Redis.

Frequently Asked Questions

What is Redis used for?

Redis is an in-memory data store used mainly for caching, session storage, rate limiting, and job queues. It keeps data in RAM for microsecond access, which makes it ideal for work that must be fast and can tolerate being rebuilt. It is not a replacement for a durable relational database like PostgreSQL.

Does Out Plane offer managed Redis?

No. Out Plane's only managed database is PostgreSQL, which includes automated backups, point-in-time recovery, read replicas, and pgvector. There is no managed Redis, MySQL, or MongoDB. To use Redis, you self-host the official image as a container with a persistent volume, connected to your app over the private network, and you operate it yourself.

Is it safe to self-host Redis?

Yes, when configured correctly. Always set a password with requirepass, keep protected-mode on, and never expose the Redis port to the public internet. Run it on a private network reachable only by your own containers. An unauthenticated, internet-facing Redis is one of the most commonly exploited misconfigurations, so isolation is the priority.

What is Redis Commander?

Redis Commander is an open-source web interface for Redis. You run it as a container alongside your Redis instance to browse keys, inspect values, and run commands from the browser instead of the command line. Protect it with HTTP basic auth using the HTTP_USER and HTTP_PASSWORD variables, and keep it off any public route when possible.

Should I use RDB or AOF persistence?

For a pure cache, you can skip persistence, since the data refills on its own. For sessions or job queues, enable AOF with appendonly yes so you lose at most about one second of writes. Running both RDB snapshots and AOF together gives you fast restarts and low data loss, which is a sensible default when the data matters.

How much memory should I give Redis?

Set maxmemory to a value that fits your container plan, then pick a maxmemory-policy. Use allkeys-lru for a cache so old keys are evicted under pressure, or noeviction for a queue where losing keys is unacceptable. Sizing depends on your dataset, so start small, watch usage, and raise the limit when you approach it.

How does my app connect to self-hosted Redis?

Through a single REDIS_URL environment variable in the form redis://default:password@host:6379/0, where host is the Redis container name on the private network. Standard Redis client libraries in Node, Python, Go, and others accept this URL directly. No public address is involved, because your app and Redis talk over the internal network.

Conclusion

To self-host Redis well, you need a persistent volume so data survives restarts, a password so nothing unauthenticated reaches it, sensible persistence with AOF, a memory limit with the right eviction policy, and a private network so the port never faces the internet. Add Redis Commander as a second container when you want a web UI, and protect that UI just as carefully. Because Out Plane's managed database is PostgreSQL only, Redis lives as a container you run and operate, which buys you full control at the cost of owning the backups and upgrades.

The next step is to deploy it. Create your Redis container in the console at https://console.outplane.com, attach a persistent volume, wire your app to it with REDIS_URL over the private network, and start on the free Hobby tier with $20 in trial credit and no credit card. See the details on pricing when you are ready to move to production.