Wekan shipped 22 release events in 30 days and 30 GitHub releases in 90 days. That is the headline, but the interesting part is what those releases contain. This is not a kanban app chasing a new productivity fad. It is a self-hosted project-management tool grinding through backups, Docker upgrades, MongoDB behavior, test fixes, login bugs, and security response.

The official site still positions Wekan plainly: an open-source, customizable, privacy-focused kanban with boards, lists, cards, access controls, and a self-hosted option. The GitHub repository describes it as the open-source kanban built with Meteor, and the project points support users toward commercial support rather than GitHub issues. That split matters. Wekan is not presenting itself as a hosted SaaS growth machine. It is presenting itself as software you run and maintain.

ToolVitals gives Wekan a 96 ToolVitals score, 94 health score, 98 shipping score, 203.9 hot score, and 20,925 GitHub stars. Its openness field is clear: Wekan is OSI-approved OSS under the MIT license. That is stronger language than source-available or fair-code, and it fits the project’s public positioning.

The release stream is mostly operational work

The recent releases read like a maintainer fixing the parts that hurt operators.

v9.22 added a script for upgrading Docker WeKan from an old version to a new version, added backup-all.sh, backed up attachments and avatars, documented Meteor security, and fixed multitenancy behavior around oplog and sockjs. That is not shiny roadmap theater. That is admin survival work.

v9.21 added documentation for Meteor 3 Docker WeKan with ChangeStreams, changed defaults, and fixed sudden logouts. v9.20 touched build scripts, attachment and avatar path fallback, oplog and sockjs defaults, and MongoDB indexes. v9.19 updated dependencies, isolated Playwright from root node_modules, fixed Docker Compose syntax, worked through Playwright test failures, and fixed LDAP Admin Sync, comments, board visibility, card opening, and due-date notification email behavior.

The pattern is obvious. Wekan is spending release energy on deployability, regression repair, data safety, and self-hosted edge cases. For a project-management tool, that may be more valuable than another dashboard view.

The security response is part of the story

v9.09 fixed critical AuthBleed security issues, clarified SECURITY.md, updated GitHub Actions for release bundles, and added Playwright tests with 306 passing checks according to the release note. That does not prove Wekan is secure. It does show that the project disclosed a critical security fix in the release stream and tied it to documentation and tests.

That is the kind of evidence ToolVitals can use carefully. It can say the project is actively responding to security and maintenance work. It cannot say the codebase is safe by inspection.

What ToolVitals cannot infer

ToolVitals sees public signals: releases, stars, health score, shipping score, openness, SSL and uptime signals when available, and public project activity. It does not see code quality. It does not see whether upgrades are painless in your environment. It does not see user satisfaction, support quality, revenue, or how many production teams rely on Wekan.

The release notes also show churn. Frequent releases are good when they mean fast fixes. They can also mean operators need to track changes closely. ToolVitals should treat the 98 shipping score as a strong activity signal, not as proof that every release is low-risk.

Compared with nearby tools

Among related project-management entries, Wekan is busier than QOwnNotes by release count: 22 release events in 30 days versus QOwnNotes at 9. Wekan also has more GitHub stars, 20,925 versus 5,758. TREK is closer on release activity with 20 release events in 30 days, but Wekan still leads on stars, 20,925 versus 5,114.

The openness distinction also matters. Wekan, QOwnNotes, and TREK are all tracked as OSI-approved OSS in this payload, though under different licenses: Wekan uses MIT, QOwnNotes uses GPL-2.0, and TREK uses AGPL-3.0. n8n appears in the related set with a higher hot score and 43 release events in 30 days, but it is fair-code, not OSI-approved open source, according to the payload. That is not a small footnote if your procurement or internal policy requires an OSI-approved license.

Recommendation

If your team wants a self-hosted kanban tool and cares more about control, backups, upgrade scripts, and license clarity than polished SaaS packaging, evaluate Wekan seriously. Start with the Docker upgrade and backup paths, then test login, attachments, LDAP if you use it, and board permissions against your own deployment setup.

Do not adopt it just because 22 release events looks exciting. Adopt it if that release stream matches your risk model: active maintenance, MIT licensing, self-hosting, and a maintainer culture that keeps fixing the boring parts.

Sources