Vikunja vs PLANKA

These two look interchangeable in a screenshot. They are not. Vikunja is a task manager that happens to have a board view: list, table, kanban, calendar and gantt are five ways of looking at the same tasks, and a CalDAV endpoint at /dav pushes those tasks into a phone app. PLANKA is a Trello clone: projects, boards, lists, cards, drag and drop, markdown descriptions, and instant sync between everyone staring at the same board.

Pick the shape you need, then read the licence. One of these two has changed its licence twice.

PLANKA is not open source any more#

Settle this first. PLANKA was MIT, then AGPL-3.0 from 2023, and since the 2.0 release candidates in May 2025 the community edition ships under the PLANKA Community License, a Fair Use License derived from n8n's Sustainable Use License and held by PLANKA Software GmbH. That is source-available, not open source, and it fails any procurement checklist that requires an OSI-approved licence.

For most readers it costs nothing. It permits, free and indefinitely:

• personal use
• hobby use
• educational use
• internal-organization use

It forbids:

• giving board access to anyone outside your own legal entity in a commercial relationship
• running PLANKA as a hosted service for other people
• selling anything whose value derives from PLANKA

Consulting about PLANKA is fine. A company running its own delivery boards is fine. An agency that puts clients on a shared board is not, and needs Pro. Two smaller traps: files with .pe. in the name or path are Pro/Enterprise code and not covered by the community licence, and the 1.x tags remain AGPL-3.0, so pinning 1.x keeps copyleft and loses every 2.x security fix. Licence drift has the wider pattern.

The version that actually hurts: 2.2.0#

The licence is a policy problem. This is an operational one. PLANKA 2.2.0, August 2026, removed OIDC from the community edition and moved it to PLANKA Pro. Because SSO-based users have no password to fall back on, the same upgrade deactivated every one of those accounts. An administrator then has to set a password for each user and reactivate them one at a time.

If your PLANKA sits behind Authelia, authentik or Pocket ID today, plan that migration before you pull the image. Forward authentication at the proxy still gates the app, but it does not create PLANKA logins, so you end up with local accounts either way. Single sign-on for self-hosters covers what forward auth can and cannot do, and Authelia vs authentik covers the provider choice.

Vikunja is the mirror image: OpenID Connect against any provider is built in, with LDAP added in 1.0.0, and no plugin.

What the spec table decides#

Three rows carry the whole comparison. Licence is AGPL-3.0-or-later against a Fair Use License, which is the section above. Idle memory is 70 MB against 220 MB, which on a Pi or a small VPS is a real number rather than noise. Datastore is SQLite by default for Vikunja and PostgreSQL only for PLANKA, which is why the backup shapes differ: a SQLite backup against a Postgres dump.

Operational load is 2 out of 5 against 3. Vikunja is one binary plus an optional database; PLANKA is always two services, and its 2.x line ships breaking changes worth reading before every minor upgrade.

Vikunja's upgrade history is short and sharp#

Vikunja is eight years old (first tagged release 0.1 in September 2018) but its stable line is barely a year old. 1.0.0 landed on 27 January 2026 after more than a year with no stable release, and 2.0.0 on 25 February 2026, four weeks later, to fix four CVEs and rebuild session handling. Three changes in that sequence break stacks that are not updated in step.

The two container split is gone. Through 0.22, Vikunja ran as a separate api and frontend pair with an nginx splitting /api from /. 0.23.0 merged the repositories and deprecated the vikunja/frontend image. Run vikunja/vikunja alone, delete the frontend container and the splitting proxy, and send all traffic to port 3456. staticpath was removed and frontendurl became publicurl. Skip that and you get 502s and a blank page.

CORS is on by default since 1.0. service.publicurl must match the URL the browser actually uses, scheme and port included. Get it wrong and the UI renders, then every API call fails with something opaque that never says CORS. Fix the public URL before rummaging in your proxy config.

environment:
  VIKUNJA_SERVICE_PUBLICURL: "https://tasks.example.org"
  VIKUNJA_SERVICE_SECRET: "<openssl rand -hex 32>"
  VIKUNJA_DATABASE_TYPE: sqlite

Without VIKUNJA_SERVICE_SECRET, sessions reset on every container restart. Mount /app/vikunja/files for attachments and backgrounds, and chown the host directory first: the container runs as uid 1000 with no group.

1.0 changed OpenID config from a list to a map, keyed by provider name, and the upgrade does not rewrite it. An old-format config produces no provider buttons and no error at all, so edit config.yml or the VIKUNJA_AUTH_OPENID_* variables by hand and keep password login on until the new config works. 2.0.0 invalidates every session to fix CVE-2026-27575, where sessions stayed valid after a password change, so budget for a fleet-wide logout and a matching desktop build. An update strategy that does not lose data generalizes the discipline.

One person's tasks, or one team's board#

Vikunja suits a person managing their own work. Due dates, reminders, recurrence, labels, priorities and per-project permissions sit under five views of one task set, and the gantt view is real rather than a plugin. First run drops you on a registration screen instead of a seeded admin account, so register immediately and turn open registration off. It is the better answer for anyone leaving Todoist.

PLANKA suits a small team managing shared work. Drag and drop feels like Trello because it is trying to, and the live sync is the point: two people moving cards on the same board see each other do it. Vikunja's kanban view does not give you that. Now the parts nobody advertises.

Vikunja is bad at realtime collaboration, and its CalDAV, the headline feature, is still labeled early alpha in its own documentation. Thunderbird 68 and iOS CalDAV Sync are listed as not working, ATTACH, LOCATION and ORGANIZER are unsupported, and recurrence rules sync out and never back in. If you are choosing Vikunja because "it has CalDAV", test your exact client before migrating anything.

PLANKA is bad at everything that is not a board. No CalDAV endpoint, no gantt view, no five views over one task set, no free SSO. It is also the heavier of the two by design: a Node.js process holding an open websocket per connected client, so memory grows with concurrent viewers rather than card count.

The defaults that will embarrass you later#

PLANKA's shipped compose has two settings you must change.

• SECRET_KEY=notsecretkey is the published example value, and it signs every access token. Leave it and anyone who has read the repository can mint a token for any account on your instance. Recent versions warn on every start until you fix it.
• POSTGRES_HOST_AUTH_METHOD=trust with a passwordless DATABASE_URL. Contained while the database stays on the compose network. Publish 5432 for a backup tool and anyone who reaches it connects as superuser.

openssl rand -hex 32   # SECRET_KEY, before the first user logs in

Changing SECRET_KEY later kills every existing session, so do it first. SECRET_KEY__FILE and DATABASE_PASSWORD__FILE read both from Docker secrets, the pattern in Docker Compose conventions.

Then pin a version floor. PLANKA 2.2.1, released 10 August 2026, one day after 2.2.0, fixed a path traversal in the static file routes that let any authenticated user read arbitrary files from the server, configuration included. There is no workaround short of trusting everyone who holds an account, so if you are on 2.2.0 or earlier in the 2.x line, that upgrade comes first.

Vikunja's equivalent is the restore path: vikunja dump wraps config, database and files into one zip, but the matching restore had a zip traversal bug fixed in 2.0.0 (CVE-2026-27819). Only restore archives you made yourself.

Backups are two different jobs#

Vikunja: the database plus /app/vikunja/files. On SQLite, check where the file actually is first, because 1.0 changed relative SQLite paths to resolve against service.rootpath, and use sqlite3 <db> ".backup out.db" rather than a live cp. On Postgres take a pg_dump. The files directory is regenerable from nothing.

PLANKA: the Postgres database plus the /app/data volume, in that order. The repo's own docker-backup.sh is blunt in its header: it runs pg_dumpall first and copies files second, so anything created in the gap leaves an inert orphan. Stop the app or take a volume snapshot. The archive is also written in the clear unless you set BACKUP_PASSPHRASE, while containing password hashes, live sessions, TOTP secrets and recovery codes, SMTP credentials and API keys. Push it into restic or another encrypted target. Backing up a running database and Backups that actually restore cover the rehearsal that makes any of this real.

Which one for your situation#

What to do next#

One question: does more than one person need to move the same card at the same time? If no, run Vikunja with SQLite, set VIKUNJA_SERVICE_PUBLICURL and VIKUNJA_SERVICE_SECRET before first start, then register the first account and disable open registration. If yes, run PLANKA, generate a real SECRET_KEY, set a Postgres password instead of trust, and start on 2.2.1 or later.

Either way, put it behind Caddy rather than exposing port 3456 or 3000, and write the restore procedure down before you have data worth restoring. The rest is in Productivity.