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 VPS, den Sie kontrollieren. Es gibt keine Begrenzung der Benutzerzahl und keine Abrechnung pro Benutzer, weil nur die Kosten für den Server anfallen. In dieser Anleitung wird Planka mit Docker Compose hinter Traefik bereitgestellt. Für die Daten wird Postgres verwendet. Für jede hochgeladene Datei wird ein benanntes Volume verwendet.

Diese 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 einsetzen möchten, lesen Sie zuerst den Vergleich selbst gehosteter Trello-Alternativen. Diese Anleitung setzt voraus, dass die Entscheidung bereits getroffen wurde, 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. Lesen Sie außerdem die Grundlagen von Docker Compose für einen VPS, wenn Ihnen die folgende Datei nicht vertraut ist.

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 auf Hosting-Seiten häufig genannten Werte von 2 vCPU und 4 GB sind ein komfortabler Standard des Anbieters und keine vom Projekt gemessene Anforderung. Für ein Board, das von fünf Personen genutzt wird, ist das großzügig bemessen.

Tatsächlich laufen nur wenige Komponenten: ein Node.js-Prozess für die API und das kompilierte Frontend sowie ein Postgres-Prozess für die Daten. Ein dritter kleiner Proxy-Prozess läuft innerhalb des Planka-Containers und filtert dessen ausgehende Anfragen. 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.

Bemessen Sie den Speicherplatz vor dem Arbeitsspeicher, weil 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, nicht am Tag der Installation. Ein ungenutztes Board sagt nichts über Ihr Team aus.

Compose-Datei schreiben

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

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 absichtlich so gewählt. Eine Hex-Zeichenfolge enthält nur Ziffern und die Buchstaben a bis f. Dadurch 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 allgemeine Vorgehen wird unter Secrets aus der Compose-Datei heraushalten beschrieben.

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 und später bereut werden.

• Beim Planka-Dienst gibt es keinen ports:-Block. Traefik erreicht den Container über das proxy-Netzwerk. Deshalb 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 Beispiel aus dem Upstream erreicht den Dienst nur über 3000, weil es den Port auf den Host abbildet. Hier gibt es keine Host-Zuordnung. Deshalb muss Traefik der Container-Port mitgeteilt werden.
• condition: service_healthy wird zusammen 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 technischen Details finden Sie unter Compose-Healthchecks und Startreihenfolge.
• Der Datenbankdienst heißt absichtlich postgres. Planka 2 leitet seine ausgehenden 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'

Der Befehl gibt die Datei aus und ersetzt die .env-Werte bereits. Ein leerer Wert bedeutet, dass Compose die Datei .env nicht einliest. 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 angelegt. Eine neue Datenbank enthält daher zunächst keinen Benutzer, der sich anmelden kann. Die Gruppe DEFAULT_ADMIN_* ist eine von zwei Möglichkeiten, dieses Problem zu beheben.

Beim Start sucht Planka nach einem Benutzer, der DEFAULT_ADMIN_EMAIL entspricht. Gibt es keinen solchen Benutzer, wird anhand der zugehörigen Variablen ein Benutzer mit dem festgelegten Passwort, Anzeigenamen und Benutzernamen angelegt. Das geschieht beim ersten Start mit einer leeren Datenbank. Diese Variablen legen also ein Konto an, verwalten es aber nicht.

DEFAULT_ADMIN_EMAIL erfüllt zusätzlich eine Funktion, die häufig übersehen wird. Solange die Variable gesetzt ist, kann niemand das darin angegebene Konto über die Benutzeroberfläche bearbeiten oder löschen. Das verhindert eine Aussperrung. Deshalb können Sie den Namen dieses Kontos in der Benutzeroberfläche auch nicht ändern und seine E-Mail-Adresse nicht bearbeiten. Entfernen Sie die Variable und starten Sie den Container neu. Danach ist das Konto ein normaler Administrator, den Sie wie jedes andere Administratorkonto bearbeiten können.

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

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

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

Der Befehl fragt nach E-Mail-Adresse, Passwort, Anzeigenamen und optionalem Benutzernamen. Anschließend schreibt er den Benutzer direkt in die Datenbank. Das Passwort gelangt dabei weder in die Compose-Datei noch in die Container-Umgebung. Verwenden Sie diese Variante, wenn mehrere Personen Shell-Zugriff auf den VPS haben. Der Befehl startet Postgres wegen depends_on zuerst. Daher funktioniert er auch mit einem Stack, der bisher noch nicht gestartet wurde.

Bei beiden Varianten müssen Sie die Planka-Passwörter manuell verwalten. Wenn Ihr Team dadurch bereits den vierten Satz Zugangsdaten verwaltet, kann Planka die Anmeldungen stattdessen an einen OIDC-Anbieter delegieren, beispielsweise an Authentik als eigenen Single-Sign-on-Server. Das Bootstrap-Administratorkonto bleibt dabei als Notfallkonto für den Fall erhalten, dass der Anbieter nicht verfügbar ist.

Warum BASE_URL den Login verhindert, wenn sie nicht mit dem Hostnamen übereinstimmt

BASE_URL ist die genaue 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 falscher Wert für BASE_URL führt daher nicht zu einer eindeutigen Fehlermeldung. Stattdessen wird eine Seite geladen, deren Ladevorgang anschließend nicht abgeschlossen wird.

Der häufigste Fall: Sie übernehmen das Upstream-Beispiel, lassen BASE_URL=http://localhost:3000 unverändert und rufen die Site über HTTPS unter Ihrer tatsächlichen Domain auf. Das Login-Formular wird abgeschickt, und Ihre Zugangsdaten werden akzeptiert. Das Board wird jedoch nicht angezeigt. Öffnen Sie die Entwicklerkonsole des Browsers. Dort sehen Sie, dass Anforderungen an /socket.io/ fehlschlagen, weil der Client angewiesen wurde, seine dauerhafte Verbindung zu localhost:3000 zu öffnen. Auf Ihrem Laptop ist diese Adresse jedoch nicht erreichbar.

TRUST_PROXY=true ist die andere Hälfte desselben Problems. Planka läuft hinter Traefik. Deshalb erreicht jede Anforderung die Anwendung innerhalb des Docker-Netzwerks von der Adresse des Proxy über HTTP. Ohne TRUST_PROXY ignoriert die Anwendung die von Traefik gesetzten Header X-Forwarded-Proto und X-Forwarded-For. Sie geht daher davon aus, dass die Verbindung unsicher ist, und behandelt alle Clients so, als hätten sie dieselbe 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, es hier zu bevorzugen. Unter nginx benötigt socket.io einen eigenen location-Block mit proxy_set_header Upgrade $http_upgrade und proxy_set_header Connection "upgrade". Andernfalls erhalten Sie denselben festhängenden Ladeindikator, allerdings aus einer anderen Ursache.

Wenn Sie das Board später auf einen neuen Hostnamen verschieben, müssen Sie zwei Dinge gemeinsam ändern: den Wert BASE_URL und die Traefik-Regel Host(). Wenn Sie nur eines davon ändern, bleibt der Ladeindikator erneut hängen. Die Bereitstellung von Planka unter einem Unterpfad wie https://example.com/planka funktioniert ab Version 2.1.0, die im März 2026 veröffentlicht wurde. Verwenden Sie bei älteren Tags stattdessen 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 von Boards liegen alle dort. Version 1 verwendete drei separate Verzeichnisse. Daher bindet eine aus einer älteren Anleitung kopierte Compose-Datei Pfade ein, die nicht mehr existieren. Das tatsächliche Datenverzeichnis bleibt dadurch ungemountet.

Dieser einzelne Mount entscheidet darüber, ob ein Board ein Upgrade übersteht oder einen längeren Ausfall verursacht. Wenn /app/data nicht auf einem Volume liegt, werden Uploads in der beschreibbaren Schicht des Containers gespeichert. Diese Schicht wird zerstört, wenn der Container neu erstellt wird. Der Container wird bei jeder Änderung des Image-Tags neu erstellt. Das Board wird wieder angezeigt, die Karten sind noch vorhanden, aber jeder Link auf einen Anhang ist ungültig. Die Datenbankzeilen verweisen weiterhin auf Dateien, die nicht mehr existieren.

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

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

Der Unterschied zwischen beiden Varianten wird unter Bind-Mounts im Vergleich zu benannten Volumes erläutert.

Wenn die 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. Das kann auf einen gehosteten Bucket oder auf einen selbst gehosteten MinIO-Objektspeicher auf einem anderen Rechner zeigen. Legen Sie diese Entscheidung fest, bevor das Team das Board 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, nicht die Anwendung.

docker compose logs -f planka

Bei einem erfolgreichen ersten Start werden die Datenbankmigrationen ausgeführt. Danach meldet der Server, dass er auf Port 1337 lauscht. Prüfen Sie direkt in Postgres, ob das Schema tatsächlich angelegt wurde, statt sich auf das Log zu verlassen:

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

Eine Tabellenliste mit board und card zeigt, dass die Migrationen ausgeführt wurden. "Did not find any relations" bedeutet, dass Planka keine 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 aus, nicht vom VPS:

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

HTTP/2 200 bedeutet, dass Traefik ein Zertifikat besitzt und den Container erreicht. Eine von Traefik ausgelieferte 404 bedeutet, dass die Router-Labels nicht übereinstimmen. Meistens ist der Container dann nicht mit dem Netzwerk proxy verbunden. Öffnen Sie nun die Website und melden Sie sich mit dem Administratorkonto an.

Vor jedem Versionssprung ein pg_dump erstellen

Ihr Board wird in zwei getrennten Speichern abgelegt. Eine Sicherung muss daher beide abdecken: die Postgres-Datenbank und das planka-data-Volume. Erstellen Sie den Dump, während der Stack läuft.

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

Der -T ist zwingend erforderlich. Ohne ihn weist Compose ein Pseudo-Terminal zu. Die Terminalschicht ändert dann die Zeilenenden im Datenstrom. Dadurch entsteht eine Dump-Datei, bei deren Wiederherstellung der Vorgang abbricht. Der Fehler wird möglicherweise erst Wochen später sichtbar. Das ist der ungünstigste Zeitpunkt dafür.

Sichern Sie anschließend die Uploads. Ermitteln Sie zuerst den tatsächlichen Volume-Namen. Compose stellt ihm den Namen des Projektverzeichnisses voran.

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. In der offiziellen Dokumentation werden sie über einen nächtlichen cron-Job ausgeführt. Beide Vorgehensweisen sind geeignet. Nicht geeignet ist eine Sicherung, die Sie noch nie wiederhergestellt haben. Stellen Sie daher einmal eine Sicherung auf einem Test-VPS wieder her. Prüfen Sie anschließend, ob Sie sich anmelden und einen Anhang öffnen können.

Erstellen Sie den Dump unmittelbar vor jeder Versionsänderung. Eine Sicherung von letzter Nacht ist nicht dasselbe wie eine Sicherung vor der Migration, die Sie gleich ausführen werden.

Tags festlegen und die Release Notes lesen

Beide Image-Tags in dieser Datei sind absichtlich festgelegt.

ghcr.io/plankanban/planka:2.1.1 bezeichnet ein bestimmtes Release, das im August 2026 aktuell ist. latest ändert sich bei jeder Veröffentlichung durch das Upstream-Projekt. 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 Security Release veröffentlicht. Genau solche Änderungen sollten Sie gezielt lesen und nicht versehentlich übernehmen.

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, sodass der Tag auf 17 wechselt, startet der Container 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 dabei keine Daten verloren. Ein Neustart behebt das Problem ebenfalls nicht. Der Wechsel auf eine neue Postgres-Major-Version erfordert einen Dump der alten Version und eine Wiederherstellung in einem neuen Datenverzeichnis der neuen Version. Das ist ein geplanter Vorgang bei angehaltenem Stack und keine Nebenwirkung eines Image-Pulls.

Wenn Sie eine bestehende Planka-1.x-Installation migrieren, 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 wiederholt 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 erstmaligen 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 auf dem Host-Verzeichnis sudo chown -R 1000:1000 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 Container-Schicht, 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. Dort werden Tippfehler sichtbar.

Benachrichtigungen oder Webhooks kommen nie an. Planka 2 sendet ausgehende 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, statt den Filter zu entfernen.

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

FAQ

Warum lädt Planka nach der Anmeldung endlos?

Die Zugangsdaten wurden akzeptiert, aber die Live-Verbindung konnte nicht hergestellt werden. Planka erstellt seine WebSocket-URL aus BASE_URL. Wenn diese Variable noch auf http://localhost:3000 gesetzt ist, während Sie die Website unter https://kanban.example.com aufrufen, versucht der Browser, eine Verbindung zu einer Adresse herzustellen, 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 sowie die 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, wo docker inspect es auslesen kann. Wenn DEFAULT_ADMIN_EMAIL anschließend gesetzt bleibt, ist das 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 an ein benanntes Volume. Wenn das Volume nicht eingebunden ist, liegen die Dateien in der beschreibbaren Schicht des Containers. Sie werden beim nächsten Neuerstellen des Containers gelöscht. Das geschieht bei jedem Image-Upgrade. 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 2 vCPU und 4 GB sind ein Standardwert des Anbieters und keine Messung. Für ein kleines Board ist dieser Wert großzügig bemessen. 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 Werte. Überwachen Sie den Speicherplatz genauer als den Arbeitsspeicher, weil vor allem Anhänge wachsen.

Wie aktualisiere ich Planka ohne Datenverlust?

Erstellen Sie unmittelbar vor dem Upgrade einen Datenbank-Dump und ein Archiv des Upload-Volumes. Verwenden Sie nicht den Zeitplan vom Vorabend. 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 den Image-Tag in eine bestimmte Version statt in latest. Führen Sie anschließend 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.