PrimeNG is no longer open source: what changed, what it costs, and your options

If you build Angular applications, there is a reasonable chance one of them depends on PrimeNG. It has been one of the most widely used Angular component libraries for a decade, and until 2026 it was MIT licensed. That changed. This article sets out exactly what changed, what it now costs, and what your realistic options are.

What actually changed

PrimeTek archived the PrimeNG repository and continued the work under a new name, PrimeUI, on a commercial licence. The last MIT-licensed release remains MIT — an existing licence cannot be revoked retroactively — so the version you already depend on stays free forever. What is no longer free is everything published after it.

• The MIT-licensed PrimeNG releases you already use remain MIT, permanently. Nothing about your current installation changes.
• The successor, PrimeUI, ships under a commercial licence with a restricted free Community tier.
• PrimeUI packages are distributed compiled, without source, which is a meaningful practical difference from an MIT dependency you can read and patch.
• The commercial licence contemplates the software displaying a licence notice where a key is missing or invalid.

The price list, in full

PrimeUI is sold per developer, as a perpetual licence with one year of updates included. After that year, updates stop unless you renew; the version you hold keeps working.

The standalone Pro components are worth noticing, because they are priced separately from the main licence. A team that needs the Scheduler is looking at the per-developer commercial licence plus a second per-developer figure for that one component.

What that means over three years

Per-developer, per-year pricing compounds in a way a single sticker price does not show. For a team of ten, buying at the launch rate and renewing for two further years, the arithmetic is ten times $599, then ten times $399 twice.

The free tier, and who actually qualifies

PrimeUI has a Community tier at no cost. The eligibility is conjunctive — you must satisfy every condition, not any one of them.

• Under $1M in annual revenue.
• Fewer than 5 developers.
• Fewer than 10 employees.
• Under $3M in venture funding raised.

It covers individuals, students, non-profits and non-commercial open source. Read the conditions carefully against your own organisation before assuming you qualify: a company with eleven employees and no revenue is outside the tier, and so is a well-funded startup with three developers. The thresholds are also the kind of thing a company crosses without noticing, which makes this a licence you have to re-check rather than set and forget.

Is anyone actually leaving?

This is the question worth asking before you decide anything, and it has a measurable answer. npm publishes download counts, so here is what they say rather than what anyone claims.

PrimeNG remains one of the most-installed Angular component libraries by a wide margin, at around 944,000 downloads in that week. The first version of this article compared two August weeks and described a fall; later figures did not bear that out, so the claim is gone. What the registry supports is a level on a given week, and that is all this table states.

The community fork, Optimus UI, is at around 36,700 weekly downloads in the same week — real usage, and just under 4% of PrimeNG's count. Most PrimeNG installs have not moved to it.

Your options, including the ones that are not us

There are five realistic paths. Which is right depends far more on your team size, your update appetite and your tolerance for compiled dependencies than on anything a vendor says.

1. Stay on the last MIT release

Free, permanent, and requires nothing from you today. You keep an MIT licence and full source. What you give up is future Angular-version support, security fixes and new components. This is the right answer for an application in maintenance, or one on a fixed Angular version with a known end of life. It is a poor answer for an application you expect to move to Angular 23 and beyond.

2. Pay PrimeTek

The path of least disruption by a wide margin. Your imports, your API knowledge, your theming and your team's muscle memory all survive; you are buying continuity. It is the right answer when migration cost exceeds licence cost — which for a large application with deep PrimeNG usage it very often does. Do the arithmetic on your real headcount over three years rather than the first-year figure, and check whether you need any of the separately priced Pro components.

3. Move to the community fork

Optimus UI continues the last MIT codebase under the original licence. It keeps your API and it keeps your source. The honest caveat is that a volunteer fork is not a support contract: the question is not whether the code works today but who will do the Angular 23 compatibility work, and how quickly a security issue gets a release. Check its issue tracker and commit cadence yourself before betting a product on it.

4. Move to a headless or copy-paste library

spartan-ng gives you unstyled primitives and copy-paste components with Tailwind styling, MIT licensed, and you own the code once it is in your repository. Angular Material remains free, first-party and enormous. Google's own @angular/aria package now ships accessible headless primitives as a supported part of the framework. This path costs the most engineering time and buys the most control; it suits teams with a design system and the appetite to maintain their own component layer.

5. Move to a different commercial kit

Including this one. The relevant questions are the same ones you should have asked PrimeUI: do you get the source, is the free tier usable without thresholds, is the pricing per developer per year or one-off, and does anything in the product change behaviour if a licence key is absent. Ask them of every candidate, including Styloviz.

A way to decide

1. Count how many developers actually need a licence — usually fewer than the whole team. Multiply by three years, not one.
2. Check the Community thresholds against your organisation honestly, including where you expect to be in eighteen months.
3. Estimate the migration cost of your ten most-used components. If it is under the three-year licence cost, migrating is the cheaper path; if not, paying is.
4. Decide whether shipping a compiled dependency you cannot read or patch is acceptable in your codebase. For some regulated environments it is not, and that decision is made for you.
5. Whichever way you go, pin your versions and write down the decision and its date. The next person will need to know why.