Planka mit Docker Compose: Eigenes Kanban-Board lokal auf Port 3000 starten

Wenn aktuelle News nicht belastbar genug sind, muss der Fallback echten Nutzwert haben. Planka ist dafuer stark genug: ein selbst hostbares Kanban-Board mit sichtbarem Ergebnis im Browser, sauber dokumentiertem Docker-Weg und einem klaren lokalen Endpunkt auf http://127.0.0.1:3000.

Stand: 15. Juni 2026, 10:00 Uhr CEST. Die aktuelle PLANKA-Doku verweist weiter auf den Compose-Weg, die Release-Seite listet v2.1.1 als neueste Version, und das GitHub-Container-Paket fuehrt 2.1.1 zugleich als latest. Fuer ein reproduzierbares Setup pinne ich hier trotzdem bewusst auf ghcr.io/plankanban/planka:2.1.1 statt blind auf latest.

Wichtig ist noch ein Punkt aus der offiziellen Admin-Doku: seit Version 1.13 wird kein Administrator automatisch erzeugt. Genau deshalb setzt dieses Tutorial die Admin-Zugangsdaten beim ersten Start direkt ueber Umgebungsvariablen.

Was du am Ende hast

ein laufendes Planka-Board unter http://127.0.0.1:3000
persistente Daten fuer Anwendung und PostgreSQL in lokalen Ordnern
einen ersten Admin-Login ohne manuelle Nacharbeit im Container
ein sichtbares Ergebnis statt nur eines weiteren abstrakten Docker-Grundlagenposts

Voraussetzungen

Du brauchst:

Docker Engine oder Docker Desktop
docker compose
openssl
einen freien Port 3000

Kurz pruefen:

docker --version
docker compose version
openssl version

1. Arbeitsordner anlegen

Starte bewusst in einem neuen Projektordner:

mkdir planka-lab && cd planka-lab

2. Secret Key erzeugen

Die offizielle Docker-Doku verlangt einen SECRET_KEY. Erzeuge ihn direkt lokal:

openssl rand -hex 64

Kopiere die Ausgabe. Du brauchst sie gleich fuer PLANKA_SECRET_KEY.

3. `.env` mit deinen Werten anlegen

Lege jetzt eine planka-lab/.env an:

POSTGRES_PASSWORD=ersetze-das-durch-ein-starkes-db-passwort
PLANKA_SECRET_KEY=ersetze-das-durch-deinen-hex-key
[email protected]
PLANKA_ADMIN_PASSWORD=ersetze-das-durch-ein-starkes-admin-passwort
PLANKA_ADMIN_NAME=Eckelsoft Admin
PLANKA_ADMIN_USERNAME=eckelsoft

Fuer einen reinen lokalen Test ist die .test-Adresse praktisch, weil sie nicht versehentlich als echte Mailadresse missverstanden wird.

4. Compose-Datei schreiben

Erstelle jetzt planka-lab/compose.yaml:

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

  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    container_name: planka
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    ports:
      - "3000:1337"
    environment:
      BASE_URL: http://127.0.0.1:3000
      DATABASE_URL: postgresql://postgres:${POSTGRES_PASSWORD}@postgres/planka
      SECRET_KEY: ${PLANKA_SECRET_KEY}
      DEFAULT_ADMIN_EMAIL: ${PLANKA_ADMIN_EMAIL}
      DEFAULT_ADMIN_PASSWORD: ${PLANKA_ADMIN_PASSWORD}
      DEFAULT_ADMIN_NAME: ${PLANKA_ADMIN_NAME}
      DEFAULT_ADMIN_USERNAME: ${PLANKA_ADMIN_USERNAME}
    volumes:
      - ./data:/app/data

Warum genau diese Werte?

3000:1337 folgt dem offiziellen Docker-Muster: lokal 3000, intern lauscht Planka auf 1337.
postgres:16-alpine entspricht dem offiziellen Compose-Beispiel.
DEFAULT_ADMIN_* spart dir den spaeteren manuellen Bootstrap und ist laut offizieller Admin-Doku ausdruecklich vorgesehen.
Das lokale Volume ./data:/app/data behaelt Uploads und Anwendungsdaten ueber Neustarts hinweg.

Nach dem ersten erfolgreichen Login kannst du die DEFAULT_ADMIN_*-Variablen wieder aus compose.yaml entfernen, wenn du diesen Bootstrap-Zugang nicht dauerhaft im Compose-Setup behalten willst.

5. Stack starten

Ziehe die Images und starte dann den Stack:

docker compose pull
docker compose up -d

Beim ersten Start initialisiert PostgreSQL die Datenbank, danach startet Planka mit dem Admin-Konto aus deiner .env.

6. Funktion sauber pruefen

Nimm jetzt die drei sinnvollen Checks mit:

docker compose ps
docker compose logs --tail=100 postgres
docker compose logs --tail=100 planka
curl -I http://127.0.0.1:3000

Woran du ein gutes Ergebnis erkennst:

docker compose ps zeigt beide Container als laufend an
die Logs von postgres enthalten keine dauernden Restart-Schleifen
die Logs von planka enden nicht in Datenbankfehlern
curl -I liefert einen erfolgreichen HTTP-Status statt connection refused

Damit ist der wichtigste Teil verifiziert: Die Weboberflaeche antwortet wirklich lokal und der App-Container kommt an seine Datenbank.

7. Im Browser einloggen

Oeffne jetzt:

http://127.0.0.1:3000

Melde dich mit den Werten aus deiner .env an:

PLANKA_ADMIN_EMAIL
PLANKA_ADMIN_PASSWORD

Wenn der Login steht, kannst du direkt:

einen Workspace anlegen
dein erstes Projekt erstellen
ein Board mit Listen wie Backlog, In Arbeit und Erledigt bauen

Genau dort wird der Nutzwert sichtbar: nicht nur Container laufen, sondern ein echtes Aufgabenboard ist nach wenigen Minuten einsatzbereit.

8. Was das Setup praktisch taugt

Planka ist fuer kleine Teams, Solo-Projekte und interne Ablagen stark, weil es den typischen Kanban-Kern ohne SaaS-Zwang liefert:

Boards, Karten und Listen laufen auf deinem eigenen Host
PostgreSQL und App-Daten bleiben lokal unter deiner Kontrolle
das Ergebnis ist sofort sichtbar und nicht nur ein Backend ohne Oberflaeche

Gerade fuer Nebenprojekte, Vereinsarbeit, kleine Agenturteams oder private Roadmaps ist das greifbarer als ein weiterer allgemeiner Docker-Text ohne klares Endprodukt.

9. Update und Alltag

Ein normales Update faehrt sich so:

docker compose pull
docker compose up -d

Zum Stoppen:

docker compose down

Deine Daten bleiben erhalten, solange die Ordner planka-lab/data und planka-lab/postgres bestehen bleiben.

Fazit

Planka ist als Docker-Compose-Projekt ein sinnvoller Fallback, weil die offizielle Doku konkret bleibt, die aktuelle Version verifizierbar ist und der Nutzen sofort sichtbar wird. Du startest nicht nur zwei Container, sondern landest am Ende bei einem echten Kanban-Board mit eigenem Admin-Zugang und lokaler Datenhaltung.