v9.85 2026-07-11 WeKan ® release

This release adds the following features and fixes:

• Docker: FerretDB v1 + SQLite is now the default docker-compose.yml:

  The default database for docker compose up -d is now FerretDB v1 with embedded
  SQLite (from https://github.com/wekan/FerretDB) — light and self-contained, no
  separate database server. The compose files were renamed accordingly:
  docker-compose-ferretdb-v1-sqlite.yml -> docker-compose.yml (the new default),
  and the previous MongoDB default docker-compose.yml -> docker-compose-mongodb-v7.yml.
  The other files are unchanged: docker-compose-ferretdb-v2-postgresql.yml (FerretDB 2

  • PostgreSQL) and docker-compose-multitenancy.yml (MongoDB multitenancy). To use
    MongoDB 7, run docker compose -f docker-compose-mongodb-v7.yml up -d or rename that
    file to docker-compose.yml. rebuild-wekan.sh / rebuild-wekan.bat Docker menus now
    list FerretDB v1 SQLite first (default) and point at the new filenames, the compose
    files' own header comments were updated, and the Docker docs now describe which
    compose file maps to which database. The Docker menus also gained a Build from
    source & start (up -d --build) action per compose file, which builds the wekan-app
    image from the local Dockerfile (tagged as the image the compose file references)
    and starts that freshly built container instead of a possibly-stale prebuilt image —
    useful when a change (e.g. the FerretDB Version-page detection) isn't in the pulled
    image yet. Finally, the obsolete version: attribute (which Docker Compose v2 warns
    about and ignores) was removed from all compose files (docker-compose.yml,
    docker-compose-mongodb-v7.yml, docker-compose-ferretdb-v2-postgresql.yml,
    docker-compose-multitenancy.yml, .devcontainer/docker-compose.yml, and the
    ToroDB docs example).

• rebuild-wekan.sh / rebuild-wekan.bat: reorganized into category submenus + Docker start/logs/stop:

  The long flat menu is now grouped into a short top-level menu — Setup,
  Dev server, Tests, Docker, Tools, Quit — each opening a small
  submenu with 0) Back, so you read only a handful of items at a time and labels
  are shorter (the category provides the context). Docker is a two-stage submenu:
  pick a backend (MongoDB docker-compose.yml, FerretDB v1 SQLite, FerretDB v2
  PostgreSQL, MongoDB Multitenancy), then an action — Start (up -d),
  Follow logs (logs -f) or Stop (down) — which removes the previous
  repetition of 12 near-identical entries. The .sh auto-detects docker compose
  vs legacy docker-compose. All existing actions are unchanged, just regrouped.

• rebuild-wekan.sh / rebuild-wekan.bat: Dev server options now stop the previous
  server (including the rspack :8080 dev server) before starting, plus a new "Kill
  all dev servers" option, and docs updated for the new menu:

  Every Dev server option (localhost:3000, + trace warnings, + bundle visualizer, CURRENT-IP:3000, CURRENT-IP:3000 + MONGO_URL 27019, and
  CUSTOM-IP:PORT) now stops any Meteor dev server already running before starting a
  fresh one, so re-running a dev option no longer fails because a port is taken — no
  need to hunt down and kill the old processes yourself. Crucially it frees both
  the app port and the rspack dev-server port 8080: meteor run starts an rspack
  dev server on 8080 that can outlive the meteor parent, and a leftover one made the
  restart crash with Error: listen EADDRINUSE ... :8080. Port detection now checks the
  listening socket directly (ss/lsof, with a bash /dev/tcp fallback that needs no
  external tools, and netstat on .bat) instead of an HTTP probe, so it also catches
  a server that is still building. A new Dev server -> Kill all dev servers option
  frees every dev/test port the scripts use at once — the dev app (3000) and its Mongo
  (3001), the Mocha test server (3100) and its Mongo (3101), a Sandstorm standalone dev
  server (4000) and its Mongo (4001), and the rspack dev server (8080) — killing meteor,
  the rspack watcher and Meteor's bundled --replSet meteor Mongos (never a
  production/system Mongo). Both scripts escalate to SIGKILL if a port does not free up.
  Also updated the build-from-source docs (README.md, Build-from-source.md,
  Build-and-Create-Pull-Request.md, Emoji.md, and the two Sandstorm developer docs) to
  the new two-level menu (Setup -> Install dependencies, Setup -> Build WeKan,
  Dev server -> localhost:3000) and fixed a stale dev-server port
  (localhost:4000 -> 3000).

• FerretDB: quieter logs, and removed a dead MongoDB-driver-selection subsystem:

  On FerretDB (SQLite), the driver debug logs revealed a second, TLS-enabled Mongo
  monitor connection retrying every ~0.5s and being rejected by the plaintext FerretDB
  port, which FerretDB logged at WARN (Connection stopped … invalid message length /
  before secure TLS connection was established) — harmless (WeKan runs fine on the real
  plaintext connection) but very noisy. FerretDB is now started with --log-level=error
  in all bundled launch points (Docker entrypoint, snap ferretdb-control, the release
  start-wekan.sh, and the docker-compose-ferretdb-v1-sqlite.yml example), which drops
  the per-connection WARN spam. Separately removed a dead, unused "MongoDB Driver System"
  (server/mongodb-driver-startup.js + models/lib/{meteorMongoIntegration,mongodbConnectionManager,mongodbDriverManager}.js)
  — an abandoned attempt to auto-detect MongoDB 3.0–8.0 and pick versioned driver packages
  that were never even installed; WeKan uses the mongodb-7 driver via Meteor.

• Fix snap build failing on the caddy part (Cloudsmith unreachable on Launchpad):

  The snap installed Caddy from the Cloudsmith apt repo
  (curl … dl.cloudsmith.io … | gpg --dearmor), which fails on the Launchpad remote
  builders — their network is restricted to a fetch proxy that can't reach Cloudsmith, so
  gpg got no key (no valid OpenPGP data found) and the caddy override-build failed
  with code 2 on both arches, all attempts. Both snapcraft.yaml and snapcraft-core24.yaml
  now download the official prebuilt Caddy static binary from GitHub releases (per-arch,
  latest stable with a pinned fallback) instead. WeKan uses only built-in Caddy directives,
  so vanilla Caddy is sufficient — no apt repo, no gpg, no xcaddy/custom-module build.

• Fix Admin Panel / Version showing "MongoDB" when running on FerretDB:

  The database detection only recognised a buildInfo.ferretdb sub-document, but the
  wekan/FerretDB v1 fork reports its identity as a top-level ferretdbVersion string
  (e.g. v1.24.2-60-gb5523566) plus ferretdbFeatures, with its git commit in gitVersion.
  So the Version page showed Database type: MongoDB and hid the FerretDB rows. Detection now
  handles both shapes (server/statistics.js),
  so it shows Database type: FerretDB, the FerretDB version and FerretDB commit rows, and
  the SQLite storage engine. (FerretDB v1's version: 7.0.42 is the MongoDB version it emulates.)

• Design doc: WeKan on Sandstorm (Meteor 3.5 / Node 24) with MongoDB 3 → FerretDB migration:

  Added docs/Platforms/FOSS/Sandstorm/Meteor3/Migration.md
  describing how to build a modern Sandstorm .spk (Node 24, replacing meteor-spk
  0.6.0's Node 14) that runs on FerretDB v1 (embedded SQLite) instead of MongoDB 3.0,
  migrating an existing grain's MongoDB 3.0 data on first launch — reusing the snap's
  proven migrate-mongo3-to-ferretdb logic (mongoexport read → FerretDB insert;
  CollectionFS/Meteor-Files GridFS attachments+avatars → filesystem). Includes the
  grain sandbox (seccomp) compatibility analysis, the rewritten start.js, and a new
  isSandstorm-only Admin Panel / Attachments / Sandstorm section (migration status,
  raw-MongoDB disk usage, and a guarded delete-raw-MongoDB-files action). Implementation
  of the in-app pieces follows.

• Sandstorm: Admin Panel / Attachments / Sandstorm (migration status + free raw-MongoDB disk space):

  Implemented the in-app pieces from the design above. When WeKan runs inside a
  Sandstorm grain (isSandstorm), a new Sandstorm section appears in Admin
  Panel / Attachments showing whether the one-time MongoDB 3 → FerretDB v1
  migration succeeded, and the disk space the raw MongoDB 3 database files, the
  FerretDB SQLite, and the attachments/avatars currently use inside the grain.
  An admin can delete the now-redundant raw MongoDB files to free disk space —
  guarded so it only runs after a confirmed-successful migration, behind a
  confirmation. New admin-gated server methods sandstormMigrationStatus /
  sandstormDeleteRawMongo (server/methods/sandstormMigration.js);
  the migration importer now writes a migration-status.json the panel reads.

• Sandstorm: grain launcher + spk build tooling (Node 24 / FerretDB, no releases.wekan.team):

  Added the grain launcher sandstorm-src/start.js:
  on first launch it runs the migration chain for whatever an existing grain holds —
  niscu (MongoDB 2.x) → MongoDB 3.0 (the preserved legacy path for very old grains) then
  MongoDB 3.0 → FerretDB v1 — then runs WeKan (Node 24) on FerretDB. Migration support from
  old versions is permanent (niscud + mongod 3.0 are kept). Added the deps-assembly script
  sandstorm-src/build-deps.sh
  which builds a modern meteor-spk.deps on top of upstream meteor-spk 0.6.0
  (dl.sandstorm.io) — swapping in Node 24, adding FerretDB + the Mongo 3.x CLIs + the
  launcher/importer, keeping niscud — with extra binaries fetched from GitHub releases
  (the retired releases.wekan.team / old projects.7z are no longer used). sandstorm.yml
  now calls it, and WRITABLE_PATH in sandstorm-pkgdef.capnp is /var/files. Build/CI only —
  not yet packed/tested end-to-end in a grain.

Thanks to xet7.

Thanks to above GitHub users for their contributions and translators for their translations.