FR
live

Planka strips SSO from its community edition and deactivates OIDC accounts on upgrade

On August 9, 2026 Planka shipped version 2.2.0, which removes OIDC/SSO from the community edition and deactivates the accounts that depended on it. Before you upgrade, create a local admin account or you risk locking yourself out of your own instance.

A white access badge snapped into two halves on a dark desk, the amber circuitry exposed on one of the pieces.

August 9, 2026. Planka shipped version 2.2.0 of its self-hosted kanban, and the release notes open with a warning in bold: “OIDC/SSO has been removed from PLANKA Community.” On August 14, Self-Host Weekly led its editorial with the story. The consequence for production instances is immediate: every account that signed in through SSO is deactivated when you upgrade.

If your Planka instance relies on OIDC or SAML for authentication, this is not a routine update. It is a business-model change that lands on your doorstep with a trap built in: an admin who exists only through SSO ends up locked out of their own instance.

What 2.2.0 actually does

The release notes leave no room for doubt. OIDC/SSO authentication is removed from the Community edition and moved into the paid Planka Pro tier. The mechanics are explicit:

  • After the upgrade, all SSO-based users are deactivated, because they no longer have a local password.
  • An admin can restore access by setting a password for each affected user and reactivating them, one at a time.
  • If your only admin account is SSO-based, you are locked out. The docs tell you to create a local admin before upgrading.

Two other changes ride along. The release requires Node.js 24 for manual installs — Docker deployments are unaffected — and drops the armv7 Docker images. That is a footnote for most x86-64 or ARM64 homelabs, but Raspberry Pi 3 and other 32-bit boards stay on 2.1.1.

The takeaway is operational, not technical. An update that silently deactivates accounts — possibly including the admin — is not routine maintenance. It is a migration, and it deserves to be treated as one.

The SSO tax, arriving after the fact

This move has a name in the self-hosted world: the SSO tax. The logic is simple — single sign-on is a feature an organisation cannot afford to lose, so some projects put it behind a paywall to generate revenue. The sso.tax site catalogues the pattern, and Planka is far from the only offender.

What sets Planka apart is the timing. Most projects that practise the SSO tax do it from day one: the feature was never free, so the user chooses with eyes open. Here, SSO/OIDC was available in the community edition, used in production by teams and non-profits, and it is being removed retroactively. For people who invested time and infrastructure in the platform, that is a rug-pull, and the reaction on the GitHub repository (issue #1754) matched the frustration.

It also matters for the security of small instances. SSO is not an enterprise luxury: for a small team it is often the only clean way to handle departures, access revocation and strong authentication. Stripping SSO from the free edition pushes those teams toward two bad options — paying for a feature that was free, or falling back to shared local passwords.

To be fair, the other side deserves a hearing. The Planka maintainers owe nobody anything, and maintaining open source does not pay the bills — the line “Commits on GitHub don’t pay for groceries,” spotted in the same Self-Host Weekly edition, sums up the tension. A vendor has every right to hunt for a sustainable business model. The question is not whether to monetise but how: removing an existing security feature, while deactivating the accounts that used it, is the most brutal way to do it.

None of this changes the operational reality. For an instance whose users sign in through an identity provider, 2.2.0 is a forced choice with a deadline — and the only wrong move is to discover that deadline at the next docker compose up -d.

What you gain in exchange

By an irony of timing, 2.2.0 is not a stripped-down release. It adds security features for local accounts precisely where it removes federated login:

  • Two-factor authentication (TOTP) for local accounts, with ten recovery codes and an admin reset.
  • Auto-logout on inactivity, with a configurable timeout and a warning before sign-out.
  • Trusted devices: mark a browser as trusted to skip 2FA for a set period, with a list and per-device revocation.

In other words, the release hardens local authentication at the exact moment it removes federated authentication. The message is unambiguous: 2FA is free, OIDC is paid. For a solo homelab or a small team without SSO, this release is a genuine improvement. For an organisation that leans on an identity provider, it is a clear regression.

How to know if you are affected

Before deciding anything, check whether your instance actually uses SSO. Two signals are enough: accounts created via OIDC/SAML in the user list, and an identity provider configured in your deployment. If everyone signs in with a local username/password, 2.2.0 will deactivate nobody — the only remaining impact is the Node.js 24 requirement for manual installs and the end of armv7 images.

If a single account — even yours — goes through SSO, treat the upgrade as a migration, not a routine update.

The check takes minutes and costs nothing; the lockout it prevents can cost an afternoon.

Your options before the upgrade

If you depend on SSO, you have four exits, and you need to choose before you run docker compose pull.

The first is the simplest: do not upgrade. Pinning the image to the last compatible release is defensible in the short term while you prepare the migration:

yaml
services:
  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    # stays on the last release that still includes SSO/OIDC

The second is to create a local admin before upgrading, so you never risk a lockout. Since 1.13, Planka no longer creates an admin automatically; you create one via script or environment variables:

bash
docker compose run --rm planka npm run db:create-admin-user

The third is to migrate to Planka Pro, where SSO remains included and supported. Migration from the Community edition is documented and handled from the customer panel after purchase.

The fourth is to switch tools. The self-hosted kanban market is crowded — Vikunja, Focalboard, Kanboard or Wekan cover comparable needs with different monetisation policies. It is the most expensive option in time, but the only one that does not leave you dependent on a feature the vendor can withdraw overnight.

Verdict

Planka remains an excellent self-hosted kanban, and 2.2.0 brings real value — TOTP 2FA and automatic logout were long overdue. The problem is not the engineering, it is the method: removing an existing security feature from the free edition, while deactivating the accounts that used it, sets a precedent that weighs on long-term trust.

If you do not use SSO, 2.2.0 is a clean upgrade: you gain 2FA, auto-logout and trusted devices, and lose nothing.

If you run OIDC/SAML in production, do not upgrade until you have created a local admin and chosen a destination — Planka Pro, a fork, or a competing tool. Pinning 2.1.1 buys you the time to decide without enduring a lockout on the next docker compose up -d.

References

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

HCCF submits its bid to ICANN for the .self domain, a TLD built for self-hosting

The Human-Centered Computing Foundation has filed its application with ICANN for the .self top-level domain, a namespace designed for self-hosted, human-centered projects. Behind the symbol, the real question is what a domain name can actually guarantee — and whether .self will serve self-hosters or mark them as targets.

Jellyfin loses three core maintainers in a week and renumbers its releases

Within a single week, Jellyfin saw three of its most experienced maintainers leave, including long-time project leader Joshua Boniface, who stepped down citing burnout. The project then settled a long-running versioning question and will jump straight to 12.0 — here is what that means for your server.

← Back to the feed

Type at least two characters.

navigate open esc dismiss