Zum Inhalt springen
Kanban Everything

Ein Board für die Arbeit und alles andere.

Kanban Everything hält die ganze Liste: das Release, das du ausliefern willst, und den Wasserhahn, der getauscht werden muss. Projekte verschachteln sich, Tags bleiben flach, und eine gespeicherte Ansicht verkleinert das Board auf das, worum es heute Nachmittag geht. Es läuft auf einem Server, der dir gehört – ein Container, eine SQLite-Datei.

Selbst betreiben Quellcode lesen

FastAPI und Vue · Docker Compose · keine gehostete Version, keine Anmeldung, keine Telemetrie

Das Board von Kanban Everything mit fünf Spalten – Backlog, Zu tun, In Arbeit, Wartet, Fertig – mit Aufgaben aus Arbeit und Privatleben
Ein Board, zwei Leben: Release Notes und die Zählerstandsmeldung an den Vermieter im selben Workflow. Die Farben auf den Karten sind Projekte, die Pillen rechts sind Prioritäten.

Ein Board – nicht eines pro Projekt.

Projekte verschachteln sich. work › website › launch ist ein Pfad, keine drei Boards. Filtere auf ein Projekt, und du nimmst optional seinen ganzen Unterbaum mit. Eine Aufgabe darf in mehreren Projekten liegen: die Release Notes gehören zu website und zu launch, ohne kopiert zu werden.

Tags bleiben flach. Beliebig viele pro Aufgabe, unabhängig von Projekten, getroffen als „eines davon“ oder „alle davon“. Benenne eines um, und jede Aufgabe zieht mit.

Ansichten merken sich die Kombination. Projekte, Tags, Prioritäten, den Suchtext und welche Spalten in welcher Reihenfolge sichtbar sind – gespeichert unter einem Namen, den du wählst, umgeschaltet mit einem Klick. Eine Ansicht ändert keine Aufgabe; sie entscheidet nur, worauf du schaust.

Die Suche liest die ganze Aufgabe. Titel, Beschreibungen, Kommentare, Projekt- und Tag-Namen, Link-Labels und URLs – gefiltert, während du tippst, zusätzlich zu allem, was ohnehin schon gefiltert ist.

Das Filter-Panel mit dem verschachtelten Projektbaum, Tag-Chips und Prioritäten
Der Filter: der Projektbaum mit seiner Einrückung, Tags, Prioritäten. Anwenden – und als Ansicht speichern.

Eine Aufgabe, keine Zeile in einer Liste.

Öffne eine Karte, und du bekommst ein Dokument: Markdown mit lebendiger Vorschau, Checkboxen, die sich wirklich abhaken lassen, und Bilder, die zur Aufgabe gehören – beim Speichern, nie beim Einfügen, damit nichts nur deshalb liegen bleibt, weil du es zufällig kopiert hast.

Kommentare sind ebenfalls Markdown und bearbeitbar. Links, die an einem Projekt hängen, erscheinen an jeder Aufgabe darin, nach URL entdoppelt: das Runbook ist aus allem in api einen Klick entfernt, ohne in fünfzehn Karten zu kleben.

Es gibt keinen Speichern-Knopf. Schließen behält den geänderten Entwurf; das Rückgängig ist das Abbrechen. Und eine Aufgabe, die niemand anfassen soll, lässt sich sperren: jeder Schreibzugriff kommt mit Begründung zurück, bis du sie entsperrst.

Eine geöffnete Aufgabe mit Beschreibung und Checkliste, zwei Kommentaren und der Detailspalte mit Status, Priorität, Projekten, Tags und Fälligkeit
TASK-8, mitten in Arbeit: zwei von vier Checklistenpunkten erledigt, zwei Kommentare, rechts die Details.

Nichts passiert unprotokolliert.

Jede Änderung wird in derselben Transaktion in ein dauerhaftes Event-Log geschrieben wie die Änderung selbst. Was fehlschlägt, hinterlässt weder Daten noch eine Spur von sich, und eine Handlung von dir ist eine Operation: das Löschen einer Spalte, in der noch Arbeit lag, protokolliert die Löschung und jede verschobene Aufgabe als einen Eintrag, den du später lesen kannst.

Undo liegt auf dem Server. Seite neu laden, morgen wiederkommen, an einem anderen Rechner sitzen: der Stapel ist noch da. Sind mehrere Leute auf dem Board, machst du deine eigenen Operationen rückgängig – und eine, die inzwischen überholt wurde, wird abgelehnt statt durchgedrückt.

Du kannst eine einzelne alte Sache zurücknehmen. Wähle eine Operation von letztem Dienstag und nimm nur diese zurück, ohne alles Spätere aufzurollen. Bei einzelnen Aufgaben geht es weiter: lies eine so, wie sie zu einem beliebigen Zeitpunkt war, und stelle diesen Stand als ganz normale neue Änderung wieder her.

Löschen ist die Ausnahme – der einzige unumkehrbare Schritt. Es räumt die Aufgabe leer und schwärzt ihre Historie: ids, Zeitstempel und Feldnamen bleiben, der Inhalt nicht, an keinem Punkt der Zeitleiste. Archivieren, was du meistens willst, behält alles.

Die Verlaufsleiste mit Operationen – Undo, Archivieren, Sperren, Verschieben, eine angelegte Spalte – von denen eine in ihre vier Events ausgeklappt ist
Der Verlauf, gefiltert oder nicht. Der ausgeklappte Eintrag ist eine Operation aus vier Events; der Pfeil rechts nimmt sie zurück.

Geteilt mit Absicht, nie aus Versehen.

Allein betrieben bleibt es ein privates Board – du verschickst einfach nie eine Einladung. Kommen Leute dazu, ändern sich deine eigenen Aufgaben nicht: jemand sieht ein Projekt oder eine einzelne Aufgabe, weil du sie freigegeben hast, als Lesen, Kommentieren oder Schreiben. Freigaben auf einem Projekt fließen den Unterbaum hinunter, die stärkste gewinnt, und der Zugriff wird pro Anfrage berechnet – ein Entziehen wirkt beim nächsten Klick.

Personen werden über die E-Mail-Adresse benannt, mit der sie sich anmelden; Teilen braucht also kein Benutzerverzeichnis. Passwörter sind argon2id-Hashes, Sessions sind widerrufbare Zeilen, und Registrierung geht nur auf Einladung: der erste Administrator kommt beim ersten Start aus der Umgebung, alle anderen folgen einem einmalig gültigen Link, der abläuft. Ein Mailserver ist an keiner Stelle beteiligt.

Was du nicht sehen darfst, kannst du auch nicht erschließen. Eine mit dir geteilte Aufgabe kann in Projekten liegen, auf die du keinen Zugriff hast – die erscheinen als Zahl, +2 privat, nie als Name. Administratoren verwalten Accounts, Spalten und Tags; eine Hintertür zu den Aufgaben anderer haben sie nicht. Skripte bekommen eigene API-Tokens pro Person, mit genau deren Rechten.

Der Freigabe-Dialog einer Aufgabe, der eine Kollegin mit Kommentarrecht auflistet
Eine Aufgabe, für eine Kollegin freigegeben, mit Kommentarrecht. Denselben Dialog gibt es für ein Projekt samt Unterbaum.

Das Board ist ein Client seiner eigenen API.

Nichts in der Oberfläche hat eine geheime Abkürzung in die Datenbank. Jede Fähigkeit ist zuerst ein HTTP-Endpunkt, versioniert unter /api/v1, dokumentiert per generiertem OpenAPI und offen für alles, was ein Token hat – ein Skript, ein Cronjob, eine Kurzbefehl-Verknüpfung auf dem Handy.

Ein GET /board liefert alles, was eine Darstellung braucht. Fehler kommen als problem+json mit stabilen Codes, ein Skript kann also auf task_locked verzweigen statt einen Satz zu parsen, und ein Schreibzugriff auf veralteter Grundlage wird abgelehnt statt stillschweigend zu gewinnen. Der Echtzeit-Kanal ist dasselbe Event-Log über einen WebSocket, fortsetzbar da, wo ein Client stehen geblieben ist.

Die Swagger UI liegt unter /api/v1/docs – in Produktion hinter Authentifizierung und außer Reichweite von Crawlern.

shell
# Aufgabe von überall anlegen, mit einem Token
curl -X POST https://kanban.example.com/api/v1/tasks \
  -H "Authorization: Bearer $KANBAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title": "Domain verlängern",
       "priority": "high",
       "due_date": "2026-08-14"}'

# 201 Created – und jedes offene Board zeigt es
# innerhalb der Sekunde, über den WebSocket.

Dunkel, wenn du willst. Brauchbar auf dem Handy.

Dasselbe Board, dieselben Daten, zwei Themes und jede Breite. Auf schmalen Schirmen klappen Spalten zu einer Leiste zusammen und nehmen trotzdem eine gezogene Karte an.

Dasselbe Board im dunklen Theme der Anwendung
Das dunkle Theme – ein echtes Theme, kein invertierender Filter.
Das Board auf einem handybreiten Schirm
430 Pixel breit, im Handy-Browser.

Selbst betreiben

Docker mit Compose v2.24 oder neuer, auf allem, was du erreichst: ein NAS, ein VPS, der Rechner unter dem Schreibtisch. Python und Node brauchst du nur, wenn du daran arbeiten willst.

Starten

Klonen, die Beispiel-Umgebung kopieren, hochfahren. Migrationen laufen von selbst. Setz den ersten Administrator in .env, bevor du das erste Mal startest – diese Variablen werden nur gelesen, solange es noch keinen Account gibt.

shell
git clone \
  https://github.com/Andreas-Menzel/kanban-everything
cd kanban-everything
cp .env.example .env
docker compose up -d --build
# http://localhost:8080

Auf eine Domain stellen

Ein Overlay hängt die App an einen Traefik, den du schon betreibst – womit TLS, Zertifikate und HSTS dort bleiben, wo sie hingehören. Die App veröffentlicht dann überhaupt keine Host-Ports und ist nur über den Proxy erreichbar.

shell
docker compose -f compose.yaml \
  -f compose.traefik.yaml up -d --build

Sichern – und wissen, dass es geklappt hat

Die Datenbank läuft im WAL-Modus: die Datei zu kopieren, während die App läuft, ist kein Backup – aktuelle Commits liegen in einer Sidecar-Datei, und eine Kopie kann eine halb geschriebene Seite erwischen. Zieh stattdessen einen Snapshot; er führt VACUUM INTO aus und prüft das Ergebnis, bevor er es dir gibt.

shell
docker compose exec -T app \
  python -m app.backup /tmp/snapshot.db

Und dann wie einen Dienst behandeln

Im Repository liegen Host-Skripte, die aus diesem Snapshot einen stündlichen, verschlüsselten restic-Job mit Aufbewahrung machen, und ein Deployment, das vorher sichert, damit eine schlechte Migration zurückgerollt werden kann. Das Betriebshandbuch deckt Deployment, Rollback, Restore, Desasterfall und einen wöchentlichen Nur-Lese-Check ab – geschrieben, um ihm um zwei Uhr nachts zu folgen.

Betriebshandbuch Alle Einstellungen, dokumentiert Architektur und Entscheidungen

Was es nicht ist

Eine kurze Liste, denn ein Werkzeug, das alles zu können behauptet, kann meistens nichts davon richtig:

  • Kein Dienst. Es gibt nichts, wofür man sich anmeldet; wenn du es nicht betreibst, existiert es für dich nicht.
  • Noch keine Importer. Trello, Jira und CSV werden nicht unterstützt. Die Synchronisation mit GitHub- und GitLab-Issues ist im Repository vollständig spezifiziert und der nächste große Arbeitsblock – gebaut ist sie nicht.
  • Keine native App. Die Weboberfläche passt sich dem Handy an, und die API liegt bereit, wenn du lieber etwas baust.
  • Bewusst nicht vorhanden: WIP-Limits, Swimlanes, wiederkehrende Aufgaben, Erinnerungen und Benachrichtigungen, Anhänge außer Bildern, Volltextsuche. Jedes davon ist eine aufgeschriebene Entscheidung, kein Versehen – und bleibt draußen, bis etwas es wirklich braucht.

Warum es das gibt

Ich wollte ein Board für alles, was ich zu tun habe, auf meiner eigenen Maschine, wo eine letzten Monat archivierte Aufgabe noch da ist und eine versehentliche Änderung zurückgenommen werden kann. Alles auf dieser Seite liegt heute im Repository, und das Design-Dokument dort ist ehrlich in Bezug auf die Teile, die es nicht gibt.

Es entsteht in meiner Freizeit und ist kostenlos. Wenn es am Ende deine Woche organisiert, ist ein Kaffee eine schöne Art, das zu sagen.

Auf GitHub holen Kaffee spendieren

Fragen, die gestellt werden

Gibt es eine gehostete Version?
Nein. Du betreibst den Container, die Daten liegen auf deiner Platte. Kein Mandant, keine Telemetrie, nichts zu kündigen.
Lohnt sich das für eine einzelne Person?
Genau da hat es angefangen, und das ist noch der Normalfall: ein Account, ein Board, Arbeit und Privates nebeneinander. Accounts und Freigaben kamen später und halten sich raus, bis du jemanden einlädst.
Wo genau liegen meine Daten?
In einer SQLite-Datei auf einem Named Docker Volume, unter /data/kanban.db. In eine Aufgabe eingefügte Bilder liegen als Blobs in derselben Datei – ein Snapshot ist also wirklich das ganze Board, Anhänge inklusive.
Wie sichere ich es, und wie bekomme ich es zurück?
Nicht durch Kopieren der laufenden Datei – im WAL-Modus kann das aktuelle Commits verpassen oder eine halb geschriebene Seite erwischen. Nutze den Snapshot-Befehl, der VACUUM INTO ausführt und die Kopie danach verifiziert. Das Zurückspielen ist eine dokumentierte Prozedur und keine Dateikopie, weil das Volume root gehört und der Container nicht; im Betriebshandbuch steht sie Schritt für Schritt.
Kann ich es ins Internet stellen?
Ja, hinter einem Reverse Proxy, den du schon betreibst. Zwei Einstellungen sind wichtig: welches Proxy-Subnetz Forwarded-Header setzen darf, damit das Login-Ratelimit echte Client-Adressen sieht und nicht einen geteilten Eimer, und deine öffentliche Origin, denn sie speist die WebSocket-Origin-Prüfung. Beides ist in .env.example dokumentiert, die Begründung in einem Decision Record.
Kann ein kleines Team damit arbeiten?
Ja – Accounts, Freigaben pro Projekt und pro Aufgabe, Undo pro Person, ein Verlauf mit Namen und Echtzeit-Updates, gefiltert auf das, was jede Person sehen darf. Für hundert Leute ist es nicht gebaut: eine SQLite-Datei, ein Schreiber, Registrierung nur auf Einladung. Eine Handvoll Kolleginnen und Kollegen ist der Entwurfspunkt.
Wie fertig ist es?
Es wird vom Autor täglich benutzt und weiter aktiv entwickelt. Alles, was hier gezeigt wird, funktioniert heute; „Was es nicht ist“ oben sagt, was nicht. Nichts gilt als fertig, bevor Linting, strenge Typprüfung und beide Testsuiten durchlaufen – die Teile, die es gibt, sollen sich also benehmen.
Was kostet es?
Nichts, und es wartet keine Bezahlversion hinter einer Funktion. Die einzigen Kosten sind die Maschine, auf der du es betreibst.