#redis

XXX is the first few characters of the container ID.

Bash inside a container

docker exec -it XXX /bin/bash

Restart policy

docker update --restart=always XXX

Docs

My default containers

Databases and the broker are bound to 127.0.0.1 only

PostgreSQL 18

Mounting a database from your local disk is convenient, but in the long run it causes problems on Windows:

docker run --name postgres18 --restart=always --stop-timeout=30 -e POSTGRES_PASSWORD=YOUR_SUPER_SECRET_LOCAL_PASS -d -p 127.0.0.1:5432:5432 -v c:/postgres:/var/lib/postgresql postgres:18

A docker volume is more reliable and faster:

docker volume create postgres-data
docker run --name postgres18 --restart=always --shm-size=1g --stop-timeout=60 -e POSTGRES_PASSWORD=YOUR_SUPER_SECRET_LOCAL_PASS -d -p 127.0.0.1:5432:5432 -v postgres-data:/var/lib/postgresql postgres:18

Worth remembering: since 18 the mount point is /var/lib/postgresql, and the data lives in the 18/docker subdirectory. Handy for a later migration, e.g. to Postgres 19.

Redis

docker run -d --name redis -p 127.0.0.1:6379:6379 --restart=always -e REDIS_PASSWORD=YOUR_SUPER_SECRET_LOCAL_PASS bitnami/redis:latest

FlareSolverr

Proxy server to bypass Cloudflare and anti-bot protection.

docker run -d --name=flaresolverr --restart=always -p 8191:8191 -e LOG_LEVEL=error --tmpfs /tmp:rw,size=4g,mode=1777 ghcr.io/flaresolverr/flaresolverr:latest

--tmpfs: /tmp in RAM, 4 GB max. Abandoned Chromium profiles and crash dumps never reach the container layer, so docker_data.vhdx doesn’t grow because of them. Wiped on container restart.

RabbitMQ + management console

docker run -d --name rabbit01 --hostname rabbit01 --restart=always -e RABBITMQ_DEFAULT_USER=rabbit-user -e RABBITMQ_DEFAULT_PASS=YOUR_SUPER_SECRET_LOCAL_PASS -p 127.0.0.1:15672:15672 -p 127.0.0.1:5672:5672 rabbitmq:management

Port 5672 is AMQP, 15672 is the web console.

--hostname: RabbitMQ stores its data in a directory named after the hostname. Without a fixed one, a new container gets a random hostname and doesn’t see the old data.

Automatic updates

Not for PostgreSQL — update the database by hand, when you choose. The postgres:18 tag only pulls 18.x anyway;

But something like FlareSolverr is worth keeping on the latest version. Simplest way: a compose.yaml:

services:
  flaresolverr:
    image: ghcr.io/flaresolverr/flaresolverr:latest
    pull_policy: daily
    restart: unless-stopped
    ports:
      - "8191:8191"
    environment:
      LOG_LEVEL: error
    tmpfs:
      - /tmp:rw,size=4g,mode=1777

and a Task Scheduler job (two actions in one task):

docker compose -f C:\docker\flaresolverr\compose.yaml up -d
docker image prune -f

The task starts in System32, hence the full path in -f. image prune removes the old images left behind by updates.

With pull_policy: daily the check runs at most once a day. If the image hasn’t changed, the container isn’t recreated.

Switching from docker run? Remove the old container first, otherwise port 8191 is taken:

docker rm -f flaresolverr

redis-cli --scan --pattern 'KEY_PREFIX*' | xargs -r -n 500 redis-cli UNLINK

--scan walks the keys in chunks.

UNLINK — it frees the memory on a separate thread, no blocking. -n 500 so you don’t spawn a process per key, -r skips the call when nothing matches.

Check what you’re about to nuke first:

redis-cli --scan --pattern 'KEY_PREFIX*' | head

--scan only walks on your current node (check –cluster call for cluster)

Biggest keys

redis-cli --bigkeys

Walks the whole database with SCAN and shows the biggest key of each type.

Mind the units: for strings it counts bytes, for collections the number of elements. A list with a million short entries will look “bigger” here than a single 10 MB string.

What it actually weighs

redis-cli --memkeys

Same walk, but measured with MEMORY USAGE — real bytes. Slower, but it doesn’t lie. Redis 6 and up.

A single key:

redis-cli MEMORY USAGE mykey

Both walks cover the entire keyspace. On a large database add -i 0.1 so they pause between batches instead of hammering the server.

Command stats

INFO commandstats

How many times each command ran and how long it took on average (usec_per_call). Usually this is where it turns out Redis isn’t slow — somebody is just hammering KEYS in a loop.

Reset the counters before measuring:

CONFIG RESETSTAT