How to run and monitor Redis in Docker with FrontierStack

Published 2026-09-02

Redis is fast enough that people forget it is there; until it hits its memory ceiling and starts evicting the keys the application assumed would still exist. It also has an unfortunate history of being left open to the internet. This guide covers both.

Native or containerised

Services ▸ Redis installs it natively (Homebrew formula, brew services entry, start and stop from the pane). A container suits the common case better: Redis is usually a dependency of one application, and putting it in its own container keeps it that way; disposable, versioned, and gone when the project is.

Creating the container

Docker pane ▸ Create Container… ▸ the Redis preset gives you redis:alpine on port 6379, bound to 127.0.0.1 only.

That bind default deserves a paragraph of its own. Redis with no password on 0.0.0.0 is one of the most reliably exploited misconfigurations on the internet; automated scanners find it within hours. The preset binds to localhost, so the safe thing is what happens if you change nothing. If you do untick it, set requirepass and firewall the port in the same sitting, and check Security ▸ Open Ports afterwards to confirm what is actually listening.

Two options worth considering here. Redis has no volume in the preset, which is correct for a pure cache; but if you are using it as a datastore, add one at /data or you lose everything on restart. And add a --appendonly yes style argument in Advanced if you want persistence at all.

Read the command before you run it

The preview shows the exact docker run line, so you can check the bind address and the flags before anything happens. Press Create, and the container appears in the Docker pane with logs, a shell, and start/stop/restart.

Or on a linked server

Point the sheet at any host in your Fleet and the container is created there over SSH instead.

What to watch

Redis is one of the five engines Database Health understands, so it appears alongside your SQL servers rather than needing its own tooling. The numbers worth watching are memory used against maxmemory, the eviction count, whether the last background save succeeded, and connected-client count.

The failure mode people miss is persistence: if bgsave has been failing; usually a disk or permissions problem; Redis keeps serving perfectly from memory and you lose everything on the next restart. That is exactly the kind of silent failure worth an alert rather than a dashboard.

Ask the AI Administrator

"Is Redis on the app server healthy, and is it exposed?" gets you the memory picture, the persistence state and the bind address in one answer.

Where this lives in the app

Databases ▸ Database Health is the pane doing the work. Pick a target, and it lists every live connection, flags the ones worth worrying about, and; for MySQL and PostgreSQL; answers "why is this slow or stuck?" against the running server rather than guessing from a log.

Nothing here needs an agent installed on the database host. FrontierStack reaches a linked server over SSH using the key you already use, and reads through the database's own admin interfaces.

Set the alert before you need it

The useful moment for monitoring is the one before something breaks. Add the host in Fleet, point Database Health at it, and let the checks run on a schedule; a dead database reads as "no data", not "no problem", so an explicit alert is what turns a silent failure into a notification you actually receive.