Self-hosted Jira alternatives: OpenProject, Plane and Vikunja compared

Do you want to run project work in house? WZ-IT chooses the right tool, migrates what exists and takes on operations, see managed open source. Discuss your setup

Lists of Jira alternatives are plentiful, and most share a problem: they are copied rather than checked. Two of the most frequently named candidates have not been developed for years, and that appears in hardly any of those lists.

This article first checks what is still alive, then compares the three active candidates, and answers the question the decision usually turns on in companies: where does the free edition end.

All details from the repositories and vendor pages, as of 31 August 2026.

Table of contents

• What is left of the usual recommendations
• The three active candidates
• Three ways to draw a commercial boundary
• OpenProject
• Plane
• Vikunja
• Single sign-on as the dividing line
• What a migration from Jira really costs
• Which one for which situation
• How we approach this at WZ-IT
• Further guides

What is left of the usual recommendations

Before comparing features, the date of the last commit is worth a look. For two common recommendations it is sobering.

Taiga appears regularly in recommendation lists. The canonical repository was last touched in December 2023, nearly three years ago. No actively maintained successor is apparent.

Focalboard has moved from mattermost/ to mattermost-community/ and carries a README notice that it is currently not maintained and that anyone interested in becoming a maintainer should get in touch. The Mattermost plugin version continues separately; the standalone tool does not.

Neither is therefore a viable basis for a new deployment. Anyone using them anyway should do so deliberately, not because they appeared on a list.

The three active candidates

Figures from the public repositories, as of 31 August 2026.

Three ways to draw a commercial boundary

For open-source software with a commercial offering there are three architectures, and they differ above all in how well you can see the boundary in advance.

The third architecture is the least conspicuous. With OpenProject you install the same software whether or not you hold a contract; a key unlocks features. The source therefore does not tell you what belongs to the free edition, because all of it is in there.

That is not an accusation. It only means the test "is the code open" says nothing here about the usable scope. That question is answered by the vendor's feature overview alone.

How such boundaries can shift over the years we assembled in the chronicle of licence changes.

OpenProject

OpenProject comes from Berlin and is the candidate closest to Jira in the classic sense: work packages, Gantt charts, time tracking, budgets, wiki, reporting.

The Community Edition is under GPL-3.0, self-hostable and has no user limit. That is more than many vendors permit in a free edition.

The paid tiers are called Basic, Professional, Premium and Corporate. They hold, among other things:

• portfolio management across multiple projects
• resource planning
• advanced baseline comparisons
• single sign-on

The last point is the most significant for companies, and we return to it below.

Activation happens through a licence key in the same installation. A trial can be requested through the admin interface, which makes comparison before a decision easier.

Plane

At 58,588 stars Plane is the most visible project in the comparison and the youngest. Its orientation is agile: issues, cycles, modules, views as list, board or calendar. Anyone coming from Jira Software who worked in sprints finds their footing quickly.

The public repository is entirely under AGPL-3.0. It contains no directory with a differing licence; the source of the paid tiers is not published.

For assessment this means: what you self-host is fully inspectable. What the paid tiers add can only be taken from the feature overview.

Authentication through an identity provider is available in the self-hosted edition, which makes Plane the more straightforward candidate for companies with central account management.

Vikunja

Vikunja is the leanest of the three and the most honest about its scope: it manages tasks, not projects. Lists, kanban, Gantt, calendar, labels, reminders.

It is under AGPL-3.0, written in Go, and correspondingly modest in memory use. For a small team on a shared server it is the most resource-efficient route.

What it cannot do belongs to the assessment: no portfolio management across projects, no budget tracking, no reporting at OpenProject's scope. Vikunja does not replace Jira but covers the part Jira was oversized for in many teams anyway.

Single sign-on as the dividing line

Across these comparisons a pattern emerges worth stating: the commercial boundary runs strikingly often at integration with central user management.

With OpenProject, single sign-on is an Enterprise feature. With Seafile, LDAP integration sits in the Professional Edition. That is no coincidence: it is the feature that turns a tool from a personal one into a company one, and therefore the point at which paying customers separate from the rest.

For the decision this yields a simple test question that comes before any feature comparison: do accounts have to be managed centrally? If so, integration with Keycloak or Authentik belongs in the cost calculation, and with one of the three candidates it means a contract.

What a migration from Jira really costs

Moving the data is the easy part. Issues, comments and attachments can be migrated.

The effort sits in what Jira has accumulated over years:

Workflows. A grown Jira has status transitions with conditions, post-functions and validators. None of the alternatives reproduces that one for one, and trying to rebuild it is the most common reason migrations fail.

Automations. Rules that assign issues, set fields or trigger notifications have to be rethought.

Custom field types and permission schemes. Both are transferable, but rarely mechanically.

Reports and evaluations. Whatever someone exports monthly has to be producible in the new tool, or it comes back after three months.

The route that works in practice: do not rebuild the estate, but start with a team whose process is simple and migrate the rest afterwards. What is not missed does not have to be rebuilt.

Which one for which situation

How we approach this at WZ-IT

We start with the question of what is actually used in Jira today, not what is configured. In the environments we have seen, the difference between the two is regularly considerable, and it decides whether a lean tool suffices.

Then we settle the authentication question, because with one candidate it triggers cost and with the others it does not. Only then does the feature comparison follow.

We take on operations on request, including updates, backup and a restore test. A migration counts as finished with us once a recovery has worked at least once.

Further guides

• Open-source licence changes - how boundaries shift over the years
• Nextcloud, Seafile, OpenCloud or ownCloud - the same boundary question for file storage
• Authentik versus Zitadel - identity providers for single sign-on
• Keycloak at WZ-IT - connecting central authentication
• Managed open source - operating open-source applications

Unclear which tool fits how you work? We look at what is actually used today, settle the authentication question and support the migration. Book a call

Sources

• OpenProject on GitHub
• OpenProject: editions and pricing
• Plane on GitHub
• Vikunja on GitHub
• Taiga: canonical repository with its last state
• Focalboard: notice about the lack of maintenance