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.

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. https://github.com/moonrepo/moon/issues/1520#issuecomment-2347311851

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.

https://github.com/nrwl/nx/issues/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 :pray:. 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.