Zum Hauptinhalt springen
S-EDV news
← Alle Anleitungen
📘 Anleitung Cloud / Hosting 26.06.2026 · 10 min Lesezeit

Super Productivity mit Docker installieren: Fortgeschrittene To-do- und Zeiterfassungs-App selbst hosten

Super Productivity ist die FOSS-Antwort auf Todoist Premium plus Toggl: Aufgabenverwaltung, Zeiterfassung und Timeboxing in einer App – ohne Abo, ohne Telemetrie, vollständig lokal. Mit Docker Compose läuft das Setup inklusive WebDAV-Sync in unter 15 Minuten.

Super Productivity mit Docker installieren als selbst gehostete Open Source To-do- und Zeiterfassungs-App mit Aufgabenverwaltung, Projekten, Kalenderplanung, Statistiken, Datenbank und sicherer Docker Infrastruktur.

Wer Aufgabenverwaltung, Zeiterfassung und Timeboxing in einer einzigen App vereinen möchte, ohne dafür monatliche Abo-Kosten zu zahlen oder Arbeitsdaten an externe Clouds zu übergeben, findet in Super Productivity eine ausgereifte Alternative. Die MIT-lizenzierte Software vereint ein Kanban-Board, einen integrierten Pomodoro-Timer, direktes Timeboxing per Kalender sowie tiefe Integrationen in Jira, GitHub, GitLab, Gitea, OpenProject, Linear, ClickUp, CalDAV und Azure DevOps – alles lokal im Browser, ohne Benutzerkonten oder Telemetrie. Über 20.000 GitHub-Sterne und 370 Releases sprechen für ein aktiv gepflegtes Projekt. Per Docker Compose lässt sich das vollständige Setup – App-Container plus WebDAV-Sync-Server – plattformneutral auf jedem Linux-Host, NAS oder Raspberry Pi in weniger als 15 Minuten aufsetzen.

Voraussetzungen

  1. Docker Engine ab 20.10 mit Docker Compose Plugin v2 (docker compose, kein altes docker-compose). Wer das noch nicht eingerichtet hat, findet die Grundlagen in der Anleitung Docker und Docker Compose auf Linux installieren.
  2. Linux-Host, VM, NAS mit Docker-Unterstützung oder Raspberry Pi 4/5 (linux/amd64, linux/arm64 und linux/arm/v7 werden offiziell unterstützt).
  3. Mindestens 256 MB freier RAM für App- und WebDAV-Container gemeinsam.
  4. Ca. 200 MB Speicherplatz für Images plus Datenspeicher.
  5. Netzwerkzugriff auf Docker Hub für den einmaligen Image-Pull.
  6. Texteditor (z. B. nano, vim oder VS Code) für webdav.yaml und .env.
  7. Optional: Reverse Proxy (Traefik, Caddy, Nginx Proxy Manager) für HTTPS-Termination bei öffentlichem Zugriff – dazu mehr im Abschnitt „Reverse Proxy und HTTPS".

Eckdaten auf einen Blick

EigenschaftWert
Image (App)johannesjo/super-productivity:latest
Image (WebDAV)hacdias/webdav:v5
Image-Größe Appca. 73 MB (nginx-basiert)
Interner Port App80 → Compose-Mapping: 8080:80
WebDAV-Port2345:2345
Architekturlinux/amd64, linux/arm64, linux/arm/v7
DatenpersistenzBrowser-LocalStorage + WebDAV-Volume
LizenzMIT
Version (Juni 2026)18.10.0
UmgebungsvariableStandardBedeutung
WEBDAV_BASE_URLhttp://localhost:2345/WebDAV-Server-URL (Vorausfüllung Einstellungen)
WEBDAV_USERNAMEadminWebDAV-Benutzername (Vorausfüllung)
WEBDAV_SYNC_FOLDER_PATH/Sync-Pfad auf dem WebDAV-Server
SYNC_INTERVAL15Synchronisierungsintervall in Sekunden
IS_COMPRESSION_ENABLEDtrueDatenkomprimierung aktivieren
IS_ENCRYPTION_ENABLEDfalseEnde-zu-Ende-Verschlüsselung

Alle Variablen sind optional – sie füllen lediglich die Einstellungsseite im Browser vor. Die App startet auch ohne sie. Es gibt keinen Pflicht-SECRET_KEY und kein Datenbankpasswort für den normalen Betrieb.

Schritt 1: Projektordner und WebDAV-Konfiguration anlegen

Lege zunächst einen sauberen Projektordner an und erstelle dort die webdav.yaml. Diese Datei ist Pflicht – ohne sie verweigert der WebDAV-Container den Start mit der Fehlermeldung „no such file or directory" für /etc/webdav/config.yaml.

mkdir -p /opt/super-productivity
cd /opt/super-productivity

Erstelle jetzt die webdav.yaml. Der Standardwert aus dem offiziellen Repo lautet Benutzer admin / Passwort admin – das muss vor dem ersten Start auf ein sicheres Passwort geändert werden, damit der Sync-Endpunkt nicht offen erreichbar ist:

# /opt/super-productivity/webdav.yaml
address: 0.0.0.0
port: 2345
auth: true
tls: false
prefix: /
scope: /data
modify: true
rules: []
users:
  - username: meinbenutzername
    password: SicheresPasswort2026!
    scope: /data

Passe username und password auf eigene Werte an und notiere sie – du benötigst sie gleich in der .env und später in den App-Einstellungen.

Verifizieren: Die Datei muss im Projektordner liegen und lesbar sein.

ls -la /opt/super-productivity/
# Erwartete Ausgabe: webdav.yaml mit korrekten Rechten sichtbar

Schritt 2: .env-Datei mit Zugangsdaten erstellen

Die .env-Datei hält alle projektspezifischen Werte außerhalb der compose.yaml und ermöglicht einfaches Anpassen ohne Änderungen an der Compose-Konfiguration selbst.

# /opt/super-productivity/.env

# WebDAV-Zugangsdaten (müssen mit webdav.yaml übereinstimmen)
WEBDAV_BASE_URL=http://localhost:2345/
WEBDAV_USERNAME=meinbenutzername

# Sync-Einstellungen
WEBDAV_SYNC_FOLDER_PATH=/
SYNC_INTERVAL=15

# Datenkomprimierung und Verschlüsselung
IS_COMPRESSION_ENABLED=true
IS_ENCRYPTION_ENABLED=false

Wer den WebDAV-Endpunkt öffentlich erreichbar macht, sollte IS_ENCRYPTION_ENABLED=true setzen oder den Zugriff ausschließlich über einen HTTPS-Reverse-Proxy erlauben.

Verifizieren:

cat /opt/super-productivity/.env
# Alle Variablen korrekt gesetzt, kein Tippfehler in der URL

Schritt 3: compose.yaml erstellen

Die folgende compose.yaml enthält zwei Services: die eigentliche App und den WebDAV-Sync-Server. PostgreSQL und der SuperSync-Dienst aus dem offiziellen GitHub-Repo sind bewusst weggelassen – sie sind ausschließlich für E2E-Tests vorgesehen und im produktiven Betrieb unnötig ressourcenhungrig.

# /opt/super-productivity/compose.yaml
services:
  app:
    image: johannesjo/super-productivity:latest
    container_name: super-productivity
    restart: unless-stopped
    ports:
      - "8080:80"
    environment:
      WEBDAV_BASE_URL: ${WEBDAV_BASE_URL:-http://localhost:2345/}
      WEBDAV_USERNAME: ${WEBDAV_USERNAME:-admin}
      WEBDAV_SYNC_FOLDER_PATH: ${WEBDAV_SYNC_FOLDER_PATH:-/}
      SYNC_INTERVAL: ${SYNC_INTERVAL:-15}
      IS_COMPRESSION_ENABLED: ${IS_COMPRESSION_ENABLED:-true}
      IS_ENCRYPTION_ENABLED: ${IS_ENCRYPTION_ENABLED:-false}
    depends_on:
      webdav:
        condition: service_healthy

  webdav:
    image: hacdias/webdav:v5
    container_name: super-productivity-webdav
    restart: unless-stopped
    ports:
      - "2345:2345"
    volumes:
      - ./webdav.yaml:/etc/webdav/config.yaml:ro
      - webdav_data:/data
    healthcheck:
      test: ["CMD", "wget", "--quiet", "--tries=1", "--spider", "http://localhost:2345/"]
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 10s

volumes:
  webdav_data:

Der App-Container hat bewusst keine eigenen Volume-Mounts: Daten liegen im Browser-LocalStorage, Persistenz wird ausschließlich über den WebDAV-Sync-Container sichergestellt. Das named Volume webdav_data überlebt Container-Neustarts und Updates vollständig.

Verifizieren: YAML-Syntax prüfen, bevor du startest:

cd /opt/super-productivity
docker compose config
# Keine Fehler, beide Services und das Volume werden ausgegeben

Schritt 4: Container starten

Jetzt startest du den Stack. Docker Compose lädt zunächst beide Images von Docker Hub und startet dann zuerst den WebDAV-Container (inklusive Healthcheck-Wartezeit), bevor der App-Container hochfährt.

cd /opt/super-productivity
docker compose up -d

Der erste Pull dauert je nach Verbindung 30–60 Sekunden (App ca. 73 MB, WebDAV-Image deutlich kleiner). Anschließend wartet Compose bis der WebDAV-Healthcheck healthy zurückmeldet – das dauert typischerweise 10–30 Sekunden.

Verifizieren:

docker compose ps
# Erwartete Ausgabe:
# NAME                          IMAGE                                    STATUS
# super-productivity            johannesjo/super-productivity:latest     Up (running)
# super-productivity-webdav     hacdias/webdav:v5                        Up (healthy)

docker compose logs --tail=20
# Keine Fehlermeldungen zu Image/Port/Volume/Config

Zusätzlich per curl prüfen:

curl -I http://localhost:8080
# HTTP/1.1 200 OK  ← App liefert Antwort

curl -I http://localhost:2345/
# HTTP/1.1 401 Unauthorized  ← WebDAV erreichbar, Authentifizierung erwartet

Schritt 5: Erste Einrichtung im Browser und WebDAV-Sync aktivieren

Öffne http://HOST:8080 im Browser (ersetze HOST durch die IP-Adresse oder den Hostnamen deines Servers). Super Productivity startet direkt ohne Login-Maske – kein Benutzerkonto, keine Registrierung.

Der wichtigste Schritt nach dem ersten Aufruf: den WebDAV-Sync aktivieren. Ohne diese Einstellung liegen alle Daten nur im Browser-LocalStorage – ein Browserwechsel, das Löschen von Browserdaten oder ein Inkognito-Fenster würde alles vernichten.

  1. Öffne die Einstellungen (Zahnrad-Symbol unten links).
  2. Wechsle zum Bereich Sync / WebDAV.
  3. Die Felder „WebDAV-URL", „Benutzername" und „Sync-Pfad" sind bereits durch die Umgebungsvariablen vorausgefüllt – prüfe die Werte und ergänze das Passwort aus deiner webdav.yaml.
  4. Klicke auf Verbindung testen – bei Erfolg erscheint eine grüne Bestätigung.
  5. Aktiviere den Sync und klicke auf Speichern.

Ab jetzt werden alle Aufgaben, Zeiterfassungs-Einträge und Einstellungen automatisch alle 15 Sekunden mit dem WebDAV-Container synchronisiert.

Verifizieren: Im Browser die Entwicklertools öffnen (F12) → Netzwerk-Tab: Alle 15 Sekunden sollte eine Anfrage an http://HOST:2345/ erscheinen (PUT oder PROPFIND). Alternativ im Terminal:

docker compose logs webdav --tail=10
# Erwartete Ausgabe: PUT- oder PROPFIND-Requests von der App-IP

Schritt 6: Jira, GitHub oder GitLab verbinden (optional)

Super Productivity glänzt durch seine tiefen Integrationen. Die Einrichtung folgt immer demselben Schema: Einstellungen → Projekte → Neues Projekt anlegen → Integration wählen.

Für Jira benötigst du die Basis-URL deiner Jira-Instanz, deinen Benutzernamen und ein API-Token (über id.atlassian.com/manage-profile/security/api-tokens abrufbar). Issues werden bidirektional synchronisiert, Zeiterfassung kann direkt auf Jira-Tickets gebucht werden.

Für GitHub und GitLab reicht ein Personal Access Token mit read:project-Berechtigung. Issues erscheinen dann als Aufgaben in Super Productivity und lassen sich mit Zeiterfassung versehen.

Alle Zugangsdaten bleiben ausschließlich im Browser-LocalStorage – sie verlassen deinen Host nicht.

Verifizieren: Nach dem Verbinden einer Integration sollten Issues des Projekts in der Aufgabenliste erscheinen. Bei Fehlern zeigt Super Productivity eine Inline-Fehlermeldung mit HTTP-Statuscode – typische Ursachen sind ein abgelaufenes Token oder eine falsche Basis-URL.

Schritt 7: Reverse Proxy und HTTPS einrichten (empfohlen)

Im LAN-Betrieb ist HTTP auf Port 8080 ausreichend. Sobald die App aus dem Internet erreichbar sein soll, ist HTTPS-Termination über einen Reverse Proxy Pflicht – andernfalls sind WebDAV-Zugangsdaten und Aufgabendaten unverschlüsselt übertragbar.

Eine ausführliche Anleitung zur HTTPS-Absicherung mit automatischem Zertifikatsmanagement findest du unter Caddy als Reverse Proxy einrichten: Anfänger-Anleitung mit automatischem HTTPS und Traefik als Docker-Reverse-Proxy mit automatischem HTTPS.

Wichtig beim Proxy-Setup: Die WEBDAV_BASE_URL muss dann auf die öffentliche HTTPS-URL des WebDAV-Endpunkts aktualisiert werden (z. B. https://webdav.meine-domain.de/). Anschließend docker compose up -d wiederholen, damit der App-Container die neue URL als Voreinstellung übernimmt.

Verifizieren:

curl -I https://meine-domain.de
# HTTP/2 200  ← TLS aktiv, App erreichbar

Schritt 8: Updates und Backup

Da der App-Container selbst keine persistenten Daten hält, ist ein Update unkompliziert:

cd /opt/super-productivity
docker compose pull
docker compose up -d
# Kein Migrations-Schritt erforderlich; webdav_data bleibt unberührt

Für das Backup des WebDAV-Volumes reicht ein einfaches Tar-Archiv:

docker compose exec webdav tar czf /tmp/sp-backup.tar.gz /data
docker cp super-productivity-webdav:/tmp/sp-backup.tar.gz ./sp-backup-$(date +%Y%m%d).tar.gz

Zusätzlich kannst du jederzeit aus der App heraus einen Export als JSON oder CSV erstellen (Einstellungen → Daten → Exportieren) – kein Vendor-Lock-in, volle Portabilität.

Wer Container-Updates automatisieren möchte, findet einen strukturierten Vergleich der gängigen Werkzeuge in der Anleitung Docker-Container automatisch aktualisieren nach dem Watchtower-Aus: Diun, WUD und Renovate im Vergleich.

Verifizieren:

docker compose ps
# Beide Container STATUS = Up; Image-Tags zeigen aktuelle Version

docker compose logs --tail=5
# Keine Fehler nach dem Update

Troubleshooting / Typische Fehler

  1. WebDAV-Container startet nicht / „no such file or directory": Die Datei webdav.yaml fehlt oder liegt nicht im Projektordner. Sicherstellen, dass ./webdav.yaml relativ zur compose.yaml existiert und lesbar ist.
  2. App-Container startet nicht (wartet endlos): Der WebDAV-Healthcheck schlägt fehl. Mit docker compose logs webdav prüfen – häufigste Ursachen sind eine fehlerhafte webdav.yaml-Syntax oder ein belegter Port 2345. ss -tlnp | grep 2345 zur Port-Prüfung.
  3. Port 8080 belegt: Ein anderer Dienst läuft bereits auf Port 8080. In der compose.yaml das Host-Port-Mapping auf einen freien Port ändern, z. B. "9080:80".
  4. WebDAV-Verbindungstest schlägt im Browser fehl: URL oder Zugangsdaten stimmen nicht mit webdav.yaml überein. Passwort in den Sync-Einstellungen neu eingeben. Groß-/Kleinschreibung beachten.
  5. Datenverlust nach Browser-Update oder Profil-Wechsel: Daten lagen noch im LocalStorage ohne aktiven WebDAV-Sync. Sofort nach dem Erststart den Sync einrichten – danach sind Daten im Volume webdav_data gespeichert und bleiben erhalten.
  6. ARM64: Container startet nicht auf Raspberry Pi: Sehr alte Images (vor v8) hatten noch keinen ARM64-Support. Sicherstellen, dass :latest oder eine aktuelle Version verwendet wird. docker inspect johannesjo/super-productivity:latest | grep Architecture zeigt die geladene Architektur.
  7. PostgreSQL und SuperSync werden unnötig gestartet: Das passiert, wenn die compose.yaml direkt unverändert aus dem GitHub-Repo kopiert wurde. Für den produktiven Betrieb nur app und webdav wie in dieser Anleitung verwenden.
  8. Integrations-Issues erscheinen nicht: Bei Jira das API-Token auf Ablauf prüfen; bei GitHub/GitLab die Token-Berechtigungen (read:project bzw. read_api) kontrollieren. Super Productivity zeigt HTTP-Fehlercodes in der Einstellungs-UI.

Häufige Fragen

Brauche ich PostgreSQL für den Betrieb?

Nein. PostgreSQL ist ausschließlich Bestandteil des E2E-Test-Setups im GitHub-Repo und für den normalen produktiven Betrieb nicht erforderlich. Super Productivity speichert alle Daten im Browser-LocalStorage; dauerhafte Persistenz wird über den WebDAV-Sync-Container sichergestellt. Wer das PostgreSQL-Setup aus dem Repo verwendet, startet unnötig einen Datenbankserver und verbraucht mehrere hundert MB RAM zusätzlich.

Funktioniert der Container auf einem Raspberry Pi?

Ja. Das offizielle Image unterstützt seit Ende 2024 (PR #3699) offiziell linux/arm64 und linux/arm/v7. Docker wählt die passende Architektur automatisch anhand des Hosts. Wer explizit eine Architektur erzwingen möchte, kann --platform linux/arm64 in der compose.yaml unter platform: angeben. Immer :latest oder eine aktuelle Version verwenden – ältere Images vor v8 hatten noch keinen ARM64-Support.

Wie sichere ich meine Daten regelmäßig?

Zwei Wege: Entweder manuell über den App-internen JSON/CSV-Export (Einstellungen → Daten → Exportieren) oder automatisiert per Volume-Backup. Das Volume webdav_data enthält alle synchronisierten Daten und lässt sich mit docker compose exec webdav tar czf /tmp/backup.tar.gz /data sichern. Für eine durchdachte Backup-Strategie mit Offsite-Kopie empfiehlt sich die Anleitung 3-2-1-Backup-Strategie umsetzen: Anleitung mit Restic, USB-Disk und S3-Cloud.

Kann ich Super Productivity auf mehreren Geräten nutzen?

Ja, über den WebDAV-Container (oder alternativ Dropbox, Nextcloud oder iCloud Drive). Alle Geräte müssen auf dieselbe WebDAV-URL zeigen und den Sync in den App-Einstellungen aktiviert und mit dem gleichen Passwort konfiguriert haben. Super Productivity ist jedoch eine Single-User-App – mehrere Benutzer benötigen separate Browser-Profile oder separate Container-Instanzen.

Wie aktualisiere ich den Stack?

Mit docker compose pull && docker compose up -d. Da keine Anwendungsdaten im App-Container selbst gespeichert sind, ist kein Migrations-Schritt notwendig. Die WebDAV-Daten im Volume webdav_data bleiben bei jedem Update vollständig erhalten.

Kann ich Jira-Zeit direkt auf Tickets buchen?

Ja. Nach der Verbindung eines Jira-Projekts in den Einstellungen kann die laufende Zeiterfassung direkt einem Jira-Issue zugeordnet werden. Beim Stoppen des Timers bietet Super Productivity an, die Zeit als Jira-Worklog-Eintrag zu übermitteln. Das funktioniert sowohl für Jira Cloud als auch für Jira Server/Data Center.

Fazit

Super Productivity ist eine der ausgereiftesten Open-Source-Produktivitäts-Apps im Self-Hosting-Bereich. Das Docker-Setup ist bewusst schlank gehalten: zwei leichtgewichtige Container, kein Datenbankserver, kein API-Schlüssel als Pflichtangabe. Der WebDAV-Begleit-Container löst das Persistenz-Problem elegant und lässt sich bei Bedarf durch Dropbox oder Nextcloud ersetzen. Für Freelancer und kleine Teams im DACH-Raum, die Todoist Premium und Toggl ablösen möchten, ohne Daten in externe Clouds zu geben, bietet Super Productivity ein überzeugendes Gesamtpaket – MIT-lizenziert, ohne Premium-Stufe, ohne Abo-Kosten.

Weiterführende Anleitungen und Quellen

  1. Docker und Docker Compose auf Linux installieren (Ubuntu/Debian): die Self-Hosting-Grundlage
  2. Docker Compose absichern: Secrets, Healthchecks, Non-Root und Read-Only für den Produktivbetrieb
  3. Traefik als Docker-Reverse-Proxy mit automatischem HTTPS einrichten
  4. 3-2-1-Backup-Strategie umsetzen: Anleitung mit Restic, USB-Disk und S3-Cloud

Offizielle Quellen: Super Productivity auf GitHub · Offizielles Docker-Wiki (2.13) · Docker Hub: johannesjo/super-productivity · super-productivity.com

Passende Anleitungen auf S-EDV

  1. GPT-5.5-Cyber: OpenAI startet Sicherheitsmodell als Konkurrenz zu Anthropic Myth
  2. PostgreSQL schließt elf Sicherheitslücken in den Versionen 14 bis 18
  3. netcup Local Block Storage bestellen, einrichten und unter Linux einbinden