Planka selbst hosten mit Docker Compose und Traefik

Was Sie durch das Self-Hosting von Planka erhalten

Mit dem Self-Hosting von Planka erhält Ihr Team ein Kanban-Board mit dem Karten-, Listen- und Label-Modell, das viele bereits aus Trello kennen. Die Anwendung läuft auf einem von Ihnen kontrollierten VPS. Es gibt keine Begrenzung der Benutzeranzahl und keine Abrechnung pro Benutzer, weil nur die Kosten für den Server anfallen. In dieser Anleitung wird Planka mit Docker Compose hinter Traefik eingerichtet. Postgres speichert die Daten. Für jede hochgeladene Datei wird ein benanntes Volume verwendet.

Die Anleitung richtet sich an ein Team mit zwei bis fünf Personen, das den kostenlosen Trello-Tarif verlässt. Wenn Sie noch entscheiden, welches Board Sie betreiben möchten, lesen Sie zuerst den Vergleich selbst gehosteter Trello-Alternativen. Diese Anleitung setzt voraus, dass die Entscheidung bereits gefallen ist, und behandelt nur die Bereitstellung.

Sie benötigen einen VPS mit Docker Engine und dem Compose-Plugin sowie einen DNS-A-Record, der auf diesen VPS zeigt. Außerdem muss auf diesem Server bereits eine Traefik-Instanz TLS (Transport Layer Security) terminieren. Wenn Traefik noch nicht eingerichtet ist, konfigurieren Sie zuerst einen Traefik-Reverse-Proxy vor mehreren Compose-Anwendungen. Wenn Ihnen die folgende Datei nicht vertraut ist, lesen Sie außerdem die Grundlagen von Docker Compose für einen VPS.

Wie viel VPS benötigt Planka?

Das Projekt veröffentlicht keine Mindestanforderungen an die Hardware. Betrachten Sie daher jede genannte Zahl als Ausgangspunkt und nicht als Messwert. Die Angaben von 2 vCPU und 4 GB, die auf Hosting-Seiten wiederholt werden, sind ein komfortabler Standardwert des Anbieters und keine vom Projekt gemessene Anforderung. Für ein Board, das fünf Personen verwenden, ist das großzügig bemessen.

Tatsächlich laufen nur wenige Komponenten: ein Node.js-Prozess stellt die API und das kompilierte Frontend bereit, und ein Postgres-Prozess speichert die Daten. Im Planka-Container läuft außerdem ein kleiner Proxy-Prozess, der die ausgehenden Anfragen filtert. Ein Tarif mit 1 vCPU und 2 GB reicht für ein Board mit zwei bis fünf Personen aus. Der größte Teil des freien Arbeitsspeichers wird von Postgres als Cache verwendet. Ein Board belastet den Server nur gering. Wenn derselbe VPS auch die Dokumente Ihres Teams speichern soll, dimensionieren Sie ihn zuerst für diese Anwendung: AFFiNE als Notion-ähnlichen Arbeitsbereich betreiben benötigt bereits für sich einige Gigabyte, bevor Planka zusätzlichen Speicher anfordert.

Dimensionieren Sie den Speicherplatz, bevor Sie den Arbeitsspeicher dimensionieren, da Anhänge am stärksten wachsen. Messen Sie Ihre eigene Instanz, statt sich auf diesen Abschnitt zu verlassen:

docker stats --no-stream
docker system df -v

Der erste Befehl zeigt den aktuellen Arbeitsspeicher- und CPU-Verbrauch pro Container. Der zweite zeigt, wie viel Speicherplatz jedes Volume belegt. Führen Sie beide Messungen nach einer normalen Arbeitswoche durch und nicht am Installationstag. Ein ungenutztes Board sagt nichts über die Nutzung durch Ihr Team aus.

Compose-Datei schreiben

Erstellen Sie das Verzeichnis und übertragen Sie den Besitz darauf, damit Sie diese Dateien nie über sudo bearbeiten müssen.

sudo mkdir -p /opt/planka
sudo chown "$USER":"$USER" /opt/planka
cd /opt/planka

Generieren Sie die Secrets in eine Datei .env neben der Compose-Datei. Compose liest diese Datei automatisch und ersetzt die Werte.

umask 077
{
  printf 'SECRET_KEY=%s\n' "$(openssl rand -hex 64)"
  printf 'POSTGRES_PASSWORD=%s\n' "$(openssl rand -hex 24)"
  printf 'ADMIN_PASSWORD=%s\n' "$(openssl rand -hex 12)"
} > .env
chmod 600 .env

openssl rand -hex ist beabsichtigt. Eine Hex-Zeichenfolge enthält nur Ziffern und die Buchstaben a bis f. Daher kann sie die DATABASE_URL-Verbindungszeichenfolge, in die sie eingefügt wird, nicht beschädigen. Ein Base64-Passwort mit einem Schrägstrich oder einem At-Zeichen verursacht einen Verbindungsfehler, der wie ein falscher Hostname aussieht. Das kann Sie eine Stunde kosten. Das übergeordnete Muster wird unter Secrets aus der Compose-Datei heraushalten behandelt.

Erstellen Sie nun docker-compose.yml. Ersetzen Sie kanban.example.com an beiden Stellen durch Ihren eigenen Hostnamen.

services:
  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    restart: unless-stopped
    volumes:
      - planka-data:/app/data
    environment:
      - BASE_URL=https://kanban.example.com
      - DATABASE_URL=postgresql://planka:${POSTGRES_PASSWORD}@postgres/planka
      - SECRET_KEY=${SECRET_KEY}
      - TRUST_PROXY=true
      - DEFAULT_ADMIN_EMAIL=you@example.com
      - DEFAULT_ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - DEFAULT_ADMIN_NAME=Your Name
      - DEFAULT_ADMIN_USERNAME=admin
    networks:
      - proxy
      - internal
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=proxy"
      - "traefik.http.routers.planka.rule=Host(`kanban.example.com`)"
      - "traefik.http.routers.planka.entrypoints=websecure"
      - "traefik.http.routers.planka.tls.certresolver=default"
      - "traefik.http.services.planka.loadbalancer.server.port=1337"
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=planka
      - POSTGRES_USER=planka
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    networks:
      - internal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U planka -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  planka-data:
  db-data:

networks:
  proxy:
    external: true
  internal:

Vier Entscheidungen in dieser Datei sollten erklärt werden. Es sind die Einstellungen, die häufig geändert werden und später Probleme verursachen.

• Beim Planka-Dienst gibt es keinen ports:-Block. Traefik erreicht den Container über das proxy-Netzwerk. Daher wird Port 1337 nie auf dem Host veröffentlicht. Eine Veröffentlichung würde jedem ermöglichen, Ihren Proxy und Ihr Zertifikat zu umgehen.
• loadbalancer.server.port=1337 bezeichnet den Port innerhalb des Containers. Planka lauscht auf 1337. Das Upstream-Beispiel erreicht den Dienst nur über Port 3000, weil es den Port auf den Host abbildet. Hier gibt es keine Host-Abbildung. Daher muss Traefik der Container-Port mitgeteilt werden.
• condition: service_healthy wird mit dem Postgres-Healthcheck verwendet. Ohne diese Einstellung startet Planka, bevor die Datenbank Verbindungen akzeptiert. Die erste Abfrage schlägt fehl und der Prozess beendet sich. Das sieht wie eine Neustartschleife aus. Die Details finden Sie unter Compose-Healthchecks und Startreihenfolge.
• Der Datenbankdienst heißt absichtlich postgres. Planka 2 leitet eigene ausgehende Anfragen über einen internen Filter. Dessen standardmäßige Sperrliste ist localhost,postgres. Wenn Sie den Dienst umbenennen, entfernen Sie die Datenbank unbemerkt aus dieser Liste.

Prüfen Sie, ob Compose Ihre Secrets sehen kann, bevor Sie etwas starten:

docker compose config | grep -E 'image:|BASE_URL|POSTGRES_USER'

Dieser Befehl gibt die Datei aus. Die .env-Werte sind bereits eingesetzt. Ein leerer Wert bedeutet, dass Compose die Datei .env nicht liest. Meistens führen Sie den Befehl aus einem anderen Verzeichnis aus.

Was die Bootstrap-Variablen für den Administrator tatsächlich bewirken

Seit Planka 1.13 wird kein Administrator mehr automatisch für Sie angelegt. Eine neue Datenbank hat daher zunächst niemanden, der sich anmelden kann. Die Gruppe DEFAULT_ADMIN_* ist eine von zwei Möglichkeiten, das zu beheben.

Beim Start sucht Planka nach einem Benutzer, der DEFAULT_ADMIN_EMAIL entspricht. Gibt es keinen solchen Benutzer, wird anhand der daneben gesetzten Variablen ein Benutzer mit dem angegebenen Passwort, Anzeigenamen und Benutzernamen angelegt. Das geschieht beim ersten Start mit einer leeren Datenbank. Diese Variablen richten also ein Konto ein, verwalten es aber nicht dauerhaft.

DEFAULT_ADMIN_EMAIL erfüllt eine zweite Funktion, die häufig übersehen wird. Solange die Variable gesetzt ist, kann das damit bezeichnete Konto von niemandem über die Oberfläche bearbeitet oder gelöscht werden. Das ist eine Sperre gegen versehentliche Änderungen. Deshalb können Sie den Namen dieses Kontos in der Oberfläche weder ändern noch seine E-Mail-Adresse anpassen. Entfernen Sie die Variable und starten Sie Planka neu. Danach ist das Konto wieder ein gewöhnlicher Administrator, den Sie wie jedes andere Konto bearbeiten können.

Bei der Passwortzeile ist besondere Vorsicht erforderlich. Alles unter environment: kann von jedem gelesen werden, der im Container docker inspect ausführen darf. DEFAULT_ADMIN_PASSWORD sollte daher nicht dauerhaft dort stehen. Melden Sie sich an, ändern Sie Ihr Passwort in der Oberfläche, löschen Sie die Zeile und führen Sie anschließend erneut docker compose up -d aus.

Der sauberere Weg kommt vollständig ohne diese Variablen aus. Kommentieren Sie die gesamte Gruppe DEFAULT_ADMIN_* aus und legen Sie das Konto interaktiv an:

docker compose run --rm planka npm run db:create-admin-user

Das Programm fragt nach E-Mail-Adresse, Passwort, Anzeigenamen und einem optionalen Benutzernamen. Anschließend schreibt es den Benutzer direkt in die Datenbank. Das Passwort gelangt weder in die Compose-Datei noch in die Container-Umgebung. Verwenden Sie diesen Weg, wenn mehrere Personen Shell-Zugriff auf den VPS haben. Der Befehl startet zuerst Postgres, weil depends_on verwendet wird. Daher funktioniert er auch bei einem Stack, der noch nie gestartet wurde.

Bei beiden Wegen verwalten Sie die Planka-Passwörter weiterhin manuell. Wenn dies bereits der vierte Zugang ist, den Ihr Team verwalten muss, kann Planka die Anmeldungen stattdessen an einen OIDC-Anbieter delegieren, beispielsweise an Authentik als eigenen Single-Sign-On-Server. Den Bootstrap-Administrator behalten Sie dabei als Notfallkonto für den Fall, dass der Anbieter nicht verfügbar ist.

Warum BASE_URL die Anmeldung verhindert, wenn sie nicht mit dem Hostnamen übereinstimmt

BASE_URL ist die exakte Adresse, die Benutzer in den Browser eingeben, einschließlich Schema und ohne abschließenden Schrägstrich. Für diesen Stack ist das https://kanban.example.com. Planka erstellt aus diesem Wert eigene Links und seine WebSocket-Verbindung. Ein falsches BASE_URL führt daher nicht zu einer eindeutigen Fehlermeldung. Stattdessen wird eine Seite geladen, deren Ladevorgang anschließend nicht abgeschlossen wird.

Der häufige Fall sieht so aus: Sie übernehmen das Beispiel des Upstream-Projekts, lassen BASE_URL=http://localhost:3000 unverändert und rufen die Website über HTTPS unter Ihrer tatsächlichen Domain auf. Das Anmeldeformular wird abgesendet, und Ihre Zugangsdaten werden akzeptiert. Das Board wird jedoch nicht angezeigt. Öffnen Sie die Entwicklerkonsole des Browsers. Dort sehen Sie, dass Anfragen an /socket.io/ fehlschlagen, weil der Client angewiesen wurde, seine Live-Verbindung zu localhost:3000 herzustellen. Auf Ihrem Laptop ist diese Adresse jedoch nicht erreichbar.

TRUST_PROXY=true ist die zweite Hälfte desselben Problems. Planka läuft hinter Traefik. Deshalb erreicht jede Anfrage die Anwendung über die Adresse des Proxy und innerhalb des Docker-Netzwerks über plain HTTP. Ohne TRUST_PROXY ignoriert die Anwendung die Header X-Forwarded-Proto und X-Forwarded-For, die Traefik setzt. Sie geht daher davon aus, dass die Verbindung unsicher ist, und behandelt alle Clients so, als kämen sie von derselben IP-Adresse. Wenn TRUST_PROXY gesetzt ist, liest die Anwendung diese Header und verwendet dasselbe Schema wie der Browser.

Traefik proxied WebSockets ohne zusätzliche Konfiguration. Das ist ein Grund, warum Traefik für diesen Anwendungsfall geeignet ist. Bei nginx benötigt socket.io einen eigenen location-Block mit proxy_set_header Upgrade $http_upgrade und proxy_set_header Connection "upgrade". Andernfalls sehen Sie denselben dauerhaft angezeigten Ladekreisel, allerdings aus einem anderen Grund.

Wenn Sie das Board später auf einen neuen Hostnamen verschieben, müssen Sie zwei Dinge gemeinsam ändern: den Wert von BASE_URL und die Traefik-Regel Host(). Wenn Sie nur eines davon ändern, wird der Ladekreisel erneut angezeigt. Planka kann ab Version 2.1.0, die im March 2026 veröffentlicht wurde, unter einem Unterpfad wie https://example.com/planka bereitgestellt werden. Verwenden Sie bei älteren Tags eine eigene Subdomain.

Wo Planka Anhänge und Avatare speichert

Planka 2 speichert alle Uploads eines Benutzers unter einem einzigen Pfad im Container: /app/data. Anhänge, Benutzeravatare und Hintergrundbilder für Boards befinden sich dort. Version 1 verwendete drei separate Verzeichnisse. Deshalb bindet eine aus einer älteren Anleitung übernommene Compose-Datei Pfade ein, die nicht mehr existieren. Das tatsächliche Datenverzeichnis bleibt dadurch ohne Mount.

Dieser eine Mount entscheidet darüber, ob ein Board ein Upgrade übersteht oder erheblicher manueller Aufwand entsteht. Wenn /app/data nicht auf einem Volume liegt, werden Uploads in der beschreibbaren Schicht des Containers gespeichert. Diese Schicht wird beim Neuerstellen des Containers gelöscht. Der Container wird bei jeder Änderung des Image-Tags neu erstellt. Das Board wird scheinbar vollständig wiederhergestellt, und alle Karten sind vorhanden. Alle Links zu Anhängen sind jedoch ungültig, weil die Datenbankzeilen weiterhin auf nicht mehr vorhandene Dateien verweisen.

Das benannte Volume in der obigen Compose-Datei verhindert dieses Problem. Ein Bind-Mount funktioniert ebenfalls und erleichtert die Sicherung der Dateien mit gewöhnlichen Werkzeugen. Dafür ist jedoch ein zusätzlicher Schritt erforderlich. Der Node-Prozess im Container läuft als UID 1000. Ein Hostverzeichnis, das root gehört, führt beim ersten Upload zu einem Berechtigungsfehler:

sudo chown -R 1000:1000 /opt/planka/data

Der Unterschied zwischen beiden Varianten wird unter Bind-Mounts gegenüber benannten Volumes erläutert.

Wenn Anhänge den Speicherplatz Ihres Tarifs überschreiten, kann Planka sie stattdessen über S3_ENDPOINT, S3_BUCKET und die zugehörigen Schlüsselvariablen in einem S3-kompatiblen Speicher ablegen. Dabei kann es sich um einen gehosteten Bucket oder um einen selbst gehosteten MinIO-Objektspeicher auf einem anderen Server handeln. Legen Sie dies fest, bevor das Team das Board mit Inhalten füllt, da die Einstellung nur für neue Uploads gilt.

Stack starten und Funktion prüfen

docker compose pull
docker compose up -d
docker compose ps

docker compose ps sollte postgres als healthy und planka als running anzeigen. Wenn Planka in einer Neustartschleife läuft, prüfen Sie zuerst die Datenbankverbindung und nicht die Anwendung.

docker compose logs -f planka

Bei einem erfolgreichen ersten Start führt der Dienst die Datenbankmigrationen aus und meldet anschließend, dass der Server auf Port 1337 lauscht. Prüfen Sie direkt mit Postgres, ob das Schema tatsächlich angelegt wurde, statt sich nur auf das Log zu verlassen:

docker compose exec postgres psql -U planka -d planka -c '\dt'

Eine Tabellenliste mit board und card bedeutet, dass die Migrationen ausgeführt wurden. „Did not find any relations“ bedeutet, dass Planka nie eine Verbindung hergestellt hat. Vergleichen Sie daher DATABASE_URL mit den Werten POSTGRES_USER und POSTGRES_PASSWORD in Ihrer .env.

Prüfen Sie anschließend die Route von Ihrem eigenen Rechner und nicht vom VPS aus:

curl -I https://kanban.example.com

HTTP/2 200 bedeutet, dass Traefik ein Zertifikat verwendet und den Container erreicht. Eine von Traefik gelieferte 404 bedeutet, dass die Router-Labels nicht übereinstimmen. Die häufigste Ursache ist, dass der Container nicht mit dem Netzwerk proxy verbunden ist. Öffnen Sie nun die Website und melden Sie sich mit dem Administratorkonto an.

Vor jedem Versionssprung ein pg_dump erstellen

Zwei getrennte Speicher enthalten Ihre Board-Daten. Eine Sicherung muss daher beide abdecken: die Postgres-Datenbank und das planka-data-Volume. Erstellen Sie den Datenbank-Dump, während der Stack läuft.

docker compose exec -T postgres pg_dump -U planka -d planka > "planka-db-$(date +%F).sql"

Das -T ist nicht optional. Ohne diese Option weist Compose ein Pseudo-Terminal zu. Die Terminalschicht ändert dann die Zeilenenden im Datenstrom. Dadurch entsteht eine Dump-Datei, deren Wiederherstellung vorzeitig fehlschlägt. Der Fehler tritt möglicherweise erst Wochen später auf. Das ist der ungünstigste Zeitpunkt.

Sichern Sie anschließend die Uploads. Ermitteln Sie zuerst den tatsächlichen Volume-Namen, da Compose den Namen des Projektverzeichnisses voranstellt.

docker volume ls | grep planka
docker run --rm -v planka_planka-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/planka-files-$(date +%F).tgz -C /data .

Das Projekt enthält außerdem docker-backup.sh und docker-restore.sh in seinem Repository. Die offizielle Dokumentation richtet dafür einen nächtlichen Cron-Job ein. Beide Ansätze sind geeignet. Nicht geeignet ist eine Sicherung, die Sie nie wiederhergestellt haben. Stellen Sie daher einmal eine Sicherung auf einem Test-VPS wieder her. Bestätigen Sie anschließend, dass Sie sich anmelden und einen Anhang öffnen können. Dasselbe Paar von Speichern findet sich in jeder Compose-Anwendung, die Uploads akzeptiert. Wenn Sie später Chatwoot auf demselben Server wie Ihr Supportsystem betreiben, können Sie die hier erstellte Routine mit kaum mehr als geänderten Volume-Namen übernehmen.

Führen Sie den Dump unmittelbar vor jeder Versionsänderung aus. Eine Sicherung von letzter Nacht ist nicht dasselbe wie eine Sicherung unmittelbar vor der Migration, die Sie jetzt ausführen wollen.

Tags festlegen und Release-Notes lesen

Beide Image-Tags in dieser Datei sind absichtlich festgelegt.

ghcr.io/plankanban/planka:2.1.1 ist ein bestimmtes Release und war im August 2026 aktuell. latest ändert sich, sobald Upstream ein neues Release veröffentlicht. Ein routinemäßiges docker compose pull kann dadurch zu einem Zeitpunkt eine Schema-Migration einspielen, den Sie nicht gewählt haben. Lesen Sie die Release-Notes, bevor Sie diese Zahl ändern. Dort werden inkompatible Änderungen und Sicherheitskorrekturen beschrieben. Version 2.0.3 wurde als Sicherheits-Release veröffentlicht. Genau solche Änderungen sollten Sie bewusst lesen und nicht versehentlich übernehmen. Das Festlegen eines Tags ist hier einfach, weil Upstream überhaupt Images veröffentlicht. Wenn ein Projekt keine Images bereitstellt, müssen Sie dieselbe Disziplin mit einem zusätzlichen Schritt einhalten, wie bei openGym, das auf dem System aus einem ausgecheckten git-Tag erstellt wird.

postgres:16-alpine ist aus einem wichtigeren Grund auf eine Major-Version festgelegt. Postgres schreibt sein Datenverzeichnis in einem Format, das an die Major-Version gebunden ist. Der Server verweigert das Öffnen eines Verzeichnisses, das von einer anderen Version geschrieben wurde. Schreiben Sie postgres:latest, lassen Sie den Tag auf 17 weiterlaufen, und der Container startet nicht:

FATAL:  database files are incompatible with server
DETAIL:  The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.

Es gehen keine Daten verloren. Auch ein Neustart behebt das Problem nicht. Der Wechsel auf eine neue Postgres-Major-Version erfordert einen Dump mit der alten Version und eine Wiederherstellung in ein neues Datenverzeichnis mit der neuen Version. Das ist ein geplanter Vorgang bei angehaltenem Stack und keine Nebenwirkung eines Image-Pulls.

Wenn Sie eine vorhandene Planka-1.x-Installation aktualisieren, statt neu zu beginnen, hat dieses Upgrade ein eigenes dokumentiertes Verfahren in der Projektdokumentation. Ohne vorher erstelltes Backup gibt es keinen Weg zurück zu Version 1.

Fehlerbilder und die angezeigten Meldungen

Planka startet in einer Schleife neu, und im Log wird die Datenbank genannt. Die Zugangsdaten in DATABASE_URL stimmen nicht mit der Postgres-Umgebung überein. Beachten Sie, dass POSTGRES_PASSWORD nur bei der ersten Initialisierung des Datenverzeichnisses angewendet wird. Wenn Sie die Variable nach einem fehlerhaften ersten Start korrigieren, ändert das nichts. Sie müssen das db-data-Volume entfernen und erneut starten.

Die Anmeldung ist erfolgreich, aber das Board wird nie geladen. BASE_URL stimmt nicht mit der Adresse in der Browserzeile überein, oder TRUST_PROXY fehlt. Die Browserkonsole zeigt fehlgeschlagene Anfragen an /socket.io/.

Uploads schlagen fehl, während alles andere funktioniert. Ein Bind-Mount gehört root. Führen Sie sudo chown -R 1000:1000 im Host-Verzeichnis aus und starten Sie den Container neu.

Anhänge sind nach einem Upgrade verschwunden. /app/data lag nicht auf einem Volume. Die Dateien befanden sich daher in der Containerschicht, die durch das Upgrade ersetzt wurde. Stellen Sie die Dateien aus einem Backup wieder her. Fügen Sie anschließend das Volume hinzu, bevor Sie den Image-Tag erneut ändern.

Traefik gibt 404 zurück. Der Container befindet sich nicht im proxy-Netzwerk, oder die Host()-Regel stimmt nicht mit Ihrem DNS-Eintrag überein. docker compose config zeigt die Labels nach der Ersetzung an. Dort werden Tippfehler sichtbar.

Benachrichtigungen oder Webhooks kommen nie an. Planka 2 sendet seine ausgehenden HTTP-Anfragen über einen internen Filter. Die Standard-Blockliste umfasst localhost und postgres. Ein Webhook an einen anderen Container auf demselben Host kann daher absichtlich blockiert werden. Passen Sie OUTGOING_ALLOWED_HOSTS an, anstatt den Filter zu entfernen.

Nach dem Start ist der Betriebsaufwand gering. Verfolgen Sie die Release Notes und erstellen Sie vor jedem Upgrade einen Datenbank-Dump. Nach einem Reboot wird der Stack aufgrund von restart: unless-stopped automatisch wieder gestartet, sofern der Docker-Dienst selbst beim Booten aktiviert ist. Compose-Stacks, die nach einem Reboot automatisch wieder starten behandelt die Fälle, in denen dies nicht geschieht.

FAQ

Warum lädt Planka nach der Anmeldung dauerhaft?

Die Anmeldedaten wurden akzeptiert, aber die Live-Verbindung wurde nicht hergestellt. Planka erstellt seine WebSocket-URL aus BASE_URL. Wenn diese Variable weiterhin http://localhost:3000 enthält, während Sie die Website unter https://kanban.example.com aufrufen, versucht der Browser, eine Socket-Verbindung zu einer Adresse zu öffnen, die auf Ihrem Rechner nicht existiert. Die Entwicklerkonsole zeigt fehlgeschlagene Anfragen an /socket.io/. Setzen Sie BASE_URL auf die exakte öffentliche Adresse ohne abschließenden Schrägstrich. Fügen Sie TRUST_PROXY=true hinzu, damit die Anwendung den X-Forwarded-Proto-Header Ihres Reverse Proxy berücksichtigt. Führen Sie anschließend docker compose up -d aus.

Wie erstelle ich den ersten Planka-Administrator?

Seit Version 1.13 wird kein Administrator mehr automatisch erstellt. Setzen Sie entweder DEFAULT_ADMIN_EMAIL zusammen mit den zugehörigen Variablen für Passwort, Namen und Benutzernamen und starten Sie den Stack. Alternativ können Sie docker compose run --rm planka npm run db:create-admin-user ausführen und die Eingabeaufforderungen beantworten. Der interaktive Befehl ist auf einem gemeinsam genutzten Server sicherer, weil das Passwort nicht in die Container-Umgebung gelangt, in der docker inspect es lesen kann. Wenn DEFAULT_ADMIN_EMAIL anschließend gesetzt bleibt, ist dieses Konto gegen Änderungen und Löschung über die Benutzeroberfläche gesperrt.

Wo speichert Planka Anhänge und Avatare?

In Planka 2 liegen alle hochgeladenen Dateien innerhalb des Containers unter /app/data. Dazu gehören Anhänge, Benutzeravatare und Board-Hintergründe. Binden Sie diesen Pfad in ein benanntes Volume ein. Wenn das Volume nicht eingebunden ist, liegen die Dateien in der beschreibbaren Schicht des Containers. Beim nächsten Neuerstellen des Containers werden sie gelöscht. Das geschieht bei jedem Upgrade des Images. Ein Bind-Mount funktioniert ebenfalls. Der Node-Prozess läuft jedoch als UID 1000. Führen Sie daher sudo chown -R 1000:1000 für das Verzeichnis auf dem Host aus. Andernfalls schlagen Uploads mit einem Berechtigungsfehler fehl.

Wie viel RAM benötigt ein selbst gehostetes Planka?

Das Projekt veröffentlicht keine Mindestanforderungen an die Hardware. Die auf Hosting-Seiten häufig genannten Werte von 2 vCPU und 4 GB sind ein Standardwert des Anbieters, keine Messung. Für ein kleines Board ist diese Ausstattung großzügig. Die gesamte Arbeitslast besteht aus einem Node-Prozess und einem Postgres-Prozess. Daher reicht ein Tarif mit 1 vCPU und 2 GB für ein Team mit zwei bis fünf Personen aus. Führen Sie nach einer normalen Woche docker stats --no-stream aus und dimensionieren Sie anhand Ihrer eigenen Messwerte. Überwachen Sie den Speicherplatz genauer als den Arbeitsspeicher, weil vor allem Anhänge wachsen.

Wie aktualisiere ich Planka ohne Datenverlust?

Sichern Sie die Datenbank und archivieren Sie das Uploads-Volume unmittelbar vor dem Upgrade. Verwenden Sie nicht den nächtlichen Sicherungszeitplan vom Vortag. Verwenden Sie docker compose exec -T postgres pg_dump -U planka -d planka > planka-db.sql und behalten Sie -T bei, damit das Pseudo-Terminal die umgeleitete Ausgabe nicht beschädigt. Lesen Sie die Release Notes für jede übersprungene Version. Ändern Sie anschließend den Image-Tag in eine bestimmte Version statt in latest. Führen Sie dann docker compose pull und docker compose up -d aus und überwachen Sie das Log auf die Migration. Lassen Sie den Postgres-Tag auf seine Major-Version festgelegt. Der Server verweigert das Öffnen eines Datenverzeichnisses, das von einer anderen Major-Version geschrieben wurde.