Download Latest Version
wekan-11.72-s390x.zip (286.8 MB)
Get an email when there's a new version of wekan
Binaries in these bundles
Each bundle carries a Node.js, a FerretDB and the MongoDB Database Tools. Which source has a given CPU varies from release to release - nodejs.org builds some architectures, unofficial-builds others, and the wekan/node-patches build the ones neither of them does - and not every source publishes a checksum. This is what went into this release, and which downloads were checked against a published SHA256.
| Bundle | Binary | From | Version | Checked | SHA256 |
|---|---|---|---|---|---|
| amd64 | FerretDB | wekan/FerretDB | v1.50.0 | verified | 9e001227107f244b… |
| amd64 | Node.js | nodejs.org | v24.19.0 | verified | 14b342e71204f811… |
| arm64 | FerretDB | wekan/FerretDB | v1.50.0 | verified | 4e63385a721f1c04… |
| arm64 | Node.js | nodejs.org | v24.19.0 | verified | 01443c1e1a29e531… |
| armhf | FerretDB | wekan/FerretDB | v1.50.0 | verified | e8c9f64f14433749… |
| armhf | Node.js | wekan/node-patches | v24.19.0 | verified | b55350f3071b765a… |
| armv6 | FerretDB | wekan/FerretDB | v1.50.0 | verified | 11cf98ff5e2f0ed4… |
| armv6 | Node.js | wekan/node-patches | v24.19.0 | verified | 128ded0cda638c1f… |
| armv7 | FerretDB | wekan/FerretDB | v1.50.0 | verified | e8c9f64f14433749… |
| armv7 | Node.js | wekan/node-patches | v24.19.0 | verified | 8dbe0a9aa8550ad5… |
| i386 | FerretDB | wekan/FerretDB | v1.50.0 | verified | fc8a8d0e01748a20… |
| i386 | Node.js | wekan/node-patches | v24.19.0 | verified | 3b0b3bbfe27daf58… |
| mac-arm64 | FerretDB | wekan/FerretDB | v1.50.0 | verified | 0864e1d8c74a0cd4… |
| mac-arm64 | Node.js | nodejs.org | v24.19.0 | verified | 3f1cf157479c1480… |
| mac-x64 | FerretDB | wekan/FerretDB | v1.50.0 | verified | 83d6fde4b70088a8… |
| mac-x64 | Node.js | nodejs.org | v24.19.0 | verified | d35e95230f46f6f0… |
| ppc64le | FerretDB | wekan/FerretDB | v1.50.0 | verified | 9a3aec0a01e50f54… |
| ppc64le | Node.js | nodejs.org | v24.19.0 | verified | c510c6ce12f07010… |
| riscv64 | FerretDB | wekan/FerretDB | v1.50.0 | verified | 71c33d684350893e… |
| riscv64 | Node.js | unofficial-builds.nodejs.org | v24.19.0 | verified | cd1f14af28121480… |
| s390x | FerretDB | wekan/FerretDB | v1.50.0 | verified | dc8dfb6f11f5188f… |
| s390x | Node.js | nodejs.org | v24.19.0 | verified | a4792e65962ffa0a… |
| win-arm64 | FerretDB | wekan/FerretDB | v1.50.0 | verified | e210ec18a59a24c2… |
| win-arm64 | Node.js | nodejs.org | v24.19.0 | verified | 8502f4a50b458d4c… |
| win64 | FerretDB | wekan/FerretDB | v1.50.0 | verified | d232f53684f84bea… |
| win64 | Node.js | nodejs.org | v24.19.0 | verified | 57f71ab3652e797d… |
A row saying no checksum published is not a failed check - it is a source that publishes nothing to check against. Those are the ones worth fixing at the source.
v10.91 2026-08-13 WeKan ® release
In short: four reports from admins who could not tell what their own WeKan was doing, and two pieces of theming. Member Settings / Change color gained an All Boards switch beside "Default (no override)" - the overview's tiles take the theme's lighter colour instead of eleven different board colours, if that is what you want - and a highlighted popup row now follows the theme like the left menu does instead of being a fixed navy. Clicking a minicard again did not close the card it had opened - the toggle was there and had a test, and it was closing the wrong thing, so it was the one part of this that nobody could see was broken. A snap waiting for its database answered nothing at all on the web port, so an upgrade that left the database down looked like WeKan itself loading forever; the wait is a page now, with the commands that say why, and it carries the product name and the schema-upgrade dashboard's colours. The Admin Panel reports were full of things that never happened - an ordinary restart written up as a crash (and, because of the same bug, actually turned into minutes of downtime), and a reverse proxy written up as a spoofing attempt. And a snap serving the older of its two copies of the data was told "No problems detected", because the status report reads only the database WeKan is connected to and never said WHICH one that is; it now ends with a section that does, and names the two recovery commands. Below that: two open issues that the current code already answers, closed by reading it.
The binaries below are carried over from v10.90 and have NOT been checked
against a newer build; releases/provenance-table.sh prints the real table
from the provenance each build job records.
| Platform | Binary | From | Version | SHA256 |
|---|---|---|---|---|
| amd64 | Node.js | nodejs.org | v24.19.0 | 14b342e71204f811bde6153be8e04b62aef63c236fef92b55f9c83154b409647 |
| amd64 | FerretDB | wekan/FerretDB | v1.49.0 | 7c74941ff043f26aa4411ef5065d6b2d0766e369fc2a4458364c2f5571c12762 |
| arm64 | Node.js | nodejs.org | v24.19.0 | 01443c1e1a29e531ccad5a46fefa6df490d2189c49f7955904aecdbb0fe86fdc |
| arm64 | FerretDB | wekan/FerretDB | v1.49.0 | 092132531555a39eac12566240a5f1ed02f62148b2dca0540a74c68e5957f6b5 |
| armhf | Node.js | wekan/node-patches | v24.19.0 | b55350f3071b765a98ed66fdc410657ff168a937935057077fd7ab33cb30b9aa |
| armhf | FerretDB | wekan/FerretDB | v1.49.0 | 144404fb9793dc8e039874812f4e2cb3e6d8b1df0ffdbe50254e7790a342a2f4 |
| armv6 | Node.js | wekan/node-patches | v24.19.0 | 128ded0cda638c1f144eadb23ad249889515df017d298fd49c8faf3db110f0f1 |
| armv6 | FerretDB | wekan/FerretDB | v1.49.0 | 7c27b2c15448709a24eace9b3c951c62fbe33413f7d20d56cb5520f4436efe2d |
| armv7 | Node.js | wekan/node-patches | v24.19.0 | 8dbe0a9aa8550ad5275c5538ebf868eb2037f0c4d9cccbe319f63b7e5854cd45 |
| armv7 | FerretDB | wekan/FerretDB | v1.49.0 | 144404fb9793dc8e039874812f4e2cb3e6d8b1df0ffdbe50254e7790a342a2f4 |
| i386 | Node.js | wekan/node-patches | v24.19.0 | 3b0b3bbfe27daf583b3a0f432efacc508407a012cdd9e8847250e7c015565bac |
| i386 | FerretDB | wekan/FerretDB | v1.49.0 | 1f70cb1687411b2a0fa9ac3b5bfc8c4ed9ce25ec2ddfa17e6fd3efb38136a39c |
| mac-arm64 | Node.js | nodejs.org | v24.19.0 | 3f1cf157479c1480352083105e13faf9d008ede98e7e157746b6df940d197b94 |
| mac-arm64 | FerretDB | wekan/FerretDB | v1.49.0 | 576364db59dfce3ba564b9a3e484496eb57f95d76d2007b9f83241acdbd2f4fa |
| mac-x64 | Node.js | nodejs.org | v24.19.0 | d35e95230f46f6f0751df497c56622c6735e05d5e1fb1630996a005b9d328fe4 |
| mac-x64 | FerretDB | wekan/FerretDB | v1.49.0 | 37d70cd90aad6d3867b6686507ff1888f1edf6791818c31d014d130e8f39fc14 |
| ppc64le | Node.js | nodejs.org | v24.19.0 | c510c6ce12f07010f771e6edb22a3fe23f4f2e6f40b1ffd4941aed0646a0d8b3 |
| ppc64le | FerretDB | wekan/FerretDB | v1.49.0 | 7c61d4853d5163ad8761449d693fd458ebbb8611a2351c718014876242c5b1fb |
| riscv64 | Node.js | unofficial-builds.nodejs.org | v24.19.0 | cd1f14af2812148002f58b58a5f9af512a50e3b8e8c148e0db44019dcb68edfd |
| riscv64 | FerretDB | wekan/FerretDB | v1.49.0 | bd4912da70f5e6c1475ab989668c76b4ab7db4ee06c44357693df64f5e1d0e0b |
| s390x | Node.js | nodejs.org | v24.19.0 | a4792e65962ffa0af42627aacf1122a60c3c88dbf4e4184f06820d66f9da8ba4 |
| s390x | FerretDB | wekan/FerretDB | v1.49.0 | no checksum published |
| win-arm64 | Node.js | nodejs.org | v24.19.0 | 8502f4a50b458d4cc38ed8f2001556c2cd239d464920f74017926ccb1e1c157f |
| win-arm64 | FerretDB | wekan/FerretDB | v1.49.0 | 792166623e774b0af2aced31ed3ae39f545ca5268dc4c2b8d1a329228ff52cbc |
| win64 | Node.js | nodejs.org | v24.19.0 | 57f71ab3652e797d84acddc79c81cc9ff1c6ddb2a1974cdb83f00fee9bff4c73 |
| win64 | FerretDB | wekan/FerretDB | v1.49.0 | f42c50aa84095a9616b00f27a584c66b7bf79e3b109450c62a5f146ba3c85478 |
This release fixes the following bugs:
Cards on the board - opening one, and closing it again.
Clicking a minicard again really closes the card, wherever the card was opened from. Thanks to Heart1010, csonkaoszimt and xet7.
*"you now can click outside your mini card and the popout will close. Clicking the mini card again to close the popout is still not possible I think"* - [#6465](https://github.com/wekan/wekan/issues/6465), on v10.90, which already had the toggle and a test suite pinning it. The toggle was closing the wrong thing. On a desktop-sized screen the card details are not the address you are at: clicking a minicard writes the card id into the `openCards` session list and the board renders one draggable window per id in it, leaving the URL on the board. The toggle asked whether the card was `currentCard` and closed it by navigating to the board - which clears `currentCard` and leaves the window on screen, because nothing had taken the card OUT of `openCards`. Only the window's own X button did that, which is why closing worked from the card and not from the minicard. Both questions are now the card details' own close logic, so both ways of closing a card do the same thing. "Already open" is asked of the list that renders the window, which also fixes it for *Open many cards at once*: with several open, `currentCard` is only the last one clicked, so every earlier window was impossible to close from its minicard. Closing navigates back to the board only when the card really IS the address - a card opened by a click is not, and navigating would reset the board view for nothing.Member Settings - the theme, and what it reaches.
All Boards tiles can take the theme's lighter colour, and a highlighted popup row follows the theme too. Thanks to khuongsatou and xet7.
Two things in Member Settings / Change color. Beside **Default (no override)**, on the same row, a second switch: **All Boards**. Turned on, every tile in the All Boards overview takes the theme's lighter colour — a white veil over the theme accent, which is one shade up from whatever the theme is — with white text on it, instead of the colour its own board was given. Turned off, which is the default, the overview is exactly what it was. A board with a background *image* keeps its image: that is a picture somebody chose, not a colour. That is [#6593](https://github.com/wekan/wekan/pull/6593)'s observation as a per-user choice rather than a stylesheet. The pull request paints every tile white for everybody, and what it noticed is right — a wall of boards in eleven colours reads as a palette rather than a list — but *"the tile colours are noise"* and *"the tile colours are how I find my board"* are both true, of different people. So it lives where the rest of that user's theme is chosen, and only there: a board has no overview of its own, and a site admin does not choose this for everybody. And the **highlighted row** in a popup: it was filled with a fixed dark navy that appears nowhere else in WeKan and stayed navy however the user had themed it. The All Boards left menu fills its selected row with the theme accent and turns the label and icon white, and so does the Admin Panel — the popup does now too, so there is one selected-thing look rather than three.Starting up - and what a browser shows while WeKan cannot yet serve.
A snap waiting for its database says so in the browser, instead of timing out. Thanks to Alishara and xet7.
*"We upgraded from 10.85 to 10.89 and later to 10.90 - a reload of wekan got a timeout (loading forever)"* - [#6592](https://github.com/wekan/wekan/issues/6592). WeKan does not open its web port until the database answers, and the snap's two waits are endless on purpose: a database can take minutes to come up after an update, and giving up on it would be worse than waiting. They are not silent either - after two minutes each prints what to check. But nothing was listening on the web port while they waited, so the browser got a timeout and everything printed went to `snap logs`, which is the last place somebody whose site is down thinks to look. It also makes the two possible faults look the same: *"WeKan does not load"* is the report whether WeKan is broken or FerretDB simply did not start. The wait now serves a page saying **WeKan is waiting for its database**, naming the database it is waiting for and, in the browser, the commands that answer why: the service's own log (an `exec format error` is the bundled binary not running on this CPU), `wekan.problems` for which copy of the data is served, `snap start --enable` for a service left stopped by a failed migration, and `snap revert` back to the revision that worked. It refreshes itself away when WeKan starts, appears only after 30 seconds so an ordinary restart never shows it, and is stopped before anything else binds the web port. This does not say why the reporter's database did not come up - the issue has no logs yet - but the next person sees the reason instead of a timeout.The Admin Panel reports - what they say happened, and whether it did.
A restart is not a crash, and a reverse proxy is not a spoofer. Thanks to xet7.
Two reports from a server running 10.90 Snap, both full of things that never happened. **Filesystem integrity**, over and over: *"the previous run STOPPED WITHOUT SHUTTING DOWN CLEANLY, and this server was down for about 4 minute(s)"*, severity high — on a snap that had been refreshed, not crashed. Two faults, and the second made the downtime real rather than merely reported. `IntegrityKeys.update()` is not synchronous in Meteor 3: it starts a write and hands back a promise nobody waited for, so the clean-shutdown mark was never on disk when the process went. And registering ANY listener for `SIGTERM` replaces Node's default behaviour, which is to terminate — nothing in that listener exited, so WeKan ignored `SIGTERM` outright, systemd waited out its stop timeout and used `SIGKILL`. That is both the minutes of "downtime" in those rows and a genuinely unclean kill on every ordinary restart. The mark is written with `updateAsync` now and the handler exits: with 0, after at most two seconds, and exactly once however many signals arrive. What a crash IS was not touched — the rows were wrong because the input was wrong. **Security Report**, over and over: a medium-severity *spoofing* row for `/metrics` denied *"with X-Forwarded-For present"*, from 127.0.0.1. Every reverse proxy adds that header to everything it forwards, so a Prometheus scrape through a local proxy on a server whose allowlist does not cover it was being written up as an attack, in the report where a real one would have to be noticed. The spoof has a signature and it is asked for now: the header NAMES an allowlisted address while the connection is not from one. The 401 is unchanged and gained the sentence the admin needs — the address in it is the proxy, not the scraper, unless `METRICS_TRUST_PROXY` says how many hops to trust.The pages shown when there is no database use the product name and the dashboard's colours. Thanks to xet7.
The snap's standalone pages — under maintenance, recovering data, database too old, and the new one above — are a small HTTP server with no database connection, which is the whole point of them. The product name therefore comes from a file that `wekan-control` cached once per start, which leaves the case that matters: the name is set in the Admin Panel and the snap is not restarted before the next outage, so a rebranded WeKan tells its users *"WeKan is waiting for its database"* — a word they have never seen. WeKan is the only thing that knows the name the moment it changes, so WeKan writes it, at startup and whenever the setting changes. They also wear the schema-upgrade dashboard's colours now — the same `#111` ground, `#7bf` blue and monospace face — because that dashboard and these pages are the same thing to a reader: the product saying what it is doing while it cannot show them the app.Recovering a snap that has two copies of its data - and finding out that it has.
The status report says which copy of the data is being served, and how to compare them. Thanks to waltermhl and xet7.
*"error: cannot find app "database-compare" in "wekan". It seems, that database compare is not included in wekan 10.82"* - [#6583](https://github.com/wekan/wekan/issues/6583). It is not: the two recovery commands are snap apps, so they exist only in the revision that ships them, v10.90. That is the smaller half. The larger half is what happened before it. The same instance, serving data from a migration done in July, ran `snap run wekan.problems` and was told *"No problems detected"* - which was true of everything it checks, because it reads the one database WeKan is connected to and every check inside it passed. Nothing asked WHICH of the two copies that is, while the documentation already claimed this command answered it. The report now ends with a **Databases on this machine** section: which copy is being served and why, whether MongoDB files and a FerretDB database both exist, and - when they do - the two commands to run. It reads the files rather than a database, so it answers with WeKan down, and it declares no fault: two copies is the normal state of a migrated snap. A revision without the commands says to refresh rather than leaving snapd's "cannot find app" as the last word, and says why a refresh is safe here - it does not import an old MongoDB over a FerretDB already in use, and neither copy is ever deleted. `wekan.help` and [Migration-to-FerretDB.md](https://github.com/wekan/wekan/blob/main/docs/Platforms/FOSS/Container/Snap/Migration-to-FerretDB.md) list both commands with the release they arrived in.Reported behaviour that the current code already gets right
