Trello-Alternativen selbst hosten: Tools im Vergleich

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

Drei selbst gehostete Trello-Alternativen sind besonders empfehlenswert: Planka, wenn Sie Trellos Boards und Importdatei unverändert verwenden möchten; Vikunja, sobald ein Team Single Sign-on und mehr als nur ein Board benötigt; und Kanboard, wenn der VPS (virtual private server) wenig Arbeitsspeicher hat. Beginnen Sie kein neues Projekt mit Focalboard. Für den eigenständigen Server wurde seit 783 Tagen kein Release veröffentlicht, und in der README wird inzwischen nach einem Maintainer gesucht.

Wekan ist das fünfte der 5 hier aufgeführten 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 geprüft.

Wie viel RAM benötigt jedes Board-Tool?

[
  {
    "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 Werte im Leerlauf nach einer frischen Installation, wenn niemand das Tool verwendet. Gemeint ist die Größenordnung, die docker stats eine Minute nach dem Start des Stacks meldet. Verwenden Sie diese Werte zur Planung und messen Sie anschließend Ihre eigene Umgebung. Die Größenordnung ist wichtiger als der exakte Megabyte-Wert. Wenn auf derselben VPS auch Ihre Fotosammlung liegen soll, dimensionieren Sie diesen Bereich zuerst. Denn die Mindestwerte in dem Vergleich von PhotoPrism und Immich liegen in einer anderen Größenordnung. Ein Board-Tool passt dann in den verbleibenden Speicher.

Kanboard benötigt 70 MB und bildet damit den unteren Wert, weil es PHP mit SQLite verwendet. Kein langlebiger Anwendungsprozess hält Ihre Boards im Speicher. Deshalb benötigt der Container zwischen Anfragen im Leerlauf fast keinen Speicher. Vikunja ist eine einzelne Go-Binärdatei und benötigt 110 MB. 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. Planka unterstützt SQLite nicht. Die Datenbank ist daher nicht optional.

Wekan benötigt 750 MB, weil es eine Meteor-Anwendung ist. Meteor hält eine Live-Query-Schicht im Node-Speicher und überträgt jede Änderung an einem Board über einen WebSocket an jeden geöffneten Browser. Der Speicherbedarf steigt daher mit der Zahl der verbundenen Personen, statt konstant zu bleiben. Auf einer VPS mit 1 GB startet Wekan zunächst. Sobald einige Personen ein großes Board öffnen, wird der Prozess beendet. Das zeigt sich an einem Container, der mit Exit-Code 137 verschwindet und wieder startet. docker compose ps zeigt dies als Neustartschleife an. Bestätigen Sie die Ursache auf dem Host mit dmesg -T | grep -i "out of memory". Der Out-of-Memory-Killer des Kernels informiert die Anwendung darüber nicht.

Die Datenbankabhängigkeit bestimmt einen großen Teil Ihres Backup-Aufwands. Hier ist die Übersicht in jeweils 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 spricht das MongoDB-Wire-Protokoll. Die standardmäßige Compose-Datei enthält inzwischen FerretDB v1 mit einem eingebetteten SQLite-Backend anstelle eines echten MongoDB-Servers. Wenn Sie einen echten MongoDB-Server verwenden möchten, gibt es eine separate Compose-Datei für MongoDB 7.

Welche dieser Projekte werden noch gepflegt?

[
  {
    "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 vom Juni 2024. Mattermost hat die Entwicklung der Boards in ein Plugin in einem separaten Repository verlagert. In der README der eigenständigen Version steht, dass das Repository derzeit nicht gepflegt wird. Das ist in diesem Vergleich das eindeutige „Nein“. Bei allen anderen Projekten müssen Sie abwägen.

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 vom April 2026. Kanboard hat v1.2.53 12 Tage vor der Prüfung veröffentlicht. Die beiden vorherigen Versionen erschienen im März und April 2026.

Vikunja und Wekan haben beide innerhalb eines Tages vor der Prüfung eine Version veröffentlicht. Diese beiden Fakten sollten Sie unterschiedlich bewerten. Vikunja hat v2.5.0 als reguläre Minor-Version veröffentlicht. Wekan hat v10.65, v10.66 und v10.67 am selben Tag veröffentlicht. 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 das Tag und lesen Sie vor jeder Aktualisierung die Versionshinweise.

Erhalten Sie mehr als ein Board?

Die meisten Vergleichsartikel beschränken sich auf die Aussage: „Es sieht aus wie Trello.“ Dieser Punkt ist wichtiger als der RAM, denn ein Board eignet sich schlecht für alles, was eine Frist hat.

• 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 Arbeit, Unteraufgaben, Anhängen, Kommentaren, automatischen Aktionen und einer kleinen Abfragesprache zum Filtern. Auf der eigenen Homepage heißt es: „Die Anzahl der Funktionen ist freiwillig begrenzt.“ Das ist eine zutreffende Beschreibung.
• 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. Der Vollständigkeit halber ist es hier aufgeführt.

Wenn Sie tatsächlich ein Wiki mit angehängter Aufgabenverwaltung benötigen, ist dies der falsche Vergleich. BookStack, Wiki.js und Outline behandelt diese Struktur, und 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 kommentieren sie daher aus, statt ein Upgrade durchzufü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 es Teams und die Freigabe auf Projektebene. Genau das benötigt eine Organisation mit zwanzig Personen in der Praxis.

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

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 beendet, ohne auf die Kürzung hinzuweisen. Prüfen Sie die Datei selbst, bevor Sie dem Ergebnis vertrauen.

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

Wekan akzeptiert in seinem 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-Historie übertragen müssen.

Wie ist die mobile Nutzung?

Vikunja ist das einzige der fünf Projekte mit offiziellen mobilen Apps. Android- und iOS-Versionen werden zusammen mit jeder Veröffentlichung bereitgestellt. Das Repository der App bezeichnet sich selbst als Alpha-Version. Betrachten Sie die App daher als Ergänzung zur Weboberfläche und nicht als primären Zugangsweg. Für Planka gibt es 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 Desktop-Bildschirm 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 startete unter der MIT-Lizenz, wechselte 2023 zu AGPL-3.0 und wird seit der 2.0-Reihe unter der PLANKA Community License veröffentlicht, einer Fair-Code-Lizenz von PLANKA Software GmbH. GitHub führt die Lizenz als „Other“, weil sie nicht von der OSI anerkannt ist. Das Self-Hosting für die eigenen Nutzer ist kostenlos und ausdrücklich erlaubt. Dies umfasst die private, interne, gemeinnützige und pädagogische Nutzung. Für den Weiterverkauf des Zugangs oder den Betrieb als Dienst für andere Unternehmen ist eine kommerzielle Lizenz erforderlich.

Für zwei Personen ist das ein angemessenes Modell. Für ein Unternehmen ist es eine Lizenzbedingung, die geprüft werden sollte, bevor die Arbeit von zwanzig Personen darin steckt. Die anderen vier Projekte sind gewöhnliche Open-Source-Projekte: Vikunja steht unter AGPL-3.0, Wekan und Kanboard unter MIT, und Focalboard verwendet eine Kombination aus Apache 2.0 und AGPL-3.0.

Compose-Dateien für die beiden Empfehlungen mit festem Image-Tag

Verwenden Sie ein festes Image-Tag. latest bedeutet, dass Sie mit dem nächsten docker compose pull auf eine andere Hauptversion wechseln können. Hauptversionen führen Datenbankmigrationen durch, die sich nicht einfach rückgängig machen lassen. Die beiden Dateien unten entsprechen den Upstream-Dateien, verwenden aber ein festes Tag für ein tatsächlich veröffentlichtes Release.

Vikunja mit SQLite in einem 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 fehlerfreier Stack zeigt den Dienst als running an. Der Info-Endpunkt liefert JSON, 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 in zwei Containern:

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 deshalb sicher, weil der Datenbankport nicht auf dem Host veröffentlicht wird. Erreichbar ist der Port daher ausschließlich für den 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 die übliche Vorgehensweise, sobald Sie mehr als eine Anwendung hosten. Der Docker-Compose-Grundlagenleitfaden erklärt die Teile dieser Dateien, die diese Seite auslässt.

Ihr Board-Tool ist eine Datenbank, also erstellen Sie Backups

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

Kopieren Sie niemals eine aktive SQLite-Datei mit cp. Die Kopie kann einen laufenden Schreibvorgang erfassen. Dadurch wirkt das Archiv vollständig, stellt aber eine Datenbank mit fehlenden Zeilen wieder her. 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 PostgreSQL-Dump. Kopieren Sie nicht das Datenverzeichnis eines laufenden Clusters. Sichern Sie das Uploads-Volume separat, weil sich Anhänge nicht in der Datenbank befinden:

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 deshalb anschließend die Dateigröße.

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

Zwei Empfehlungen

Für zwei Personen auf einem 2-GB-VPS: Planka. Optisch und funktional kommt es Trello am nächsten. Der Trello-Import besteht aus einer Datei, die Sie per Drag-and-drop hinzufügen. Mit 280 MB im Leerlauf bleibt der größte Teil der 2 GB für den Reverse Proxy und weitere 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.

Für 20 Personen in einer Organisation: 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. Ein großer Teil der Arbeit passt außerdem nicht auf ein Board. 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 Lizenzfrage entsteht. Verwenden Sie PostgreSQL statt SQLite, betreiben Sie Vikunja hinter einem Reverse Proxy und speichern Sie den täglichen Dump auf einem anderen Server.

Wenn der Server über weniger als 1 GB RAM verfügt, trifft keine der beiden Antworten zu. Wählen Sie Kanboard mit 70 MB, akzeptieren Sie, dass Sie Ihre Trello-Karten neu eingeben müssen, und verwenden Sie den eingesparten Speicher für etwas anderes aus der Self-Hosting-Auswahlliste für 2026. Wenn auf dem Server bereits Jellyfin läuft, baut Halcyon die Bibliothek als begehbare Videothek der 90er-Jahre neu auf. Das ist ein unterhaltsamerer Dienst als ein zweites Board-Tool. 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 ungefähr 70 MB, weil es PHP mit SQLite verwendet und zwischen Anfragen nichts im Arbeitsspeicher hält. Danach folgt Vikunja mit etwa 110 MB als einzelnes Go-Binary. Wekan benötigt mit ungefähr 750 MB am meisten, weil Meteor für jeden verbundenen Browser eine Live-Query-Schicht im Node-Speicher hält. Messen Sie den eigenen Verbrauch mit docker stats, sobald der Stack im Leerlauf ist. Die Werte sind typische Richtwerte und keine Zusicherung.

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

Planka und Wekan übernehmen den JSON-Board-Export von Trello direkt. Vikunja importiert über den OAuth-Ablauf von Trello. Der Migrator muss in der Konfiguration aktiviert werden, bevor er in der Oberfläche erscheint. Kanboard verfügt über keinen integrierten Importer. Planen Sie zwei Einschränkungen ein: Planka importiert weder Benutzer noch Anhänge und verarbeitet pro Karte nur eine Checkliste. Außerdem bricht Trellos standardmäßiger JSON-Export bei 1,000 Aktionen ab, ohne Sie darauf hinzuweisen, dass er gekürzt wurde.

Ist Focalboard 2026 noch eine gute Wahl?

Nein. Das letzte eigenständige Release, v8.0.0, stammt aus dem Juni 2024. Zum Zeitpunkt der Prüfung dieses Vergleichs am 5. August 2026 lag es 783 Tage zurück. Die README weist darauf hin, dass das Repository derzeit nicht gepflegt wird. Mattermost setzte die Entwicklung von Boards nur noch als Plugin in einem separaten Repository fort. Der Server, den Sie selbst hosten würden, wurde daher nicht weiterentwickelt. Verwenden Sie stattdessen Planka oder Vikunja.

Ist Planka weiterhin Open Source?

Nicht nach der Definition der OSI. Planka stand zunächst unter MIT, wechselte 2023 zu AGPL-3.0 und wird ab Version 2.0 unter der PLANKA Community License veröffentlicht. Für die persönliche, interne, gemeinnützige und schulische Nutzung ist das Self-Hosting kostenlos. Der Weiterverkauf des Zugriffs oder der Betrieb als Dienst für Dritte erfordert eine kommerzielle Lizenz. Die Kalenderansicht, Gastrollen und wiederkehrenden Karten sind hinter der Pro-Stufe verfügbar. 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 eine kleine Anzahl von 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 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.