Fider mit Docker Compose: Feedback-Portal selbst hosten

Kundenwünsche landen oft verstreut in Postfächern und Tickets. Für eine Roadmap braucht es einen Ort, an dem Kunden und Kollegen Ideen einreichen, abstimmen und den Bearbeitungsstand sehen. Fider ist genau so ein Feedback-Portal: Open Source unter AGPL-3.0, in Go geschrieben, mit PostgreSQL als einziger Datenquelle. Diese Anleitung zeigt, wie Sie Fider 0.38.2 mit Docker Compose betreiben, den ersten Administrator per E-Mail-Bestätigung anlegen, die Datenbank sichern, eine Wiederherstellung tatsächlich durchspielen und Updates kontrolliert einspielen. Alle Befehle und Ausgaben stammen aus einem eigenen Testlauf.

Voraussetzungen

Im Test belegte der App-Container nach dem Start rund 15 MiB RAM, PostgreSQL knapp 100 MiB. Planen Sie trotzdem Reserven für Datenbank-Cache und Backups ein.

• Linux-Server oder VM mit 1 bis 2 CPU-Kernen, 2 GB RAM und 10 GB freiem Speicher, x86_64 oder ARM64 (das Image gibt es für amd64 und arm64, je rund 190 MB komprimiert)
• Docker Engine mit Docker Compose v2
• eine Subdomain wie feedback.example.de mit DNS-Eintrag und ein Reverse Proxy mit TLS-Zertifikat, zum Beispiel Caddy oder Nginx
• ein SMTP-Konto für den Versand, etwa ein Postfach Ihres Mailanbieters mit Port 587 und STARTTLS
• ein Speicherziel außerhalb des Servers für die nächtlichen Datenbank-Dumps

Schritt 1: Eckdaten und Image-Tag festlegen

Bevor Sie Dateien anlegen, lohnt der Blick auf die Tags. Die offizielle Doku verwendet getfider/fider:stable. Beim Test am 15.10.2026 stammte stable auf Docker Hub vom 06.07.2026, während das aktuelle Release v0.38.2 vom 05.10.2026 als eigener Tag vorlag. Einen Tag latest gibt es nicht, ein Pull ohne Tag findet deshalb kein Image. Wichtig ist außerdem das v-Präfix: v0.38.2 existiert, 0.38.2 nicht.

Eckdatum	Wert
Image	getfider/fider:v0.38.2, Datenbank postgres:17
Port	3000 im Container, hier auf 8080 des Hosts gelegt
Volumes	./pg_data für PostgreSQL; die App selbst ist zustandslos
Pflicht-Env	BASE_URL, DATABASE_URL, JWT_SECRET, EMAIL_NOREPLY, EMAIL_SMTP_HOST, EMAIL_SMTP_PORT
Healthcheck	im Image eingebaut: ./fider ping, HTTP-Endpunkt /_health

sudo mkdir -p /opt/fider && cd /opt/fider
curl -s https://hub.docker.com/v2/repositories/getfider/fider/tags/v0.38.2 | grep -o '"name":"v0.38.2"'

Verifizieren: Der zweite Befehl gibt "name":"v0.38.2" aus. Kommt nichts zurück, prüfen Sie die Schreibweise des Tags.

Schritt 2: compose.yaml und .env anlegen

Die Compose-Datei orientiert sich an der offiziellen Doku, ergänzt aber zwei Dinge, die sich im Test bewährt haben: einen Healthcheck für PostgreSQL und depends_on mit service_healthy. Ohne diese Bedingung startet Fider oft vor der Datenbank und meldet zunächst connection refused, bis Docker den Container neu startet. Passwörter stehen nicht in der Compose-Datei, sondern in der .env.

services:
  db:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_USER: fider
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: fider
    volumes: ["./pg_data:/var/lib/postgresql/data"]
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U fider -d fider"]
      interval: 10s
      timeout: 5s
      retries: 5

  app:
    image: getfider/fider:v0.38.2
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    ports: ["8080:3000"]
    environment:
      BASE_URL: ${BASE_URL}
      DATABASE_URL: postgres://fider:${DB_PASSWORD}@db:5432/fider?sslmode=disable
      JWT_SECRET: ${JWT_SECRET}
      LOCALE: de
      EMAIL_NOREPLY: ${EMAIL_NOREPLY}
      EMAIL_SMTP_HOST: ${SMTP_HOST}
      EMAIL_SMTP_PORT: ${SMTP_PORT}
      EMAIL_SMTP_USERNAME: ${SMTP_USER}
      EMAIL_SMTP_PASSWORD: ${SMTP_PASSWORD}

Die .env erzeugen Sie mit zufälligen Geheimnissen. BASE_URL muss exakt die Adresse sein, unter der Nutzer Fider später aufrufen, denn daraus baut Fider jeden Link in den Anmelde-Mails.

cat > .env <<EOF
BASE_URL=https://feedback.example.de
DB_PASSWORD=$(openssl rand -hex 16)
JWT_SECRET=$(openssl rand -base64 48 | tr -d '\n/+=')
EMAIL_NOREPLY=noreply@example.de
SMTP_HOST=smtp.example.de
SMTP_PORT=587
SMTP_USER=noreply@example.de
SMTP_PASSWORD=IhrSmtpPasswort
EOF
chmod 600 .env

Läuft der Reverse Proxy auf demselben Host, binden Sie den Port besser nur lokal mit "127.0.0.1:8080:3000", damit Fider nicht unverschlüsselt von außen erreichbar ist. Für einen ersten Test ohne echtes Postfach eignet sich Mailpit als Fang-Postfach: Dienst mailpit mit Image axllent/mailpit:v1.31.5 ergänzen, SMTP_HOST=mailpit, SMTP_PORT=1025 und Benutzer sowie Passwort leer lassen. So lief auch unser Testaufbau.

Verifizieren: docker compose config --quiet endet ohne Ausgabe, und docker compose config | grep BASE_URL zeigt Ihre öffentliche Adresse.

Schritt 3: Starten und ersten Administrator anlegen

docker compose pull
docker compose up -d
docker compose logs app | grep -v 'Running Version'

Beim ersten Start spielt Fider sein Datenbankschema ein. Im Test lautete die Ausgabe:

[MIGRATE] Found total of 95 migration files.
[MIGRATE] Current version is 0
[MIGRATE] 95 migrations have been applied.
[WEB] Version: v0.38.2-e492af4a30db30c104df3dfb9e0f04e55757ba9e
[WEB] http server started on :3000

Rufen Sie danach Ihre Adresse im Browser auf. Solange noch kein Board existiert, leitet Fider auf /signup um. Dort tragen Sie Ihren Namen, Ihre E-Mail-Adresse und den Namen des Boards ein. Fider verschickt daraufhin eine Bestätigungs-Mail, und erst der Klick auf den Link darin legt das Board an und macht Sie zum Administrator. Ein Passwort gibt es nicht: Auch spätere Anmeldungen laufen über eine Mail mit Link oder sechsstelligem Code, der 15 Minuten gültig ist.

Nach dem Anlegen des ersten Boards ist die Registrierung geschlossen: /signup leitet im Test auf die Startseite um, und ein zweiter Anlageversuch über die API endete mit 400 und This subdomain is not available anymore.

Verifizieren: docker compose ps zeigt beide Container als Up, die App nach einigen Sekunden als healthy. curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8080/_health liefert 200, und nach dem Klick auf den Bestätigungslink sind Sie im Board angemeldet.

Schritt 4: Board einrichten und betreiben

Unter dem Zahnrad im Administrationsbereich legen Sie Titel, Begrüßungstext, Datenschutz-Einstellungen, Tags und Einladungen fest. Interne Boards stellen Sie unter Privacy auf privat. Nutzer reichen Ideen ein, stimmen ab und kommentieren; Administratoren setzen einen Status wie Geplant, Gestartet oder Erledigt und schreiben eine öffentliche Antwort dazu.

Alles, was die Oberfläche kann, steht auch über die REST-API unter /api/v1 bereit. Seit 0.38.2 begrenzt Fider limit bei /api/v1/posts auf 1000 und lehnt Anfragen über 25 MiB mit 413 ab. Außerdem lässt sich Fider nicht mehr per iframe in fremde Seiten einbetten. Wer das Board bisher in ein Kundenportal eingebettet hat, muss stattdessen verlinken.

Für den Alltag genügen drei Befehle: docker compose logs app --since 1h für Fehler, docker compose ps für den Healthcheck und docker stats --no-stream für den Speicherverbrauch.

Verifizieren: Ein Testbeitrag erscheint auf der Startseite, und curl -s http://localhost:8080/api/v1/posts liefert ihn als JSON zurück.

Schritt 5: Backup erstellen

Der gesamte Zustand von Fider liegt in PostgreSQL: Beiträge, Stimmen, Nutzer, Einstellungen und, solange BLOB_STORAGE auf dem Standard sql steht, auch hochgeladene Bilder und Logos. Ein Datenbank-Dump im Custom-Format genügt deshalb. Sichern Sie zusätzlich die .env und die compose.yaml, denn ohne den alten JWT_SECRET sind nach einer Wiederherstellung alle Sitzungen ungültig.

mkdir -p backup
docker compose exec -T db pg_dump -U fider -d fider -Fc > backup/fider-$(date +%F).dump
cp .env compose.yaml backup/

Im Administrationsbereich unter Export bietet Fider zusätzlich backup.zip an. Das Archiv enthielt im Test 14 JSON-Dateien, etwa posts.json, users.json und comments.json. Für die Wiederherstellung des Servers haben wir den Dump verwendet. Speichern Sie die Dumps per Cronjob täglich und kopieren Sie sie auf ein anderes System.

Verifizieren: docker compose exec -T db pg_restore -l < backup/fider-$(date +%F).dump | grep -c "TABLE DATA" zählt die gesicherten Tabellen. Im Test waren es 24 bei einer Dumpgröße von 86 KB.

Schritt 6: Restore durchführen und prüfen

Im Test haben wir einen Beitrag mit dem Titel MARKER-RESTORE-4711 angelegt, gesichert und danach in der Oberfläche gelöscht. Dabei zeigte sich ein wichtiges Detail: Fider löscht Beiträge nur logisch. Der Beitrag verschwindet aus Board und API, bleibt aber mit status = 6 in der Tabelle posts. Um einen echten Totalverlust nachzustellen, haben wir deshalb die komplette Datenbank entfernt und aus dem Dump zurückgespielt.

docker compose stop app
docker compose exec -T db dropdb -U fider fider
docker compose exec -T db createdb -U fider -O fider fider
docker compose exec -T db pg_restore -U fider -d fider --no-owner --exit-on-error < backup/fider-2026-10-15.dump
docker compose start app

Die App muss vorher gestoppt sein, sonst blockieren offene Verbindungen dropdb. Nach dem Leeren zählte information_schema.tables im Schema public null Tabellen, pg_restore endete mit Rückgabewert 0. Die Abfrage der Beiträge lieferte danach wieder:

docker compose exec -T db psql -U fider -d fider -tAc "select number,status,title from posts order by number"
1|4|Dunkelmodus für das Kundenportal
2|0|Export der Rechnungen als CSV
3|0|MARKER-RESTORE-4711 Zwei-Faktor-Anmeldung per App

Der Marker war mit Status 0 wieder sichtbar, ebenso der Status Geplant (4) am ersten Beitrag. Weil der JWT_SECRET unverändert blieb, blieb die bestehende Sitzung des Administrators gültig.

Verifizieren: curl -s http://localhost:8080/_health liefert 200, curl -s http://localhost:8080/api/v1/posts enthält den Marker-Beitrag, und im Board erscheinen alle Beiträge mit Stimmen und Status.

Schritt 7: Updates einspielen

Fider führt Datenbankmigrationen bei jedem Start selbst aus, das Image startet mit ./fider migrate && ./fider. Ziehen Sie vor jedem Update einen frischen Dump, lesen Sie die Release Notes auf GitHub und tragen Sie erst dann den neuen Tag ein. Getestet haben wir den Sprung von v0.38.1 auf v0.38.2 mit einem bestehenden Board:

docker compose exec -T db pg_dump -U fider -d fider -Fc > backup/vor-update.dump
sed -i 's/fider:v0.38.1/fider:v0.38.2/' compose.yaml
docker compose pull app
docker compose up -d
docker compose logs app | grep -E 'Current version|Version:'

[MIGRATE] Current version is 202606121200
[WEB] Version: v0.38.2-e492af4a30db30c104df3dfb9e0f04e55757ba9e

Zwischen diesen beiden Versionen gab es keine neue Migration, das Board war nach wenigen Sekunden wieder erreichbar und unverändert. Nach Migrationen führt der Rückweg nur über den Dump, nicht über das Zurücksetzen des Tags.

Verifizieren: Die Log-Zeile Version: nennt den neuen Stand, die Fußzeile des Boards zeigt v0.38.2, und Ihre Beiträge sind vollständig vorhanden.

Troubleshooting

Die folgenden Meldungen haben wir im Test gezielt ausgelöst:

• panic: could not find environment variable named 'EMAIL_SMTP_HOST': Es fehlt jede E-Mail-Konfiguration. Fider startet ohne Versandweg nicht. Ergänzen Sie SMTP, Mailgun oder Amazon SES.
• pq: password authentication failed for user "fider" (28P01) direkt nach [MIGRATE] Found total of 95 migration files.: Das Passwort in DATABASE_URL passt nicht zur Datenbank. Häufige Ursache ist ein geändertes DB_PASSWORD in der .env, nachdem pg_data bereits initialisiert war. PostgreSQL übernimmt das Passwort nur beim allerersten Start.
• Anmeldung meldet Erfolg, aber keine Mail kommt an: Die API antwortet trotzdem mit 200. Erst das Log zeigt failed to send email with template signin_email und die Ursache, im Test dial tcp: lookup mailpit on 127.0.0.11:53: server misbehaving bei gestopptem Mailserver. Prüfen Sie Host, Port, STARTTLS-Einstellung und Zugangsdaten.

Zwei weitere Fehlerquellen ergeben sich aus dem Aufbau:

• Links in Mails zeigen auf die falsche Adresse: BASE_URL stimmt nicht mit der öffentlichen Adresse überein. Nach jeder Änderung an der .env mit docker compose up -d neu erstellen, ein reiner Neustart liest die Umgebung nicht neu ein.
• Image wird nicht gefunden: Tag ohne v oder ohne Tag verwendet, dann sucht Docker nach dem nicht vorhandenen latest. Schreiben Sie v0.38.2.

Häufige Fragen

Braucht Fider wirklich einen Mailserver?

Ja. Ohne E-Mail-Konfiguration startet der Container nicht, und die Anmeldung per E-Mail ist der Standardweg. Alternativ lassen sich OAuth-Anbieter wie Google, GitHub oder ein eigener OpenID-Connect-Dienst einbinden, der Versand von Benachrichtigungen braucht trotzdem SMTP, Mailgun oder SES.

Wo liegen hochgeladene Bilder?

Standardmäßig in PostgreSQL, deshalb deckt der Dump sie ab. Mit BLOB_STORAGE=fs oder s3 landen sie im Dateisystem oder in einem S3-Bucket, dann gehört dieser Speicher zusätzlich ins Backup. Die Umstellung verschiebt vorhandene Dateien nicht.

Wie verhindere ich, dass Suchmaschinen das Board indexieren?

Neue Boards waren im Test mit der Einstellung zum Verhindern der Indexierung angelegt. Wer das Board öffentlich auffindbar machen möchte, ändert das in den Administrationseinstellungen; interne Boards stellen Sie zusätzlich auf privat.

Fazit

Fider ist ein schlankes Feedback-Portal, das mit zwei Containern und sehr wenig Speicher auskommt. Die wichtigsten Stolpersteine liegen nicht in der Installation, sondern im Umfeld: ein funktionierender Mailversand, eine exakt gesetzte BASE_URL und ein fest geschriebener Image-Tag statt des veralteten stable. Weil der komplette Zustand in PostgreSQL liegt, ist die Datensicherung übersichtlich; ein täglicher pg_dump plus .env reichte im Test für eine vollständige Wiederherstellung.

Weiterführende Anleitungen und Quellen

• Mailpit mit Docker Compose als SMTP-Testserver einrichten
• PostgreSQL mit pg_dump und pg_restore sichern und migrieren
• Caddy als Reverse Proxy mit automatischem HTTPS
• Docker-Container-Updates im Blick behalten mit Diun und WUD
• HedgeDoc mit Docker Compose und PostgreSQL sichern
• Fider Docs: Hosting on Docker und Konfigurationsreferenz
• getfider/fider auf GitHub
• Release Notes Fider v0.38.2
• Image-Tags getfider/fider auf Docker Hub