SSD Nodes Learn 🎉 VPS ab $4.99/Monat
Anleitungen Matt ConnorVon Matt Connor · Aktualisiert 2026-08-07

Trello-Alternativen selbst hosten im Vergleich

Planka, Vikunja, Focalboard, Wekan und Kanboard im Vergleich: RAM-Bedarf, Datenbank, SSO, Trello-Import und welche Projekte noch gepflegt werden.

Welche selbst gehostete Trello-Alternative sollten Sie auswählen?

Drei selbst gehostete Trello-Alternativen sind Ihre Zeit wert: Planka, wenn Sie Trellos exaktes Board und dessen Importdatei benötigen, Vikunja, sobald ein Team Single Sign-on und mehr als nur ein Board braucht, und Kanboard, wenn der VPS (virtuelle private Server) klein ist. Starten Sie kein neues Projekt mit Focalboard. Für dessen eigenständigen Server wurde seit 783 Tagen kein Release veröffentlicht, und die README bittet inzwischen um einen Maintainer.

Wekan ist das fünfte der hier vorgestellten 5 Tools. Es funktioniert, benötigt jedoch ein Mehrfaches des Arbeitsspeichers aller anderen Lösungen. Jede unten genannte Version, Lizenz und jedes Datum wurde am 5. August 2026 überprüft.

Wie viel RAM benötigt jedes Board-Tool?

ChartTypical idle memory per stack in MB, Docker on Ubuntu 24.04
The data behind this chart
[
  {
    "tool": "Planka + Postgres",
    "idle_memory_mb": 280
  },
  {
    "tool": "Vikunja + SQLite",
    "idle_memory_mb": 110
  },
  {
    "tool": "Focalboard + SQLite",
    "idle_memory_mb": 120
  },
  {
    "tool": "Wekan + FerretDB",
    "idle_memory_mb": 750
  },
  {
    "tool": "Kanboard + SQLite",
    "idle_memory_mb": 70
  }
]

Das sind typische Leerlaufwerte einer frischen Installation, die niemand verwendet. Gemeint ist der Wert, den docker stats etwa eine Minute nach dem Start des Stacks meldet. Verwenden Sie diese Werte zur Planung. Messen Sie anschließend Ihre eigene Umgebung. Das Größenverhältnis ist wichtiger als der exakte Megabyte-Wert.

Kanboard ist mit 70 MB der niedrigste Wert, weil es PHP mit SQLite verwendet. Kein langlebiger Anwendungsprozess hält Ihre Boards im Arbeitsspeicher. Deshalb benötigt der Container zwischen Anfragen im Leerlauf fast keinen Speicher. Vikunja ist mit 110 MB eine einzelne Go-Binärdatei. SQLite ist die Standarddatenbank. Daher umfasst ein Container den gesamten Stack. Planka benötigt 280 MB, weil es immer aus zwei Containern besteht: einem Node-Server und PostgreSQL. Für Planka gibt es keine SQLite-Option. Die Datenbank ist daher vorgegeben.

Wekan liegt bei 750 MB, weil es eine Meteor-Anwendung ist. Meteor hält eine Live-Query-Schicht im Node-Arbeitsspeicher und überträgt jede Änderung an einem Board per WebSocket an jeden geöffneten Browser. Der Speicherbedarf wächst daher mit der Zahl der verbundenen Benutzer, statt konstant zu bleiben. Auf einem VPS mit 1 GB startet Wekan zunächst. Beim ersten Öffnen eines großen Boards durch mehrere Benutzer beendet sich der Dienst jedoch. Das typische Symptom ist ein Container, der verschwindet und mit dem Exit-Code 137 zurückkehrt. docker compose ps zeigt dies als Neustartschleife an. Bestätigen Sie den Vorgang auf dem Host mit dmesg -T | grep -i "out of memory", da der Out-of-Memory-Killer des Kernels der Anwendung keine Meldung übermittelt.

Die Datenbankabhängigkeit bestimmt einen großen Teil Ihrer Sicherungsarbeit. Hier ist die Übersicht jeweils in einer Zeile. Planka benötigt PostgreSQL. Vikunja verwendet standardmäßig SQLite und unterstützt außerdem PostgreSQL sowie MySQL oder MariaDB. Kanboard verwendet standardmäßig SQLite und unterstützt außerdem MySQL, MariaDB und PostgreSQL. Die Dokumentation empfiehlt PostgreSQL und warnt vor SQLite auf NFS (network file system). Focalboard verwendet standardmäßig SQLite. Wekan unterstützt das MongoDB-Wire-Protokoll. Die standardmäßige Compose-Datei liefert inzwischen FerretDB v1 mit einem eingebetteten SQLite-Backend statt eines echten MongoDB-Servers aus. Zusätzlich gibt es eine separate Compose-Datei für MongoDB 7, falls Sie MongoDB verwenden möchten.

Welche dieser Projekte werden noch gepflegt?

ChartAge of the newest stable release in days, checked 5 August 2026
The data behind this chart
[
  {
    "tool": "Planka 2.1.1",
    "release_age": 109
  },
  {
    "tool": "Vikunja 2.5.0",
    "release_age": 1
  },
  {
    "tool": "Focalboard 8.0.0",
    "release_age": 783
  },
  {
    "tool": "Wekan 10.67",
    "release_age": 1
  },
  {
    "tool": "Kanboard 1.2.53",
    "release_age": 12
  }
]

Focalboard ist mit 783 Tagen der Ausreißer. Die letzte eigenständige Version, v8.0.0, stammt aus dem Juni 2024. Mattermost hat die Board-Entwicklung in ein Plugin in einem separaten Repository verschoben. In der README des eigenständigen Projekts steht, dass das Repository derzeit nicht gepflegt wird. Das ist in diesem Vergleich das einzige eindeutige „Nein“. Bei allen anderen Projekten gibt es Abwägungen.

Die 109 Tage von Planka sind für ein Projekt, das einige Versionen pro Jahr veröffentlicht, ein guter Wert. Version 2.1.1 stammt aus dem April 2026. Kanboard veröffentlichte v1.2.53 12 Tage vor der Prüfung. Die beiden vorherigen Versionen erschienen im März und April 2026.

Vikunja und Wekan veröffentlichten beide innerhalb eines Tages vor der Prüfung eine Version. Diese beiden Fakten sollten Sie jedoch unterschiedlich bewerten. Vikunja markierte v2.5.0 als reguläre Minor-Version. Wekan markierte v10.65, v10.66 und v10.67 am selben Tag. Das entspricht dem üblichen Veröffentlichungsrhythmus des Projekts. Häufige Veröffentlichungen bedeuten nicht, dass das Ziel stabil ist. Bei Wekan entscheiden Sie sich dafür, einer sich schnell ändernden Versionsnummer zu folgen. Fixieren Sie daher den Tag und lesen Sie vor jeder Aktualisierung die Versionshinweise.

Mehr als ein Board?

Die meisten Vergleichsartikel bleiben bei „sieht aus wie Trello“ stehen. Dieses Kriterium ist wichtiger als der Arbeitsspeicher, weil ein Board für Aufgaben mit Frist nur schlecht geeignet ist.

  • Planka ist ausschließlich ein Board-Tool: Projekte, Boards, Listen, Karten, Labels, Checklisten, Kommentare und Anhänge. Kalender- und Kartenansichten sind seit August 2026 Pro-Funktionen.
  • Vikunja bietet vier Ansichten für denselben Aufgabensatz: Liste, Kanban, Tabelle und Gantt. Eine Aufgabe existiert nur einmal. Sie wechseln die Ansicht, statt die Aufgabe zu duplizieren.
  • Kanboard bietet Boards mit Limits für laufende Arbeiten, Unteraufgaben, Anhängen, Kommentaren, automatischen Aktionen und einer kleinen Abfragesprache zum Filtern. Auf der eigenen Homepage steht: „The number of features is voluntarily limited“. Das beschreibt das Produkt angemessen.
  • Wekan bietet Boards mit Swimlanes sowie Checklisten, benutzerdefinierten Feldern, einer REST-API (representational state transfer) und Webhooks.
  • Focalboard bot Board-, Tabellen- und Kalenderansichten für dieselben Karten. Es ist hier der Vollständigkeit halber aufgeführt.

Wenn Sie tatsächlich ein Wiki mit angehängter Aufgabenverwaltung suchen, ist dies der falsche Vergleich. BookStack, Wiki.js und Outline behandelt diese Art von Anwendung. Die selbst gehosteten Notion-Alternativen decken den All-in-one-Arbeitsbereich ab.

Zugriff für mehrere Benutzer und Single Sign-on

Planka unterstützt OpenID Connect in der kostenlosen Community-Edition. Die offizielle Compose-Datei enthält die Einstellungen auskommentiert, darunter OIDC_ISSUER, OIDC_CLIENT_ID und OIDC_CLIENT_SECRET. Sie müssen die Einstellungen daher nur einkommentieren und kein Upgrade durchführen. Gastrollen für Personen außerhalb Ihrer Organisation sind eine Pro-Funktion.

Vikunja unterstützt OpenID Connect gleichzeitig mit mehreren Providern. Setzen Sie VIKUNJA_AUTH_OPENID_ENABLED=true und fügen Sie anschließend pro Provider einen Block mit VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_*-Variablen hinzu. Außerdem bietet Vikunja Teams und eine projektbezogene Freigabe. Das ist für eine Organisation mit zwanzig Personen tatsächlich erforderlich.

Wekan unterstützt LDAP (Lightweight Directory Access Protocol), OAuth2, OIDC und SAML. Kanboard verfügt über integrierte LDAP-Unterstützung und ein generisches OAuth2-Plugin für alle anderen Fälle. Zusätzlich bietet es projektbezogene Rollen und Gruppen. Der eigenständige Server von Focalboard unterstützt überhaupt kein Single Sign-on. Das ist ein weiterer Grund, Focalboard nicht einzusetzen.

Alle diese Anwendungen lassen sich mit einem selbst betriebenen Authentik-Identity-Provider verbinden. Das ist in der Regel sinnvoller, als zwanzig Personen für jede Anwendung ein eigenes Passwort zu geben.

Können Sie Ihre Trello-Boards importieren?

Planka bietet den einfachsten Weg. Exportieren Sie das Board aus Trello als JSON, erstellen Sie ein Board in Planka, klicken Sie auf „Import“ und wählen Sie Trello aus. Lesen Sie zuerst die Einschränkungen, da sie relevant sind: Benutzer und Anhänge werden nicht importiert, pro Karte wird nur eine Checkliste übernommen, und der standardmäßige JSON-Export von Trello wird nach 1,000 Aktionen ohne Warnung abgeschnitten. Prüfen Sie die Datei selbst, bevor Sie dem Ergebnis vertrauen.

Vikunja importiert über den OAuth-Ablauf von Trello. Die Funktion befindet sich unter „Settings“ und anschließend „Import from other services“. Jeder Importer muss in der Konfiguration aktiviert werden, bevor sein Symbol angezeigt wird, und VIKUNJA_SERVICE_PUBLICURL muss korrekt sein, da die OAuth-Weiterleitung in Ihrem Browser und nicht vom Server aus erfolgt. Vikunja importiert außerdem aus Todoist, Microsoft To Do, TickTick und Wekan.

Wekan akzeptiert im Importformular ein eingefügtes Trello-Board-JSON. Kanboard verfügt über keinen integrierten Trello-Importer. Das ist der wichtigste Grund, Kanboard zu überspringen, wenn Sie mehrere Jahre Trello-Verlauf übertragen möchten.

Wie ist die Nutzung auf Mobilgeräten?

Vikunja ist das einzige der fünf Projekte mit offiziellen mobilen Apps. Android- und iOS-Versionen werden zusammen mit jeder Veröffentlichung bereitgestellt. Das App-Repository bezeichnet die App als Alpha-Version. Betrachten Sie sie daher als Ergänzung zur Weboberfläche und nicht als primären Zugang. Planka bietet keine offizielle App des Projekts. Die Weboberfläche ist jedoch responsiv, und es gibt Clients von Drittanbietern. Wekan und Kanboard sind ausschließlich webbasiert. Die Oberfläche von Kanboard ist eindeutig für einen Desktopbildschirm ausgelegt.

Die Lizenzfrage und warum sich Planka unterscheidet

Planka ist nicht mehr Open Source. Das ist der entscheidende Punkt, den die meisten Vergleiche auslassen. Das Projekt begann unter der MIT-Lizenz, wechselte 2023 zu AGPL-3.0 und wird seit der 2.0-Serie unter der PLANKA Community License veröffentlicht, einer Fair-Code-Lizenz von PLANKA Software GmbH. GitHub führt die Lizenz als „Other“, weil diese Lizenz nicht von der OSI anerkannt ist. Das Self-Hosting für die eigenen Mitarbeiter ist kostenlos und ausdrücklich erlaubt. Dies umfasst die private, interne, gemeinnützige und pädagogische Nutzung. Der Weiterverkauf des Zugangs oder der Betrieb als Dienst für andere Unternehmen erfordert eine kommerzielle Lizenz.

Für zwei Personen ist das ein fairer Vertrag. Für ein Unternehmen ist es eine Bedingung, die geprüft werden sollte, bevor die Arbeit von zwanzig Personen in das Projekt einfließt. Die anderen vier Projekte stehen unter gewöhnlichen Open-Source-Lizenzen: Vikunja unter AGPL-3.0, Wekan und Kanboard unter MIT sowie Focalboard unter einer Kombination aus Apache 2.0 und AGPL-3.0.

Festgelegte Compose-Dateien für die beiden Empfehlungen

Fixieren Sie den Image-Tag. latest bedeutet, dass das nächste docker compose pull Sie über eine Hauptversion hinweg aktualisieren kann. Hauptversionen führen Datenbankmigrationen aus, die sich nicht einfach rückgängig machen lassen. Beide folgenden Dateien entsprechen den Upstream-Dateien, wobei der Tag auf ein tatsächliches Release festgelegt ist.

Vikunja mit SQLite, ein Container:

services:
  vikunja:
    image: vikunja/vikunja:2.5.0
    restart: unless-stopped
    environment:
      VIKUNJA_SERVICE_PUBLICURL: https://tasks.example.com
      VIKUNJA_SERVICE_SECRET: replace-with-a-long-random-string
      VIKUNJA_SERVICE_TIMEZONE: Europe/Berlin
      VIKUNJA_DATABASE_TYPE: sqlite
      VIKUNJA_DATABASE_PATH: /app/vikunja/files/vikunja.db
    ports:
      - "127.0.0.1:3456:3456"
    volumes:
      - ./files:/app/vikunja/files

Erstellen Sie zuerst das Datenverzeichnis mit dem richtigen Eigentümer. Der Container läuft als UID 1000 und kann nicht in ein Verzeichnis schreiben, das root gehört:

mkdir -p files && sudo chown 1000 files
docker compose up -d
docker compose ps
curl -sf http://127.0.0.1:3456/api/v1/info

Ein intakter Stack zeigt den Dienst als running an. Der Info-Endpunkt gibt JSON zurück, das ein Feld version enthält. Connection refused bedeutet hier, dass der Container beendet wurde. docker compose logs vikunja nennt den Grund. Ein Berechtigungsfehler für die Datenbankdatei ist die häufigste Ursache.

Planka mit PostgreSQL, zwei Container:

services:
  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    restart: unless-stopped
    volumes:
      - data:/app/data
    ports:
      - "127.0.0.1:3000:1337"
    environment:
      - BASE_URL=https://boards.example.com
      - DATABASE_URL=postgresql://postgres@postgres/planka
      - SECRET_KEY=replace-with-openssl-rand-hex-64
    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_HOST_AUTH_METHOD=trust
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  data:
  db-data:

POSTGRES_HOST_AUTH_METHOD=trust bedeutet, dass PostgreSQL jede Verbindung ohne Passwort akzeptiert. Das ist nur sicher, weil der Datenbankport nicht auf dem Host veröffentlicht wird. Erreichbar ist er daher nur vom anderen Container im selben Compose-Netzwerk. Fügen Sie dem postgres-Dienst keinen Eintrag ports: hinzu.

Keiner der beiden Stacks sollte direkt aus dem Internet erreichbar sein. Beide binden an 127.0.0.1. Setzen Sie daher einen Reverse Proxy davor und beenden Sie TLS (Transport Layer Security) dort. Traefik vor mehreren Compose-Anwendungen ist der übliche Weg, sobald Sie mehr als eine Anwendung hosten. Der Grundlagenleitfaden zu Docker Compose behandelt die Teile dieser Dateien, die auf dieser Seite nicht erklärt werden.

Ihr Board ist eine Datenbank. Erstellen Sie daher Sicherungskopien.

Ein Board-Tool kann unbemerkt ausfallen. Ein fehlendes Backup bemerkt niemand, bis ein Volume verloren geht. Eine beschädigte SQLite-Datei lässt sich zunächst normal öffnen und meldet den Fehler erst database disk image is malformed Wochen später.

Kopieren Sie niemals eine aktive SQLite-Datei mit cp. Die Kopie kann einen laufenden Schreibvorgang erfassen. Dadurch sieht das Archiv vollständig aus, lässt sich in eine Datenbank zurückspielen und enthält dennoch fehlende Zeilen. Stoppen Sie den Dienst für die wenigen Sekunden, die der Kopiervorgang dauert:

docker compose stop vikunja
tar czf vikunja-$(date +%F).tgz files
docker compose start vikunja

Erstellen Sie für Planka stattdessen einen Dump der PostgreSQL-Datenbank. Kopieren Sie nicht das Datenverzeichnis eines laufenden Clusters. Sichern Sie das Uploads-Volume separat, weil die Anhänge nicht in der Datenbank gespeichert werden:

docker compose exec -T postgres pg_dump -U postgres -Fc planka > planka-db.dump
docker volume ls
docker run --rm -v planka_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/planka-files.tgz -C /data .

docker volume ls gibt den tatsächlichen Volume-Namen aus. Dieser besteht aus dem Namen Ihres Compose-Projekts gefolgt von _data. Wenn Sie einen nicht vorhandenen Namen übergeben, wird ein leeres Volume erstellt. Sie erhalten dann ohne Fehlermeldung ein gültiges, aber leeres Archiv. Prüfen Sie daher anschließend die Dateigröße.

Stellen Sie das Backup einmal in einem Test-Stack auf demselben Server wieder her. Öffnen Sie anschließend eine Karte, an die Sie sich erinnern. Ein Backup, das Sie noch nie wiederhergestellt haben, ist nur eine Vermutung. Übertragen Sie die Archive zusätzlich vom Server weg. Eine Kopie auf dem VPS, den Sie schützen, ist kein Backup. restic-Backups von einem VPS behandelt diesen Teil.

Zwei Empfehlungen

Zwei Personen auf einem 2-GB-VPS: Betreiben Sie Planka. Optisch und bei der Bedienung kommt es Trello am nächsten. Der Trello-Import erfolgt über eine Datei, die Sie per Drag-and-drop hineinziehen. Mit 280 MB im Leerlauf bleibt der größte Teil der 2 GB für den Reverse Proxy und andere gehostete Dienste frei. Die Community License deckt ein internes Team mit zwei Personen kostenlos ab. Wenn Sie nicht von einer source-available-Lizenz abhängig sein möchten, ist Vikunja mit SQLite und 110 MB die Open-Source-Option für denselben Server.

Zwanzig Personen in einer Organisation: Betreiben Sie Vikunja mit PostgreSQL. Bei dieser Größe benötigen Sie OpenID Connect statt 20 lokaler Passwörter. Sie benötigen Teams und die Freigabe pro Projekt. Außerdem lässt sich ein großer Teil der Arbeit nicht auf einem Board abbilden. Die Ansichten List, Table und Gantt sind daher keine bloße Zusatzfunktion mehr. AGPL-3.0 bedeutet außerdem, dass bei wachsender Teamgröße keine Lizenzdiskussion entsteht. Verwenden Sie PostgreSQL statt SQLite. Betreiben Sie Vikunja hinter einem Reverse Proxy und speichern Sie den täglichen Dump an einem anderen Ort als auf diesem Server.

Wenn der Server über weniger als 1 GB RAM verfügt, trifft keine der beiden Optionen zu. Verwenden Sie Kanboard mit 70 MB. Akzeptieren Sie, dass Sie Ihre Trello-Karten erneut eingeben müssen, und verwenden Sie den eingesparten Speicher für etwas anderes aus der Self-Hosting-Auswahlliste für 2026. Die ausführliche Installation des gewählten Tools gehört in eine eigene Anleitung. Auf dieser Seite geht es nur um die Auswahl.

FAQ

Welche selbst gehostete Trello-Alternative benötigt am wenigsten RAM?

Kanboard benötigt im Leerlauf etwa 70 MB, weil es PHP mit SQLite verwendet und zwischen Anfragen nichts im Speicher hält. Danach folgt Vikunja mit etwa 110 MB als einzelne Go-Binärdatei. Wekan benötigt mit etwa 750 MB am meisten, weil Meteor für jeden verbundenen Browser eine Live-Query-Schicht im Node-Speicher vorhält. Messen Sie den tatsächlichen Verbrauch Ihrer Installation mit docker stats, sobald der Stack im Leerlauf ist. Die Werte sind typische Richtwerte und keine Garantie.

Kann ich meine Trello-Boards in ein selbst gehostetes Tool importieren?

Planka und Wekan können den JSON-Board-Export von Trello direkt importieren. Vikunja importiert über Trello's OAuth-Ablauf. Der Migrator muss zuvor in der Konfiguration aktiviert werden, damit er in der Oberfläche erscheint. Kanboard verfügt über keinen integrierten Importer. Berücksichtigen Sie zwei Einschränkungen: Planka importiert weder Benutzer noch Anhänge und verarbeitet pro Karte nur eine Checkliste. Außerdem bricht Trello's standardmäßiger JSON-Export nach 1,000 Aktionen ab, ohne darauf hinzuweisen, dass die Ausgabe gekürzt wurde.

Ist Focalboard im Jahr 2026 noch eine gute Wahl?

Nein. Die letzte eigenständige Version v8.0.0 stammt aus dem Juni 2024. Das waren 783 Tage, bevor dieser Vergleich am 5. August 2026 geprüft wurde. Die README gibt an, dass das Repository derzeit nicht gepflegt wird. Mattermost setzte die Board-Entwicklung nur als Plugin in einem separaten Repository fort. Der selbst gehostete Server ist daher der Teil, dessen Entwicklung eingestellt wurde. Verwenden Sie stattdessen Planka oder Vikunja.

Ist Planka weiterhin Open Source?

Nicht nach der Definition der OSI. Planka stand zunächst unter der MIT-Lizenz, wechselte 2023 zu AGPL-3.0 und wird ab Version 2.0 unter der PLANKA Community License veröffentlicht. Self-Hosting ist für die private, interne, gemeinnützige und schulische Nutzung kostenlos. Für den Weiterverkauf des Zugriffs oder den Betrieb als Dienst für Dritte ist eine kommerzielle Lizenz erforderlich. Kalenderansicht, Gastrollen und wiederkehrende Karten sind außerdem Bestandteil der Pro-Stufe. Wenn eine von der OSI anerkannte Lizenz zwingend erforderlich ist, steht Vikunja unter AGPL-3.0 und Kanboard unter MIT.

Benötige ich PostgreSQL, oder reicht SQLite aus?

Vikunja, Kanboard und Focalboard verwenden standardmäßig SQLite. Das ist für wenige Personen auf einem Server ausreichend. Planka benötigt PostgreSQL und bietet keine SQLite-Option. Wechseln Sie zu PostgreSQL, sobald mehrere Personen gleichzeitig schreiben, weil SQLite Schreibvorgänge serialisiert und eine ausgelastete Instanz dann database is locked zurückgibt. Legen Sie eine SQLite-Datei außerdem nicht auf einer Netzwerkfreigabe ab. Die Dokumentation von Kanboard warnt aus genau diesem Grund vor SQLite auf NFS.

#kanban#project-management#planka#vikunja#self-hosting#docker