Wer Aufgaben im Team bisher per Mail, Tabelle oder Zuruf verteilt, verliert vor allem eines: den Überblick darüber, wer gerade woran arbeitet. PLANKA ist ein selbst gehostetes Kanban-Werkzeug, das genau diese Lücke schließt, ohne dass Projektdaten bei einem Cloud-Anbieter landen. Diese Anleitung führt Schritt für Schritt durch die Installation von PLANKA 2.2.1 mit Docker Compose, durch die Erstkonfiguration, den sicheren Betrieb hinter einem Reverse Proxy, Backup und Wiederherstellung sowie durch die Fehlerbilder, die in der Praxis am häufigsten auftreten.

Die Installation und die Funktionsprüfung wurden für diesen Artikel in einer isolierten Testumgebung tatsächlich durchgeführt. Jeder Abschnitt kennzeichnet ausdrücklich, was dabei selbst ausgeführt wurde und was ausschließlich aus der offiziellen Projektdokumentation stammt. Reverse Proxy mit TLS, SMTP-Versand und S3-Speicher wurden nicht getestet und sind entsprechend markiert.

Was PLANKA ist und wo seine Grenzen liegen

PLANKA ist eine Webanwendung für Projektorganisation nach dem Kanban-Prinzip: Projekte enthalten Boards, Boards enthalten Listen, Listen enthalten Karten. Eine Karte trägt Beschreibung, Kommentare, Anhänge, Fälligkeitsdatum, Zuständige und eine Stoppuhr für Zeiterfassung. Änderungen erscheinen in Echtzeit bei allen verbundenen Nutzern, weil die Anwendung dafür WebSocket-Verbindungen nutzt. Dieses Detail ist später beim Reverse Proxy entscheidend.

Für kleine und mittlere Unternehmen ist vor allem der Betriebsmodus interessant. PLANKA läuft auf eigener Hardware oder einem eigenen Mietserver, gegen die eigene Datenbank, mit eigenen Backups. Es gibt keine Nutzerlizenz pro Kopf und keinen externen Datenverarbeiter, der in ein Verzeichnis von Verarbeitungstätigkeiten aufgenommen werden müsste. Für Teams, die bislang aus Datenschutzgründen auf ein Kanban-Board verzichtet haben, ist das der praktische Hebel.

Ebenso wichtig sind die Grenzen. Laut der offiziellen Gegenüberstellung von Community- und Pro-Edition enthält die frei selbst hostbare Community-Edition Boards, Listen, Karten mit Echtzeit-Zusammenarbeit, Markdown-Beschreibungen, Anhänge, Kommentare, benutzerdefinierte Felder, Stoppuhr und Fälligkeitsdaten, Benachrichtigungen über mehr als hundert Anbieter, Webhooks, eine dokumentierte REST-Schnittstelle sowie Zwei-Faktor-Authentifizierung. Nicht enthalten sind laut derselben Übersicht unter anderem Kalender-, Zeitstrahl-, Karten- und Medienansichten, wiederkehrende Karten, Board- und Kartenvorlagen, Gastrollen, Single Sign-on über OIDC sowie PDF- und HTML-Export. Eine klassische Gantt-Planung mit Vorgangsabhängigkeiten und kritischem Pfad ist damit nicht Teil der Community-Edition, und PLANKA ersetzt kein Projektcontrolling mit Ressourcen- und Kostenrechnung.

Die Lizenzlage sollte man vor einer Unternehmensentscheidung kennen. Die Datei LICENSE.md im Projektarchiv wurde für diesen Artikel direkt abgerufen. Sie enthält keine Standardlizenz wie MIT oder AGPL, sondern die sogenannte PLANKA Community License in Version 1.1, die auf einer Fair Use License aufsetzt. Erlaubt sind demnach unter anderem persönliche, hobbymäßige und bildungsbezogene Nutzung sowie die interne Nutzung innerhalb der eigenen Organisation. Ausdrücklich untersagt ist der Betrieb von PLANKA als gehosteter Dienst für Dritte zu kommerziellem Nutzen. Der interne Einsatz im eigenen Unternehmen, um den es in dieser Anleitung geht, ist von der Community License gedeckt. Wer PLANKA als Dienstleistung für Kunden betreiben will, braucht eine kommerzielle Lizenz. Die Bezeichnung als quelloffene Software im Sinne der Open Source Definition wäre hier unpräzise, deshalb steht sie hier bewusst nicht.

Voraussetzungen und Ressourcenbedarf

Die Testumgebung für diesen Artikel bestand aus einem Ubuntu-Host mit Docker 29.1.3, Docker Compose 2.40.3, zwei CPU-Kernen, 8 GB RAM und x86_64-Architektur. Das ist deutlich mehr, als der Stack im Leerlauf braucht, spiegelt aber einen realistischen kleinen Server wider.

Docker und Docker Compose: Compose wird als Plugin mit dem Befehl docker compose verwendet, nicht als altes eigenständiges docker-compose. Die offizielle Projektanleitung setzt eine funktionierende Docker- und Compose-Installation voraus.
Architektur: Das Manifest des Images ghcr.io/plankanban/planka:2.2.1 wurde direkt bei der GitHub Container Registry abgefragt. Es ist ein Multi-Plattform-Index und enthält Einträge für linux/amd64 und linux/arm64. Damit läuft der Stack sowohl auf gängigen x86-Servern als auch auf ARM-Systemen wie einem Raspberry Pi 4 oder 5 mit 64-Bit-System. Andere Architekturen sind im Manifest nicht als nutzbare Plattform ausgewiesen.
Speicherplatz: Das PLANKA-Image belegt laut docker image inspect in der Testumgebung 135.870.338 Byte, also rund 136 MB. Dazu kommen das PostgreSQL-Image und der laufende Datenbestand. Der eigentliche Platzbedarf wird später von Anhängen bestimmt, nicht von der Anwendung.
Arbeitsspeicher: Für ein kleines Team ist ein Server mit 2 GB RAM ein realistischer Einstieg, wobei PostgreSQL und die Node.js-Anwendung sich den Speicher teilen. Eine verbindliche Mindestanforderung nennt die Projektdokumentation nicht, deshalb steht hier kein offizieller Wert.
Netzwerk und Namen: Für den Produktivbetrieb wird ein DNS-Name und ein TLS-Zertifikat benötigt, siehe Abschnitt zum Reverse Proxy.
Datenbank: PLANKA benötigt PostgreSQL. Die offizielle Beispieldatei des Projekts verwendet postgres:16-alpine, diese Version wurde auch getestet.

Die vollständige Compose-Datei und jeder Parameter

Die folgende Datei ist die in der Testumgebung tatsächlich verwendete Konfiguration, zurückgestellt auf den Standardport 3000. In der Testumgebung wurde stattdessen Port 33000 verwendet, weil Port 3000 auf dem Testhost bereits belegt war. Wer selbst einen abweichenden Port wählt, muss ihn an zwei Stellen ändern: in der Portzuordnung und in BASE_URL.

Legen Sie ein Verzeichnis an, zum Beispiel /opt/planka, und speichern Sie die Datei dort als docker-compose.yml.

services:
  planka:
    image: ghcr.io/plankanban/planka:2.2.1
    restart: on-failure
    volumes:
      - data:/app/data
    ports:
      - 3000:1337
    environment:
      - BASE_URL=http://localhost:3000
      - DATABASE_URL=postgresql://postgres@postgres/planka
      - SECRET_KEY=BITTE_ERSETZEN_MIT_OPENSSL_RAND_HEX_32
      - DEFAULT_ADMIN_EMAIL=admin@example.com
      - DEFAULT_ADMIN_PASSWORD=BITTE_STARKES_PASSWORT_EINSETZEN
      - DEFAULT_ADMIN_NAME=Test Admin
      - DEFAULT_ADMIN_USERNAME=admin
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    restart: on-failure
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=planka
      - POSTGRES_HOST_AUTH_METHOD=trust
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  data:
  db-data:

Was die einzelnen Parameter bewirken

image: ghcr.io/plankanban/planka:2.2.1 pinnt eine feste Version. Die offizielle Beispieldatei verwendet latest. Für den Produktivbetrieb ist ein fester Tag die bessere Wahl, weil sonst ein beliebiges docker compose pull ungeplant eine neue Hauptversion einspielen kann.
restart: on-failure startet den Container nach einem Absturz neu, aber nicht nach einem bewussten Stopp.
data:/app/data ist das persistente Volume für hochgeladene Dateien, Avatare und Hintergrundbilder. Ohne dieses Volume sind alle Anhänge nach einem Container-Neustart verloren.
3000:1337 bildet den Hostport 3000 auf den Containerport 1337 ab. PLANKA lauscht im Container immer auf 1337, das ändert sich nicht.
BASE_URL ist die Adresse, unter der Nutzer die Instanz erreichen. Sie muss exakt der später tatsächlich verwendeten öffentlichen Adresse entsprechen, inklusive Schema und Port, sonst brechen Links und WebSocket-Verbindungen.
DATABASE_URL verweist auf den Dienstnamen postgres aus derselben Compose-Datei. Compose löst diesen Namen im internen Netz auf, ein Hostname oder eine IP-Adresse ist nicht nötig.
SECRET_KEY signiert jeden ausgestellten Zugriffstoken. Details dazu im nächsten Abschnitt, das ist der sicherheitskritischste Wert der gesamten Datei.
DEFAULT_ADMIN_EMAIL, DEFAULT_ADMIN_PASSWORD, DEFAULT_ADMIN_NAME und DEFAULT_ADMIN_USERNAME legen beim ersten Start automatisch ein Administratorkonto an. Die offizielle Beispieldatei weist darauf hin, dass ein gesetztes DEFAULT_ADMIN_EMAIL verhindert, dass dieser Nutzer später bearbeitet oder gelöscht wird.
depends_on mit condition: service_healthy sorgt dafür, dass PLANKA erst startet, wenn PostgreSQL den Healthcheck bestanden hat. Ohne diese Bedingung startet die Anwendung gegen eine noch nicht bereite Datenbank und stirbt.
POSTGRES_HOST_AUTH_METHOD=trust deaktiviert die Passwortabfrage der Datenbank. Warum das in dieser Konstellation vertretbar ist und wann nicht, steht im Sicherheitsabschnitt.
Der healthcheck ruft alle zehn Sekunden pg_isready auf, wartet maximal fünf Sekunden auf eine Antwort und versucht es bis zu fünf Mal, bevor der Dienst als ungesund gilt.
Der Block volumes: am Dateiende deklariert die beiden benannten Volumes. Docker verwaltet sie, ein Pfad auf dem Host muss nicht angegeben werden.

Variante mit .env-Datei

Wer Geheimnisse nicht in der Compose-Datei stehen haben will, kann sie in eine .env im selben Verzeichnis auslagern. Compose liest diese Datei automatisch ein. Die Datei selbst gehört mit chmod 600 geschützt und niemals in ein Git-Repository.

# Datei: /opt/planka/.env
# Enthaelt nur Platzhalter, echte Werte niemals veroeffentlichen
PLANKA_BASE_URL=https://planka.example.com
PLANKA_SECRET_KEY=HIER_DEN_WERT_AUS_OPENSSL_RAND_HEX_32_EINSETZEN
PLANKA_ADMIN_EMAIL=admin@example.com
PLANKA_ADMIN_PASSWORD=HIER_EIN_STARKES_PASSWORT_EINSETZEN
PLANKA_ADMIN_NAME=Vorname Nachname
PLANKA_ADMIN_USERNAME=admin

In der Compose-Datei werden die Werte dann über die bekannte Variablensyntax referenziert, also zum Beispiel - SECRET_KEY=${PLANKA_SECRET_KEY} statt eines literalen Wertes.

Sicherheitsrelevante Variablen richtig setzen

Drei Punkte der offiziellen Beispielkonfiguration verdienen besondere Aufmerksamkeit, weil sie in der Vorlage bewusst unsicher beziehungsweise nur für den lokalen Test geeignet sind.

SECRET_KEY ist kein optionales Feld

Die offizielle Beispieldatei des Projekts enthält den Wert SECRET_KEY=notsecretkey und warnt im Kommentar direkt darüber ausdrücklich davor, ihn stehen zu lassen. Der Grund steht dort ebenfalls: Jeder Zugriffstoken wird mit diesem Schlüssel signiert. Wer den veröffentlichten Beispielwert unverändert übernimmt, ermöglicht damit jedem, der die Vorlage kennt, das Ausstellen eines gültigen Tokens für jedes beliebige Konto dieser Instanz. Die Beispieldatei weist außerdem darauf hin, dass PLANKA bei jedem Start warnt, solange der Wert nicht geändert wurde.

# Schluessel erzeugen und direkt in die Zwischenablage bzw. Datei uebernehmen
openssl rand -hex 32

Die offizielle Installationsanleitung für die Docker-Produktivversion nennt an dieser Stelle openssl rand -hex 64. Beide Varianten liefern einen zufälligen Hexadezimalwert, die 64er-Variante ist doppelt so lang. Wer sich an die Projektdokumentation halten will, nimmt 64.

POSTGRES_HOST_AUTH_METHOD=trust verstehen, nicht blind kopieren

Dieser Wert bedeutet, dass sich jeder Client ohne Passwort an der Datenbank anmelden darf. Das ist in dieser konkreten Konstellation nur deshalb vertretbar, weil der PostgreSQL-Dienst in der Compose-Datei keinen einzigen Port nach außen veröffentlicht. Er ist ausschließlich im internen Compose-Netz erreichbar, also praktisch nur vom PLANKA-Container.

Daraus folgt eine harte Regel: Fügen Sie dem postgres-Dienst niemals einen ports:-Block hinzu, solange trust gesetzt ist. Ein 5432:5432 in dieser Datei würde eine passwortlose Datenbank mit allen Projektdaten im Netz veröffentlichen. Wer von außen auf die Datenbank zugreifen muss, etwa für ein Auswertungswerkzeug, setzt stattdessen ein echtes Passwort und entfernt trust.

Docker Secrets statt Klartext

PLANKA unterstützt laut offizieller Beispieldatei für mehrere sensible Werte eine Dateivariante, bei der nicht der Wert selbst, sondern der Pfad zu einer Datei mit dem Wert übergeben wird. Dokumentiert sind DATABASE_PASSWORD__FILE, SECRET_KEY__FILE, DEFAULT_ADMIN_PASSWORD__FILE und SMTP_PASSWORD__FILE. Wichtig dabei: Wenn die Dateivariante genutzt wird, darf die gleichnamige normale Variable nicht zusätzlich gesetzt sein. In Produktivumgebungen ist das der sauberere Weg, weil die Geheimnisse dann nicht in der Prozessumgebung und nicht in der Compose-Datei stehen.

Weitere dokumentierte Variablen

TRUST_PROXY=true ist zu setzen, wenn PLANKA hinter einem Reverse Proxy läuft, damit weitergereichte Header korrekt ausgewertet werden.
LOG_LEVEL steuert die Ausführlichkeit der Protokollierung, die Beispieldatei zeigt warn als Beispielwert.
MAX_UPLOAD_FILE_SIZE begrenzt die Größe hochgeladener Dateien.
TOKEN_EXPIRES_IN legt die Gültigkeit von Zugriffstoken fest, die Angabe erfolgt laut Kommentar in Tagen.
STORAGE_LIMIT und ACTIVE_USERS_LIMIT setzen Obergrenzen für Speicherverbrauch und aktive Nutzer.
DEFAULT_LANGUAGE legt die Standardsprache fest, die als Rückfallebene dient, wenn ein Nutzer keine eigene Sprache gesetzt hat, und die auch für Board-Benachrichtigungen verwendet wird.
SHOW_DETAILED_AUTH_ERRORS liefert ausführlichere Anmeldefehler. Die Projektdokumentation weist ausdrücklich darauf hin, dass diese Option ohne einen Rate Limiter aus Sicherheitsgründen nicht aktiviert werden sollte, weil sie das Durchprobieren von Konten erleichtert.
GRAVATAR_BASE_URL aktiviert Profilbilder über Gravatar. Der Kommentar in der offiziellen Beispieldatei warnt, dass die direkte Nutzung von Gravatar die IP-Adressen der Nutzer und gehashte Mailadressen gegenüber einem Dritten offenlegt und damit ein DSGVO-Risiko darstellt. Empfohlen wird ein selbst kontrollierter Proxy oder das Weglassen der Variable.
SWAGGER_EXPOSED stellt die Swagger-Spezifikation unter /swagger.json bereit, ist in der Vorlage aber deaktiviert.

Ausgehender Datenverkehr über den internen Proxy

Ein für KMU besonders nützliches Detail steckt in den Kommentaren der offiziellen Beispieldatei: Alle ausgehenden HTTP-Anfragen von PLANKA, also SMTP, Webhooks, Apprise-Benachrichtigungen und der Abruf von Favicons, laufen über einen Proxy. Ist OUTGOING_PROXY gesetzt, wird dieser verwendet. Ist die Variable nicht gesetzt, startet PLANKA laut Kommentar einen internen Squid-Proxy im Container selbst. Dieser wird über vier weitere Variablen gesteuert:

OUTGOING_BLOCKED_IPS und OUTGOING_BLOCKED_HOSTS sperren Ziele. Diese Sperrliste hat laut Kommentar die höchste Priorität. Der Beispielwert lautet localhost,postgres.
OUTGOING_ALLOWED_IPS und OUTGOING_ALLOWED_HOSTS schränken umgekehrt auf ausschließlich erlaubte Ziele ein.

Praktisch bedeutet das: Selbst wenn ein Nutzer einen Webhook auf eine interne Adresse konfiguriert, lässt sich zentral verhindern, dass die Anwendung damit ins eigene Servernetz hineinfunkt. Die offizielle Installationsanleitung empfiehlt ausdrücklich, interne Dienste in die Sperrliste aufzunehmen, und nennt als Beispiel auch S3-Endpunkte und andere interne Integrationen. Standardmäßig sind laut dieser Anleitung nur die Hostnamen localhost und postgres gesperrt.

Abweichende Benutzerkennung

Die offizielle Beispieldatei enthält auskommentiert die Möglichkeit, den Container unter einer anderen Kennung laufen zu lassen, über user: 1000:1000 in Verbindung mit einem tmpfs-Eintrag für /app/.tmp mit passenden Werten für Modus, Benutzer und Gruppe. Das ist relevant, wenn statt benannter Volumes Verzeichnisse vom Host eingebunden werden.

Warum mindestens Version 2.2.1

Die Versionswahl in dieser Anleitung ist kein Zufall. Version 2.2.1 vom 10.08.2026 ist laut den Angaben des Projekts ein Sicherheitsrelease. Behoben wurde eine Schwachstelle der Klasse Path Traversal, also CWE-22, in den durch JWT geschützten Routen für statische Dateien unter /user-avatars, /background-images und /favicons.

Die praktische Auswirkung: Auf Instanzen mit lokalem Dateispeicher konnte ein bereits angemeldeter Nutzer beliebige Dateien lesen, die für den PLANKA-Prozess lesbar waren. Behoben wurde das, indem erzwungen wird, dass aufgelöste Pfade innerhalb des Upload-Wurzelverzeichnisses bleiben. Instanzen mit S3-basiertem Speicher waren laut Projektangabe nicht betroffen. Die Schwachstelle wurde verantwortungsvoll durch Alpastx gemeldet.

Für Administratoren heißt das konkret: Wer eine ältere 2.x-Version mit lokalem Dateispeicher betreibt, sollte den Versionsstand prüfen und aktualisieren. Für eine Neuinstallation gibt es keinen Grund, unterhalb von 2.2.1 zu bleiben.

Zum Projektzustand: Der Abruf der GitHub-Schnittstelle am 14.09.2026 ergab 12.541 Sterne für das Repository, den letzten Push am 13.09.2026 und keinen Archivierungsstatus. Das Projekt wird also aktiv gepflegt.

Installation und erster Start

Die folgenden Schritte wurden in der isolierten Testumgebung tatsächlich so ausgeführt, lediglich mit Port 33000 statt 3000.

# Verzeichnis fuer den Stack anlegen
mkdir -p /opt/planka
# In das Verzeichnis wechseln
cd /opt/planka
# Sicheren Schluessel erzeugen und notieren
openssl rand -hex 32
# Danach die docker-compose.yml dort ablegen und SECRET_KEY sowie
# DEFAULT_ADMIN_PASSWORD durch echte Werte ersetzen
nano docker-compose.yml
# Stack im Hintergrund starten
docker compose up -d

Alternativ lässt sich die offizielle Vorlage laut Projektdokumentation direkt herunterladen und anschließend anpassen:

# Offizielle Beispieldatei beziehen
curl -L https://raw.githubusercontent.com/plankanban/planka/master/docker-compose.yml -o /opt/planka/docker-compose.yml

Beachten Sie dabei, dass die Vorlage den Tag latest verwendet und den unsicheren Beispielschlüssel enthält. Beides ist vor dem ersten Start zu ändern.

Der Startablauf im Detail

In der Testumgebung waren beide Container nach kurzer Zeit im Status Up (healthy). Das Compose-Protokoll zeigt dabei genau die Reihenfolge, die durch die Healthcheck-Abhängigkeit erzwungen wird: Zuerst wird der PostgreSQL-Container gestartet, dann wartet Compose auf ihn, dann meldet es ihn als gesund, und erst danach wird der PLANKA-Container gestartet.

Das ist die sichtbare Wirkung von depends_on mit condition: service_healthy. Ohne diese Bedingung würde Compose beide Container gleichzeitig starten. PLANKA würde dann versuchen, sich mit einer noch initialisierenden Datenbank zu verbinden, scheitern und wegen restart: on-failure in eine Neustartschleife laufen, bis die Datenbank zufällig rechtzeitig bereit ist.

Im Protokoll erscheinen bei einer frischen Installation zwei Meldungen, die kein Fehler sind. Die erste lautet sinngemäß, dass keine eigenen Nutzungsbedingungen gefunden wurden und auf die mitgelieferte Vorlage zurückgegriffen wird. Die zweite ist ein Hinweis des zugrunde liegenden Sails-Frameworks, dass die Konfiguration sails.config.sockets.onlyAllowOrigins nur localhost enthält. Beides ist bei einer Standardinstallation auf localhost erwartbar und wird im Abschnitt zum Reverse Proxy noch relevant.

Rufen Sie nach dem Start die Adresse auf, die Sie in BASE_URL hinterlegt haben, also bei der Standardkonfiguration http://localhost:3000. Melden Sie sich mit der Mailadresse oder dem Benutzernamen aus DEFAULT_ADMIN_EMAIL beziehungsweise DEFAULT_ADMIN_USERNAME und dem dort gesetzten Passwort an.

Beim ersten Login verlangt PLANKA 2.2.1 die Zustimmung zu den Nutzungsbedingungen. Das ist kein Fehler und kein Konfigurationsproblem, sondern ein bewusster Schritt der Anwendung. Ohne diese Zustimmung wird kein Zugriffstoken ausgestellt, und zwar weder im Browser noch über die Schnittstelle.

Solange keine eigenen Bedingungen hinterlegt sind, verwendet PLANKA eine mitgelieferte Vorlage. Die offizielle Dokumentation formuliert dazu unmissverständlich, dass diese Vorlage nur als Ausgangspunkt gedacht ist und geprüft sowie an die eigenen rechtlichen Anforderungen angepasst werden muss. Für ein Unternehmen, das PLANKA intern einsetzt, ist das ein Punkt für die Rechtsabteilung oder den Datenschutzbeauftragten, nicht für die IT allein.

Eigene Bedingungen werden laut Dokumentation als Markdown-Dateien hinterlegt, benannt nach Sprachcode mit der Endung .md, also zum Beispiel de-DE.md. Die Datei besteht aus dem eigentlichen Text und einem Bestätigungsabschnitt, der durch die Zeile [confirmations]:: gefolgt von --- abgetrennt wird und als Ankreuzfelder dargestellt wird. Die Dateien gehören in das Verzeichnis /app/terms/custom im Container. Bei der Docker-Installation geschieht das laut Dokumentation über ein Verzeichnis terms neben der Compose-Datei, das per Volume eingebunden wird. Die offizielle Beispieldatei enthält dafür bereits eine auskommentierte Zeile im volumes-Block des PLANKA-Dienstes. Nach dem Hinzufügen oder Ändern von Dateien ist ein Neustart nötig.

Nach der Zustimmung landen Sie in der leeren Projektübersicht. Legen Sie ein erstes Projekt an, darin ein Board, darin Listen wie Offen, In Arbeit und Erledigt. Danach sollten weitere Nutzer angelegt und der Administratorzugang nicht für die tägliche Arbeit verwendet werden.

Funktions- und Healthcheck

Die folgenden Prüfungen wurden in der Testumgebung tatsächlich ausgeführt. Die Ausgaben stammen aus dem echten Lauf.

# Status beider Container anzeigen
docker compose ps
# Erwartet: beide Dienste im Status Up (healthy)

# HTTP-Statuscode der Oberflaeche pruefen, ohne den Seiteninhalt auszugeben
curl -s -o /dev/null -w "%{http_code}
" http://localhost:3000/
# Erwartet: 200

# Protokoll der Anwendung ansehen
docker compose logs planka --tail 50

# Unter welcher Kennung laeuft der Prozess im Container
docker compose exec planka id
# Erwartet: uid=1000(node) gid=1000(node)

In der Testumgebung lieferte der Aufruf der Oberfläche HTTP 200, beide Container standen auf Up (healthy), und der Prozess läuft als Benutzer node mit Kennung 1000 und Gruppe 1000. Der Aufruf von /api/config ohne gültiges Token beantwortete der Server mit HTTP 401, was das erwartete Verhalten für einen geschützten Endpunkt ist.

Selbst getestet: der Weg über die Schnittstelle und die Terms-Hürde

Dieser Abschnitt beschreibt einen in der isolierten Testumgebung vollständig durchgeführten Ablauf. Er ist deshalb interessant, weil er ein Verhalten zeigt, über das jeder stolpert, der PLANKA automatisiert ansprechen will, etwa für eine Überwachung oder ein Skript.

Ein Anmeldeversuch per POST /api/access-tokens mit korrektem Benutzernamen und korrektem Passwort liefert bei einem Konto, das den Nutzungsbedingungen noch nicht zugestimmt hat, kein Token, sondern HTTP 403 mit einer Antwort der Form {"code":"E_FORBIDDEN","pendingToken":"...","message":"Terms acceptance required","step":"accept-terms"}. Wer an dieser Stelle das Passwort für falsch hält, sucht an der falschen Stelle.

Der korrekte Ablauf besteht aus drei Schritten: Anmeldung, die den pendingToken liefert. Abruf der Bedingungen über GET /api/terms. Bildung des SHA256-Hashes über den gelieferten Text und Senden dieses Hashes als signature zusammen mit dem pendingToken an POST /api/access-tokens/accept-terms. Erst diese Antwort enthält bei HTTP 200 das eigentliche Zugriffstoken.

Ein zu kurzer Wert im Feld signature wird abgewiesen. In der Testumgebung wurde das mit dem Wert kurz ausprobiert und ergab HTTP 400 mit der Meldung, dass der Wert kürzer als die konfigurierte Mindestlänge von 64 Zeichen ist. Ein SHA256-Hash in Hexadezimaldarstellung ist genau 64 Zeichen lang und passt damit exakt.

Das folgende Skript bildet den gesamten Ablauf ab. Es verwendet ausschließlich die Standardbibliothek von Python 3 und wurde in dieser Form in der Testumgebung ausgeführt.

# Skript ausfuehren, Adresse und Zugangsdaten vorher anpassen
python3 planka_check.py

import hashlib
import json
import urllib.error
import urllib.request

BASE = "http://localhost:3000"
USER = "admin"
PASSWORD = "HIER_DAS_ECHTE_PASSWORT"


def call(path, payload=None, token=None):
    headers = {"Content-Type": "application/json"}
    if token:
        headers["Authorization"] = "Bearer " + token
    body = json.dumps(payload).encode("utf-8") if payload else None
    request = urllib.request.Request(BASE + path, data=body, headers=headers)
    try:
        with urllib.request.urlopen(request) as response:
            return response.status, json.loads(response.read())
    except urllib.error.HTTPError as error:
        return error.code, json.loads(error.read())


# Schritt 1: Anmeldung
status, data = call("/api/access-tokens", {"emailOrUsername": USER, "password": PASSWORD})

if status == 403 and data.get("step") == "accept-terms":
    # Schritt 2: Nutzungsbedingungen abrufen
    _, terms = call("/api/terms")
    content = terms["item"]
    if not isinstance(content, str):
        content = content.get("content", "")
    # Schritt 3: SHA256-Hash als Signatur senden
    signature = hashlib.sha256(content.encode("utf-8")).hexdigest()
    status, data = call(
        "/api/access-tokens/accept-terms",
        {"pendingToken": data["pendingToken"], "signature": signature},
    )

token = data["item"]

# Funktionspruefung 1: eigenes Konto abfragen
status, me = call("/api/users/me", token=token)
print("users/me:", status, me["item"]["role"])

# Funktionspruefung 2: Projekt anlegen
status, project = call("/api/projects", {"type": "private", "name": "S-EDV Testprojekt"}, token=token)
print("projekt angelegt:", status, project["item"]["name"])

# Funktionspruefung 3: Projekte auflisten
status, projects = call("/api/projects", token=token)
print("projekte:", status, [p["name"] for p in projects["items"]])

In der Testumgebung lieferte GET /api/users/me HTTP 200 mit der Rolle admin. Der Aufruf POST /api/projects mit dem Rumpf {"type":"private","name":"S-EDV Testprojekt"} lieferte HTTP 200 und legte das Projekt tatsächlich an, und der anschließende GET /api/projects listete es auf. Nach einmaliger Zustimmung liefert die Anmeldung für dieses Konto direkt HTTP 200 mit Token, der Umweg über accept-terms entfällt dann.

Persistente Daten und Rechte

Der Stack legt zwei benannte Volumes an. Das Volume data hält die Nutzdaten der Anwendung, also hochgeladene Anhänge, Avatare und Hintergrundbilder. Das Volume db-data hält das PostgreSQL-Datenverzeichnis mit allen Projekten, Boards, Listen, Karten, Kommentaren und Nutzerkonten.

In der Testumgebung wurde das geprüft. Das Verzeichnis /app/data im Container gehört Benutzer und Gruppe node und ist bei einer frischen Installation leer, weil noch keine Dateien hochgeladen wurden. Der Prozess selbst läuft ebenfalls als node mit Kennung 1000 und Gruppe 1000.

# Volumes des Stacks auflisten
docker volume ls | grep planka

# Host-Pfad eines Volumes ermitteln
docker volume inspect planka_data --format '{{.Mountpoint}}'

# Inhalt und Rechte im Container pruefen
docker compose exec planka ls -la /app/data

Der Mountpoint auf dem Host lag in der Testumgebung unter /var/lib/docker/volumes/test_planka_data/_data. Der Präfix vor _data ergibt sich aus dem Projektnamen, den Compose vom Verzeichnisnamen ableitet. Bei einem Verzeichnis /opt/planka heißen die Volumes entsprechend planka_data und planka_db-data.

Wer statt benannter Volumes lieber Verzeichnisse vom Host einbindet, muss die Rechte selbst setzen. Die offizielle Dokumentation nennt dafür ausdrücklich den Befehl chown -R 1000:1000 auf das jeweilige Verzeichnis, damit der Benutzer node im Container schreiben kann.

Reverse Proxy und TLS

Wichtiger Hinweis vorab: Der Reverse-Proxy-Betrieb mit TLS wurde für diesen Artikel nicht selbst getestet. Die folgende Konfiguration und die Erläuterungen stammen aus der offiziellen Projektdokumentation und aus den Kommentaren der offiziellen Beispieldatei.

Für den Produktivbetrieb sollte PLANKA nicht direkt auf einem offenen Port hängen. Der übliche Aufbau ist ein Reverse Proxy, der TLS terminiert und die Anfragen intern weiterreicht. Zwei Punkte sind dabei entscheidend.

Erstens die WebSocket-Weiterleitung. PLANKA überträgt Änderungen an Karten und Boards in Echtzeit über Socket-Verbindungen. Ein Proxy, der nur gewöhnliche HTTP-Anfragen weiterreicht, liefert eine Oberfläche, die auf den ersten Blick funktioniert, bei der aber Änderungen anderer Nutzer nicht ankommen und bei der die Verbindung ständig neu aufgebaut wird. Die offizielle Nginx-Beispielkonfiguration löst das mit einem eigenen Location-Block für Pfade, die auf .io enden, in dem die Header Upgrade und Connection gesetzt werden.

Zweitens das Zusammenspiel von BASE_URL und TRUST_PROXY. In BASE_URL gehört die öffentliche Adresse, unter der Nutzer die Instanz aufrufen, also zum Beispiel https://planka.example.com, nicht die interne Adresse mit Port. Gleichzeitig ist TRUST_PROXY=true zu setzen, damit die vom Proxy weitergereichten Header ausgewertet werden. Sonst hält die Anwendung jede Anfrage für eine unverschlüsselte lokale Verbindung, und Weiterleitungen zeigen auf die falsche Adresse.

Hier schließt sich der Kreis zur Protokollmeldung aus dem Startabschnitt. Der Hinweis, dass sails.config.sockets.onlyAllowOrigins nur localhost enthält, ist bei einer lokalen Standardinstallation korrekt und harmlos. Sobald die Instanz unter einem eigenen Namen erreichbar sein soll, muss BASE_URL diesen Namen enthalten, damit Socket-Verbindungen von der richtigen Herkunft akzeptiert werden.

Die folgende Konfiguration orientiert sich an dem in der offiziellen Dokumentation veröffentlichten Nginx-Beispiel. Ersetzen Sie planka.example.com durch Ihren Namen. Die TLS-Einrichtung selbst erfolgt separat, zum Beispiel über Let's Encrypt.

upstream planka {
    server 127.0.0.1:3000;
    keepalive 32;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name planka.example.com;

    access_log /var/log/nginx/planka-access.log;
    error_log  /var/log/nginx/planka-error.log error;

    # TLS-Zertifikate separat einrichten, zum Beispiel per Certbot
    ssl_certificate     /etc/letsencrypt/live/planka.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/planka.example.com/privkey.pem;

    # Socket-Verbindungen fuer die Echtzeit-Aktualisierung
    location ~* \.io {
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        client_max_body_size 50M;
        proxy_set_header Host $http_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;
        proxy_set_header X-Frame-Options SAMEORIGIN;
        proxy_buffers 256 16k;
        proxy_buffer_size 16k;
        client_body_timeout 60;
        send_timeout 300;
        lingering_timeout 5;
        proxy_connect_timeout 1d;
        proxy_send_timeout 1d;
        proxy_read_timeout 1d;
        proxy_pass http://planka;
    }

    location / {
        client_max_body_size 50M;
        proxy_set_header Connection "";
        proxy_set_header Host $http_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;
        proxy_set_header X-Frame-Options SAMEORIGIN;
        proxy_buffers 256 16k;
        proxy_buffer_size 16k;
        proxy_read_timeout 600s;
        proxy_pass http://planka;
    }
}

Passend dazu ändern sich zwei Werte im Umgebungsblock der Compose-Datei. Außerdem sollte die Portfreigabe dann nur noch auf die lokale Schnittstelle binden, damit der Dienst nicht am Proxy vorbei erreichbar ist.

services:
  planka:
    ports:
      - 127.0.0.1:3000:1337
    environment:
      - BASE_URL=https://planka.example.com
      - TRUST_PROXY=true

Die offizielle Dokumentation enthält neben Nginx auch Beispielkonfigurationen für Apache2, Traefik und Caddy. Wer bereits einen dieser Proxys betreibt, sollte die dortige Vorlage nehmen statt die Nginx-Variante zu übersetzen.

Backup und Wiederherstellung

Der häufigste und teuerste Fehler in diesem Bereich ist, nur die Datenbank zu sichern. In der Datenbank stehen Projekte, Boards, Listen, Karten, Kommentare und Nutzer. Die hochgeladenen Anhänge stehen dort nicht, sie liegen im Volume data. Eine Wiederherstellung aus einem reinen Datenbank-Dump ergibt eine Instanz, in der jede Karte auf Anhänge verweist, die nicht mehr existieren. Beides gehört zusammen gesichert.

Selbst getestet: Datenbank sichern

Der folgende Befehl wurde in der Testumgebung tatsächlich ausgeführt. Er erzeugte eine SQL-Datei von rund 51 KB, in der das zuvor über die Schnittstelle angelegte Testprojekt nachweisbar enthalten war.

# In das Stack-Verzeichnis wechseln
cd /opt/planka
# Datenbank als SQL-Datei sichern
docker compose exec -T postgres pg_dump -U postgres planka > backup.sql
# Groesse der Sicherung pruefen
ls -lh backup.sql
# Stichprobe: taucht ein bekannter Projektname in der Sicherung auf
grep -c "Mein Projektname" backup.sql

Die Option -T ist wichtig. Ohne sie versucht Compose, ein Pseudo-Terminal zuzuweisen, und die Ausgabe in die Datei wird unbrauchbar.

Anhänge sichern

Für das Datenvolume bietet sich ein Tar-Archiv über einen kurzlebigen Hilfscontainer an. Der folgende Befehl bindet das Volume schreibgeschützt ein und schreibt das Archiv in das aktuelle Verzeichnis des Hosts.

# Datenvolume als Tar-Archiv sichern
docker run --rm -v planka_data:/data:ro -v "$PWD":/backup alpine tar czf /backup/planka-data.tgz -C /data .
# Inhalt des Archivs stichprobenartig ansehen
tar tzf planka-data.tgz | head

Der Volume-Name richtet sich nach dem Compose-Projektnamen, siehe Abschnitt zu den persistenten Daten. Prüfen Sie ihn vorher mit docker volume ls.

Die mitgelieferten Skripte des Projekts

Laut offizieller Dokumentation liefert das Projekt zwei Skripte mit, die beides in einem Schritt erledigen: docker-backup.sh exportiert Datenbank, Avatare, Hintergrundbilder und Anhänge in eine einzelne .tgz-Datei, docker-restore.sh spielt eine solche Datei wieder ein. Diese Skripte wurden für diesen Artikel nicht selbst getestet, sie sind aber der vom Projekt vorgesehene Weg.

# Ablageverzeichnis fuer Sicherungen anlegen
mkdir -p /opt/planka/backup
# Skripte aus dem Projektarchiv beziehen
curl -L https://raw.githubusercontent.com/plankanban/planka/master/docker-backup.sh -o /opt/planka/backup/backup.sh
curl -L https://raw.githubusercontent.com/plankanban/planka/master/docker-restore.sh -o /opt/planka/backup/restore.sh

Für die Automatisierung nennt die Dokumentation einen nächtlichen Cron-Eintrag um zwei Uhr sowie zwei weitere Einträge, die Sicherungen und Protokolldateien löschen, die älter als 14 Tage sind. Prüfen Sie, ob 14 Tage zu Ihrer Aufbewahrungsvorgabe passen.

Wiederherstellung

Der folgende Ablauf beschreibt die Wiederherstellung aus den beiden oben erzeugten Einzelsicherungen. Er wurde in dieser Form nicht selbst getestet und sollte vor dem Ernstfall einmal auf einem Testsystem durchgespielt werden. Eine Sicherung, deren Wiederherstellung nie geprüft wurde, ist keine Sicherung.

# Anwendung stoppen, Datenbank weiterlaufen lassen
cd /opt/planka
docker compose stop planka

# Bestehende Datenbank leeren und neu anlegen
docker compose exec -T postgres dropdb -U postgres planka
docker compose exec -T postgres createdb -U postgres planka

# Sicherung einspielen
docker compose exec -T postgres psql -U postgres planka < backup.sql

# Anhaenge zurueckspielen
docker run --rm -v planka_data:/data -v "$PWD":/backup alpine sh -c "rm -rf /data/* && tar xzf /backup/planka-data.tgz -C /data"

# Rechte im Datenvolume wiederherstellen
docker run --rm -v planka_data:/data alpine chown -R 1000:1000 /data

# Anwendung wieder starten
docker compose start planka

# Funktion pruefen
curl -s -o /dev/null -w "%{http_code}
" http://localhost:3000/

Der Schritt mit chown ist leicht zu übersehen. Wird er vergessen, gehören die zurückgespielten Dateien dem Benutzer root, und der als node laufende Prozess kann keine neuen Anhänge in denselben Verzeichnissen ablegen.

Updates und Grenzen des Rollbacks

Die offizielle Dokumentation beschreibt den Update-Ablauf in drei Schritten und stellt ihm einen ausdrücklichen Hinweis voran, vorher eine Sicherung anzulegen. Der dort beschriebene Ablauf lautet: PLANKA stoppen, die neue Version herunterladen, PLANKA wieder starten.

# Vor jedem Update: Datenbank sichern
cd /opt/planka
docker compose exec -T postgres pg_dump -U postgres planka > backup-vor-update.sql

# Danach das Datenvolume sichern
docker run --rm -v planka_data:/data:ro -v "$PWD":/backup alpine tar czf /backup/planka-data-vor-update.tgz -C /data .

# Erst jetzt die Versionsnummer in der docker-compose.yml erhoehen
nano docker-compose.yml

# Stack stoppen
docker compose down

# Neues Image beziehen
docker compose pull

# Stack wieder starten
docker compose up -d

# Status und Protokoll pruefen
docker compose ps
docker compose logs planka --tail 50

Beachten Sie den Unterschied zur Vorlage: Weil in dieser Anleitung ein fester Versions-Tag verwendet wird, holt docker compose pull allein noch keine neue Version. Die Versionsnummer in der Datei muss zuerst geändert werden. Genau das ist der Sinn des Pinnens. Ein Stack mit latest kann bei jedem beliebigen pull unbeabsichtigt eine neue Hauptversion einspielen, inklusive Datenbankmigration, ohne dass jemand das entschieden hätte.

Zum Rollback ist eine ehrliche Einordnung nötig. Ein neues Release führt in der Regel Migrationen am Datenbankschema aus. Sind diese einmal gelaufen, passt der Datenbestand nicht mehr zum Programmcode der alten Version. Ein bloßes Zurücksetzen des Image-Tags auf die Vorgängerversion ist dann kein sauberer Rückweg und kann die Instanz in einen inkonsistenten Zustand bringen. Der einzige verlässliche Rückweg ist, die vor dem Update erzeugte Sicherung zusammen mit dem alten Image-Tag wiederherzustellen. Deshalb ist der pg_dump vor dem Update keine Empfehlung, sondern Pflicht.

Typische Fehler mit Diagnose und Lösung

Port bereits belegt. Der Start scheitert mit einer Meldung über eine bereits verwendete Adresse. Prüfen Sie mit ss -tlnp | grep 3000, welcher Prozess den Port hält. Entweder beenden Sie diesen Dienst oder Sie wählen einen anderen Hostport. Genau dieser Fall trat in der Testumgebung auf, dort wurde auf Port 33000 ausgewichen. Wichtig dabei: Beim Wechsel des Ports muss auch BASE_URL angepasst werden, sonst zeigen Links im Frontend auf den alten Port.
Container startet nicht, Warnung zum SECRET_KEY. PLANKA warnt laut offizieller Beispieldatei bei jedem Start, solange der Beispielwert nicht ersetzt wurde. Setzen Sie einen mit openssl rand -hex 32 oder openssl rand -hex 64 erzeugten Wert ein und starten Sie den Stack neu. Wenn der Wert per SECRET_KEY__FILE aus einer Datei kommt, darf die normale Variable nicht zusätzlich gesetzt sein.
Anmeldung über die Schnittstelle scheitert mit E_FORBIDDEN. Die Zugangsdaten sind korrekt, aber das Konto hat den Nutzungsbedingungen noch nicht zugestimmt. Antwort und Lösungsweg stehen oben im Abschnitt zur Schnittstelle. Keine Passwortzurücksetzung nötig, sondern der Zwischenschritt über /api/terms und /api/access-tokens/accept-terms.
Signatur wird mit HTTP 400 abgelehnt. Die Meldung nennt eine Mindestlänge von 64 Zeichen. Ein SHA256-Hash in Hexadezimalform hat genau diese Länge. Wenn Ihr Wert kürzer ist, wurde vermutlich der Hash in Binärform, ein gekürzter Wert oder ein Platzhalter gesendet.
Oberfläche lädt, aber Änderungen erscheinen nicht bei anderen Nutzern. Klassisches Symptom eines Reverse Proxy ohne WebSocket-Weiterleitung. Prüfen Sie, ob der Location-Block mit den Headern Upgrade und Connection vorhanden ist und ob der Browser in den Entwicklerwerkzeugen abgebrochene Socket-Verbindungen meldet.
Falsche BASE_URL. Symptome sind Weiterleitungen auf localhost statt auf den eigenen Namen, fehlschlagende Socket-Verbindungen und Warnungen im Protokoll zu erlaubten Herkünften. Tragen Sie in BASE_URL exakt die öffentliche Adresse ein, unter der Nutzer die Instanz aufrufen, und setzen Sie beim Proxy-Betrieb zusätzlich TRUST_PROXY=true.
Datenbank wird nicht gesund. Der PLANKA-Container startet dann gar nicht, weil er auf den Healthcheck wartet. Prüfen Sie mit docker compose logs postgres, ob PostgreSQL überhaupt hochkommt. Häufige Ursachen sind ein voller Datenträger oder ein Datenverzeichnis aus einer anderen PostgreSQL-Hauptversion, das nach einem Versionswechsel nicht mehr gelesen werden kann.
Anhänge lassen sich nicht hochladen. Bei eingebundenen Host-Verzeichnissen fehlen meist die Rechte. Setzen Sie sie gemäß Dokumentation mit chown -R 1000:1000 auf das betroffene Verzeichnis. Bei großen Dateien kann zusätzlich MAX_UPLOAD_FILE_SIZE oder beim Proxy client_max_body_size im Weg stehen.

Saubere Deinstallation

Zum Abschalten des Stacks ohne Datenverlust reicht ein einfaches Herunterfahren. Die Volumes bleiben dabei erhalten, ein späteres docker compose up -d bringt die Instanz mit allen Daten zurück.

# Container stoppen und entfernen, Volumes bleiben erhalten
cd /opt/planka
docker compose down

Warnung: Der folgende Befehl löscht zusätzlich die benannten Volumes. Damit sind die Datenbank und das Datenvolume unwiederbringlich weg, also alle Projekte, Boards, Karten, Kommentare, Nutzerkonten und sämtliche hochgeladenen Anhänge. Es gibt keinen Papierkorb und keine Rückfrage. Führen Sie diesen Befehl nur aus, wenn Sie eine geprüfte Sicherung haben oder die Daten sicher nicht mehr benötigen.

# ACHTUNG: loescht Container UND Volumes samt aller Daten
cd /opt/planka
docker compose down -v

Anschließend können die Images und das Verzeichnis entfernt werden.

# Images entfernen
docker image rm ghcr.io/plankanban/planka:2.2.1
docker image rm postgres:16-alpine
# Verbliebene Reste pruefen
docker volume ls | grep planka

Einordnung für kleine Unternehmen

Der Aufwand für diese Installation ist überschaubar: eine Compose-Datei, zwei geänderte Werte, ein Startbefehl. Der eigentliche Aufwand entsteht danach, und zwar bei genau drei Dingen. Erstens einer funktionierenden und einmal getesteten Sicherung, die Datenbank und Anhänge umfasst. Zweitens einem Reverse Proxy mit TLS, wenn die Instanz über das lokale Netz hinaus erreichbar sein soll. Drittens einem festen Platz im Patch-Prozess, damit Sicherheitsreleases wie 2.2.1 nicht monatelang liegen bleiben.

Für Teams, die heute mit Mail und Tabellen arbeiten, ist PLANKA in der Community-Edition ein realistischer Einstieg in geordnete Aufgabenverteilung, ohne Nutzerlizenzen und ohne externen Datenverarbeiter. Wer Kalender- und Zeitstrahlansichten, Single Sign-on oder Gastrollen braucht, sollte vor der Einführung prüfen, ob die Pro-Edition oder ein anderes Werkzeug besser passt, statt das später nachrüsten zu wollen. Und wer PLANKA für Kunden betreiben möchte, muss die Lizenzfrage vorab klären.

Passende Anleitungen auf S-EDV

Docker Compose Grundlagen und Stacks erklärt die Bausteine der hier verwendeten Compose-Datei von Grund auf.
Docker Compose absichern mit Secrets, Healthchecks und Non-Root vertieft genau die Punkte, die bei PLANKA sicherheitsrelevant sind.
Plane mit Docker als Projektmanagement betreiben stellt eine Alternative vor, wenn PLANKA für Ihren Anwendungsfall zu knapp ausfällt.

Quellen

PLANKA Projektarchiv auf GitHub, abgerufen am 14.09.2026, inklusive Angaben zu Sternen, letztem Push und Release 2.2.1.
Offizielle docker-compose.yml des Projekts mit allen dokumentierten Umgebungsvariablen und Sicherheitshinweisen.
PLANKA Community License, Version 1.1, Lizenzdatei des Projektarchivs.
Offizielle Installationsanleitung für die Docker-Produktivversion.
Offizielle Dokumentation zu Backup und Wiederherstellung.
Offizielle Dokumentation zum Update-Ablauf.
Offizielle Nginx-Beispielkonfiguration inklusive Socket-Weiterleitung.
Offizielle Dokumentation zum Anpassen der Nutzungsbedingungen.
Offizielle Gegenüberstellung von Community- und Pro-Edition.