Kanboard 1.2.57: A Maintenance-Mode Kanban Tool That Still Ships Regularly

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. 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 visible in the repository, though a jsonrpc.php file sits at the top level. 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.57 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 should not expect it from the author. The author is not actively developing new major features, only small fixes, though the README says pull requests for new features and bug fixes are accepted as long as the guidelines are followed. That means the community must do the work. 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 different open-source tool 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 in maintenance mode, 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 the author is not developing new major features.

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 an automated update mechanism, although the repository carries a SECURITY.md. 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 author not developing new major features, 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 maintenance-mode 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 the author is not actively growing. 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.

Frequently asked questions

Official sources

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