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.53.0 | verified | eae1f0a8f73bfc97… |
| amd64 | Node.js | nodejs.org | v24.19.0 | verified | 14b342e71204f811… |
| arm64 | FerretDB | wekan/FerretDB | v1.53.0 | verified | bdc50caee3ac2849… |
| arm64 | Node.js | nodejs.org | v24.19.0 | verified | 01443c1e1a29e531… |
| armhf | FerretDB | wekan/FerretDB | v1.53.0 | verified | f7f050207e656d65… |
| armhf | Node.js | wekan/node-patches | v24.19.0 | verified | b55350f3071b765a… |
| armv6 | FerretDB | wekan/FerretDB | v1.53.0 | verified | 34f5f553dcd2bff3… |
| armv6 | Node.js | wekan/node-patches | v24.19.0 | verified | 128ded0cda638c1f… |
| armv7 | FerretDB | wekan/FerretDB | v1.53.0 | verified | f7f050207e656d65… |
| armv7 | Node.js | wekan/node-patches | v24.19.0 | verified | 8dbe0a9aa8550ad5… |
| i386 | FerretDB | wekan/FerretDB | v1.53.0 | verified | 515b1189b4c7d58f… |
| i386 | Node.js | wekan/node-patches | v24.19.0 | verified | 3b0b3bbfe27daf58… |
| mac-arm64 | FerretDB | wekan/FerretDB | v1.53.0 | verified | cb14ffe93e285903… |
| mac-arm64 | Node.js | nodejs.org | v24.19.0 | verified | 3f1cf157479c1480… |
| mac-x64 | FerretDB | wekan/FerretDB | v1.53.0 | verified | d97dfa9afa60aa05… |
| mac-x64 | Node.js | nodejs.org | v24.19.0 | verified | d35e95230f46f6f0… |
| ppc64le | FerretDB | wekan/FerretDB | v1.53.0 | verified | 481d36a80ec73673… |
| ppc64le | Node.js | nodejs.org | v24.19.0 | verified | c510c6ce12f07010… |
| riscv64 | FerretDB | wekan/FerretDB | v1.53.0 | verified | 4b43f86eb0f3fa0b… |
| riscv64 | Node.js | unofficial-builds.nodejs.org | v24.19.0 | verified | cd1f14af28121480… |
| s390x | FerretDB | wekan/FerretDB | v1.53.0 | verified | fe74e03894b84897… |
| s390x | Node.js | nodejs.org | v24.19.0 | verified | a4792e65962ffa0a… |
| win-arm64 | FerretDB | wekan/FerretDB | v1.53.0 | verified | f1186c310a4dd144… |
| win-arm64 | Node.js | nodejs.org | v24.19.0 | verified | 8502f4a50b458d4c… |
| win64 | FerretDB | wekan/FerretDB | v1.53.0 | verified | c6dad7bc8ad56f47… |
| 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.95 2026-08-16 WeKan ® release
In short: the Sandstorm .spk still will not pack - Sandstorm refuses an
app over 1 GiB uncompressed - and v10.94 was supposed to say what filled it.
It said nothing, because the size report ran BEFORE meteor-spk pack, and pack
is what builds the trees it was trying to measure. The sizes are taken after
pack now, on failure and on success, dereferencing the symlink that hid most of
them; and the bundle is pruned of its build-only toolchain and packed once more
before the job gives up, which is the same pruning every other bundle already
gets and the one reduction available without guessing.
| Platform | Binary | From | Version | SHA256 |
|---|---|---|---|---|
| amd64 | Node.js | nodejs.org | v24.19.0 | 14b342e71204f811bde6153be8e04b62aef63c236fef92b55f9c83154b409647 |
| amd64 | FerretDB | wekan/FerretDB | v1.53.0 | eae1f0a8f73bfc979738bfff7284d40fd1bc55de2cc56514721fc155c3624f7d |
| arm64 | Node.js | nodejs.org | v24.19.0 | 01443c1e1a29e531ccad5a46fefa6df490d2189c49f7955904aecdbb0fe86fdc |
| arm64 | FerretDB | wekan/FerretDB | v1.53.0 | bdc50caee3ac28495b42d2130b94a042a9dd6d3a38f732cac02b648f36c891da |
| mac-arm64 | Node.js | nodejs.org | v24.19.0 | 3f1cf157479c1480352083105e13faf9d008ede98e7e157746b6df940d197b94 |
| mac-arm64 | FerretDB | wekan/FerretDB | v1.53.0 | cb14ffe93e285903e5a8a9c1821687ddb5b8a979a11c584bf4af534b272c6d3e |
| mac-x64 | Node.js | nodejs.org | v24.19.0 | d35e95230f46f6f0751df497c56622c6735e05d5e1fb1630996a005b9d328fe4 |
| mac-x64 | FerretDB | wekan/FerretDB | v1.53.0 | d97dfa9afa60aa05f25384327de82efe7b71d958ed24c1f66618284294a65cd3 |
This release fixes the following build failures:
The release workflow - the bundles a release is supposed to carry.
The Sandstorm .spk fails on a size limit, and now says what filled it. Thanks to xet7.
`build-sandstorm` fails with *App exceeds uncompressed size limit of 1 GiB* and nothing else. Because Sandstorm refuses to pack, no `.spk` is written, so there is no artifact to open and no list of what filled it. The first attempt at that added a size report **before** `meteor-spk pack`, and the next run showed it printing nothing at all: --- packing (Sandstorm refuses over 1 GiB uncompressed) Building Meteor app... `meteor-spk pack` is what BUILDS the Meteor app - *Building Meteor app...* comes after it starts - so `.meteor-spk/deps` and `.meteor-spk/bundle` do not exist until it has run. The report was measuring two directories that were not there, found neither, and skipped both silently. A diagnostic that runs before the thing it diagnoses says nothing at all. The sizes are taken AFTER pack now: on failure, where they are the whole point, and on success, where the headroom against 1 GiB is worth knowing before the next thing is added. `du -shL` DEREFERENCES, because `deps` is a symlink to the tree `sandstorm-src/build-deps.sh` assembles and a plain `du -sh` on a symlink reports the link rather than the gigabyte behind it. The bundle's server packages are listed separately, because they are the part every other bundle prunes. And one bounded RETRY, which is an attempt at the fix rather than more looking. `meteor-spk pack` runs `npm install` inside the bundle's `programs/server` - that is where `tar@6.2.1` and node-gyp's tree come from in the log - and the Sandstorm leg is the only one that never removes them afterwards. `prune-build-only-modules.mjs` drops 83 of 120 packages everywhere else, and nothing in a packed app runs any of them. Whether it is enough turns on something no log has answered yet: does a second pack REUSE `.meteor-spk/bundle`, or rebuild it and undo the prune? Both answers are useful and neither is worse than the hard failure that is there now - if it rebuilds, the second failure is identical and the log says the prune was undone; if it reuses, the `.spk` packs. It runs once, only after a failure, and only if the bundle is actually there.Thanks to above GitHub users for their contributions and translators for their translations.