Migrating Nx core to Rust & deprecating custom runners

[vsavkin]

UPDATE FROM JAN 15:

Thank you to everyone for engaging with us.

First, we are introducing a new API: #29637
It handles most of the functionality that custom tasks runners were used for, but in a much more clear way and without impending our ability to evolve Nx. Please take a look.

Second, your involvement has reminded us and the team how important it is to keep the community in the loop. After speaking with numerous individuals and teams over the last 3 months, we've implemented several process improvements:

RFC Process Implementation

We've introduced an RFC (Request for Comments) process for major API changes. Examples include:

• RFC: Linking Packages with Workspaces (New TypeScript Setup) - github.com/nrwl/nx/discussions/29099
• RFC: Infinite Tasks - github.com/nrwl/nx/discussions/29025

Enhanced Communication

I've begun posting overviews of significant changes on social media. Recent examples:

• Update 1
• Update 2
• Update 3

Roadmap Transparency

We've published our roadmap and plan to do so regularly:

• Current Roadmap

Community Engagement

• We now host regular office hours on Discord. Join us at discord.com/invite/SWyp4xfGjn
• We're expanding our Champions program, which involves community leaders in early design proposal reviews
• Although not an official policy, I always engage with folks who DM me on social. So if you have any concerns, reach out.

We will review our processes again in March to see if anything can be improved.

---

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 [email protected].

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
• Nx Powerpack is free for small companies or companies with small engineering teams. Please contact us at [email protected], and we will help you out.
• Large organizations that need a license right away can go to https://nx.dev/powerpack and get a trial license on the spot.
• If you work at a large organization, and you don't know what to do. I.e., you feel like this change is blocking you, contact us at [email protected] and we will unblock you.

So far hundreds of companies of different sizes, from different industries, reached out, and we were able to unblock everyone.

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 [email protected], 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 [email protected], 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?

[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.

[vsavkin]

@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" It's a bug that should be fixed. If you upgrade to latest, the issue should go away.

@alexhanga Could we set up a call to discuss your checks? Could you email [email protected], and I'll arrange a call?

[JoeRJohnson11]

@o629625 Can we have a call to discuss your situation? If you email [email protected] we'll find a time to talk.

[ytchenak]

@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" It's a bug that should be fixed. If you upgrade to latest, the issue should go away.

@vsavkin, I’m glad to hear that there’s no additional cost for running concurrent jobs, but unfortunately, the issue persists even in the latest version (20.1.2). Please refer to this comment for more details: #28772 (comment).

This issue is preventing us from upgrading to the latest NX versions. For now, I am forced to use the last NX version that does not rely on SQLite.

[vsavkin]

Folks,

I'd like to post a quick update on the process initiatives that should give a lot more visibility into the roadmap, how features are developed etc:

1. We published 2025 roadmap: Nx 2025 Roadmap #28731
2. We are trying a new RFC process. This is the first BIG feature: RFC: Continuous Tasks #29025 I also created a video showing what we are trying to do https://www.youtube.com/watch?v=-gezeX9zxuM
3. We started hosting regular office hours on Discord. More details to come soon.

Let us know what we can do to tweak the process changes (especially the RFC) if they are useful or not.

[TriPSs]

It could be just me (and I really hope it is), but we are now a couple of weeks further along, and although a new RFC process has been introduced, we still don't have any clear answers regarding the custom runners?

[el-davo]

@TriPSs I have to agree. The communication and side stepping here is not a great look. @vsavkin Please answer the following questions so we can make a decision on our future of using nx. We only need yes or no answers, we are not interested in why these changes would be a good thing for us.

• Will the removal of custom runners have an RFC before being implemented?
• Are NX going ahead with putting private remote caching behind a paywall?

Any other response is redundant as far as my organization is concerned

[JoeRJohnson11]

@el-davo & @TriPSs Would you be willing to have a call to talk about your situation? If you write into [email protected], we'll find a time to talk.

[TriPSs]

@el-davo & @TriPSs Would you be willing to have a call to talk about your situation? If you write into [email protected], we'll find a time to talk.

I believe a call isn't the best solution in this context. While it might solve my problem, it wouldn't address the needs of other people who have similar concerns. I can clearly outline the solutions I'm seeking here:

1. Preferred: Continue supporting third-party solutions for storing/retrieving cache and remove the warning about this. If Powerpack can do it, other third parties should be able to as well.
2. Hardest and most work: Remove the license requirement entirely, even if it's a free license. In my opinion, you should not need to apply for a license if it's free. And add support for all the then missing providers.

Also, as @el-davo stated, everyone would like answers to the following questions:

• Will the removal of custom runners have an RFC before being implemented?
• Are NX going ahead with putting private remote caching behind a paywall?

[joshlartz]

#28360

[bahizi]

Hi @vsavkin first of all, thanks for all the work you and the team have been doing over the years to support nx. I understand it takes time and effort to build a powerful tool like this, open source or not, so I also understand the need for the powerpack commercial products, but can we reconsider the vendor lock-in aspect of this change?

Remote caching is crucial for NX in a CI/CD environments that use docker containers to run jobs (which I think is how most folks do CI/CD nowadays). Frankly without remote cache and therefore no Fast CI (a previously key out-the-box attractive nx feature, along with nx affected), nx (and monorepos in general) becomes somewhat impractical and also goes against some of the NX key pros that were listed in this post a while ago: https://nx.dev/concepts/turbo-and-nx, taking the overall nx project on the path to an arguably freemium product as well.

Again, we're not against the powerpack products, but please leave options for custom remote cache implementations.

[JoeRJohnson11]

@bahizi would you mind having a call with us so we can better understand your situation?
If you write into [email protected] we'll find a time to talk.

[TriPSs]

Hi @JoeRJohnson11,

In our call a couple of weeks ago, I asked if you could provide an update on this thread. Since that hasn’t happened yet, I’ll take the liberty to share my understanding of the situation. If anything is incorrect, please feel free to clarify.

Key points discussed:

• The Rust migration is here to stay, which includes the deprecation and removal of custom runners.
• Users can apply for a "free" Powerpack license to continue using their own AWS/GCP buckets for remote caching.
• Nx is open to working with users who have other custom implementations to find potential solutions. (However, we didn’t address the broader perception of this change, or the concern that no feature is guaranteed to remain outside the license wall.)

As I mentioned during the call, I will not be applying for a "free" license to continue using something I’m already using. Additionally, there’s the concern that the license could become perpetual for a specific version, which I understand to mean that while it’s free now, it might not remain so with future Nx versions.

My conclusions:

• I’m no longer worried about the Rust migration for plugins, as Nx assured us that they will work with plugin maintainers to ensure compatibility. Based on how the migration from our Playwright plugin to Nx’s version was handled, I’m confident this will go smoothly.
• However, I’m still concerned about the removal of custom runners. I’m uncertain about the path forward—whether I’ll continue using Nx until the removal, attempt a workaround, or move away from Nx entirely.

Answers to our key questions:

Will the removal of custom runners have an RFC before implementation?

No.

Is Nx moving forward with putting private remote caching behind a paywall?

Yes.

PS: I also noticed that Vercel made their caching free (source). It even states that Nx users as of version 19.7+ may need to pay a license fee to Nx to continue using Vercel Remote Cache.

Let me know if I’ve missed or misunderstood anything!

[wvanderdeijl]

As the maintainer of nx-remotecache-gcs, an Nx plugin that enables Google Cloud Storage for remote caching, I’m disappointed by this decision. To safeguard our organization, we’ve applied for a free Powerpack license, but it’s only valid for one year, requiring renewal annually.

Is there any assurance that these licenses will continue to be free in the future?

While we’ll observe how this unfolds in the near term, the gradual shift toward paywalling remote caching doesn’t sit well with us. Given the current direction, we’re actively exploring alternatives to Nx.

[lppedd]

@wvanderdeijl as far as I know Turborepo is going to jump on this and release an how-to migrate document. Just FYI.

[o629625]

In our organization, I have recently come across custom remote cache implementations that use a REST API to interact with the cache store, because it it not possible to connect directly to the S3 bucket from CI.

It doesn't look like Powerpack will work here. This is another example of the variety of ways the NX community have used custom runners and if NX moves forward with removing them, many may have no choice but to migrate to a different monorepo solution.

[bahizi]

For those interested, consider gradle as an alternative as well. It can be configured for monorepos and has features similar to nx affected and remote cache with various backends (s3, nfs, azure blob, google, etc), all via plugins. They also have Gradle Enterprise but that is optional and is really for more advanced, truly enterprise capabilities.

Currently testing it out and the DevExperience so far is a bit clunky but that can be ironed out later once we have it fully working within our current nx monorepo and benchmarked.

[lppedd]

@bahizi I'm curious to know how, for example, you'd replace the Angular executors with Gradle tasks.
You'd have to write a Gradle plugin I guess, with accompanying extensions to make it customizable.
Pretty much the same is valid for other technologies, it's a massive effort imo with little returns.

[vsavkin]

Folks,

We are introducing a new API: #29637

It handles most of the functionality that custom tasks runners were used for, but in a much clearer way and without impending our ability to evolve Nx.

Please take a look and provide feedback.

Thank you!

[Jordan-Hall]

Folks,

We are introducing a new API: #29637

It handles most of the functionality that custom tasks runners were used for, but in a much clearer way and without impending our ability to evolve Nx.

Please take a look and provide feedback.

Thank you!

Thank you, but I'm not sure if the two is linked. It appears most here saying custom runner for a wide range of issues. I'll leave a comment anywsy, but looks like custom caching harder/may not be as good here :/

I still think and rust needs a API around caching that people can hook into as well.

[vsavkin]

@wvanderdeijl

Is there any assurance that these licenses will continue to be free in the future?

Yes. Your free license will always be free. Also, non-free licenses are perpetual, so they will continue working after expiring with version restrictions.

[med8bra]

It seems nx team is fully committed on making self-hosted remote cache a subscription service, and to host your cache you will need to go through a paywall. Not sure what was the basis of this product decision, but I believe nx has more potential than just to be a payme for cache product.

Turborepo documents their Remote Caching features, documented the API specification, and allowed the community to implement self hosted cache solutions.

[Playjasb2]

I understand that the Nx team needs funding to sustain themselves, but putting the custom remote caching feature behind a paywall is disappointing. I was an advocate for using Nx in my company, and we are deeply invested in the way that Nx works in our project, and I recently got a development server and I intended to use that for our remote caching server, and now this news hit.

My team is too used to the way that Nx works in our project, and it's too expensive in time and effort to move to another monorepo framework, as I had documented Nx use cases in our own GitHub wiki and it's used in our GitHub Actions pipeline. Plus, the company I'm in is not a small business, so we won't qualify for a free license.

We are effectively vendor-locked, which I didn't exactly see coming, since it's a FOSS, and I thought that given the reputation Nx had with the community, they wouldn't do something like backing away from a prior promise of a free remote caching solution. There are a lot of people that bought into Nx for the free remote caching option, and now they're stuck.

Right now, I'm trying to understand if I should use Nx in the next project I'll be working on. Issue is that I spent quite a lot of time learning Nx, how it works, and how to resolve the various quirks that it has, that jumping to another monorepo framework would be another issue, since I have to start from the very beginning again. Plus I got used to Nx that I'm not sure if any other frameworks has the same equivalent feature set.

But this may not have been the case for anyone else if this was not an advertised feature from the start, as others would've just used free remote caching features offered by Rush, Bazel, Turborepo, etc. Cause at that point, some people wouldn't have given Nx a chance there if they prioritized free remote caching.

It reminds me of Thunder Client, where they gave everyone a taste of the VSCode extension for free, but out of nowhere, they paywalled a lot of their features, which made the developers who spent their time and effort developing with it to now have to consider the option of paying, even though that was not the plan from the start. Had the extension been advertised like that from the start, then the developers who weren't interested in that scheme wouldn't have used it. Trying to get people comfortable with a product for free and then out of nowhere rescind the free promise and to get them to pay, it's wasting people's time and effort.

Given the comfort with the tool, it feels like I would have to use Nx and lock it down to v20 if I want to retain the free feature, which is not ideal. I'd have to look elsewhere for continuous support.