Volta is unmaintained; we recommend migrating to mise

The volta maintainers recommend using mise. It is the tool that most of them use nowadays. They're working on getting an official statement out to that effect at some point. Until then, this pinned issue serves as a useful signpost to anyone who visits.

https://mise.jdx.dev/

They sadly do not have time to respond to comments on this issue. However, volta users are free to share their volta->mise migration steps in the comments below.

@cspotcode

Thanks for adding this, @cspotcode. Pinned for reference. ~~I’m also locking the conversation so we don’t end up with a lot of noise.~~ I unlocked so folks can share migration tips, but if we end up with too much other stuff in the contents, I will lock it.

mise: replace volta

First of all, thanks to everyone who has worked on Volta! It's been a joy to use.

Here are my steps to migration (I think I've got a fully working environment). I use the Fish shell.

brew install mise
mise use --global node@20 (we're still on node v20)
Close terminal tab and re-open to get mise auto-activation for Fish shell
Remove all VOLTA variables from shell configs (~/.config/fish)
rm -rf /usr/local/bin/node (was symlinked to ~/.volta/bin/node)
rm -rf $HOME/.volta
pnpm was missing... => corepack enable fixed that.

Hope this is useful to others. I found this Mise page about Mise + Node.js useful for the last bits of getting set up.

started a discussion on the mise side: jdx/mise#7199

First of all, thanks to everyone who has worked on Volta! It's been a joy to use.

Here are my steps to migration (I think I've got a fully working environment). I use the Fish shell.
1. `brew install mise`

2. `mise use --global node@20` (we're still on node v20)

3. Close terminal tab and re-open to get `mise` auto-activation for Fish shell

4. Remove all VOLTA variables from shell configs (`~/.config/fish`)

5. `rm -rf /usr/local/bin/node` (was symlinked to ~/.volta/bin/node)

6. `rm -rf `$HOME/.volta`

7. `pnpm` was missing... => `corepack enable` fixed that.
Hope this is useful to others. I found this Mise page about Mise + Node.js useful for the last bits of getting set up.

recommand to add a step activate mise between step 2 and 3

Some deal breakers for migrating to Mise:

Requires creating a new file in every repo, instead of it just using the package.json file (this seems like a technically very simple thing for them to implement that I fear would be blocked by the maintainers just not wanting to make people's lives easier). They could even check for the Volta object and make this 100% seamless.
Mise requires running a command on every repo to give mise "trust", which is a 100% unnecessary constant speedbump in using it. I assume this "trust" issue has to do with one of the other dozens of tools it handles.

If I am incorrect in these issues, correct me below. Otherwise I am open to better suggestions than Mise, which seems like a major downgrade from Volta.

If anyone forks Volta, I'd also be interested in that, especially if it is re-written in JS. I've always had an issue with tooling for JS devs not being written in JS, it leads to situations like this, where JS devs can't easily contribute or take over open source projects when abandoned/deprecated/archived.

Also, willing to do some small USD donations if funding at all helps with Volta maintenance (it doesn't sound like that was the issue, but still worth mentioning).

@TheJaredWilcurt

@TheJaredWilcurt a couple notes:

There’s a deep and annoying tradeoff here—we argued a bunch about which way to go on this front when we originally implemented Volta, and one of our longest-standing requests was to implement support for using standalone files to define things. Embedding it in package.json is nice in some ways, but it means anyone using Volta must add it to a file that is nearly always in version control. The approach taken by Mise (and nvm and many other tools) to have an external file keeps most of the benefits and means people can use it without committing it (using .git/info/exclude or other similar approaches). This is just my opinion, not speaking for anyone else on the team, but if I could time travel, I’d default to putting it in an external file instead for Volta, too.
The security posture from Mise is quite good, actually, in my view. You should explicitly trust the specified environment rather than implicitly doing so in general. This isn’t solely down to the other tools it supports; there’s a reason pnpm asks for explicit trust on building packages after installation too! It’s a tiny bit of friction that you only pay once per package, and critically you only have to pay it when the config does something potentially dangerous, unless you choose to opt into a more restrictive mode! See the discussion in Mise’s docs for its paranoid mode for more details on that.

As for a fork—we’re quite open to folks doing that! And as a meta note, one major reason we support that path rather than handing over control here is that any such fork would have to earn trust on its own, rather than being able to piggyback off the reputation Volta itself has built up over the years.

I don’t think a JS rewrite is a great idea, though. Volta is as fast and “invisible” as it is largely because it’s written in Rust. (The same is true for Mise, which is one reason we all like it!) For context: Volta’s shims execute in roughly the same amount of time as simply printing node --version and meaningfully faster than you can do console.log("hello world") in Node. There are definitely things you can do to help with that, but it would be quite difficult, and getting a JS tool that does what Volta does anywhere nearly as effectively as Volta does it… would require writing pretty arcane JS. A JS dev that would have a hard time coming up to speed on Volta would also have a hard time coming up to speed on that kind of codebase.

Finally, as for donations, “small USD donations” aren’t remotely enough to cover the kind of investment Volta would need to be a going concern. Volta doesn’t need year-round full time effort, but to get it back up to be a healthy project would probably take 2–3 months of engineering work—at the consulting rates any of the maintainers would charge, that is tens of thousands of dollars!—and then ongoing effort of at least a month a year. This is a common challenge for projects like this! It doesn’t make sense to fund full-time work on it, but it needs more than nights and weekends—and none of the maintainers are in phases of life where we want to spend nights and weekends on this instead of time with our families and the like anyway, especially for free or “small USD donations”.

Hope that makes sense!

Thanks for creating Volta, it is a valuable tool.

I understand that OSS maintenance can be time consuming especially for a project like Volta that got a pretty big audience. This is a general issue, paradoxically I was "lucky" that my OSS side projects got very little attention.

I appreciate that you found an alternative like mise however it is not a full replacement for volta. I am not using Windows in my day by day but still the fact that mise does not support Windows is one of the reasons I will probably keep using Volta.

For instance my main use case is the following: I have few Electron projects, one for my customer and one OSS and when I need to open Windows to create a build to test it or release it, having the exact Node.js version with Electron makes the difference, in particular if there are compiled dependencies.

Another reason is that I prefer a tool like volta which does one thing. On the other hand mise looks too complex IMHO. It also can manage environment variables but direnv looks much better to me.

In summary, thanks to the creators of volta and I hope this project can bring you some ROI anyways.

Also wanted to share this very interesting article I found about this topic, with a comprehensive feature comparison: Can Mise replace Volta?

Tip

Found a possible alternative to volta: fnm

I've been using mise on Windows and am not being pressured into using any of the features I don't want to touch. I use it to auto-download tool versions and place them on my $PATH. I use --shims.

I think mise didn't support Windows in the past, but it does today.

Big thanks for maintaining Volta! I'm using mise these days, but Volta was a huge help to me back in the day.

Let's hire some Indian or Chinese university students to maintain it. it's free 💯

The transition between the two tools will not be easy as both tool will conflict when simply using node command (it will depend on PATH order). I would be great if #2007 could be released as it would allow a migration like:

Replace every package.json with volta config with a .node-version (we have more than 100 repositories using Volta 😅)
Uninstall Volta and install Mise

What I'm looking for is a version manager that is simple, lightweight, and works out of the box after installation—something that stays in the background and is practically invisible during day-to-day development.

Did you try Proto?

It's been a while for me but I think there's some minor opt-in config you may want (eg: auto-install for package.json metadata devEngines) but it should be quite nice from then onwards? Like I linked, you can get node and pnpm managed through package.json if that's your preference.

As for Mise, I'm not very comfortable with introducing a mise.toml file into a JavaScript project. It seems better suited for polyglot projects that need to manage multiple languages and toolchains. What I'm looking for is a version manager that is simple, lightweight, and works out of the box after installation—something that stays in the background and is practically invisible during day-to-day development.

You need a mise.toml file for enabling the idiomatic version files support, but you can keep Node.js/pnpm versions in package.json.

Alright folks, after making just two simple configuration changes, I've successfully switched from Volta to Mise. I also removed all Volta-related fields from the project's package.json, and there are no Mise-related configuration files or settings anywhere in the project either.

scoop install mise
[Environment]::SetEnvironmentVariable('Path', '%USERPROFILE%\scoop\apps\mise\current\bin;%USERPROFILE%\AppData\Local\mise\shims;' + [Environment]::GetEnvironmentVariable('Path', 'User'), 'User')

mise use -g node
mise settings add idiomatic_version_file_enable_tools node
mise use -g pnpm
mise settings add idiomatic_version_file_enable_tools pnpm

package.json

-   "volta": {
-     "node": "24",
-     "pnpm": "11.4.0"
-  },
  "devEngines": {
    "runtime": {
      "name": "node",
      "version": "24",
      "onFail": "error"
    },
    "packageManager": {
      "name": "pnpm",
      "version": "11.4.0",
      "onFail": "error"
    }
  }

monorepo/subproject/package.json

-  "volta": {
-    "extends": "../../package.json"
-  },

As for a fork—we’re quite open to folks doing that! And as a meta note, one major reason we support that path rather than handing over control here is that any such fork would have to earn trust on its own, rather than being able to piggyback off the reputation Volta itself has built up over the years.

While I believe it's hard to accept abandoning software praised by many users and ceasing any updates to its repository, I can understand the decision, especially in this era of frequent supply chain attacks, it's better to not risk it and hand it over to a random individual.. Anyways I've started maintaining the fork, because I'm still grateful for the time I've spent with Volta. I don't know how it will go, perhaps I just don't want Volta to die that quickly, but I'm enjoying the present. A patch release will be expected to released when I finish chawyehsu#41. In any case, thank you to everyone who has supported #1273.

The main benefit and strength of Volta that it did one thing and did it super well.

mise - it's an ecosystem. Whilst might be attractive to some, it asks to adopt too much. E.g. even in monorepo system uv is much nicer for Python. Just is much nicer for task definitions and running, I'm sure there's other examples.

The ideal migration path is to something that simply replaces Volta/nvm, not tries to sell you a new workflow system.

Don't make the mistake of believing that mise is forcing you to use it for anything more than managing node versions. It is not. Not at all.

If someone suggests that mise prevents you from using just: it does not.

If someone suggests that mise forces you to manage your just version via mise: it does not.

This sentiment has been raised in this thread before and it is simply not true. I suspect people are employing a heuristic that does not apply in this situation. Heuristics can mislead when applied uncritically.

Of course, a tool itself does not "force" anyone into a particular workflow, that is entirely up to its users. However, it inevitably leads people to perceive mise as being more "complex" than Volta, or more neutrally, as having a broader feature set.

mise - it's an ecosystem.

mise is undeniably an ecosystem, and that's part of its moat. When it provides functionality that is more readily accessible, people naturally tend to adopt it: using task instead of just, or env instead of dotenv. This is both one of its strengths (in a positive sense) and, in some ways, one of the trade-offs that come with ecosystem-oriented software.

I don't think this is really a matter of superiority or inferiority, it's simply a matter of choice. I also don't think anyone is intentionally putting one project down to promote another in this thread. I have a great deal of respect for mise's technical merits. In fact, I considered it worth trying long before it became widely recognized. Believe me, I used mise earlier than some people. (For what it's worth, I was also the reviewer who approved mise's inclusion in the Scoop Main bucket.¹)

That said, many people may not realize that mise only gained good support for native shims on Windows in February of this year.² By "native shims", I mean a mechanism similar to volta-shim, and also similar to the shim mechanism used by Bun on Windows, the latter itself was inspired by Scoop's shim implementation.³ Prior to that, it would be hard to say that Windows support in mise was particularly strong. As for mise's preference for using hook-env instead of shim, that's another trade-off. And other trade-offs that are difficult to describe. There's no silver bullet.

Fortunately, the situation has improved, as software naturally evolves over time. As for the trade-offs between hook-env and shim-based approaches, I won't go into that here; the topic could easily warrant an entire paper. (Perhaps I should write a blog post about it)

As for where the fork goes from here, I don't have any grand plans. I intend to address a few important issues, such as adding support for devEngines, (making it more integrated into the community?). For me, the fork is simply an alternative option that I wanted for myself, and one that I am making available to others who still prefer software that is less "complex." Be grateful and nothing more than that.

Heuristics can mislead when applied uncritically.

My earlier feedback on mise in the discussion here remains accurate though no?

Rough overview follows. mise is heavily dependent upon AI for development:

PRs lack useful context (justification, decisions). Code base is not maintained for humans/collaboration, but for AI agents to consume (which makes regressions/bugs easier to introduce as proper human review isn't as viable).
Issues tracker disabled in favor of Github Discussions. I spotted a regression/breakage and it got unnoticed for weeks.
CalVer versioning to support prioritizing velocity over stability (related bug report for regression). Semver adds friction but is extremely valuable to users when updating a tool in CI/projects.
NIH syndrome.
- Related to development velocity with AI, the less ecosystem reliance for integration with third-party libs the less dependent you're on upstream to get changes needed and otherwise slow process of potentially getting that desired change landed.
- As a result, projects that are AI-driven for development DIY their own libraries instead of collaborating in the ecosystem. This occurs even for niche domain expertise, delegating trust to AI to know better, rather than a dev invest much time acquiring that knowledge with confidence. Considerably risky when it comes to security and users should be wary of trusting such, yet mise went ahead and did this anyway (fnox) for the speed and control it affords development.
- Prior to this mise integrated with another library that was vibe coded and then used that integration as a reference point for the AI agent to build an alternative from scratch (despite that the author of the prior lib integration insisted theft, kinda ironic).

Mind you mise is from someone with a good reputation as a developer prior to leveraging AI if I recall. It can be much worse for those that are inexperienced (see rant section below).

For me though, the fact that mise when I tried it was so quick to break/fail (with a security feature at that), and the experience with trying to get the concerns resolved, I could not in good faith continue using mise after that trial evaluation.

What was observed wasn't going to change, it did seem like a valuable tool compared to alternatives I knew of, but those were too many red flags for me to adopt mise and praise it (which I had seen plenty of for about a year prior).

Proto on the other hand has been a more positive experience and while not at parity with mise it still meets many of the requirements I sought after and is going in a good direction.

Rant on risks from reckless AI adoption and mindset of devs

Collapsed as off-topic

The OpenClaw/ClawdBot dev also had an experienced dev behind it but leaned so heavily into delegation with AI agents that glaring security holes (of the basic kind) were slipping through that leaked credentials or gave RCE access to users systems.

Another project (from the OpenClaw dev) had concerning decisions on permissions requested for use, it didn't need as much, but the report was ignored for months (probably near a year now since I don't think I've seen any notifications from it since), whilst the project itself still saw new development elsewhere. These devs have different priorities and with AI shift perspective that I don't really care how appealing their projects are at the surface compared to alternatives, they are very risky to place trust in.

Then there's the more common vibe coder, that lacks proper expertise in the field and does much worse. Their projects often don't get as big of a success (but can still rack up stars compared to existing non-AI OSS alternatives that aren't as featureful) and they move onto something else more interesting to them than continuing to maintain projects or libraries they release.

Without the passion and time invested into a project, especially of the niche kinds, this isn't surprising, but it also tends to come with a different attitude towards software development. A popular project with a wide install base, could be sold off to another party that then takes malicious action, and this is far more aligned with vibe coder types that are less interested in code in favor of spitting out projects and monetizing their efforts.

Some even pollute the ecosystem with slop. I saw a library claiming it was an improved fork that removed dependency on OpenSSL, but that was never used by the project at runtime, only as part of a build script to support a dependency that cloned a git project at an old commit from years ago, just to copy one static file to support the build.

They could have simply committed that file in their own repo, or read the build error properly to understand they were likely missing a system package like openssl-dev, rather than the elaborate vibe coded workaround to perform TLS without a OpenSSL library.
There wasn't even any effort to engage with upstream via issue or PR which would have revealed what they did was a bad idea... yet they were proud of it enough to publish their library to a package registry with a misleading description (to be fair they did at least communicate they relied upon AI IIRC and that their library was a fork).

@chancancode

@chancancode thank you. That is precisely my point. It's the ye olde discussion about frameworks and micro-frameworks. Different situations and teams benefit from different tools. If situation haven't changed and you're advised to flip between the two - you will raise questions if there's a better way without the intent of tarnishing the frameworks.

Volta was focused to do one thing well [micro-framework].
mise does it all [framework] and with that comes the wider risk of needing to deal with seemingly unrelated issues from why the tool was picked in the first place. Not saying it's broken, but with high velocity, one must acknowledge risk and what focus does to bug counts and feature implementation times. Maybe it's rock solid and nothing will happen, but it's the proverbial moat that people have to consider when seeking to create stability.

It's just not 1:1 replacement. Some will love it, and we are considering adopting mise in one of the projects as it could be beneficial in that specific context.
But I do believe there's space to a more focused tool being among the broad recommendation.

I am very glad to hear that someone is forking Volta.

docs: mise.tomlをローカル開発の標準ツールとしても明記 (#12)

chore: replace Volta with mise for toolchain pinning (#55)

Is there any plan to update the website at https://volta.sh/ to note the deprecation? I couldn't find a related issue or PR.

Update:

Mise now supports using the devEngines in the package.json which is great. This is the official place to put your Node/npm version according to the package.json spec. All tools should use this as the source of truth.
I would still recommend Proto over Mise, which overall does a much better job. I'd only go with Mise if there are other programming languages you are using that are supported by Mise but not Proto (both support over 100 tools).
I've updated my Full Comparison of all Node Version Management tools which is now ~14 pages long.
- To summarize the conclusion:
  - Volta is great, RIP.
  - Use Proto, but disable telemetry.
    - Here's how: Setting up Proto as a Volta replacement

ci(e2e): Run E2E tests with pnpm 12 (#25334)

Navigation Menu

Repository navigation

Volta is unmaintained; we recommend migrating to `mise` #2080

13 remaining items

Rant on risks from reckless AI adoption and mindset of devs

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Volta is unmaintained; we recommend migrating to mise #2080

Description

Activity

chriskrycho commented on Nov 15, 2025

jeremywiebe commented on Nov 25, 2025

fowl2 commented on Dec 5, 2025

birdhackor commented on Dec 25, 2025

TheJaredWilcurt commented on Dec 28, 2025

chriskrycho commented on Jan 1, 2026

fibo commented on Jan 8, 2026

cspotcode commented on Jan 8, 2026

kubosho commented on Jan 9, 2026

lizyChy0329 commented on Jan 14, 2026

GuillaumeNury commented on Jan 14, 2026

13 remaining items

polarathene commented on May 29, 2026

risu729 commented on May 29, 2026

lisonge commented on May 29, 2026

chawyehsu commented on Jun 1, 2026

JackLeo commented on Jun 4, 2026

cspotcode commented on Jun 4, 2026

chawyehsu commented on Jun 4, 2026

Footnotes

polarathene commented on Jun 5, 2026

Rant on risks from reckless AI adoption and mindset of devs

JackLeo commented on Jun 5, 2026

alxndrsn commented on Sep 17, 2026

TheJaredWilcurt commented on Sep 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Volta is unmaintained; we recommend migrating to `mise` #2080