The SSO Tax: Why Self-Hosted Projects Are Gating Login Behind a Paywall

You spin up a new self-hosted tool, get it running on your own server, and reach for the one feature that would let you log in the way you log into everything else. Single sign-on. It's sitting behind an "Enterprise" badge you can't unlock without a sales call.

That moment has a name now: the SSO tax.

What the SSO Tax Actually Means

The SSO tax describes a specific pricing pattern in open-core software: the project ships a free, self-hostable community edition, but reserves single sign-on, usually SAML specifically, for a paid Enterprise or Cloud tier. It's become common enough across self-hosted tooling that self-hosting communities now use the term as shorthand, the way "vendor lock-in" or "walled garden" get used elsewhere.

The frustration isn't abstract. A lot of self-hosting exists specifically to avoid recurring SaaS fees and vendor dependence. Watching your login method become the upsell, in the tool you chose partly to dodge upsells, lands differently than it would on a normal SaaS pricing page.

A Rug Pull, Not Just a Paywall

Planka, a project management tool popular with the self-hosting crowd, is the clearest recent example. Its v2.2.0 release pulled single sign-on out of the community edition entirely. This wasn't a feature launching paid from day one. People had already built their setups around it, and then it was gone. Self-hosting newsletters covering the change described it as a rug pull for users who'd already invested time and infrastructure around the feature, and the reaction across self-hosting communities was not a kind one.

That distinction matters for how you evaluate a project going in. A tool that never offered free SSO is making a business decision you can weigh before you commit to it. A tool that removes a feature you're already depending on is a different kind of risk, and it's one the community treats as a trust violation, not just a pricing update.

Who Gates What

The tax doesn't apply uniformly. Look across a handful of open-core projects and the actual line usually falls at a specific protocol, not at "SSO" as a category.

Grafana's own documentation states SAML is available in Grafana Enterprise and Grafana Cloud, while generic OAuth, GitHub OAuth, LDAP, and the auth proxy stay in the open source build. That's a meaningfully different situation than Passbolt, which documents SSO of any kind, including specific providers like Keycloak and Entra ID, as Pro and Cloud only. Metabase draws its line at SAML specifically, same as Grafana. PostHog goes a step further than any of these: SSO enforcement itself, not just SAML, is gated behind a paid add-on.

None of this is hidden. It's usually stated plainly in each project's docs. But "documented" and "obvious before you've built your stack around a tool" are different things, and that gap is where most of the frustration actually lives.

Why This Specific Feature, and Why Now

Enterprises need SSO for compliance and onboarding at scale, so vendors know exactly which line to draw to capture that budget. One recurring complaint from self-hosting communities is that the SSO tax almost never shows up in a project's first paying tier. It waits for the enterprise tier, priced for companies with policies that require it, which puts it out of reach for someone paying out of pocket specifically to avoid a SaaS subscription.

What's Out of Scope Here

This isn't a list of every open-core project with a paywalled feature, and it isn't a legal or ethical judgment on open-core as a business model. Projects have to fund development somehow, and reserving genuinely enterprise-scale features (SCIM provisioning, audit logs, dedicated support) for a paid tier is a defensible choice most self-hosters accept without complaint. What this piece covers specifically is the subset of that pattern where login itself, the thing every user needs on day one, is what gets paywalled, and where that line sometimes moves after the fact, as with Planka.

What to Check Before You Commit

If SSO matters to you, don't take "supports SSO" at face value. Check three things in a project's docs before you deploy it:

• Which protocol is actually gated. Generic OAuth and OIDC are often free; SAML specifically is the usual paywall line, as the table above shows.
• Community edition versus self-hosted paid license. Some projects sell a paid self-hosted license separately from cloud hosting. Read carefully which one includes the auth features you need.
• Version history for feature removal. Planka's case shows a free feature can become a paid one in a point release. Check the changelog, not just the current feature list, before you build around anything.
  If you land on a tool that doesn't support SSO in the tier you can afford, an identity proxy sitting in front of the app is a reasonable workaround. How Authentication Actually Works breaks down the session and OAuth mechanics that make this possible: you're not modifying the gated tool at all, just handling authentication upstream of it before requests ever reach the app. It's more setup than flipping a switch in a settings page, but it keeps you off the enterprise price list for a feature that used to be table stakes.

If you're auditing your broader self-hosted stack for maintenance costs rather than feature paywalls specifically, What Self-Hosters Are Ripping Out of Their Stacks in 2026 covers a related but different problem: services people are dropping not because of pricing, but because of the ongoing operational burden of running them at all.