| Name | Modified | Size | Downloads / Week |
|---|---|---|---|
| Parent folder | |||
| wekan-10.61-s390x.zip | 2026-08-04 | 318.2 MB | |
| wekan-10.61-s390x.zip.sha256sum | 2026-08-04 | 88 Bytes | |
| wekan-10.61-armhf.zip | 2026-08-04 | 303.1 MB | |
| wekan-10.61-armhf.zip.sha256sum | 2026-08-04 | 88 Bytes | |
| wekan-10.61-riscv64.zip | 2026-08-04 | 315.7 MB | |
| wekan-10.61-riscv64.zip.sha256sum | 2026-08-04 | 90 Bytes | |
| wekan-10.61-ppc64le.zip | 2026-08-04 | 317.2 MB | |
| wekan-10.61-ppc64le.zip.sha256sum | 2026-08-04 | 90 Bytes | |
| wekan-10.61-i386.zip | 2026-08-04 | 309.7 MB | |
| wekan-10.61-i386.zip.sha256sum | 2026-08-04 | 87 Bytes | |
| wekan-10.61-sandstorm.spk | 2026-08-04 | 171.2 MB | |
| wekan-10.61-win64.zip | 2026-08-04 | 297.0 MB | |
| wekan-10.61-win64.zip.sha256sum | 2026-08-04 | 88 Bytes | |
| wekan-10.61-mac-arm64.zip | 2026-08-04 | 307.7 MB | |
| wekan-10.61-mac-arm64.zip.sha256sum | 2026-08-04 | 92 Bytes | |
| README.md | 2026-08-04 | 9.1 kB | |
| v10.61 source code.tar.gz | 2026-08-04 | 34.0 MB | |
| v10.61 source code.zip | 2026-08-04 | 35.3 MB | |
| Totals: 18 Items | 2.4 GB | 0 | |
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 fork 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 |
|---|---|---|---|---|---|
| arm64 | FerretDB | wekan/FerretDB | latest | no checksum published | — |
| arm64 | FerretDB | wekan/FerretDB | latest | no checksum published | — |
| arm64 | Node.js | GitHub runner (setup-node) | v22.23.1 | no checksum published | — |
| arm64 | Node.js | GitHub runner (setup-node) | v22.23.1 | no checksum published | — |
| armhf | FerretDB | wekan/FerretDB | v1.45.0 | verified | a31a4dd877ecf5d5… |
| armhf | FerretDB | wekan/FerretDB | v1.45.0 | verified | a31a4dd877ecf5d5… |
| armhf | Node.js | fork | v24.19.0 | verified | b55350f3071b765a… |
| armhf | Node.js | fork | v24.19.0 | verified | b55350f3071b765a… |
| i386 | FerretDB | wekan/FerretDB | v1.45.0 | verified | a259f7f2603b745d… |
| i386 | FerretDB | wekan/FerretDB | v1.45.0 | verified | a259f7f2603b745d… |
| i386 | Node.js | fork | v24.19.0 | verified | 3b0b3bbfe27daf58… |
| i386 | Node.js | fork | v24.19.0 | verified | 3b0b3bbfe27daf58… |
| ppc64le | FerretDB | wekan/FerretDB | v1.45.0 | verified | de4518c7774d3025… |
| ppc64le | FerretDB | wekan/FerretDB | v1.45.0 | verified | de4518c7774d3025… |
| ppc64le | Node.js | official | v24.19.0 | verified | c510c6ce12f07010… |
| ppc64le | Node.js | official | v24.19.0 | verified | c510c6ce12f07010… |
| riscv64 | FerretDB | wekan/FerretDB | v1.45.0 | verified | 7dc2952f554e8800… |
| riscv64 | FerretDB | wekan/FerretDB | v1.45.0 | verified | 7dc2952f554e8800… |
| riscv64 | Node.js | unofficial | v24.19.0 | verified | cd1f14af28121480… |
| riscv64 | Node.js | unofficial | v24.19.0 | verified | cd1f14af28121480… |
| s390x | FerretDB | wekan/FerretDB | v1.45.0 | no checksum published | — |
| s390x | FerretDB | wekan/FerretDB | v1.45.0 | no checksum published | — |
| s390x | Node.js | official | v24.19.0 | verified | a4792e65962ffa0a… |
| s390x | Node.js | official | v24.19.0 | verified | a4792e65962ffa0a… |
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.61 2026-08-04 WeKan ® release
In short: this release is all release-build fixes. With the release job
itself working again (v10.60), the per-platform jobs it feeds surfaced their
own breakage: build-win64 ran a bash script under PowerShell,
build-mac-arm64 called the Linux-only sha256sum, build-extra-arches
never unpacked the bundle it downloaded, and an i386 entry in
snapcraft.yaml — which core24 cannot build — was a parse error that failed
every snap. The downstream Docker and AppImage jobs, which only wrap
an already-published release bundle, now skip gracefully instead of failing
when that bundle is not up yet. And a Debian type: base snap is
scaffolded so i386 can eventually ship as a snap at all, since core24 has no
i386 port.
This release fixes the following release-build issues:
The per-platform release jobs - each broke in its own way once the release job started feeding them again.
The win64, mac-arm64, extra-arch and snap release jobs each fail on their own bug. Thanks to xet7.
Four independent failures in the v10.60 run, one per job: `build-win64`'s "Check the binaries" step ran `set -euo pipefail` under the Windows default shell and PowerShell answered "A parameter cannot be found that matches parameter name 'euo'" - it now says `shell: bash`. `build-mac-arm64` ran `sha256sum`, a GNU coreutils name macOS does not have, and died exit 127; `shasum -a 256` is the BSD/macOS spelling. `build-extra-arches` downloaded `wekan-<version>-amd64.zip` but never unpacked it, so the container mounted an empty `/bundle` and the native-module rebuild died with `ENOENT ... /bundle/programs/server/package.json` (exit 254) - it now unzips the bundle like the arm64/win64/mac-arm64 jobs already do. And `snapcraft.yaml` declared an `i386` platform that core24 (Ubuntu 24.04, no i386 port) rejects with "none of these build architectures are supported" - a PARSE error that failed `snap-native` AND every `snap-launchpad` arch, not only i386. The i386 platform and its launchpad matrix entry are removed; i386 users are served by the `.deb` and AppImage.The downstream packaging jobs - Docker and AppImage only WRAP a release bundle that another job builds, so they cannot run before it exists.
Docker and AppImage skip with a notice instead of failing when the release bundle is not published yet. Thanks to xet7.
`dockerimage.yml` / `docker-publish.yml` build a Dockerfile that DOWNLOADS the prebuilt `wekan-<version>-amd64.zip`, and `AppImage.yml` wraps the per-arch bundle; all of them `exit`ed hard when that asset was not on the release - which it was not while the release was still building, or when a run targeted a version whose bundle was not published. Each now checks whether the asset it needs is on the release and SKIPS with a `::notice::` (a green run) when it is not: the docker jobs gate the build on the pinned version's zip, and AppImage flips its per-arch `BUILD_THIS` off and treats "no AppImage, and no base bundle either" as nothing-to-do. The release image / AppImages are still built by `release-all.yml` once the bundles are up; these standalone runs simply stop failing in the meantime.and scaffolds an i386 snap on a Debian base:
A Debian type:base snap so i386 can ship as a snap at all, since core24 has no i386 port. Thanks to xet7.
core24 has no i386 port, so `base: core24` cannot build an i386 snap. Debian still ships i386 and is glibc, so - unlike an Alpine/musl base - WeKan's existing binaries run unchanged, and since the snap only assembles the prebuilt `wekan-i386.zip` (which already exists), the one missing piece is an i386-capable base. `snap-base-debian/` scaffolds `wekan-base-debian13` (`type: base`), a trimmed Debian trixie rootfs, starting with i386 - which builds NATIVELY on an amd64 runner, no qemu or Launchpad. It is isolated from the working core24 `snapcraft.yaml` and is a documented, UNVERIFIED scaffold: a custom base snap needs a real `snapcraft pack` + local install + a WeKan snap running on it before CI or the (manual) store review, all of which `snap-base-debian/README.md` spells out.Thanks to above GitHub users for their contributions and translators for their translations.