Migrating Nx core to Rust & deprecating custom runners

[vsavkin]

UPDATE: Thank you for engaging with us. We took your feedback very seriously and clarified a few things. Most importantly, self-hosted remote caching provided by Nx Powerpack is free for small businesses and OSS projects. See here and here for more information.

We also added new ways of getting feedback and involve the community. See here.

Hi folks,

We are migrating Nx core from TypeScript to Rust, with a target completion date of 2025. The main reasons are to improve Nx's speed, reduce its package size, and enable a more powerful command-line interface.

While the rewrite to Rust brings many benefits, it also introduces some limitations, particularly with extensibility APIs. One example is the rarely-used API that allowed users to completely swap out Nx's task runner. While this offered theoretical "infinite" flexibility, it also meant Nx couldn't provide direct support for the use cases it enabled, leading us to discourage its use. In fact, we stopped generating any task runners properties in new Nx workspaces several years ago.

Despite the flexibility, very few concrete use cases for custom task runners emerged. The most common was larger teams wanting to use a self-hosted remote cache. Many such teams now use Nx Cloud (which starts free for small teams), but some still value the ability to choose their own solution.

To address this, we've introduced Nx Powerpack, which includes a dedicated solution for remote caching. Powerpack users can opt for our S3 or shared filesystem cache via new Nx plugins. If your team needs additional plugins for remote caching, please contact us at powerpack-support@nrwl.io.

Another niche use of custom task runners was allowing Nx contributors to experiment with runtimes like Bun and Deno before they were officially supported. We encourage contributors to work with us directly to integrate such changes into Nx's open-source task runner.

We understand that this change would mean that some teams may need Nx Powerpack. While it's a premium product designed for professional teams, we know that every Nx user's situation is unique. We therefore have the following options available:

• Open-source workspaces can use Nx Powerpack and its plugins for free, just like they have always been able to use Nx Cloud's Pro plan for free.
• If you belong to a smaller team with limited resources but feel you would benefit from the features of Nx Powerpack, please contact us at powerpack-support@nrwl.io, and we will help you out.

Finally, if you have specific use cases for custom task runners that we haven't covered, don't hesitate to open an issue.

Thank you,
Victor Savkin & Nx Core Team

[Jordan-Hall]

Another niche use of custom task runners was allowing Nx contributors to experiment with runtimes like Bun and Deno before they were officially supported. We encourage contributors to work with us directly to integrate such changes into Nx's open-source task runner.

With regard to this, I would have helped add support for Bun into Nx's own task runner, but at the time Bun didn't support half the modules Nx uses and would only work with web workers over IPC. I did actually provide feedback to the Nx team as there were some benefits over IPC.

I want to express my disappointment that Nx has refused to consider opening up remote caching in Rust. All competitors have either opened up this ability or are working on it.

1. https://rushjs.io/pages/maintainer/build_cache/#enabling-cloud-storage
2. https://www.pantsbuild.org/2.21/docs/using-pants/remote-caching-and-execution
3. https://bazel.build/remote/caching
4. https://turbo.build/repo/docs/core-concepts/remote-caching#self-hosting
5. [feature] Support Remote Execution API for caching moonrepo/moon#1520 (comment)

While I respect that Nx has venture capital to consider and needs a return on investment, and that this is Nrwl's business, I believe most enterprises would still pay for Powerpack. However, smaller teams and indie developers would much prefer to host their own. Personally, I have privacy concerns with any cloud—no offence—and would much prefer to control it myself. Taking away a functionality that you admitted was used by the community and putting it behind a paywall is disheartening.

Regarding Powerpack, I find the pricing confusing, particularly in terms of how many seats are required. Does each developer need a seat to use Powerpack? Have you considered selling sections of Powerpack independently and adjusting the pricing for small teams?

edit:

I don't like this but i'm forking NX core to consistently add API first in the JS and then into the rust to ensure community solutions can still work. I think disingenuous to call this and focus so much on task runner when this move actually remove NX support for free custom cache. Again love you guy and women but please rethink and allow the API to be open at all point not eventually.

[Elyahou]

Is it planned to expose an API to add custom remote caching in the Rust implementation ?

[Jordan-Hall]

• If you belong to a smaller team with limited resources but feel you would benefit from the features of Nx Powerpack, please contact us at powerpack-support@nrwl.io, and we will help you out.

Sorry not to keep hating but that comment feels belittling. I'm sorry you made this amazing tool. Caching was extremely useful before but we have limited funds as we not backed by VC yet. Please give me charity.

honestly thats how it reads

[ndrsg]

Shared cache Is also necessary to reuse cache between pipeline runs in a stateless build cluster like kubernetes or will there be another option to achieve this?

From my understanding, without Powerpack or NX Cloud it will not be possible to have "Smart Monorepos AND fast CI" if you dont have a stateful CI executor, but thats something that NX wanted to provide, isnt it?

If you allow a suggestion, you may put features like special/ complicated executors or plugins for e.g. Cmake, Conan or other C/C++ stuff in a powepack, but not core features.

I mean 20% faster sounds great at first, but compared to what? Typical build/test task might take some minutes, it does not really matter if it takes 100ms or 80ms to load it from cache instead.

[ItamarGronich]

So if i TL;DR; this, it can be summed up to:
We just want to put remote caching behind a paywall.

That's legitimate, but know that one of the main reasons we choose Nx is for that specific reason.
Free and self hosted remote distributed caching.

And we are now forced to evaluate other options if they turn up to be cheaper or more flexible.

And my 2 cents about typescript -> rust migration.
Nx is plenty fast. Fast enough. 20% increase in those timescales is negligible. At least from a consumer standpoint.
In my view - the flexibility, configurability and ease of contribution of TypeScript vastly outweighs the speed and size benefits of a rust implementation.

I as a consumer of Nx will greatly appreciate an extensive, robust and well documented programmatic API for Nx rather than any rust re-write and small speed improvement.

Nx is mostly IO bound (except for the caching stuff that needs to hash, read and parse and write a ton of files) can't you just make parts of Nx in rust? like the caching mechanism?

At this point i feel that Rewrite It In Rust™️ is more of a marketing strategy rather than a practical engineering consideration.

Sorry for all the 🌶 takes - i say this as a long time avid NX user.
Really appreciate what you guys are doing.

[el-davo]

In my current job we have a team of 20 developers working on a massive monorepo with NX as the underlying framework.

We chose NX specifically for its free tier features including on prem caching as security is paramount to our organization. We use on prem minio s3 storage that we control and administer ourselves.

I was surprised to learn this week by means of a warning when run pnpm nx serve that on prem caching will soon be behind a paywall

To learn such an important update from a random warning is really poor communication from NX.

I had a look at site for activating powerpack and with the amount of developers working on our project the total comes up to $495.00
USD / MONTH. Again we administer our own storage. Why would we pay such a massive amount every month for this? Does anyone think this is acceptable? And what do we get in return? A rewrite in rust that noone asked for?

A 20% speed increase in a command starting up is nothing in comparison to the speed increase that remote caching offers.

Unfortunatly NX has now lost credibility within our organization, reason being, if you can randomly put caching behind a paywall what's to stop NX from putting other features behind a paywall?

• Want to build an application with module federation - sorry that will be an extra $20 a month
• Want to use the task scheduler - sorry that will be an extra $10 a month
• Want to use local caching - Purchase nx mega powerpack to unlock

We have already started planning for migrating off of NX and are looking into turbo repo as we are not happy with essentially being held to ransom for trusting NX.

I should note that personally I was a massive fan of NX, I was the one who incorporated it into our development process and honestly it has been an amazing journey. I even wrote an article about it here - https://medium.com/better-programming/migrating-an-angular-application-to-module-federation-with-nx-74f7664bab3e?source=your_stories_page-------------------------------------

Thank you for all the work up until now, but if this change goes ahead we will be moving on and I suspect a lot of others will also

[Jordan-Hall]

We have already started planning for migrating off of NX and are looking into turbo repo as we are not happy with essentially being held to ransom for trusting NX.

Thank you for all the work up until now, but if this change goes ahead we will be moving on and I suspect a lot of others will also

100% agree, I've stopped making NX a priority for client. I'll be recommending other tools as well going forward. NX to me now has zero credibility. I also found this quiet disingenuous too around codeowner.

#20926

This is something we've discussed, but is not a priority currently. The best solution for now is to create a local plugin.

He went on to create a community plugin

npm i @swapniltech0390/nx-codeowners

https://www.npmjs.com/package/@swapniltech0390/nx-codeowners

[Jordan-Hall]

The custom NX license states:

“Nx IP” means the Software, algorithms, technology, databases, tools, know-how, or processes used to provide or deliver the Software or related services, and its documentation (“Documentation”), including all improvements, modifications, or derivative works (regardless of authorship), and all intellectual property rights (“IPR”) in any of the foregoing

However, much of this appears to be documented and available under the MIT version of the code. How is this license valid if the API/know-how for producing related software comes from the MIT version?

Does this mean any indie hacker using APIs provided by the MIT or any tweaks to the MIT code to open up would be a breach.

[Ligrev861]

I'm going to post this from an anonymous account because our threads and phone calls should not be about this.
There are several issues here.

The deprecation that prompted this series of threads
I understand Nx wants to be commercially successful but commercial viability looks challenged.
Nx Cloud offers remote caching, agents, dashboards, and log visualization. The paid version even feeds this data into an AI to generate basic insights and costs $250 for 30 people.

Nx Powerpack offers a JSON-to-CODEOWNERS converter, an ESLint rule, and cache self-hosting which was previously available but not marketed.
All current threads on GitHub talk about Powerpack in the context of caching and custom runners so it's not a stretch to assume that caching is its primary selling point.
It offers that at the cost of $717.50 for 30 people.

Assuming an organization with 30 developers, that's almost triple the price if you want to use your own cache and if you gave up on agents, dashboards, and log viz.

I understand these are two completely different products aimed at different target groups but as an engineer I can't help but compare the amount of effort that has gone in one vs. the other and the two are not close. And the way these are perceived informs whether engineers would recommend and implement Nx in their organization.

Unclear terminology in sales pages
Nx would not be my first example for a great documentation, but the Nx pricing talks about "contributors" while the Powerpack pricing talks about "seats".
Are those the same? What counts as a contributor? If a backender who doesn't know Nx is in the tech stack runs a command that sets up their environment and that command happens to run Nx in the background, does that constitue as a seat, a contributor, or neither?

Unclear licensing
Jordan Hall raises an excellent question in his comment, I won't repeat it

Removing previously available functionality
I understand the arguments about making Nx more responsive in benchmarks. Nx has come a very long way and is an excellent piece of software. We all want to see it become the best it can be, but no one wants to part ways with impactful features. We can be generous with phrasing but there's no changing the fact that an impactful feature is getting removed and its primary use is sent into closed-source land.
People are reconsidering their relationship with Nx over this. This is an extremely bad change in terms of PR and it's really tempting to describe it as a rug-pull. Trust is lost all too easily.

Comparison with competing products
At some point, usually before buying anything, people will compare their options. Nx charges for CI optimization. The biggest differentiator there is the cache. Other products listed in Jordan's other comment offer self-hosted caching for free.
There are other things that make Nx great but this is the big one, and Nx is behind.

Public communication: correctness and timeliness
The "Evolving Nx" post spends a lot of time trying to convince developers that no functionality is getting removed (which is disingenuous) and that people should get paid (which no one argues against). These two arguments put next to each other sound manipulative. The way this post is phrased makes it clear that Nx expected the backlash which only makes things worse.

Timeliness is another thing. The post is dated Sep 25th and its follow-up explanation is dated Oct 14th.

Public communication: subjective interpretation

If you belong to a smaller team with limited resources but feel you would benefit from the features of Nx Powerpack, please contact us at powerpack-support@nrwl.io, and we will help you out.

This is great, except that now Nx now has a history of removing core features. This reads as "we can help you adopt Nx but you'll have to hope we won't change the terms again".

Everything in Powerpack is new functionality, not previously free features that we’re now putting behind a paywall

This is only "technically correct" as evident by the recent issues and PRs getting created around this. Nx is offering a product to developers. Nx is taking away building blocks from developers. Nx now has to somehow convince their main audience that this is a good thing.

My team is prototyping micro frontends via module federation and NX in our company and we are potentially exploring the enterprise version of Nx. Our frontend team has always been lean so this wouldn't be a hard sell, nor it would be my money - but the actions and the communication of Nx around this are very encouraging to look for alterntaives.
This all needs addressing - and ideally a step back.

[Elyahou]

Everything in Powerpack is new functionality, not previously free features that we’re now putting behind a paywall

We have our own implementation of the Powerpack features for some time now, with our own implementations:

• Custom Remote Caching to S3, implemented through custom runners.
• Conformance, via a private package leveraging the open Nx API to enforce customizable rules.
• Codeowners Management, through another private package that uses the open Nx API to manage codeowners.
  We also rely on several other tools built on top of the Nx API.

Here’s the issue: Removing the custom runner API directly eliminates a previously free feature (custom remote caching). Forcing us into a subscription for this capability effectively moves it behind a paywall.

What’s next? Will other key Nx APIs be removed, forcing users to subscribe just to maintain custom conformance or codeowners management? This approach erode trust with your community and undermines the value that Nx provided by being open and extensible.

[JCMais]

heh I was looking into NX, but the lack of self-hosted caching without having to pay for an enterprise license is a no-go. I found this thread by looking into alternatives. NX Cloud sounds good enough, but even if we decided to pay, just not having the option to do the remote caching in-house, and for free, is a huge blocker.

[Jordan-Hall]

I'm encourage by the new license thats been recently added

This at least address concerns it felt like we need to beg for access. However their seem to be little documentation on what "restricted license " means compared to the unrestricted.

@vsavkin is their a link or something we can read to see what the restriction is. Also could you address the concerns that the powerpack license seem to contradict the MIT license

copy, modify or create derivative works of the Software or Documentation, in whole or in part; (ii) reverse engineer, disassemble, decompile, decode or otherwise attempt to derive or gain improper access to any software component of the Software,

This can be done via MIT code and looking at the code. Already using plugins that does codeowner etc. I'm personally using a patch for NX to allow remote caching (all without looking at powerpack code) does this mean that not allowed?

[pete-mcwilliams]

looks to be very restrictive:
Single workspace license type
1 seat

[Jordan-Hall]

looks to be very restrictive: Single workspace license type 1 seat

Why i'm asking because it looks no different for me

[pete-mcwilliams]

This is what I see

[Jordan-Hall]

You need to change the Number of developers

[pete-mcwilliams]

Then it is not restricted at all 👍

[Jordan-Hall]

I kinda feeling this has mainly been a badly managed release from a PR and communication point of view but if the above is right then its not perfect i think opening up cache should happen, but its a lot better than it was first presented

Then it is not restricted at all 👍

Which is why im asking for clarity

[juristr]

Sorry for the delayed response, we're still catching up after Monorepo World.

I won't repeat what Victor mentioned in his post, so please check that out first. However, I want to focus on a couple of things:

• Our goal has never been to block anyone or take anything away. We have a strong history of supporting OSS at both the company and individual level, and we continue in that support by offering our paid products for free to OSS projects (e.g., Nx Cloud is free for OSS).
• That said, we sought to create a product for large enterprises to help us in sustaining our open-source efforts. This isn't about VC funding; it's about transitioning from a consulting business to a product company, as Jeff outlined in his blog post, and making open-source work sustainable.

We're grateful for the feedback 🙏. It showed us that while we had mentioned it in a few places, we missed the mark and needed to be much more explicit in our support for smaller teams. We've now updated the Powerpack page and the license application process to make these points more clear:

• We offer Powerpack for free to OSS projects (apply here); again note that Nx Cloud is also free for OSS.
• We offer Powerpack for free to small teams (reach out here).

If you're a small team and you rely on custom task runners for S3 caching, please contact us—we definitely don't want anyone feeling blocked by this.

[vsavkin]

Thank you so much, Juri.

Everyone, I apologize for my unclear communication. And I appreciate everyone's constructive feedback.

My Twitter DMs are open to anyone who wants to talk in good faith. I'm also happy to jump on a call. I chatted with many folks last week and the week before; this remains my top priority.

Nx is a small business with a few dozen engineers. We know how hard it is to run a small business, so we're offering all small businesses remote cache implementations for free.

[vsavkin]

@Jordan-Hall That is my personal twitter account. The Nx account didn't block you.

You declined my invitation to talk to you. After I texted with you in good faith, trying to be clear and honest, you published our private communication without my permission, which isn't acting in good faith imo.

That's why I don't think I can trust you, and I decided not to engage with you on social personally. You are free to engage with other folks on the Nx core team though.

I'd also like you to read through https://github.com/nrwl/nx/blob/master/CODE_OF_CONDUCT.md which is there to protect the wellbeing of all Nx contributors, regardless of their position. Further violations of the CoC will leave us with no choice but to restrict your access on GitHub in order to preserve a safe space for our community.

If you want to restart the conversation constructively, I'm happy to have a VC with you.

Thank you!

[Jordan-Hall]

You declined my invitation to talk to you. After I texted with you in good faith, trying to be clear and honest, you published our private communication without my permission, which isn't acting in good faith imo.

I said it was something i didn't like because people seem to be in the dark. It was release as good faith so people know what it was about (not to make you look bad or in bad faith, sorry if you took it that way..

Im sorry @vsavkin, i like things open but sure would take a call now im actually feeling well enough. The new update looks great but seems confusing around "Free restricted license." I cant find documentation on the restrictions,

[rathpc]

We know how hard it is to run a small business, so we're offering all small businesses remote cache implementations for free.

What is considered a "small team" out of curiosity?

[el-davo]

free for small existing teams

Also what is an existing team?

[pumano]

@vsavkin very good idea migrate core to Rust. I also suggest to support rust-based modern toolchain like oxc / oxlint / rolldown / swc / esbuild / rspack / vite etc. Performance matters.

[vsavkin]

Some folks have asked for clarification on what we mean by one license type being "restrictive" and the other "unrestrictive."

To clarify, Nx Powerpack's self-hosted cache storage is free for small teams. See above. If you've been with us on this journey, used Nx, relied on self-hosted remote caching, and are part of a small team, we want to help you out.

Our focus has been on building additional features that benefit our Enterprise users—like Conformance, Codeowners, and more to come—without impacting smaller teams of developers. We're not looking to impose extra costs on teams that are already bootstrapping their way forward.

When we refer to a "restrictive" license, it means that free access is limited to the caching function, whereas "unrestrictive" licenses will include access to enterprise-focused features like Conformance, Codeowners, and others we develop in the future.

What constitutes a small business is a company with dozens of software engineers or, in exceptional cases, small independent teams in much larger organizations. So far hundreds of companies have requested a small-business discount for Nx Cloud. All requests were approved. We have the same attitude towards Nx Powerpack.

We will update the landing page to make the points clearer.

Thank you for engaging with us, folks!

[comp615]

Our focus has been on building additional features that benefit our Enterprise users—like Conformance, Codeowners, and more to come—without impacting smaller teams of developers. We're not looking to impose extra costs on teams that are already bootstrapping their way forward.

It seems like those are great, net new powerpack features. But based on the feedback on this thread (sorry to pile on and rehash), I think everyone would be very happy to see self-hosted caching provided as free based on the OSS usage history here and pay for those new functions. Right now it's a bait and switch. And now I have to have a conversation amid cost cutting efforts along the lines of "Hey we need to pony up tens of thousands of dollars just so that thing I committed us to and said was free last year can keep doing excatly what it does"... I'm personally very excited to see where compliance goes. but I don't like being put in that position. It's disingenuous to include caching in: "No, we’re not placing existing features behind a paywall"

We're not a small company, I don't feel legitimate amongst others here asking for a broad exception for powerpack (but I do for caching). I would go to bat and seek funding for these new features. But the money grab on caching needs to be acknowledged; there's no way around it.

[Jordan-Hall]

I know there's a real desire to avoid having a JavaScript runtime within Rust code due to performance and package size concerns. However, what about running WebAssembly or dynamically linking with a shared library? It would be great to create plugins without having to use JavaScript. This would be an ideal example to get it working without making it feel like a cash grab.

I'm sure it's a good middle ground, ensuring flexibility while still meeting all your goals.

[psalv]

@vsavkin @jeffbcross I think a big piece your team is missing is that for larger companies (like ours) we would be happy to pay for products that add value (which Nx does) but we need an off-ramp and this is what custom task runners/self-hosted caching provided—having these options available to us is a big part of why we chose to integrate with (and pay for) Nx.

This change has turned your product into a one-way door and I can’t advocate investing in a product that we have no way of pulling out of if our needs change in the future. We try to avoid putting ourselves into a state of vendor lock-in.

[Jordan-Hall]

@jeffbcross @vsavkin is it possible to start having RFC for big changes, allow community to provide early feedback ans suggestions. I'm sure people would love to help out more and with a design for making this still work in rust

[Elyahou]

You previously claimed that Powerpack was not replacing open-source features with paid subscriptions. However, this blog post change shows otherwise. We’ve now confirmed that functionality—like custom remote caching—has been moved behind a paywall.

It would be fair for the Nx team to remove this limitation and allow the same API to remain accessible in the Rust implementation. If open-source features can simply be reclassified as premium, this sets a dangerous precedent. What’s stopping other Nx APIs from being locked behind future paywalls?

This shift makes relying on Nx uncertain, as it suggests that any feature could be turned into a paid service at any time.

[ItamarGronich]

While supporting OSS and small businesses is a noble and just cause you still haven't addressed the concern for big companies yet.

We're a big company.
We chose Nx because of it's amazing free features.
Free remote caching being the a key decision point.
I now have to come to my superiors and say "Hey, Nx now decided to put remote caching behind paywall so we have three options:

1. pay X now
2. give up remote caching
3. migrate to another solution"

In either way we'll have to pay a large fee - either in buying the nx cloud service or by putting large amount of dev hours on finding another solution, or by giving it up to and eat the extra time remote caching saved us.

In any case, this feel basically like ransom and is not a behavior i would expect from a company such as yours.
Not only that, but you not directly mentioning the pricing change is very disingenuous.
It feels like you're trying to avoid saying that upfront.
You promote this by saying: "HEY! we're moving to RUST! 🦀" But what you should be saying is: "HEY! We now want you to pay for remote caching!"

This kind of behavior trashes the trust and reliability we have in Nx.
Frankly even if this ends up not going through - I'm not sure i would recommend using Nx going forward.
Since at any given time any feature you might be using today could be held ransom in the future.

[xalechez]

I'd like to second @ItamarGronich's comment from a position of another non-small-business.

I am currently investigating using Nx in our organisation. We see some huge benefits it could bring us as a business, but as with any new technology we have to go iteratively, starting from early adoption of the OSS, and then, if we prove the value, attempt to scale it further, considering commercial options like Powerpack or Nx Cloud.

However before considering paying for anything I need to build trust in the tech and the team behind it, so that we don't find ourselves with vendor lock-in in the future. I also need to show the value of it before investing any company's money which I could possibly do using custom runners before (e.g. "hey, here's how we save money on CI bills and eng context switching by using custom cache, how about we buy Nx Cloud and save us the effort of maintaining homegrown solution while also having other huge benefits?"). Now we have a big problem both with trust and the ability to demonstrate the value.

I am still an Nx enthusiast, and I believe that it has huge benefits, but this situation is a huge red flag for me.

I haven't reported it back to my superiors yet as I believe that the pushback from community could somehow convince Nx team that their decision, though seeming profitable short-term, can cost them more long-term as trust would be eroded and potential customers who are ready to pay for something that brings them value would have to consider other alternatives, but I will have to do it, and the only answer that comes to mind is to scale back the adoption and consider moving to Turborepo (which was our second choice as it loses to Nx for a number of cases specific to our business).

I appreciate your efforts to make Nx faster by jumping on the web-wide trend of rewriting to Rust, but I would appreciate even more if this decision was scaled back (and other such impactful decisions would be discussed with the community well in advance via RFCs of sorts) by providing some sort of API for those who would like to build their own caching solution (with a disclaimer of some sort "if you're using this, we'll have to run JS runtime in rust which will make your Nx core working slower", we understand the tradeoffs and we're ready to maintain some custom code for a while, because that's how big migrations in the current business environment work)

[TriPSs]

We have been using Nx for over 4 years with our custom runner in all projects, after seeing the warning and trying to investigate what a Powerpack was came to this issue.

In the past years we already had multiple annoyances of Nx doing things that broke everything for us and we had to spend hours upon hours to figure out what, we accepted this as Nx being Nx because we really liked the ecosystem and the extendability of it. That we now have to pay for something that has always been free is just absurd, even with the "free" licence, why? Why would we now suddeldy need to request and get approved for a license to use what we are/where already using for the last couple of years?

My 2 cents about the migration from Typescript to Rust:
As someone who maintains multiple plugins for Nx (and has never done anything in Rust), I'm not looking forward to this, currently breaking changes for plugins are not always documented, or testing utils that are used internally (#10992) but not available to plugin maintainers; I can only see more issues / making it harder to maintain those plugins. Are API's that are now exposed still going to be exposed?

Would rather see more focus on existing tickets/bugs that are now ignored (#22213, #26577) instead of rewriting the core into Rust to improve performance of something that, in my opinion, is not slow.

[Jordan-Hall]

@juristr with this now being closes can we assumed its all going ahead as planned and this should be closes?

[Elyahou]

Yes, I don't see any meaningful response from the Nx team on the concerns raised throughout this thread. It would be helpful to understand their approach to these issues, especially to reassure the community about the future direction of Nx. Even if no changes are planned, we still deserve a clear and direct answer.

The current silence only adds to the uncertainty. If APIs and extension points are being removed or moved behind paywalls, users need to know now, so they can make informed decisions about whether Nx will continue to meet their needs or if they should start exploring alternatives. Transparency is key to maintaining trust in the open source community.

[tidusjar]

Time to start taking NX out of everything

[johannesnormannjensen]

In my current job we have a team of 20 developers working on a massive monorepo with NX as the underlying framework.

We chose NX specifically for its free tier features including on prem caching as security is paramount to our organization. We use on prem minio s3 storage that we control and administer ourselves.

I was surprised to learn this week by means of a warning when run pnpm nx serve that on prem caching will soon be behind a paywall

To learn such an important update from a random warning is really poor communication from NX.

I had a look at site for activating powerpack and with the amount of developers working on our project the total comes up to $495.00 USD / MONTH. Again we administer our own storage. Why would we pay such a massive amount every month for this? Does anyone think this is acceptable? And what do we get in return? A rewrite in rust that noone asked for?

A 20% speed increase in a command starting up is nothing in comparison to the speed increase that remote caching offers.

Unfortunatly NX has now lost credibility within our organization, reason being, if you can randomly put caching behind a paywall what's to stop NX from putting other features behind a paywall?

• Want to build an application with module federation - sorry that will be an extra $20 a month
• Want to use the task scheduler - sorry that will be an extra $10 a month
• Want to use local caching - Purchase nx mega powerpack to unlock

We have already started planning for migrating off of NX and are looking into turbo repo as we are not happy with essentially being held to ransom for trusting NX.

I should note that personally I was a massive fan of NX, I was the one who incorporated it into our development process and honestly it has been an amazing journey. I even wrote an article about it here - https://medium.com/better-programming/migrating-an-angular-application-to-module-federation-with-nx-74f7664bab3e?source=your_stories_page-------------------------------------

Thank you for all the work up until now, but if this change goes ahead we will be moving on and I suspect a lot of others will also

We too use on prem minio storage and would not like to see this changed. It makes sense to pay for the features that NX provides as a service, but for us to pay for using a shared fs cache to setup ourselves as well... What is that about?

We've been (and myself personall) very happy with NX all through the years, but changes like this makes me rethink what the direction of the whole organisation is moving forward. As others have stated, what will be the next paywall?

[vsavkin]

Thank you for engaging with us!

Anyone who has spoken with us in person at conferences knows that the Nx team, myself included, is always happy to discuss what's in progress and what's coming next. However, we want to do a much better job of sharing this in a more public way, so everyone interested can stay informed and have an opportunity to share feedback early on.

To achieve this, we're making a few changes:

1. Publishing a 1-Year Roadmap: We're bringing back roadmaps and revamping the process. This roadmap will outline all major developments for the year, offering a chance to see what's in progress, ask questions, and share concerns. The 2025 roadmap will be published soon.
2. A More Formal RFC Process: For larger API changes (e.g., Crystal, Powerpack are past examples of such changes), we'll pilot a more structured RFC process, providing an opportunity for you to see upcoming changes early and contribute directly to the discussion. We commit to implementing major changes based on the resolutions of these RFCs, ensuring that your input guides our direction.
3. Hosting Regular Office Hours: We'll host regular office hours, providing a chance for anyone to have direct access to the team.
4. Improving the Nx Champions Program: The Nx Champions program connects 28 prominent community members with the Nx team for feedback and idea exchange. We haven't been using this program as effectively as we'd like. We're going to take action to improve the program such that there's more collaboration, early feedback gathering but also getting their help to spread big ongoing developments better in the community.

I'm personally committed to engaging with the community. If you have questions or concerns, feel free to DM me on Twitter, and I'll be happy to have a video call with you. You can also engage with Juri in the same fashion.

Discord is also a great place to engage at.

I'm sorry we didn't do a good enough job of communicating with the community. We are doing our best to address it.

If you have any questions about these updates, please engage with us!

[Jordan-Hall]

1. Publishing a 1-Year Roadmap: We're bringing back roadmaps and revamping the process. This roadmap will outline all major developments for the year, offering a chance to see what's in progress, ask questions, and share concerns. The 2025 roadmap will be published soon.
2. A More Formal RFC Process: For larger API changes (e.g., Crystal, Powerpack are past examples of such changes), we'll pilot a more structured RFC process, providing an opportunity for you to see upcoming changes early and contribute directly to the discussion. We commit to only implementing major changes based on the resolutions of these RFCs, ensuring that your input guides our direction.
3. Hosting Regular Office Hours: We'll host regular office hours, providing a chance for anyone to have direct access to the team.
4. Improving the Nx Champions Program: The Nx Champions program connects 28 prominent community members with the Nx team for feedback and idea exchange. We haven't been using this program as effectively as we'd like. We're going to take action to improve the program such that there's more collaboration, early feedback gathering but also getting their help to spread big ongoing developments better in the community.

This sounds great, but is it too late for the current approach regarding this issue? Or can you start again and rethink, or allow community input or idea on making a rust base plugin

[nielskrijger]

I'm sorry we didn't do a good enough job of communicating with the community. We are doing our best to address it.

I think you've actually engaged with the community pretty well.

It's the community that is stumped and in disbelief. As said in the opening post;

We understand that this change would mean that some teams may need Nx Powerpack. While it's a premium product designed for professional teams, we know that every Nx user's situation is unique.

There should be little doubt about what that means.

For many companies (especially outside of SF or US) the costs for your services are a significant expense for what is essentially some convenience.

In comparison to all the free CI/CD and OS options available, this can be a tough expense to justify.

Obviously; new kids are knocking at the doors. Drastic changes are necessary.

But for those who have contributed to and enjoyed using NX, this feels like a free tool being hijacked by a commercial entity.

Losing some of the community might not impact the bottom line, but without growth, the project/company's future is at risk.

If growth only comes from imitating competitors, it’s a losing game; free and open-source alternatives will simply keep nibbling away. So far, I haven’t seen anything that goes beyond merely catching up.

[murphomatic]

We too use on prem minio storage and would not like to see this changed. It makes sense to pay for the features that NX provides as a service, but for us to pay for using a shared fs cache to setup ourselves as well... What is that about?

We've been (and myself personall) very happy with NX all through the years, but changes like this makes me rethink what the direction of the whole organisation is moving forward. As others have stated, what will be the next paywall?

Just wanted to echo the sentiment in the post above by @johannesnormannjensen.

We too have been using Nx for a few years (with varying degrees of satisfaction, but pretty happy with it for the most-part), and while I can understand a pay-to-play model for consumers who wish to utilize Nx's cloud-based infrastructure for caching/analytics/build process, etc., I'm hard-pressed to understand the logic behind hobbling the framework, and then requiring a paid-package to unhobble it, for those who have no ties to Nx cloud infrastructure. In our particular situation, we are fairly tightly-controlled with respect to data egress, and we use nx-remotecache-azure so that our cacheable assets never leave the confines of our corporate network.

I've hemmed and hawed a bit about whether or not we'd just bite the bullet and "pay da man," but after fielding some bizarre build issues today that appear be related to #28599 and #28380, my confidence in the Nx tooling has taken a bit of a nose-dive. Properly sequenced builds within complex dependency chains is a core, if not -the- core, reason we chose Nx in the first place, and coming to find this broken - well ... let's just say that the corporate credit card swiftly moved back into safe confines of my wallet.

And in continuing to emphasize @johannesnormannjensen's post above, as well as @Elyahou's similar point - what is the next thing that will become pay-to-play, even if we opt to forgo computational caching for now? The ability to make implicit dependencies between projects? Limits on the number of parallel task runners? Maximum number of projects in an Nx workspace?

This approach does not seem like a sensible/logical "pay for what you use" model, but instead more of a "if we perceive you to be a big, evil, greedy corporation - we're going to work you like a mule" cash-grab. This kind of logic is made even more apparent by the attempt to assuage the angst in this thread by making self-hosted remote-caching with powerpack "free for small orgs." What difference does it make to Nx how big the org is if they're self-hosting their own cache? How does Nx define a "small org," and what will prevent that definition from changing tomorrow?

There are pay-to-play models that would make more sense here, in my opinion:

• Recurring subscription for using Nx Cloud, and the features it provides
• Recurring subscription for Enterprise-grade support with varying degrees of SLAs
• Even a licensing fee for major versions of Nx where consumers could opt to pay once and then stay with a particular major version for a longer period of time. Like we might decide to stay on v19 for the next 3 years ... I don't want my org to hemorrhage nearly $30k simply because .... "reasons."

Perhaps the time has come to start planning our move away from Nx.

[Elyahou]

Thank you for engaging with us!

Anyone who has spoken with us in person at conferences knows that the Nx team, myself included, is always happy to discuss what's in progress and what's coming next. However, we want to do a much better job of sharing this in a more public way, so everyone interested can stay informed and have an opportunity to share feedback early on.

To achieve this, we're making a few changes:

1. Publishing a 1-Year Roadmap: We're bringing back roadmaps and revamping the process. This roadmap will outline all major developments for the year, offering a chance to see what's in progress, ask questions, and share concerns. The 2025 roadmap will be published soon.
2. A More Formal RFC Process: For larger API changes (e.g., Crystal, Powerpack are past examples of such changes), we'll pilot a more structured RFC process, providing an opportunity for you to see upcoming changes early and contribute directly to the discussion. We commit to implementing major changes based on the resolutions of these RFCs, ensuring that your input guides our direction.
3. Hosting Regular Office Hours: We'll host regular office hours, providing a chance for anyone to have direct access to the team.
4. Improving the Nx Champions Program: The Nx Champions program connects 28 prominent community members with the Nx team for feedback and idea exchange. We haven't been using this program as effectively as we'd like. We're going to take action to improve the program such that there's more collaboration, early feedback gathering but also getting their help to spread big ongoing developments better in the community.

I'm personally committed to engaging with the community. If you have questions or concerns, feel free to DM me on Twitter, and I'll be happy to have a video call with you. You can also engage with Juri in the same fashion.

Discord is also a great place to engage at.

I'm sorry we didn't do a good enough job of communicating with the community. We are doing our best to address it.

If you have any questions about these updates, please engage with us!

While the proposed changes are a step in the right direction, they don’t address the immediate issue: this decision was made without community input, and the feedback so far has been overwhelmingly negative, as shown in this issue...

These changes are planned for future versions of Nx, and since it’s unclear when the migration to Rust will happen, there’s still time to reconsider. Deprecating the API before Rust is fully implemented creates unnecessary friction. To show good faith and rebuild trust, this decision should be revisited with the community’s input.

[maxisam]

It is a shame I really like NX, but I guess they have to somehow get money from NX. I totally understand that but $25 per users per month is a very expensive price.

Github copilot only cost like $20 for business and it provides more value.
Docker team is like $5 -$10 for a small team (< 100 ppl), and it provides lots of resource as well.

If we don't use nx cloud resource, I really can't justify $25 for a remote cache feature that actually using our own resource.
I think it will be very hard to sell this to a lot of smaller companies that is not in CA or big cities.

I think it is probably impossible to ask NX team to change their mind on paying, but I think could you guys at least provide something cheaper for smaller teams like ppl < 100 or 50? I think docker's pricing is a good one

---

update:

I just tried to apply for the free license, it seems like we are qualified for it. I really appreciate it.

[maxisam]

Honestly, I understand why NX decided to put the remote cache feature behind a paywall. Building and maintaining NX takes a lot of time and resources. I just hope the NX team can find a sustainable way to keep moving forward.

As an open-source developer, I recognize it’s unrealistic to expect everything for free indefinitely. I personally don’t charge for my open-source projects since it's a passion project for me. I even convinced my boss to let me support open-source contributions for the tools we use in our company as a small way to give back to the community. However, I believe there's a difference when people are working full-time to support these projects. Let's face it, if NX can't keep going forward, I think it is still a bad outcome for everyone. There are so many open source projects died already.

I’m grateful that NX provides us with a free Power Pack since we’re a small team (under 15 people).

🙏 I hope the community can come together to find a balanced solution.

[wall-street-dev]

Dear @vsavkin & @jeffbcross,
You guys are doing it wrong and you know it.
Yes, you'll get more money, and if that's your goal then it's fine. But as an OSS project, your credibility and Nx's credibility are being undermined by these types of decisions.

Godspeed.

[o629625]

This post did not age well https://www.linkedin.com/posts/zackderose_we-were-intentional-with-nx-to-allow-other-activity-7069448865090859008-vnLI

_Zachary DeRose
Engineering Manager and Architect at Nx

💯 We were intentional with Nx to allow other task runners that implement their own distributed caching!

But caching can be hard. Nx Cloud is the first-party solution here (checkout https://nx.app) and we're investing our engineering resources into making this an excellent experience for our users.

Nx Cloud is free up to 300 CI runs a month (all non-CI runs are free) and there's a special unlimited tier for all open-source projects, and comes with some nice features like linkable task logs, Version Control System integrations for Github/GitLab/BitBucket, and support for Distributed Task Execution!

You can try it now simply by running nx connect in your Nx Workspace 😎_

---

NX team must reconsider removing existing open source functionality they intentionally offered. The disruption you are causing existing teams using custom runners will likely cost more then the net revenue gained from placing it behind a pay wall.

As an architect at a leading investment bank, having used NX for over 2 years in our project, out of principal there is no way we will consider signing up for Power Pack due to the questionable approach in which it was introduced.

The LinkedIn post above from an NX core team member is partly why we felt comfortable using custom runners. Lies....

[ytchenak]

My CI/CD pipeline runs concurrent NX processes in the same workspace (e.g., build and lint). Starting with version 19.8.*, I've started seeing occasional SQLite errors, which suggests the metadata SQLite database might be corrupted by concurrent writes from multiple NX processes.

Will this scenario (concurrent NX processes in the same workspace) be supported in future versions, or do I need to purchase the Powerpack to use the remote FS cache?

[alexhanga]

We have a custom runner that calls our own API with security checks and authorization, which also have some checks for a cache before storing it to S3. So the developers don't have a real access to Amazon infrastructure and to S3 itself.

Powerpack doesn't meet our needs in security and with restricted access to Amazon infrastructure. So basically with this change, we have only three options:

1. Remove caching at all
2. Stay indefinitely on Nx 20
3. Change our security policy to be less strict and give access to Amazon infrastructure just to be able to use cache. And pay for using remote cache.

I don't think that this options are good.