Running DBX, a Lightweight Multi-DB Client, on Docker Behind Traefik at /dbx

Running DBX, a Lightweight Multi-Database Client, Behind Traefik at a /dbx Subpath

DBeaver, which lets me edit PostgreSQL data in bulk through a GUI while writing almost no SQL, had been invaluable. It is Java based, though, so it is fairly heavy to start up, and I had come to want something a bit lighter for looking at several databases together. That was when I found DBX. It is free, supports many databases, and is said to run lightly. I decided to try building it into my Traefik-fronted Docker environment. [Read More]

Pi-hole Web UI Unreachable After a Failed TLS Certificate Auto-Renewal

Pi-hole Web UI Down : A TLS Certificate Auto-Renewal Failure and the Fix

I noticed that the Web UI of the Pi-hole I run at home (http://127.0.0.1:8053/admin) had become completely unreachable. All I got back was Connection reset by peer, and neither the browser nor curl could see anything. DNS resolution (port 53) was still working fine, so there was no real damage. As far as docker ps went the container was shown as healthy, so I had not been worried, but when I looked into it I found that the problem itself went back six days, to 2026-08-01. [Read More]

Removing Containers and Volumes for Just One Docker Compose Project

Safely Clean Up a Single Docker Compose Project

There are plenty of occasions where you clone a repository on GitHub and bring up a Docker environment temporarily to try it out. Deleting the containers and volumes that are no longer needed after testing one by one, however, is a chore. Commands such as docker system prune are convenient, but using them also deletes containers and volumes that are not running and have nothing to do with the test, which has bitten me several times. So I wrote a script that can safely remove the Docker environment of one specific project in a single shot. [Read More]

Self-Hosting Miniflux with Docker Compose and Traefik

Deploy Miniflux with Traefik and Docker Compose: Complete Setup Guide

Up to now I had been self-hosting RSS with FreshRSS, but since Miniflux is lightweight and can integrate with all sorts of external services, I migrated to it.

I am building it with Docker again this time, and I am writing it up on the following assumptions.

Environment

  • My own domain (already registered with Cloudflare)
  • Network: traefik-network (external)
  • CertResolver: cloudflare
  • entryPoints: web (80), websecure (443)

docker-compose.yml

services:
  miniflux:
    image: miniflux/miniflux:latest
    container_name: miniflux
    restart: always
    depends_on:
      db:
        condition: service_healthy
    environment:
      - DATABASE_URL=postgres://miniflux:${DB_PASSWORD}@db/miniflux?sslmode=disable
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=${ADMIN_USERNAME}
      - ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - BASE_URL=https://${MINIFLUX_DOMAIN}
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=traefik-network"
      - "traefik.http.routers.miniflux.rule=Host(`${MINIFLUX_DOMAIN}`)"
      - "traefik.http.routers.miniflux.entrypoints=websecure"
      - "traefik.http.routers.miniflux.tls=true"
      - "traefik.http.routers.miniflux.tls.certresolver=cloudflare"
      - "traefik.http.services.miniflux.loadbalancer.server.port=8080"
    networks:
      - traefik-network
      - miniflux-internal
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
      interval: 10s
      start_period: 30s
  db:
    image: postgres:17
    container_name: miniflux-db
    restart: always
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=${DB_PASSWORD}
      - POSTGRES_DB=miniflux
    volumes:
      - miniflux-db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      start_period: 30s
    networks:
      - miniflux-internal
networks:
  traefik-network:
    external: true
  miniflux-internal:
    driver: bridge
volumes:
  miniflux-db:

.env

DB_PASSWORD=your_secure_db_password
ADMIN_USERNAME=admin
ADMIN_PASSWORD=your_secure_admin_password
MINIFLUX_DOMAIN=rss.your-domain.com

Starting it up

docker compose up -d

Building Miniflux safely with Traefik + Docker Compose

  • PostgreSQL: the official documentation uses Postgres 18, but it is still beta, so I use 17
  • Network isolation: the DB is connected only to miniflux-internal, so it cannot be reached from outside
  • Traefik integration: the miniflux container is connected to traefik-network, and the routing is configured with labels
  • Ports: miniflux starts on 8080 by default, so there is no need to publish a port to the host (Traefik handles it)

Securing the Vaultwarden ADMIN_TOKEN with an Argon2 Hash in Docker

Run Vaultwarden with Argon2-Hashed ADMIN_TOKEN in Docker

Making the Vaultwarden ADMIN_TOKEN secure with an Argon2 hash Introduction When you open the Vaultwarden admin page, the following warning is sometimes displayed. Copy You are using a plain text `ADMIN_TOKEN` which is insecure. Please generate a secure Argon2 PHC string by using `vaultwarden hash` or `argon2`. Since Vaultwarden 1.28.0, hashing ADMIN_TOKEN with Argon2 is recommended. In this article I explain how to configure ADMIN_TOKEN securely in a Docker Compose environment. [Read More]

Enabling NVIDIA GPU Support in Docker with nvidia-container-toolkit

Step-by-Step Guide to Leveraging GPU Power within Docker Containers

TL;DR To answer the request to use a GPU (nvidia) inside a Docker container, Docker has to be configured for GPU support. Normally a Docker container cannot access the host’s GPU resources. That is because Docker does not pass the host’s GPU devices through to the container, and the reason behind it is that the GPU driver and the CUDA libraries are not properly shared between the host and the container. To get around this, the GPU resources have to be passed through to the container with a tool such as nvidia-container-toolkit. [Read More]

Fixing network.external.name is deprecated in Docker Compose

howto configure network.external.name on docker

When I rebuilt and started, for the first time in a while, a container that uses external in order to communicate between containers in different Docker environments, I ran into the error below Copy network default: network.external.name is deprecated. Please set network.name with external: true The docker-compose.yml I had been using until then worked with the following Copy … networks: default: external: name: ${NETWORK} The compose version has gone up and the way it is written seems to have changed, and the format below is apparently the correct one [Read More]

Spinning Up a Samba Server for Testing with Docker

Testing Samba Server on Docker

At work there was a request to build a temporary Windows file sharing server on Linux and test against it. Since it was only temporary, I wanted to avoid dirtying the system by installing directly onto it, so I built it with Docker. That said, a Docker image already exists, so all I do is use it This repository looks comparatively recently updated and maintained [Read More]

Building Zabbix 6 with Docker Compose

Zabbix6.2 Docker Containers

The Zabbix server I keep running all the time was on the old version 4, and partly because of template-related issues it seems the data cannot be migrated to 6.x, so I built Zabbix 6.x from scratch with Docker. Maybe the data could be carried over by upgrading zabbix4 -> 5 –> 6 one step at a time, but in my case I do not monitor that many servers, so building 6.x in one go and configuring the monitoring again seemed more efficient. [Read More]

Fixing Bloated Container Logs in /var/lib/docker/containers

Dealing with bloated Docker logs

An LDAP server running on Docker had reached 100% disk usage, so I looked into it. This LDAP server is close to read-only, so the data should not grow that much, should it? Copy # du -sh /var/lib/docker/* |sort -n 1.2G /var/lib/docker/overlay2 2.1M /var/lib/docker/image 4.0K /var/lib/docker/runtimes 4.0K /var/lib/docker/swarm 4.0K /var/lib/docker/tmp 4.0K /var/lib/docker/trust 4.4M /var/lib/docker/volumes 7.8G /var/lib/docker/containers 20K /var/lib/docker/builder 24K /var/lib/docker/plugins 60K /var/lib/docker/network 108K /var/lib/docker/buildkit /var/lib/docker/containers is clearly the one using a lot of space [Read More]