No description
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-09-02 19:47:34 +00:00
.idea Erster Stand 2026-06-25 21:06:19 +02:00
dynamicconfig Erster Stand 2026-06-25 21:06:19 +02:00
scripts Erster Stand 2026-06-25 21:06:19 +02:00
.env Add Postiz email configuration 2026-06-26 08:03:23 +02:00
.gitignore Erster Stand 2026-06-25 21:06:19 +02:00
docker-compose.override.yml Add Postiz email configuration 2026-06-26 08:03:23 +02:00
docker-compose.yml Erster Stand 2026-06-25 21:06:19 +02:00
Installation.md Erster Stand 2026-06-25 21:06:19 +02:00
LICENSE chore(license): add AGPL-3.0-or-later license and copyright notice 2026-09-02 21:32:44 +02:00
README.md chore(license): add AGPL-3.0-or-later license and copyright notice 2026-09-02 21:32:44 +02:00

Postiz Social Media Stack

Docker-Compose-Stack fuer Postiz hinter deinem bestehenden Traefik-Reverse-Proxy.

Die Grundidee:

  • docker-compose.yml bleibt die offizielle Upstream-Datei von Postiz.
  • docker-compose.override.yml enthaelt nur unsere lokalen Anpassungen.
  • scripts/update-postiz-compose.sh aktualisiert die Upstream-Dateien kontrolliert.

Damit koennen Aenderungen aus gitroomhq/postiz-docker-compose leichter uebernommen werden, ohne unsere Traefik-, Secret- und Volume-Anpassungen jedes Mal manuell neu einzubauen.

Dateien

  • .env – lokale Konfiguration und Secrets als Template
  • docker-compose.yml – originale Postiz-Upstream-Compose-Datei
  • docker-compose.override.yml – lokale Anpassungen fuer Traefik, Env-Werte, Ports und Volumes
  • dynamicconfig/development-sql.yaml – Temporal-Konfiguration aus dem Postiz-Upstream
  • scripts/update-postiz-compose.sh – Update-Script fuer Upstream-Dateien
  • Installation.md – konkrete Installations- und Update-Schritte

Was der Override macht

  • Entfernt direkte Host-Ports aus der Upstream-Datei fuer postiz, temporal, temporal-ui und spotlight
  • Verbindet postiz mit ${PROXY_NETWORK} fuer Traefik
  • Fuegt Traefik-Labels fuer HTTPS, Let's Encrypt und Middlewares hinzu
  • Ueberschreibt die Upstream-Dummy-Secrets mit Werten aus .env
  • Legt persistente Volumes wie bei mein-SuluCMS unter ./volumes/... ab
  • Vergibt projektbezogene Container- und Netzwerknamen

Persistente Daten

Die named volumes werden auf lokale Ordner gebunden:

  • postgres-volume -> ./volumes/postiz-postgres – Postiz-Datenbank
  • postiz-redis-data -> ./volumes/postiz-redis – Redis-Daten
  • postiz-config -> ./volumes/postiz-config – Postiz-Konfiguration
  • postiz-uploads -> ./volumes/postiz-uploads – lokale Uploads/Medien
  • temporal-postgres-data -> ./volumes/temporal-postgres – Temporal-Datenbank
  • temporal-elasticsearch-data -> ./volumes/temporal-elasticsearch – Temporal-Suchindex

temporal-postgres-data und temporal-elasticsearch-data sind keine Images, sondern Daten-Volumes. Postiz nutzt Temporal fuer Hintergrundablaeufe/Workflows. Diese Daten sollten mitgesichert werden.

Schnellstart

./scripts/update-postiz-compose.sh
mkdir -p volumes/postiz-postgres volumes/postiz-redis volumes/postiz-config volumes/postiz-uploads volumes/temporal-postgres volumes/temporal-elasticsearch
docker compose config -q
docker compose up -d

Vorher .env anpassen. Details stehen in Installation.md.

Passwoerter/Secrets ohne problematische Sonderzeichen erzeugen:

LC_ALL=C tr -dc 'A-Za-z0-9' </dev/urandom | head -c 64; printf '\n'
LC_ALL=C tr -dc 'A-Za-z0-9' </dev/urandom | head -c 48; printf '\n'

DISABLE_REGISTRATION=false fuer den Erststart lassen. Nach deinem ersten Account auf DISABLE_REGISTRATION=true setzen und den Stack neu erstellen.

Mailversand / SMTP

Postiz kann E-Mails ueber zwei Provider-Typen versenden:

  • EMAIL_PROVIDER=nodemailer – klassischer SMTP-Versand ueber deinen Mailserver oder SMTP-Relay
  • EMAIL_PROVIDER=resend – Versand ueber den externen API-Dienst Resend

Fuer normale Self-Hosted-Setups ist meistens nodemailer die richtige Wahl, wenn du bereits einen SMTP-Server hast, z. B. Mailcow, mailbox.org, Hetzner, IONOS, Brevo, Mailgun SMTP, Amazon SES SMTP oder einen anderen Mailanbieter. Resend ist sinnvoll, wenn du bewusst einen API-basierten Transaktionsmail-Dienst verwenden willst und dort Domain/SPF/DKIM eingerichtet hast.

Beispiel: SMTP mit STARTTLS auf Port 587

Das ist fuer die meisten Mailanbieter die empfohlene Variante:

EMAIL_PROVIDER=nodemailer
EMAIL_HOST=smtp.example.com
EMAIL_PORT=587
EMAIL_USER=postiz@example.com
EMAIL_PASS=CHANGE_ME__smtp_password
EMAIL_SECURE=false
EMAIL_FROM_ADDRESS=postiz@example.com
EMAIL_FROM_NAME=Postiz
RESEND_API_KEY=

EMAIL_SECURE=false bedeutet hier nicht, dass unverschluesselt gesendet wird. Bei Port 587 startet die Verbindung normalerweise unverschluesselt und wird dann per STARTTLS auf TLS hochgestuft. Das ist der gaengige Standard fuer authentifizierten SMTP-Versand.

Beispiel: SMTPS mit implizitem TLS auf Port 465

Einige Anbieter nutzen weiterhin Port 465. Dann wird TLS direkt beim Verbindungsaufbau verwendet:

EMAIL_PROVIDER=nodemailer
EMAIL_HOST=smtp.example.com
EMAIL_PORT=465
EMAIL_USER=postiz@example.com
EMAIL_PASS=CHANGE_ME__smtp_password
EMAIL_SECURE=true
EMAIL_FROM_ADDRESS=postiz@example.com
EMAIL_FROM_NAME=Postiz
RESEND_API_KEY=

SSL/TLS, STARTTLS und EMAIL_SECURE

EMAIL_SECURE steuert bei Nodemailer, ob die SMTP-Verbindung sofort als TLS-Verbindung aufgebaut wird.

  • Port 587: normalerweise EMAIL_SECURE=false, danach Upgrade per STARTTLS
  • Port 465: normalerweise EMAIL_SECURE=true, TLS direkt ab Verbindungsaufbau
  • Port 25: fuer Server-zu-Server-Mail gedacht, fuer App-Login meistens nicht verwenden

Wenn dein Anbieter „TLS“, „STARTTLS“ oder „Submission Port 587“ schreibt, ist in der Regel EMAIL_PORT=587 und EMAIL_SECURE=false korrekt. Wenn dein Anbieter „SSL“, „SMTPS“ oder „Port 465“ schreibt, ist meist EMAIL_PORT=465 und EMAIL_SECURE=true korrekt.

Warum gibt es RESEND_API_KEY?

Postiz unterstuetzt neben SMTP auch Resend als Mailprovider. Dafuer wird kein SMTP-Login, sondern ein API-Key verwendet:

EMAIL_PROVIDER=resend
RESEND_API_KEY=re_xxxxxxxxxxxxxxxxxxxxxxxxx
EMAIL_FROM_ADDRESS=postiz@example.com
EMAIL_FROM_NAME=Postiz

Wenn EMAIL_PROVIDER=nodemailer gesetzt ist, bleibt RESEND_API_KEY leer. Der API-Key ist nur fuer EMAIL_PROVIDER=resend relevant. Laut Postiz-Konfiguration beeinflusst ein gesetzter RESEND_API_KEY ausserdem, ob Benutzeraktivierung per Mail erforderlich ist; deshalb nicht unnoetig setzen, wenn SMTP genutzt wird.

Wichtige Hinweise

  • EMAIL_FROM_ADDRESS sollte zu deiner Maildomain passen und beim Anbieter erlaubt sein.
  • SPF, DKIM und DMARC fuer die Absenderdomain korrekt setzen, sonst landen Mails leicht im Spam.
  • Nach Aenderungen an Mailvariablen Container neu erstellen: docker compose down && docker compose up -d.
  • SMTP-Passwoerter nicht mit normalen Login-Passwoertern verwechseln; viele Anbieter nutzen eigene App-Passwoerter oder SMTP-Credentials.

Nuetzliche Befehle

docker compose config -q
docker compose pull
docker compose up -d
docker compose ps
docker compose logs -f postiz
docker compose down

Updates

./scripts/update-postiz-compose.sh
docker compose config -q
docker compose pull
docker compose up -d

Wenn die Validierung nach einem Postiz-Upstream-Update fehlschlaegt, muss wahrscheinlich docker-compose.override.yml an die neue Upstream-Struktur angepasst werden.

Lizenz

Copyright (C) 2026 Christian Säum – web-seo-consulting.eu

Dieses Projekt steht unter der GNU Affero General Public License, Version 3 oder (nach deiner Wahl) einer späteren Version (AGPL-3.0-or-later). Der vollständige Lizenztext steht in der Datei LICENSE.

Du darfst die Software nutzen, weitergeben und – auch kommerziell – verkaufen. Gibst du eine veränderte Fassung weiter oder betreibst du sie über ein Netzwerk (z. B. als Dienst), muss deren vollständiger Quellcode ebenfalls unter der AGPL-3.0-or-later verfügbar sein. Der Copyright-Hinweis und die Nennung des ursprünglichen Autors dürfen nicht entfernt werden.

Diese Angabe betrifft nur die in diesem Repository enthaltenen eigenen Dateien (Konfiguration, Skripte, Anpassungen). Eingebundene Fremdsoftware und Container-Images unterliegen weiterhin ihren eigenen Lizenzen.