Kanboard 1.2.54: A Maintenance-Mode Kanban Tool That Still Ships Regularly
Kanban project management software. Kanboard ======== Kanboard is project management software that focuses on the Kanban methodology.
At a glance
- What is it?
- Kanboard is a PHP-based Kanban project management tool now in maintenance mode. It remains useful for teams that want a self-hosted, MIT-licensed board without a subscription, but its feature set is frozen.
- Who is it for?
- Adopt Kanboard if you need a simple, self-hosted Kanban board with an MIT license and you are comfortable with a feature set that will not grow. Do not adopt it if you expect new major features or a vendor-backed roadmap.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Kanboard Actually Solves
Kanboard solves a narrow problem: giving a team a Kanban board that runs on its own infrastructure. It is not a full project management suite with Gantt charts, resource planning, or time tracking built in. The README is blunt about its scope. It is project management software that focuses on the Kanban methodology. That focus is the product. For a team that already works with sticky notes on a wall and wants a digital equivalent without sending data to a SaaS vendor, Kanboard fits. It is also for teams that need a board they can modify, because the source is open and the license is permissive.
Maintenance Mode Is the Core Design Decision
The README states plainly that the application is in maintenance mode. The author is not actively developing new major features, only small fixes. Releases still arrive regularly, as the 2026 dates show, but they are fixes and community contributions, not innovation. This is a trade-off. You get a stable, predictable tool. You do not get new capabilities. The README even quotes Wikipedia to define maintenance mode, which is an unusual level of honesty for a project. Most projects hide this. Kanboard puts it at the top. That clarity is useful for an engineer evaluating adoption, because it sets expectations before you write any configuration.
How Kanboard Works Under the Hood
Kanboard is written in PHP and follows a classic server-rendered web application pattern. There is no separate frontend framework or API-first design visible in the material. The repository layout shows a standard PHP application with a public entry point, application code, and tests. The data flow is simple: the browser requests a page, the PHP backend renders the board, and user actions like moving a card trigger server-side updates. The documentation mentions requirements and installation instructions, but the README does not detail the database layer or the exact request cycle. Based on the repository, it is a monolithic application, not a microservice. That simplicity is a feature for small teams but a limit for large ones.
Getting Kanboard Running
The README points to official documentation for requirements and installation, but it does not list the commands directly. The docs cover a Docker setup, which is the easiest path. You would pull the Kanboard image and run it with a volume for data persistence. The exact command is not in the README, so you must consult the documentation. The upgrade section exists, which means there is a defined path from one version to the next. The release notes for v1.2.54 would tell you what changed, but the README does not enumerate them. For a PHP shop, a manual install on a web server with PHP and a database is also possible, but the README does not give the steps. Treat the docs as the source of truth for configuration keys and environment variables.
A Real Limitation: No New Features, Ever
The biggest limitation is the maintenance mode itself. If your team needs a new integration, a different board view, or a change to the core workflow, you will not get it from the project. The author only accepts small fixes. Pull requests for new features are accepted only if they follow the guidelines, but the README says the author is not actively developing new major features. That means the community must do the work, and the maintainer may reject or ignore it. For a team that needs a specific feature, this is the wrong tool. The alternative is to fork the code and maintain your own version, which is a real cost. The MIT license allows it, but you inherit the maintenance burden.
The Alternative: A Fork or a Commercial Tool
The obvious alternative is to use a fork of Kanboard or a different Kanban tool entirely. A fork like Focalboard or a commercial tool like Trello or Jira offers active development, but they differ in approach. Trello is a hosted SaaS with a free tier and a proprietary license. Jira is a heavyweight project tracker with Kanban boards as one feature among many. A fork of Kanboard keeps the same codebase but adds features, which is a risk because you depend on the fork's maintainers. The difference is clear: Kanboard is stable and frozen, while a commercial tool is evolving but costs money or locks you in. If you want an open-source tool that still gets new features, you need to look elsewhere, because Kanboard will not provide them.
Maintenance and Upgrade Cost
The upgrade cost is low in one sense: the project has a documented upgrade path, and releases are regular. But the cost is real in another sense. Because the project is in maintenance mode, you must track security fixes yourself. The MIT license gives you freedom, but it also gives you responsibility. You need to watch the ChangeLog and the release dates to know when to upgrade. The README does not mention a security policy or an automated update mechanism. The forum exists, but it is community-driven, not a support contract. For a small team, the cost is manageable. For a large enterprise, the lack of a vendor behind the project is a concern. Verify the PHP version requirements before you commit, because a maintenance-mode project may not support the newest PHP runtime.
Who Should Adopt Kanboard
The answer is a team that wants a board, not a platform. If you need a simple, self-hosted Kanban board and you are comfortable with the feature set being final, Kanboard is a solid choice. It is MIT licensed, so you can modify it, and it has a stable release cadence. The maintenance mode is a feature for those who value predictability over novelty. Who should not adopt it? A team that needs active development, new integrations, or a roadmap. A team that cannot afford to maintain its own fork if a bug is not fixed upstream. A team that needs support beyond a forum. Before you adopt, read the upgrade notes for the version you plan to install and check the requirements page to confirm your PHP setup works. Then decide if a frozen tool is acceptable.
Editorial conclusion
Adopt Kanboard if you need a simple, self-hosted Kanban board with an MIT license and you are comfortable with a feature set that will not grow. Do not adopt it if you expect new major features or a vendor-backed roadmap. Before deploying, verify that your PHP environment meets the documented requirements, check the upgrade notes for the version you plan to install, and confirm that the community forum is active enough for your support needs. The project is stable, but stability is a boundary, not a promise of evolution.
Community notes