#rabbitmq

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