Kanboard: a self-hosted Kanban board in maintenance mode

What Kanboard solves, and who it is actually for

Kanboard is project management software that focuses on the Kanban methodology, as the README's first line puts it. That sentence is also the design brief. Work items are cards, cards live in columns, columns live in a board, and the board is the primary interface rather than a view on top of a ticketing database. If you have used a spreadsheet with a status column and hated it, this is the same idea with drag-and-drop and a database underneath.

The audience is narrow and specific. It suits a team that already owns a server, wants the board on its own hardware, and does not want to pay per seat. The MIT licence removes the commercial question entirely. It also suits people who want the board to be a single PHP application with a single database, not a Node service plus a queue plus a websocket layer.

It does not suit people who want an all-in-one tool. There is no sprint planning engine, no Gantt chart, no time-tracking product, no wiki. Those exist as separate Kanboard plugins or not at all. The README points to a list of features on kanboard.org rather than describing them inline, so the honest summary is: boards, cards, columns, swimlanes, and whatever the plugin ecosystem adds.

How Kanboard is put together: PHP, a schema directory, and three databases

The repository layout tells you most of the architecture before you read any documentation. There is an app/ directory, a libs/ directory, a vendor/ directory from Composer, a cli entry point, an index.php front controller and a jsonrpc.php endpoint. That is a conventional PHP web application: nginx or Apache serves index.php, PHP-FPM executes it, and the application talks to a database.

The database layer is the interesting part. The Makefile contains targets for test-sqlite, test-mysql and test-postgres, each pointing at a separate PHPUnit configuration under tests/. There are three matching compose files at the repository root: docker-compose.sqlite.yml, docker-compose.mysql.yml and docker-compose.postgres.yml. Schema files live under app/Schema/Sql/. The Makefile's sql target regenerates those schema files by dumping a live PostgreSQL and MySQL database, including a default admin user whose password hash is generated with PHP's password_hash function.

That means SQLite is a first-class deployment target, not a toy fallback. For a single team on one server, a file-backed database removes an entire moving part. The trade-off is real: the schema files are maintained per engine, so behaviour and migration paths are not guaranteed to be identical across the three. If you pick MySQL, you are on the path the Makefile's mysqldump commands exercise most directly.

There is also a jsonrpc.php file at the root, which is the API surface. The README does not document the API inline; it links to docs.kanboard.org. The related searches show people looking for a Kanboard API, so it exists, but treat the linked documentation as the source of truth for method names rather than guessing.

Installing Kanboard with Docker and getting a first board

The README does not include installation steps. It links to the official documentation at docs.kanboard.org, specifically the installation, requirements, upgrade and Docker pages. So the commands below come from the repository's own Dockerfile and compose files, not from a tutorial in the README.

The Dockerfile is built on alpine:3.24 and installs PHP 8.4 with the extensions Kanboard needs: pdo, pdo_mysql, pdo_sqlite, pdo_pgsql, mbstring, gd, ldap and others. It declares three volumes: /var/www/app/data, /var/www/app/plugins and /etc/nginx/ssl. It exposes ports 80 and 443. The container runs nginx and PHP-FPM under s6, and the entrypoint is /usr/local/bin/entrypoint.sh.

The repository ships three compose files, one per database. This is the SQLite one, which is the least setup:

docker compose -f docker-compose.sqlite.yml up -d

After the container starts, the Dockerfile's healthcheck runs curl against the healthcheck.php script on localhost. You can check the same endpoint yourself from the host, substituting whatever port your compose file publishes:

curl -f http://localhost/healthcheck.php

If that returns successfully, the application is serving. The two volumes that matter for persistence are /var/www/app/data (which holds the SQLite database file and uploaded files) and /var/www/app/plugins. Mount them to host paths or named volumes; if you do not, a container recreation takes your board with it.

For a MySQL or PostgreSQL deployment, use the corresponding file instead:

docker compose -f docker-compose.mysql.yml up -d

The Makefile also shows how the project builds and runs its own image, which is useful if you want to pin a version rather than track main:

make docker-image
make docker-run

The Makefile sets DOCKER_IMAGE to docker.io/kanboard/kanboard and DOCKER_TAG to main, and derives VERSION from git rev-parse --short HEAD, writing it into app/version.txt during the image build. If you build your own image, that version string is whatever short commit hash you built from.

Maintenance mode is the constraint that matters most

The README states plainly that the application is in maintenance mode, and then quotes Wikipedia's definition of the term. It then lists what that means in practice: the author is not actively developing any new major features, only small fixes; new releases are published regularly depending on contributions from the community; and pull requests for new features and bug fixes are accepted as long as the guidelines in .github/pull_request_template.md are followed.

Read that carefully, because it is more nuanced than either "abandoned" or "actively developed". The repository is not archived. The last push was on 2026-08-29, which is recent, and the release history shows v1.2.54 on 2026-08-29, v1.2.53 on 2026-07-24 and v1.2.52 on 2026-04-05. Releases are still happening. What has stopped is the author's own feature roadmap.

The practical consequence is a split in how you should evaluate risk. Security fixes and small bugs have a plausible path to being merged, because the README says bug fixes are accepted. A feature you need that does not exist has a much weaker path: you either write it as a plugin, or you maintain a fork, or you pick different software. Anyone adopting Kanboard on the assumption that upstream will grow into their requirements is making a bet the README explicitly warns against.

A second, quieter constraint is PHP 8.4 in the Dockerfile. The image pins a specific Alpine and PHP generation. When Alpine 3.24 and PHP 8.4 reach end of life, the Dockerfile has to be updated by someone. In maintenance mode, that someone is a contributor, not a paid maintainer.

Where Kanboard is the wrong choice, and what to use instead

The clearest wrong-choice case is a team that wants one tool for boards plus issue tracking plus roadmaps. Kanboard is a board. If your workflow depends on sprints with velocity, epics with hierarchies, or a Gantt view, you will spend your time wiring plugins together, and the maintenance-mode statement means the upstream author will not close that gap for you. OpenProject is the alternative in that space: it is a full project management suite rather than a Kanban-first board, so the difference is not a feature list but the shape of the product. You trade a small PHP application for a considerably larger stack, and you gain the planning features Kanboard deliberately does not have.

The second case is a team that wants a modern single-page interface with real-time collaboration. Planka and Wekan both occupy the self-hosted Kanban niche, and both are built around a JavaScript stack rather than server-rendered PHP. The practical difference is the deployment shape: Kanboard is a PHP-FPM application you can drop behind any web server, with SQLite as a legitimate option. Planka and Wekan bring their own runtime assumptions. If your operations team is a PHP shop with existing tooling, Kanboard's stack is the smaller commitment; if your team lives in Node, the reverse is true.

Vikunja is the third comparison point that shows up in search data. It is a self-hosted task manager that also offers Kanban views, which is the inverse emphasis: tasks first, board as one view among several. If your work is genuinely list-shaped and the board is a nice-to-have, Vikunja's model fits better than Kanboard's board-first model.

Finally, Trello. The honest comparison is not features, it is control. Trello is hosted and you do not run it. Kanboard is software you install, back up and upgrade, and the README's maintenance-mode section is part of that bargain.

Licence, upgrades and what maintenance actually costs you

Kanboard is distributed under the MIT License, per the README's credits section, and the Dockerfile carries the matching org.opencontainers.image.licenses="MIT" label. MIT is permissive: you can use it commercially, modify it and redistribute it, provided the licence and copyright notice are preserved. That is a statement about the licence text, not legal advice for your situation; if you are embedding Kanboard in a product you sell, have someone qualified read the LICENSE file in the repository.

The licence has a second-order effect worth naming. Because there is no commercial entity with a revenue interest in Kanboard's roadmap, there is also no commercial pressure to keep the upgrade path smooth. The README links to docs.kanboard.org/v1/admin/upgrade/ for upgrade instructions, which is where the actual procedure lives. The README itself does not document rollback, and there is no migration tooling described in the repository beyond the schema files under app/Schema/Sql/ that the Makefile regenerates.

Upgrade cost therefore has two components. The first is the routine version bump: pull the new image, restart, and let the application apply schema changes. The second is the one nobody plans for, which is the Alpine and PHP version bump when the base image goes stale. The Dockerfile currently targets alpine:3.24 and php84 packages. That is a maintenance task with no product-visible payoff, and it is exactly the kind of task that stalls in a project whose author has stepped back from major work.

On a practical note, the compose files give you a cheap way to rehearse. Bring up docker-compose.sqlite.yml with a copy of your data volume, run the upgrade there, and see what happens before you touch production. That is not a documented procedure; it is what the repository's own files make possible.

Editorial conclusion

Adopt Kanboard if you want a small, MIT-licensed, self-hosted Kanban board with SQLite or MySQL or PostgreSQL behind it and you accept that the README calls the project maintenance mode: the author is not developing new major features, and releases depend on community contributions. Do not adopt it if your roadmap needs large new capabilities shipped by the upstream author, or if you want a board that doubles as an issue tracker with sprints and Gantt planning. Before committing, verify these four things in your own environment: that the Docker image's /var/www/app/data volume is writable and persisted, that the healthcheck endpoint responds on your reverse proxy, that your chosen database driver is the one you actually intend to back up, and that the plugins you need are still installable from the plugins directory. The last push was on 2026-08-29, so the repository is not abandoned; it is simply no longer growing in the way a product under active feature development would.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes