Wekan: self-hosted kanban with a FerretDB default and a MongoDB past

Who Wekan is for, and the problem it removes

Wekan is a collaborative kanban board application under the MIT license. The problem it removes is not "how do I draw columns and cards". Plenty of hosted tools do that. The problem is that the board holds your work items, and the hosted tool holds the board. Wekan is aimed at people who want the second half of that sentence to be their own server. The README frames it plainly: because it is free software, "you don't have to trust us with your data and can install Wekan on your own computer or server."

The audience follows from that. A single person keeping a todo list is a legitimate user, and so is a team running its own instance. The README claims a largest user with 30k users in one company, and lists 234 translation languages at Transifex, 197 of them essentially complete. Treat those as the project's own statements about scale and reach, not as benchmarks you can plan capacity around.

The practical cost of self-hosting is stated in the same document, which is unusual and worth noting. Requirements start at 1 GB RAM free for Wekan, with a production server at a minimum of 4 GB total. For thousands of users the README sketches a topology of three frontend servers, each with 2 CPUs and 2 wekan-app containers, against one backend wekan-db server with many CPUs. That is a real deployment shape, not a hobby footnote.

The Meteor stack, and why the database layer just changed

Wekan is JavaScript. The package.json declares the Meteor main module as client/main.js and server/main.js, and the README states that the main branch uses Meteor 3.5 with Node.js 24.x. The Dockerfile goes further and pins NODE_VERSION=v24.21.0 and [email protected], with DDP_TRANSPORT=sockjs. That last variable is the real-time transport: the README's feature line says Wekan "has real-time user interface", and sockjs is how the client keeps that connection open.

The database story is where the repository layout is most informative. The default docker-compose.yml does not run MongoDB. Its header comment describes it as "FerretDB v1 with the embedded SQLite backend", using the wekan/FerretDB fork, and explains that FerretDB "speaks the MongoDB wire protocol". So Wekan's application code still talks to something that looks like MongoDB, but the storage underneath is SQLite files on a volume. Attachments and avatars go to the filesystem, not into the database.

That is a deliberate trade. A single container plus a volume is far easier to stand up than a replica set, and the compose file notes the FerretDB binary is downloaded once and then cached on the volume, per architecture. The cost is that you are no longer on MongoDB, and the repository keeps the alternatives visible: docker-compose-ferretdb-v1-postgresql.yml, -mysql.yml, -mariadb.yml, -sap-hana.yml, docker-compose-ferretdb-v2-postgresql.yml, docker-compose-mongodb-v7.yml, and docker-compose-multitenancy.yml. The existence of that list tells you the default is a choice, not a requirement.

Installing Wekan with the default compose file

The README points downloads at https://wekan.fi/install/ and lists container images on GitHub Container Registry, Quay and Docker Hub. The default docker-compose.yml is the shortest path, and its header comment gives the commands directly. Because it is the default file, no -f flag is needed.

Start the stack in the background:

docker compose up -d

Follow the logs to confirm the app and the database came up. The compose file documents this exact command:

docker compose logs -f

Stop it again with the documented command:

docker compose down

What you should see is a Wekan instance reachable on your host, backed by FerretDB v1 and SQLite on a volume. The compose header states that the FerretDB binary is fetched from the newest wekan/FerretDB release and cached on the volume, and that only the asset matching your architecture is downloaded, so the first start is slower than later ones. The README also warns that the latest tag tracks the newest release, which is convenient and also means a pull can move you forward without warning.

If you would rather run MongoDB 7, the repository ships docker-compose-mongodb-v7.yml for that, and the FerretDB v1 files for PostgreSQL, MySQL, MariaDB and SAP HANA. Switching means passing the file you want with -f. The README does not document a migration path between those database backends, so pick before you put real boards in.

Building from source is a two-level menu, not a single command

If you want to run the development server rather than a container, the README is explicit about prerequisites: Git, Node.js 24.x, and Meteor. It recommends nvm for the Node install and shows the commands, including nvm install 24 and nvm use 24. Meteor installs with the standard installer script.

curl https://install.meteor.com/ | sh

After that, the README says to run ./build.sh, or ./build.bat on Windows. The script is not a one-shot build. It presents a two-level menu whose top level groups options into categories: 1) Setup, 2) Dev server, 3) Tests, 4) Docker, 5) Tools, 6) Quit. You choose a category number, then an item number inside it, and each submenu has a Back entry.

This is a fair design for a project with this many deployment targets, and it is also a small friction point for automation. A CI job that expects one command to produce a build will need to drive the menu or read the developer documentation instead. The README points contributors at docs/DeveloperDocs/Build-and-Create-Pull-Request.md for the fork and build steps, and at docs/DeveloperDocs/Developer-Documentation.md for the rest. For testing, package.json defines npm test for the Meteor mocha driver, npm run test:unit:node, and a Playwright suite under tests/playwright with its own install step.

The operational limits the README admits to

The most useful part of this README is the section most projects omit. Under Requirements it says: "If you run out of disk space, MongoDB database gets corrupted." That sentence sits next to a demand for enough disk space and alerts about low disk space. If you are running the default FerretDB and SQLite compose file, the storage engine differs, but the underlying point about a full volume stands as an operational risk you should monitor rather than assume away.

The backup requirement is equally blunt. Backups of the Wekan database are expected once a day minimum, and the README lists what can eat your data: bugs, updates, users deleting a list or card, a full hard drive, a hard drive crash. Then the line that should decide your rollout: "There is no undo yet." It adds that some bugs can cause a board not to load at all, requiring manual fixing of database content.

The support policy is the other constraint. The README states that only the newest Wekan is supported and that old versions have security issues because of old Node.js versions, and it asks you to check that automatic updates for Snap or Sandstorm are not turned off. That is a maintenance posture, not a bug. It means Wekan is the wrong tool for an environment where a deployed version must stay frozen for compliance or change-control reasons, and where nobody owns the upgrade.

One more honest data point: the Standard for Public Code assessment, made at 2023-11, found Wekan meets 8 of 16 criteria out of the box, with the project noting some others could be met with small changes. That is a self-reported scorecard, and it is more informative than a badge.

Where Wekan sits against Trello, Kanboard and Planka

The comparison that matters is not feature lists, it is where the board lives. Trello is a hosted service: you get the board immediately and someone else runs the database, the backups and the upgrade schedule. Wekan inverts that. You get the FerretDB or MongoDB instance, the volume, the disk-space alerts and the daily backup job. The README's own framing is that you do not have to trust the vendor with your data, and the price of that is exactly the operational list in the previous section.

Against other self-hosted boards, the difference is the runtime and the storage. Kanboard is a PHP application with a SQL database, which is a smaller operational surface if you already run PHP and MySQL. Wekan is a Meteor application with a Node.js 24 runtime and a real-time transport, and its default compose file now pairs it with FerretDB over SQLite. If your team already operates Node and containers, Wekan fits that muscle memory. If your team operates PHP and a relational database, Kanboard asks less of you.

Planka is the other name that comes up in the same searches. The repository does not document Planka's internals, so the honest statement is narrower: Wekan's distinguishing documented facts are the MIT license, the Meteor and Node.js 24 stack, the multi-database compose files, and a self-reported 234 translation languages. Anyone choosing between them should compare those specifics against the other project's own documentation rather than against a summary.

License, upgrades and the cost of staying current

Wekan is MIT licensed, stated in both the README and package.json. That is a permissive license, and it means you can run, modify and redistribute the code with few conditions. It does not mean the project owes you support. The README points commercial support at https://wekan.fi/commercial-support/ and says sponsors can fund features and bugfixes, which is the usual arrangement for a permissively licensed project with a large surface area.

On upgrades, the repository gives you the tools to see what changed: CHANGELOG.md, and a release cadence visible in the tags, with v11.24, v11.23 and v11.22 all pushed on 2026-08-29. The last push to the repository was on 2026-08-29. The README describes fixes and features being added many times a day and asks users to report new bugs immediately.

The practical upgrade cost is therefore not the download, it is the testing. A board that fails to load after an update is a manual database repair, per the README, so the sequence that makes sense is: back up first, upgrade a staging instance, confirm the boards open, then move production. The README does not document a rollback procedure, so your restore path is the backup, which is another reason the daily backup line is not optional advice. Note also that the Docker image's latest tag follows the newest release, so pin a version tag if you want the upgrade to be a decision rather than a side effect of docker compose pull.

Editorial conclusion

Adopt Wekan if you want an MIT-licensed kanban server you can run yourself and you are willing to keep it on the newest release, because the README states that only the newest version is supported and that old versions carry security issues from old Node.js runtimes. Do not adopt it if you need a single stable release to sit untouched for a year, or if you cannot run daily database backups: the README says there is no undo yet and that some bugs can leave a board unloadable until the database is fixed by hand. Before rollout, verify three things on your own hardware: that the default docker-compose.yml comes up and persists across a restart, that your backup job actually restores into a scratch instance, and which compose file matches your database preference among the FerretDB variants and docker-compose-mongodb-v7.yml.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes