Wekan’s most interesting number is not its 21,072 GitHub stars. ToolVitals records 4,487 commits and 42 release events in the last 30 days, alongside 4 active contributors. That is a strong maintenance signal and a concentration signal at the same time. Wekan looks like a self-hosted kanban product with a serious release process, but teams should evaluate the delivery model as carefully as the board features.

Wekan’s product promise is control, not novelty

The official Wekan site describes the product as an open-source, customizable, privacy-focused kanban application. Its model is familiar and concrete: users create boards, divide work into lists such as To Do, Doing, and Done, then represent individual tasks as cards. Cards can carry descriptions, due dates, labels, comments, files, and checklists.

That feature model solves a specific problem. Teams get a visual workflow without having to place their project data in a hosted service they do not control. The official site also describes board-level and user-level access controls, which makes Wekan relevant for organizations that need more than a personal task list.

The GitHub repository identifies Wekan as a collaborative kanban board built with Meteor. ToolVitals classifies its openness as OSI-approved OSS and labels the license MIT. That is a meaningful distinction from source-available or fair-code products. The supplied evidence supports calling Wekan open source under an MIT license.

Self-hosting is not an incidental deployment option. The official site presents it as a way to retain control of data, while the repository points users toward Docker and one-click installation paths on various platforms. The repository also directs FLOSS developers to GitHub issues and pull requests while sending support questions to a separate support channel. That gives prospective operators an early view of the project’s operating model: installation and maintenance are part of the user experience.

The security language needs a precise reading. Wekan’s website argues that inspectable source and self-hosting can improve control and make auditing possible. That is a product position, not proof that every deployment is secure. The repository warns users to update frequently, says only the newest Wekan version is supported, and notes that old runtime components can create security problems. Those warnings are more operationally useful than a generic security claim.

The surprising metric is velocity with a narrow visible core

ToolVitals gives Wekan a health score of 95, a shipping score of 98, and an overall ToolVitals score of 96. Its data confidence score is 90, and its hot score is 249.1. These are ToolVitals measurements, not claims made by Wekan’s maintainers, and the supplied context does not define the scoring formula in enough detail to treat any one score as a product-quality measurement.

The activity figures are unusually strong for a project-management tool. ToolVitals reports 21,072 GitHub stars, 4,487 GitHub commits in 30 days, 30 GitHub releases in 90 days, and 42 release events in 30 days. Read together, those figures show a project that is actively changing and publishing, not a repository that receives an occasional maintenance patch.

The release-event number needs careful interpretation. The supplied event feed records the same version in more than one form. For example, v11.06 appears as both a changelog entry and a GitHub release event, and v11.02 appears in both forms as well. The 42-event figure therefore signals a high level of publication activity, but it should not automatically be read as 42 unique versions or 42 separate feature drops.

The other unusual signal is the relationship between volume and visible participation. ToolVitals counts 4 active contributors while also counting 4,487 commits in the same 30-day activity window. That does not prove that every commit came from those contributors, that the work is evenly distributed, or that the commits are all manually authored product changes. It does show why contributor count matters alongside commit count. A small core can move quickly, but a team evaluating Wekan should ask how much knowledge is concentrated in that core and how the project handles maintainer absence.

The 21,072-star count adds evidence of durable public interest, not evidence of current adoption. Stars are easy to accumulate over time and do not reveal active installations, retention, support burden, or whether users have migrated away. ToolVitals can measure repository signals with reasonable confidence here, but those signals remain proxies.

The release stream is broadening the product

The recent release pages show work across user-facing behavior, administration, accessibility, exports, integrations, and build infrastructure. The direction is not a simple march toward more card fields. Wekan is tightening the edges around a self-hosted system that has to serve daily users and administrators.

The v10.99 release notes focus heavily on exports. They describe a unified export dialog whose selection is passed to each format, along with PDF and Excel changes covering localization, date formatting, multilingual text, attachment previews, locations, stickers, dependencies, and card position. The release also adds selectable board members for Requested By and Assigned By while preserving the existing free-text fields, and it includes work on subtasks.

That matters because exports are often where a task system’s practical limits become visible. A board can look complete inside the browser and still be difficult to archive, analyze, or move elsewhere. The v10.99 notes suggest that Wekan is treating exported data as a first-class representation rather than a screenshot of the board.

The v11.03 release pushes in a different but related direction. Its notes describe shared accessibility behavior for tabs, dialogs, images, password controls, and card edit targets, supported by a common keyboard utility. The same release restores or fixes custom-field behavior, cross-board card links, linked-card editing, mobile layouts, attachment previews, and several Admin Panel reports.

Taken together, v10.99 and v11.03 suggest a product moving beyond the basic To Do, Doing, Done demonstration. Linked cards, exports, directory-aware administration, responsive layouts, and accessibility details become important when a kanban board is used as an operational system. The notes do not prove that every workflow is polished, but they show the maintainers working on the failure points that appear after adoption grows.

The v11.05 release is a useful example of that maintenance style. It fixes a date-context regression that could stop card-detail rendering after a date save and leave the board in a refresh loop. The same release changes Launchpad snap jobs so they wait for architecture-specific bundles, verify the expected asset, and retain a valid artifact even when a later cleanup step fails.

That pairing is important. One fix addresses a user-visible application failure. The other addresses a release pipeline failure that could waste build time or discard a usable package. Wekan’s recent activity is therefore not only feature work. It includes the tooling required to distribute a self-hosted application across different environments.

The v11.06 release page, dated 2026-08-21, continues the same pattern. Card details once again expose valid lists and labels across swimlanes and linked cards. Person-field actions use compact accessible icons, LDAP profiles retain the directory’s full display name across scalar, array, and buffer attribute shapes, and the release adds regression coverage for the reported bugs. The release notes state that the complete plain-Node run passes all 495 suites.

The release pages also expose a distribution concern that buyers should not skip. Wekan’s bundles carry Node.js, FerretDB, and the MongoDB Database Tools. The release notes explain that different CPU architectures may come from different upstream or project-maintained sources, and that not every source publishes a checksum. The notes explicitly distinguish a missing checksum from a failed checksum check. For a self-hosting team, release selection includes provenance and artifact validation, not just clicking the newest tag.

What the data does not establish

ToolVitals measures repository activity, contributors, releases, licenses, stars, and related public evidence. It does not measure code quality, uptime, user satisfaction, revenue, support responsiveness, security incident history, or whether Wekan works well for a particular team’s workflow. A 96 overall score cannot answer those questions.

The 495-suite statement in v11.06 is useful evidence about the project’s own regression process. It is not an independent audit of the test suite, and it does not show coverage of every deployment mode, database state, browser, proxy, or upgrade path. A passing test run reduces one kind of risk. It does not eliminate operational risk.

The repository also records claims about broad usage and reach, including a largest user of 30k users and translations to 234 languages, with 197 described as essentially complete. Those are statements presented by the project in the supplied excerpt. ToolVitals does not independently validate them, so they should be treated as project-reported context rather than adoption telemetry.

The repository notes a WeKan and Standard for Public Code assessment made in 2023-11, with 8 of 16 criteria met out of the box at that time. That is a dated assessment, not a current compliance result. It can help a buyer form questions about documentation and public-project practice, but it should not be used as a current certification.

A skeptical engineering lead should treat Wekan’s activity scores as a reason to run a technical evaluation, not as a substitute for one. Test board creation, linked-card behavior, imports and exports, LDAP synchronization if required, attachment handling, access controls, mobile use, backups, restores, and an upgrade from the previous deployment. Confirm the exact release artifact and its available checksums for the target architecture. The repository says 1 GB of free RAM is the minimum for Wekan and recommends at least 4 GB of total RAM for a production server, but those figures are deployment guidance, not a capacity guarantee for a large installation.

Project-management comparisons need context

The related ToolVitals data puts Wekan above two other project-management entries on some activity measures, but not all of them. Kaneo has 8,936 GitHub stars, a shipping score of 97, and 29 release events in 30 days. Wekan has 21,072 stars, a shipping score of 98, and 42 release events in 30 days. The comparison supports a stronger measured public footprint for Wekan than Kaneo, while leaving feature fit unanswered.

Ever Gauzy presents the opposite cadence lesson. ToolVitals reports 4,361 GitHub stars, a shipping score of 96, and 75 release events in 30 days for Ever Gauzy. Its release-event count is higher than Wekan’s, while its star count and shipping score are lower. That is enough to show why release frequency alone is a poor ranking system.

ToolVitals classifies Kaneo as OSI-approved OSS with an MIT license label and Ever Gauzy as OSI-approved OSS with an AGPL-3.0 label. The related data does not provide feature-by-feature comparisons, deployment requirements, test evidence, or support terms. Treat these projects as candidates for separate evaluations, not interchangeable products selected from a leaderboard.

Recommendation for adopters and maintainers

If your team needs a self-hosted kanban board, wants an MIT license, and has an owner for upgrades, backups, and runtime operations, put Wekan on the shortlist. Start with the supplied current release line represented by v11.06 and test the exact workflows suggested by the recent notes: linked-card labels, multiple swimlanes, LDAP display names, accessible card actions, exports, and architecture-specific packaging.

Do not deploy it as a set-and-forget appliance. The repository recommends regular updates and at least daily database backups, warns about disk exhaustion, and says old versions are not supported. A restore drill should be part of acceptance testing. So should an upgrade rehearsal, especially if the installation uses Snap, Docker, custom architecture bundles, or a database configuration that differs from the documented path.

For maintainers, the public signal is clear: Wekan is shipping, and the release notes show attention to regressions that affect real operators. The next challenge is making that activity easier to understand and easier to join. Four active contributors supporting a high-volume commit stream is a concentration signal, so contributor onboarding, ownership boundaries, release provenance, and recovery procedures deserve the same care as feature code.

The release writing itself is part of that work. v11.06 gives readers a useful summary of behavior changes, data-shape handling, accessibility controls, and test coverage. By contrast, the v11.02 release notes still contain a placeholder saying that there is nothing there yet and instructing the author to replace it. A small release-index page that separates unique tags from changelog and publication events would also make the project’s velocity easier to interpret.

The concrete recommendation is simple. Teams that value data control and can operate a continuously updated self-hosted service should evaluate Wekan against their own migration, identity, backup, and accessibility requirements. Teams that cannot assign that operational responsibility should not let a 98 shipping score make the decision for them.

Sources