Wer als Administrator den Überblick über Herstellerwarnungen, Security-Advisories, Release-Notes und Branchenblogs behalten will, sammelt heute meist Newsletter in einem Postfach oder klickt sich durch ein Dutzend Webseiten. Ein selbst gehosteter Feed-Reader dreht das um: Die Quellen kommen zu Ihnen, sortiert, ohne Trackingpixel und ohne Cloud-Anbieter, der jeden Lesevorgang mitprotokolliert. Miniflux 2 ist für diesen Zweck bewusst klein gehalten. Diese Anleitung führt Schritt für Schritt durch Installation, Erstkonfiguration, Absicherung, Backup und Update von Miniflux 2.3.3 mit Docker Compose und PostgreSQL. Die Kernschritte wurden in einer isolierten Testumgebung tatsächlich ausgeführt, alles Übrige ist als Dokumentationswissen gekennzeichnet.

Was Miniflux ist und wofür es taugt

Miniflux 2 ist ein quelloffener, selbst gehosteter Feed-Reader. Er besteht aus genau zwei beweglichen Teilen: einer einzelnen in Go geschriebenen Binärdatei und einer PostgreSQL-Datenbank. Es gibt keinen PHP-Stack, keinen separaten Cache-Dienst, keine Plugin-Verwaltung und keine Theme-Galerie. Genau diese Reduktion ist der Grund, warum sich das Projekt für Admin-Umgebungen anbietet: Es gibt wenig, das kaputtgehen kann, und die Update-Strecke besteht aus einem Image-Tag und einer Datenbankmigration.

Der praktische Nutzen für Administratoren und kleinere Unternehmen liegt in der Bündelung von Informationsquellen, die sonst verstreut sind:

Herstellerwarnungen und Advisories an einer Stelle statt in fünf verschiedenen Verteilerlisten, die jeder Kollege einzeln abonnieren muss.
Security-Feeds von Behörden und Projekten lassen sich in einer eigenen Kategorie bündeln und mit höherer Priorität lesen als allgemeine Branchennews.
Release-Notes der eingesetzten Software, damit Versionssprünge und Breaking Changes nicht erst beim Update auffallen.
Marktbeobachtung und Wettbewerb, ohne dass jemand täglich manuell Webseiten abklappern muss.
Gemeinsame Nutzung im Team, weil Miniflux mehrere Benutzerkonten unterstützt und jeder seine eigenen Abonnements pflegen kann.

Ebenso wichtig sind die Grenzen, damit niemand falsche Erwartungen mitbringt. Miniflux ist bewusst minimalistisch und will kein Alleskönner sein. Es ist kein Social Reader mit Kommentarfunktion, kein Team-Chat und kein Ersatz für ein Read-it-later-System wie Wallabag, das Artikel dauerhaft archiviert. Miniflux holt zwar auf Wunsch den Originalartikel und extrahiert den Inhalt, aber alte Einträge werden nach konfigurierbaren Fristen automatisch aufgeräumt. Wer eine revisionssichere Langzeitablage von Artikeln braucht, ist mit einem Archivsystem besser bedient. Auch eine grafische Auswertung von Lesegewohnheiten oder ein ausgefeiltes Rechtemodell mit Gruppen und Rollen gibt es nicht.

Voraussetzungen und Ressourcenbedarf

Die Testumgebung für diese Anleitung war ein Ubuntu-Host mit zwei CPU-Kernen, 8 GB RAM und x86_64-Architektur, darauf Docker 29.1.3 und Docker Compose 2.40.3. Das ist deutlich mehr, als Miniflux benötigt. Der Ressourcenbedarf wird in der Praxis von PostgreSQL bestimmt, nicht von Miniflux selbst.

Ein real gemessener Wert aus dem Test macht die Größenordnung deutlich: Das Image miniflux/miniflux:2.3.3 ist 13.157.104 Byte groß, also rund 13 MB. Das ist für eine vollständige Webanwendung inklusive HTTP-Server, Feed-Parser, Scheduler und Weboberfläche ungewöhnlich wenig und der wesentliche Grund, warum Miniflux auch auf sehr kleiner Hardware läuft. Für eine Installation mit einigen Dutzend Feeds und wenigen Benutzern reichen erfahrungsgemäß 1 CPU-Kern und 1 GB RAM aus, wobei der überwiegende Teil davon an PostgreSQL geht.

Laut offizieller Docker-Dokumentation des Projekts werden die Images für die Architekturen amd64, arm64, arm/v7 und arm/v6 veröffentlicht. Damit läuft Miniflux ausdrücklich auch auf einem Raspberry Pi, was für Selfhosting im kleinen Unternehmen oder für eine Nebenlast auf einem vorhandenen NAS relevant ist. Die Images liegen in drei Registries: docker.io/miniflux/miniflux, ghcr.io/miniflux/miniflux und quay.io/miniflux/miniflux. Fällt eine Registry aus oder greift ein Rate-Limit, ist der Wechsel also nur eine Änderung am Image-Namen.

Zu den Tags gibt die Dokumentation eine klare Empfehlung: latest zeigt auf die neueste stabile Version, eine konkrete Versionsnummer auf eine feste Version, nightly auf die Entwicklungsversion. Das Projekt empfiehlt ausdrücklich, eine feste Version zu pinnen, um unerwartete Aktualisierungen zu vermeiden. Diese Anleitung folgt dieser Empfehlung und verwendet durchgängig 2.3.3.

Vorausgesetzt werden außerdem Grundkenntnisse in Docker Compose. Wer damit noch nicht gearbeitet hat, findet den Einstieg in der verlinkten Grundlagen-Anleitung am Ende dieses Artikels.

Die compose.yaml mit Erklärung jedes Parameters

Die folgende Datei entspricht der im Test tatsächlich verwendeten Konfiguration, mit einer bewussten Abweichung: Im Test lag der veröffentlichte Port auf 38080, weil auf dem Testhost die üblichen Ports bereits belegt waren. Für den produktiven Einsatz ist 8080 oder eine Bindung an die Loopback-Adresse hinter einem Reverse Proxy sinnvoller. Legen Sie ein Verzeichnis an, zum Beispiel /opt/miniflux, und speichern Sie dort die Datei compose.yaml.

services:
  miniflux:
    image: miniflux/miniflux:2.3.3
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    depends_on:
      db:
        condition: service_healthy
    environment:
      - DATABASE_URL=postgres://miniflux:${POSTGRES_PASSWORD}@db/miniflux?sslmode=disable
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=${ADMIN_USERNAME}
      - ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - BASE_URL=https://feeds.example.org/
      - LISTEN_ADDR=0.0.0.0:8080
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
      interval: 10s
      timeout: 5s
      retries: 5
  db:
    image: postgres:18-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=miniflux
    volumes:
      - miniflux-db:/var/lib/postgresql
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      start_period: 30s
volumes:
  miniflux-db:

Die einzelnen Parameter im Detail:

image: miniflux/miniflux:2.3.3 pinnt die Version fest. Wer hier latest einträgt, bekommt bei jedem docker compose pull potenziell eine neue Hauptversion inklusive neuer Datenbankmigrationen, ohne es geplant zu haben.
restart: unless-stopped startet die Container nach einem Neustart des Hosts automatisch wieder, respektiert aber ein bewusstes manuelles Stoppen.
ports: "127.0.0.1:8080:8080" veröffentlicht den Dienst nur auf der Loopback-Adresse. Damit ist Miniflux von außen zunächst gar nicht erreichbar, sondern ausschließlich über den Reverse Proxy auf demselben Host. Wer "8080:8080" schreibt, öffnet den Port auf allen Interfaces, und zwar unter Umgehung einer eventuell vorhandenen Host-Firewall wie ufw.
depends_on mit condition: service_healthy sorgt dafür, dass Miniflux erst startet, wenn PostgreSQL laut eigenem Healthcheck bereit ist. Ohne diese Bedingung startet Miniflux zu früh, findet keine Datenbank und beendet sich, was durch die Restart-Policy zu einer Startschleife führt.
DATABASE_URL ist die Verbindungszeichenfolge. Der Hostname db ist der Dienstname aus dieser Datei, die Namensauflösung übernimmt das Compose-Netzwerk. sslmode=disable ist hier vertretbar, weil der Verkehr das interne Docker-Netzwerk nicht verlässt.
RUN_MIGRATIONS=1 führt laut Dokumentation die SQL-Migrationen automatisch aus. Ohne diese Variable müssten die Migrationen nach jedem Update von Hand angestoßen werden.
CREATE_ADMIN=1 zusammen mit ADMIN_USERNAME und ADMIN_PASSWORD legt beim ersten Start den ersten Administrator an. Die Dokumentation weist ausdrücklich darauf hin, dass diese drei Variablen nach der ersten Initialisierung wieder entfernt werden können. Das ist ein Härtungsschritt, den Sie nicht vergessen sollten, dazu unten mehr.
BASE_URL ist laut Dokumentation die Basis-URL für generierte HTML-Links und der Basispfad für Cookies, Standardwert ist http://localhost. Hinter einem Reverse Proxy mit TLS muss hier die öffentliche HTTPS-Adresse stehen, sonst brechen Links und Anmeldung.
LISTEN_ADDR ist laut Dokumentation die Adresse, auf der der Dienst lauscht, Standard ist 127.0.0.1:8080. Im Container muss der Wert auf 0.0.0.0:8080 stehen, sonst ist der Dienst von außerhalb des Containers nicht erreichbar.
Der healthcheck des Miniflux-Containers ruft die eingebaute Prüfung /usr/bin/miniflux -healthcheck auto auf. Diese Prüfung wurde im Test tatsächlich verwendet, der Container erreichte damit den Status healthy.
Das Volume miniflux-db hält die PostgreSQL-Daten. Der Pfad im Container ist versionsabhängig, siehe den eigenen Abschnitt weiter unten. Das ist der wichtigste Stolperstein dieser Anleitung.

Die Zugangsdaten gehören nicht in die Compose-Datei, sondern in eine .env-Datei im selben Verzeichnis. Docker Compose liest sie automatisch ein. Die folgenden Werte sind Platzhalter und müssen ersetzt werden.

# Datei: /opt/miniflux/.env
# Passwort der PostgreSQL-Datenbank, mindestens 24 Zeichen
POSTGRES_PASSWORD=bitte-hier-ein-eigenes-langes-passwort-eintragen
# Anmeldename des ersten Administrators
ADMIN_USERNAME=admin
# Passwort des ersten Administrators, mindestens 20 Zeichen
ADMIN_PASSWORD=bitte-hier-ein-eigenes-langes-passwort-eintragen

Die Datei enthält Klartextgeheimnisse und muss entsprechend geschützt werden:

# Zugriff auf den Eigentümer beschränken
chmod 600 /opt/miniflux/.env
# Eigentümer prüfen
ls -l /opt/miniflux/.env

Wer strenger arbeiten will: Miniflux unterstützt laut Dokumentation für zahlreiche Variablen eine Dateivariante mit dem Suffix _FILE, etwa ADMIN_PASSWORD_FILE oder DATABASE_URL_FILE. Der Wert ist dann der Pfad zu einer Datei, die das Geheimnis enthält. Damit lassen sich Docker-Secrets statt Umgebungsvariablen verwenden.

Installation und erster Start

Dieser Abschnitt wurde in der isolierten Testumgebung tatsächlich ausgeführt. Zuerst die Images holen und den Stack starten:

# In das Projektverzeichnis wechseln
cd /opt/miniflux
# Images herunterladen
docker compose pull
# Stack im Hintergrund starten
docker compose up -d

Nach dem Start prüfen Sie den Zustand beider Container. Im Test standen beide nach kurzer Zeit auf Up (healthy):

# Status der Container inklusive Healthcheck anzeigen
docker compose ps

Interessanter ist das Startlog, weil es zeigt, was Miniflux beim ersten Start tut. Real beobachtet wurden diese drei Meldungen in dieser Reihenfolge:

# Logs des Miniflux-Containers anzeigen
docker compose logs miniflux
# Erwartete Zeilen beim ersten Start:
# Running database migrations current_version=0 latest_version=132
# Created new admin user username=admin user_id=1
# Starting HTTP server listen_address=0.0.0.0:8080

Die erste Zeile bedeutet, dass Miniflux die Datenbank von Version 0 auf Version 132 hebt, also beim allerersten Start 132 Migrationen nacheinander ausführt. Das dauert auf normaler Hardware nur wenige Sekunden, ist aber der Grund, warum der erste Start länger braucht als alle folgenden. Die zweite Zeile belegt, dass CREATE_ADMIN=1 gegriffen hat und der Administrator mit der Benutzer-ID 1 angelegt wurde. Die dritte Zeile zeigt, dass der HTTP-Server auf allen Adressen im Container lauscht.

Bleibt die Migrationszeile aus und stattdessen erscheinen Verbindungsfehler zur Datenbank, prüfen Sie zuerst, ob der Datenbankcontainer wirklich healthy ist und ob das Passwort in .env mit dem in DATABASE_URL verwendeten übereinstimmt.

Rufen Sie die Oberfläche im Browser auf, im lokalen Test war das http://localhost:38080, in der hier gezeigten Konfiguration entsprechend Ihre Reverse-Proxy-Adresse. Melden Sie sich mit den Zugangsdaten aus der .env-Datei an.

Ein Hinweis zur Versionsanzeige, der im Test aufgefallen ist: Der Aufruf von /version im Browser ohne Anmeldung führt zu einer Weiterleitung auf die Loginseite und liefert eben nicht die Version. Wer die Version im Monitoring abgreifen will, kommt auf diesem Weg nicht weiter. Zuverlässig ist der Containerbefehl aus dem nächsten Abschnitt.

Die sinnvolle Reihenfolge bei der Ersteinrichtung ist Kategorien zuerst, Feeds danach. Miniflux ordnet jeden Feed genau einer Kategorie zu, und nachträgliches Umsortieren von dreißig Feeds ist mühsamer als fünf Minuten Vorüberlegung. Bewährt hat sich eine Trennung nach Dringlichkeit statt nach Themen, zum Beispiel eine Kategorie für Security-Advisories, die täglich gelesen wird, eine für Release-Notes der eingesetzten Produkte und eine für allgemeine Branchennews, die auch mal eine Woche liegen bleiben darf.

Feeds legen Sie über den Menüpunkt zum Hinzufügen eines Abonnements an. Miniflux akzeptiert dabei nicht nur die direkte Feed-URL, sondern auch die Adresse der Webseite und versucht, den Feed selbst zu finden. Unterstützt werden laut Projektbeschreibung Atom 0.3 und 1.0, RSS 1.0 und 2.0 sowie JSON Feed 1.0 und 1.1.

Für den Umzug aus einem bestehenden Reader gibt es OPML-Import und OPML-Export. Exportieren Sie im alten Reader die Abonnementliste als OPML-Datei und importieren Sie diese in Miniflux über die Einstellungen. Hinweis zur Abgrenzung: Der OPML-Import wurde in dieser Testumgebung nicht ausgeführt. Die Funktion ist offiziell dokumentiert, die konkrete Migration aus einem Fremdsystem sollten Sie vor dem Produktivumzug einmal mit einer kleinen Testdatei durchspielen. Wichtig ist dabei: OPML transportiert die Feedliste und die Kategoriestruktur, nicht aber gelesene Artikel, Sternchen oder Lesezeichen.

Funktions- und Healthcheck

Alle Befehle dieses Abschnitts wurden in der Testumgebung tatsächlich ausgeführt. Sie bilden zusammen die Grundlage für ein sinnvolles Monitoring.

Der wichtigste Endpunkt für externes Monitoring ist /healthcheck. Er antwortete im Test mit HTTP 200 und dem Textkörper OK:

# Healthcheck-Endpunkt abfragen, HTTP-Status ausgeben
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:38080/healthcheck
# Antwortkörper ausgeben
curl -s http://localhost:38080/healthcheck

Für ein Monitoring-System wie Uptime Kuma oder Checkmk ist das der richtige Prüfpunkt, weil er nicht nur den HTTP-Server, sondern auch die Datenbankverbindung abdeckt. Ein simpler Portcheck auf 8080 würde einen Zustand mit abgestürzter Datenbank nicht erkennen.

Die installierte Version fragen Sie zuverlässig im Container ab. Im Test lieferte dieser Befehl exakt 2.3.3:

# Versionsnummer aus dem laufenden Container auslesen
docker compose exec -T miniflux /usr/bin/miniflux -version

Wer Prometheus einsetzt, findet in der Dokumentation die passenden Parameter: METRICS_COLLECTOR=1 aktiviert laut Dokumentation einen Metrik-Kollektor und stellt einen /metrics-Endpunkt für Prometheus bereit, standardmäßig ist er deaktiviert. Mit METRICS_ALLOWED_NETWORKS wird festgelegt, welche Netze auf diesen Endpunkt zugreifen dürfen, der Standardwert ist 127.0.0.1/8. Zusätzlich lassen sich mit METRICS_USERNAME und METRICS_PASSWORD Zugangsdaten für HTTP-Basisauthentifizierung setzen. Diese Metrik-Konfiguration wurde im Test nicht ausgeführt.

API-Check, in der Testumgebung selbst ausgeführt

Die API eignet sich gut, um die Funktion nicht nur oberflächlich, sondern bis zum tatsächlichen Feedabruf zu prüfen. Alle folgenden Aufrufe liefen im Test mit HTTP-Basisauthentifizierung gegen den Testport.

# Eigenes Benutzerprofil abfragen, liefert HTTP 200
curl -u admin:PASSWORT http://localhost:38080/v1/me

Die Antwort enthielt das Benutzerprofil, unter anderem is_admin mit dem Wert true, das gesetzte Theme, die Sprache und entries_per_page mit dem Wert 100. Damit ist belegt, dass Authentifizierung, Datenbankzugriff und API-Schicht zusammen funktionieren.

Der zweite Test legt einen echten Feed an:

# Feed per API anlegen, liefert HTTP 201
curl -u admin:PASSWORT -X POST http://localhost:38080/v1/feeds \
  -H "Content-Type: application/json" \
  -d '{"feed_url":"https://borncity.com/blog/feed/","category_id":1}'

Der Aufruf antwortete mit HTTP 201 und dem Körper {"feed_id":1}. Ein anschließendes GET /v1/feeds zeigte den Feed mit parsing_error_count gleich 0, und GET /v1/entries?limit=3 belegte, dass 20 Einträge abgerufen worden waren. Damit ist der komplette Pfad vom API-Aufruf über den Scheduler bis zum tatsächlichen Abruf der externen Quelle verifiziert.

Für den dauerhaften Betrieb empfiehlt die Dokumentation nicht die Basisauthentifizierung, sondern anwendungsbezogene API-Schlüssel, die seit Version 2.0.21 unterstützt werden. Sie werden in den Einstellungen unter API Keys erzeugt und über den HTTP-Header X-Auth-Token gesendet. Der Vorteil ist, dass ein einzelner Schlüssel widerrufen werden kann, ohne das Kennwort des Kontos zu ändern.

Persistente Daten, Rechte und der Postgres-Volumepfad

Der gesamte Zustand von Miniflux, also Feeds, Kategorien, Artikel, Benutzer und Lesestatus, liegt in der PostgreSQL-Datenbank. Der Miniflux-Container selbst hält keine dauerhaften Daten und ist damit vollständig ersetzbar. Das Volume miniflux-db ist der einzige Ort, den Sie sichern müssen.

Ein im Test bestätigter Sicherheitsaspekt: Der Miniflux-Prozess läuft nicht als root. Die Prüfung ergab uid=65534(nobody) gid=65534(nobody). Das ist ein guter Ausgangswert, weil ein erfolgreicher Angriff auf den Anwendungsprozess damit keine Root-Rechte im Container erbt.

# Benutzerkontext im laufenden Container prüfen
docker compose exec -T miniflux id

Jetzt der wichtigste Stolperstein dieser Anleitung. Der Pfad des Datenverzeichnisses im PostgreSQL-Container hängt von der Hauptversion ab. PostgreSQL 18 nutzt /var/lib/postgresql, PostgreSQL 17 und älter nutzen /var/lib/postgresql/data. Wer beim Wechsel der Postgres-Hauptversion den Pfad in der Compose-Datei nicht anpasst, mountet das Volume an der falschen Stelle. Die Folge ist ein scheinbar leerer Start: Miniflux findet eine frische, leere Datenbank vor, führt die 132 Migrationen erneut aus, legt den Admin neu an, und alle Feeds sind verschwunden. Die Daten sind dabei in der Regel nicht gelöscht, sondern liegen weiterhin im Volume, nur eben an einem Pfad, den niemand liest. Das ist die häufigste Fehlerquelle bei Versionssprüngen und der Grund, warum Sie vor jedem Postgres-Upgrade einen Dump ziehen sollten.

Netzwerkfreigabe und Reverse Proxy mit TLS

Dieser Abschnitt wurde in der Testumgebung nicht ausgeführt. Die Konfiguration stammt aus der offiziellen Dokumentation und ist hier für den produktiven Einsatz aufbereitet. Im Test lief Miniflux ausschließlich unverschlüsselt auf einem lokalen Port.

Betreiben Sie Miniflux niemals ohne TLS über ein Netzwerk, das über den eigenen Host hinausgeht. Die Anmeldung erfolgt über ein Formular, Zugangsdaten und Sitzungscookie gingen sonst im Klartext über das Netz. Der saubere Aufbau ist: Miniflux lauscht nur auf der Loopback-Adresse, ein Reverse Proxy terminiert TLS und leitet weiter. Genau dafür steht in der Compose-Datei oben 127.0.0.1:8080:8080.

Die offizielle Dokumentation zeigt folgende Nginx-Konfiguration als Beispiel, hier um den TLS-Teil ergänzt:

server {
    server_name feeds.example.org;
    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/feeds.example.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/feeds.example.org/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Entscheidend ist der Header X-Forwarded-Proto. Fehlt er, weiß Miniflux nicht, dass die Verbindung von außen bereits verschlüsselt ist, und erzeugt Weiterleitungen auf HTTP. Ebenso wichtig ist der Header X-Forwarded-For, denn ohne ihn kann Miniflux laut Dokumentation die entfernte IP-Adresse nicht bestimmen, was Logauswertung und Sitzungsübersicht entwertet.

Parallel dazu muss BASE_URL in der Compose-Datei auf die öffentliche Adresse gesetzt sein, also zum Beispiel https://feeds.example.org/. Die Variable steuert laut Dokumentation die Erzeugung von HTML-Links und den Basispfad für Cookies. Wer hier den Standardwert http://localhost stehen lässt, bekommt typischerweise eine Anmeldemaske, die nach dem Absenden wieder auf der Anmeldemaske landet, weil das Cookie für die falsche Domain gesetzt wurde.

Zusätzlich sollte HTTPS=1 gesetzt werden. Die Dokumentation beschreibt das als Erzwingen des Secure-Flags für Cookies und Senden des HSTS-Headers. Für Betrieb unter einem Unterverzeichnis, etwa https://example.org/rss/, enthält die How-To-Seite des Projekts eigene Beispiele für Nginx und Apache. Wer Traefik oder Caddy einsetzt, findet fertige Compose-Beispiele im Projekt-Repository unter contrib/docker-compose. Auch diese wurden hier nicht getestet.

Backup und Wiederherstellung

Das Backup wurde in der Testumgebung tatsächlich durchgeführt. Der folgende Befehl erzeugte eine 76 KB große, valide SQL-Datei mit korrektem PostgreSQL-Dump-Header:

# In das Projektverzeichnis wechseln
cd /opt/miniflux
# Datenbank als SQL-Dump sichern
docker compose exec -T db pg_dump -U miniflux miniflux > /var/backups/miniflux-$(date +%F).sql
# Ergebnis prüfen, Größe und Kopfzeile
ls -lh /var/backups/miniflux-$(date +%F).sql
head -5 /var/backups/miniflux-$(date +%F).sql

Das -T ist wichtig: Ohne diese Option versucht Docker, ein Pseudo-Terminal zuzuweisen, und die Umleitung in die Datei liefert eine unbrauchbare, mit Steuerzeichen verunreinigte Ausgabe. Genau daran scheitern viele automatisierte Backupskripte, die interaktiv funktionieren und im Cronjob stillschweigend Müll produzieren.

Ein Backup, das nie zurückgespielt wurde, ist kein Backup. Der Wiederherstellungsablauf sieht so aus:

# Miniflux stoppen, damit niemand während der Wiederherstellung schreibt
docker compose stop miniflux
# Bestehende Datenbank löschen und neu anlegen
docker compose exec -T db dropdb -U miniflux miniflux
docker compose exec -T db createdb -U miniflux miniflux
# Dump einspielen
docker compose exec -T db psql -U miniflux -d miniflux < /var/backups/miniflux-2026-09-14.sql
# Miniflux wieder starten
docker compose start miniflux
# Zustand prüfen
docker compose ps

Hinweis zur Abgrenzung: Der vollständige Wiederherstellungsablauf wurde in dieser Testumgebung nicht durchgespielt, nur die Erzeugung des Dumps. Testen Sie die Wiederherstellung einmal auf einem separaten Host, bevor Sie sich im Ernstfall darauf verlassen.

Zusätzlich empfiehlt sich ein regelmäßiger OPML-Export über die Weboberfläche. Er enthält nur die Feedliste und die Kategoriestruktur, keine Artikel und keinen Lesestatus, ist dafür aber winzig, menschenlesbar und lässt sich notfalls in jeden beliebigen anderen Reader importieren. Als leichtgewichtiges Notfallnetz ergänzt das den Datenbankdump gut, ersetzt ihn aber nicht.

Updates und Rollback-Grenzen

Das offizielle Vorgehen für Docker-Installationen steht in der Upgrade-Dokumentation des Projekts: neues Image mit dem neuen Tag ziehen, bei Compose den neuen Tag in der YAML-Datei eintragen und den Container neu starten, und die Datenbankmigrationen nicht vergessen, wofür RUN_MIGRATIONS=1 gesetzt sein muss. Die Dokumentation stellt dem Ganzen eine unmissverständliche Warnung voran: Software nicht blind aktualisieren, immer die Release-Notes lesen und auf Breaking Changes prüfen. Für Nicht-Container-Installationen nennt die Dokumentation zusätzlich das Abmelden aller Benutzer über miniflux -flush-sessions, das Sichern der Datenbank und die ausdrückliche Prüfung, dass das Backup funktioniert.

Der praktische Ablauf mit Compose:

# Zuerst sichern, ohne Ausnahme
docker compose exec -T db pg_dump -U miniflux miniflux > /var/backups/miniflux-vor-update.sql
# Danach in der compose.yaml den neuen Image-Tag eintragen
# Neues Image herunterladen
docker compose pull
# Container mit neuem Image neu erzeugen
docker compose up -d
# Migrationsausgabe im Log kontrollieren
docker compose logs --tail 50 miniflux

Nun zur unangenehmen Wahrheit über Rollbacks. Sobald eine neue Version ihre Migrationen ausgeführt hat, liegt das Datenbankschema auf einem neueren Stand. Ein älteres Miniflux-Image kennt dieses Schema nicht und bringt keine Abwärtsmigrationen mit. Ein Rollback durch bloßes Zurücksetzen des Image-Tags funktioniert deshalb in der Regel nicht sauber, auch wenn der Container zunächst startet. Der einzig verlässliche Rückweg ist: alte Version als Image, dazu der vor dem Update gezogene Dump, eingespielt in eine frisch angelegte Datenbank. Das ist der Grund, warum der pg_dump vor jedem Update Pflicht ist und nicht optional.

Typische Fehler mit Diagnose und Lösung

Die folgenden Fehlerbilder sind teils im Test real aufgetreten, teils aus der Dokumentation abgeleitet. Die Herkunft ist jeweils angegeben.

Nach dem Postgres-Versionswechsel sind alle Feeds weg. Ursache ist fast immer der versionsabhängige Volume-Pfad, siehe oben. Prüfen Sie mit docker compose exec -T db ls -la /var/lib/postgresql, ob die Daten dort oder in einem Unterverzeichnis data liegen, und passen Sie die Volume-Zeile an. Nicht voreilig down -v ausführen, das löscht die noch vorhandenen Daten endgültig.
HTTP 500 beim Anlegen eines Feeds per API, obwohl der Server läuft. Real im Test beobachtet: Ein POST /v1/feeds auf eine nicht existierende Feed-URL antwortete mit HTTP 500 und dem Körper {"error_message":"fetcher: resource not found (404 status code)"}. Im Log erschienen parallel eine WARN-Zeile Unable to fetch feed und eine ERROR-Zeile. Die Meldung ist irreführend, weil ein HTTP 500 einen Serverfehler suggeriert, obwohl in Wahrheit nur die angegebene Quelle nicht erreichbar war. Wer Feeds automatisiert per API anlegt, sollte deshalb bei 500 immer zuerst den error_message-Text auswerten und nicht den Miniflux-Dienst neu starten.
Einzelne Feeds lassen sich nicht abrufen, andere schon. Häufige Ursache ist ein Bot-Schutz beim Anbieter. Miniflux bietet laut Projektbeschreibung mehrere Gegenmaßnahmen: einen konfigurierbaren eigenen User-Agent, die Möglichkeit, HTTP/2 zur Reduktion von Fingerprinting zu deaktivieren, das Mitgeben eigener Cookies sowie den Abruf über einen Proxy, wofür die Dokumentation HTTP_CLIENT_PROXY und HTTP_CLIENT_PROXIES nennt. Diese Gegenmaßnahmen wurden im Test nicht ausprobiert. Prüfen Sie in der Feedübersicht den Zähler parsing_error_count und die zugehörige Fehlermeldung, bevor Sie an den Einstellungen drehen.
Anmeldung springt hinter dem Reverse Proxy immer wieder zur Loginmaske zurück. Das ist das klassische Symptom einer falschen BASE_URL. Der Wert muss exakt der öffentlichen Adresse entsprechen, inklusive Schema und abschließendem Schrägstrich. Zusätzlich muss der Proxy X-Forwarded-Proto setzen.
Die Admin-Variablen stehen nach Monaten noch in der Compose-Datei. Die Dokumentation weist darauf hin, dass CREATE_ADMIN, ADMIN_USERNAME und ADMIN_PASSWORD nach der ersten Initialisierung entfernt werden können. Lassen Sie das Administratorkennwort nicht dauerhaft als Umgebungsvariable im Prozess stehen, wo es jeder mit Containerzugriff auslesen kann. Entfernen Sie die drei Zeilen nach dem ersten erfolgreichen Login und starten Sie den Container neu.
Miniflux startet in einer Schleife neu. Prüfen Sie mit docker compose logs db, ob PostgreSQL überhaupt hochkommt. Häufig ist ein nachträglich geändertes Datenbankpasswort die Ursache, das im bestehenden Volume nicht mehr mit dem Wert in .env übereinstimmt. Das Ändern von POSTGRES_PASSWORD wirkt sich bei einem bereits initialisierten Volume nicht mehr aus.

Datenschutzfunktionen, die im Alltag wirken

Ein Teil des Nutzens von Miniflux liegt darin, was es beim Anzeigen von Artikeln aktiv unterlässt oder entfernt. Diese Eigenschaften sind in der Projektbeschreibung dokumentiert und für Unternehmen ein greifbares Argument, das über reine Bequemlichkeit hinausgeht.

Zählpixel werden entfernt, Tracking-Parameter aus URLs herausgeschnitten, darunter utm_source, utm_medium, utm_campaign und fbclid. Wer Links aus dem Reader weiterreicht, verteilt damit keine Kampagnenkennungen mehr im Unternehmen.
Externe Links werden mit rel="noopener noreferrer" und referrerpolicy="no-referrer" geöffnet, zusätzlich setzt Miniflux den HTTP-Header Referrer-Policy: no-referrer. Die aufgerufene Seite erfährt damit nicht, von welcher internen Adresse der Klick kam.
Externes JavaScript wird blockiert, externe Inhalte werden vor der Darstellung bereinigt. Durchgesetzt wird das über eine Content Security Policy und eine Trusted-Types-Policy, die nur Anwendungs-JavaScript zulassen und Inline-Skripte sowie Inline-Styles blockieren.
Ein eingebauter Medien-Proxy kann Bilder und Medien über die eigene Instanz ausliefern. Das verhindert Tracking durch Dritte und löst zugleich Mixed-Content-Warnungen auf, wenn die Instanz über HTTPS läuft, eingebettete Bilder aber per HTTP ausgeliefert werden. Gesteuert wird das laut Dokumentation über MEDIA_PROXY_MODE mit den Werten http-only, all oder none, Standard ist http-only. Der Medien-Proxy wurde im Test nicht ausprobiert.
YouTube-Videos werden über youtube-nocookie.com eingebunden, alternativ lässt sich eine Invidious-Instanz konfigurieren.
Bei FeedBurner-Feeds holt Miniflux die Originallinks zurück, statt die Umleitungsadressen zu verwenden.

Für die Inhaltsaufbereitung bringt Miniflux außerdem einen lokalen Readability-Parser mit, der den Originalartikel abruft und den relevanten Inhalt extrahiert. Ergänzend gibt es eigene Scraper-Regeln per CSS-Selektor, Rewrite-Regeln und Regex-Filter, mit denen sich Artikel gezielt ein- oder ausschließen lassen. Damit lässt sich ein Feed, der nur Anrisstexte liefert, praktisch nutzbar machen. Die Volltextsuche läuft direkt über PostgreSQL, es wird also kein zusätzlicher Suchdienst benötigt.

Saubere Deinstallation

Warnung: Der Befehl docker compose down -v löscht das Datenbankvolume und damit alle Feeds, Kategorien, Benutzer und den kompletten Lesestatus unwiderruflich. Es gibt danach keinen Weg zurück außer einem vorher erstellten Backup.

Ziehen Sie deshalb vor jeder Deinstallation zuerst einen OPML-Export über die Weboberfläche und zusätzlich einen Datenbankdump. Der OPML-Export kostet zehn Sekunden und erspart Ihnen, dreißig Feed-URLs aus dem Gedächtnis zu rekonstruieren, falls Sie später doch wieder einen Reader aufsetzen.

# Vorher sichern
cd /opt/miniflux
docker compose exec -T db pg_dump -U miniflux miniflux > /var/backups/miniflux-final.sql
# Container stoppen und entfernen, Volume bleibt erhalten
docker compose down
# Erst wenn die Daten wirklich weg dürfen: Volume mit entfernen
docker compose down -v
# Images entfernen, falls nicht mehr benötigt
docker image rm miniflux/miniflux:2.3.3 postgres:18-alpine

Wollen Sie nur den Stack neu aufbauen, aber die Daten behalten, reicht docker compose down ohne -v. Das benannte Volume überlebt das und wird beim nächsten up wieder eingehängt.

Einordnung für kleine und mittlere Unternehmen

Miniflux ist ein gutes Beispiel für Software, deren Betriebsaufwand im Verhältnis zum Nutzen sehr niedrig liegt. Zwei Container, ein Volume, ein Healthcheck-Endpunkt, ein pg_dump im Cronjob, das ist die gesamte Betriebslast. Das rund 13 MB große Image und der Betrieb als nobody sprechen zusätzlich dafür, dass hier jemand auf Angriffsfläche geachtet hat.

Belegbar ist auch die Projektlage. Das Repository miniflux/v2 auf GitHub wies beim Abruf über die GitHub-API am 14.09.2026 9.688 Sterne aus, der letzte Push war der 12.09.2026, das Repository ist nicht archiviert und wird aktiv gepflegt. Die Lizenz ist laut GitHub-API Apache-2.0. Das aktuelle Release 2.3.3 stammt vom 24.07.2026. Für ein Werkzeug, das dauerhaft im Unternehmen laufen soll, sind ein aktiver Entwicklungsstand und eine klare Lizenz die zwei Punkte, die man vor der Einführung prüfen sollte, und beide sind hier erfüllt.

Wer bereits einen anderen Reader betreibt, muss nicht zwingend wechseln. FreshRSS etwa deckt einen ähnlichen Bedarf, ist aber ein PHP-Projekt mit anderem Betriebsmodell und einer größeren Funktionsbreite inklusive Erweiterungen. Die Entscheidung läuft in der Praxis darauf hinaus, ob man lieber wenige Funktionen mit minimalem Wartungsaufwand hat oder mehr Funktionen mit etwas mehr Pflege. Wer ohnehin Docker betreibt und PostgreSQL im Haus hat, fährt mit Miniflux meist schneller ans Ziel.

Passende Anleitungen auf S-EDV

FreshRSS nativ unter Ubuntu mit Apache, PHP, SQLite und systemd zeigt den direkten Vergleich: derselbe Anwendungsfall, aber als native Installation ohne Container und mit einem funktionsreicheren, dafür pflegeintensiveren Reader.
Docker Compose Grundlagen und Stacks erklärt Dienste, Netzwerke, Volumes und Abhängigkeiten von Grund auf, falls die compose.yaml oben mehr Fragen als Antworten aufwirft.
Docker Compose absichern mit Secrets, Healthchecks und Non-Root vertieft genau die Punkte, die hier nur angerissen wurden: Geheimnisse aus Umgebungsvariablen herausziehen und Container ohne Root-Rechte betreiben.

Quellen

Miniflux Dokumentation, Docker, Registries, Architekturen, Tag-Konvention und Umgebungsvariablen für Migrationen und Admin-Anlage.
Miniflux Dokumentation, Configuration Parameters, Belege zu BASE_URL, LISTEN_ADDR, POLLING_FREQUENCY, BATCH_SIZE, den CLEANUP-Parametern, METRICS_COLLECTOR und den _FILE-Varianten.
Miniflux Dokumentation, Upgrading Miniflux, offizielles Update-Vorgehen für Docker und die Warnung vor blinden Updates.
Miniflux Dokumentation, How-To's, Reverse-Proxy-Beispiele für Nginx und Apache inklusive Betrieb in einem Unterverzeichnis.
Miniflux Dokumentation, API Reference, Authentifizierung per Basic Auth und API-Schlüssel, Endpunkte und Statuscodes.
Projekt-Repository miniflux/v2 auf GitHub, Projektbeschreibung mit Datenschutzfunktionen, Release 2.3.3 vom 24.07.2026, Lizenz Apache-2.0, Kennzahlen abgerufen am 14.09.2026.
Offizielle Compose-Beispiele im Repository, unter anderem für Traefik und Caddy.