vfox: a Go version manager that switches runtimes per project, per shell or globally

The problem vfox solves: too many runtime versions, too many managers

If you work across a Java service, a Node.js front end and a Go CLI, you probably have three version managers installed, each with its own commands, its own shell hook and its own idea of what "current version" means. The README frames the target user directly: people who "switch between development projects which expect different environments" or who are "tired of all kinds of cumbersome environment configurations". vfox replaces that stack with one binary and one command vocabulary. The same install, use and add verbs apply whether the runtime is Java, Node.js, Golang, Python or Flutter. That consistency is the product, not any single runtime's support. The secondary audience is people on Windows. The README lists Windows first among supported platforms and ships a Clink integration and an inno_setup directory for installers, territory that nvm and fvm handle poorly or not at all. The third audience is plugin authors: anyone whose runtime is not covered can write a plugin rather than wait for the core team.

How vfox works: a Go core, Lua plugins and a shell hook

The binary is written in Go (go.mod targets go 1.24.0) and embeds a Lua interpreter through github.com/yuin/gopher-lua. Plugins are Lua scripts, and the repository keeps sample ones under examples/plugins/. A plugin's job is to describe where a runtime's releases live, how to fetch them and how to lay the extracted files out on disk. That design keeps the core small and pushes per-runtime quirks into the plugin, which is the same trade-off asdf makes and the opposite of nvm, where Node.js support is compiled into the tool itself.

The second mechanism is the shell hook. The README marks it with a warning and requires you to add an activate line to your shell config. That hook is what lets vfox react as you move between directories: the README claims vfox can "automatically switch" runtime versions as you traverse your project. The README does not document how that detection is implemented, so treat the exact trigger conditions as something to confirm on your own shell.

A third mechanism is config-file compatibility. vfox reads existing .node-version, .nvmrc and .sdkmanrc files, so a repository already set up for nvm or SDKMAN does not need a new file to work. That lowers the cost of trying vfox on an existing codebase, and it is the detail that most distinguishes it from a greenfield-only tool.

Installing vfox and switching a Node.js version for one project

The README points to the Quick Start page at vfox.dev for installation options and does not reproduce the download commands itself. What it does give is the shell hook, which is mandatory. Pick the line for your shell and append it to your startup file:

echo 'eval "$(vfox activate bash)"' >> ~/.bashrc
echo 'eval "$(vfox activate zsh)"' >> ~/.zshrc
echo 'vfox activate fish | source' >> ~/.config/fish/config.fish

For PowerShell the README creates the profile file first if it is missing, then appends the activation expression:

if (-not (Test-Path -Path $PROFILE)) { New-Item -Type File -Path $PROFILE -Force }
echo 'Invoke-Expression "$(vfox activate pwsh)"' >> $PROFILE

Restart the shell afterwards. Next, add the plugin for the runtime you want. The README uses Node.js:

vfox add nodejs

Then install a specific version and make it current:

vfox install [email protected]
vfox use [email protected]
node -v

The README shows the last command printing 21.5.0. If it prints a different version, the most likely cause is that the shell hook is not active in the session you are testing, so check the activate line before debugging anything else. To see what plugins exist, the README names vfox available as the command that lists them.

Where vfox gets in the way

The shell hook is the biggest constraint. Without an eval line in .bashrc, .zshrc, the fish config or the PowerShell profile, version switching does not happen, and the README itself flags this step with a warning. That rules vfox out for environments where you cannot modify shell startup files, and it makes vfox awkward inside CI jobs that run each step in a fresh non-interactive shell. You would have to source the activation explicitly in every step.

Plugin availability is the second limit. Support for a runtime is only as good as its plugin, and plugins live in a separate registry repository rather than in the core. The README directs plugin contributions to the Public Registry. So "vfox supports X" always means "someone published a plugin for X", and quality, update frequency and correctness vary by plugin. The core project's release cadence says nothing about whether the plugin for your niche runtime was touched this year.

The third limit is scope. vfox manages runtimes. It is not a package manager, not a build tool and not a container runtime. If your real problem is that two services need different libc versions, a version manager will not help; containers will. The README's own framing is about runtime versions and ambient libraries, which is a narrower promise than "reproducible environments".

vfox compared with asdf and nvm

The README places vfox alongside nvm, fvm, sdkman and asdf-vm, so the honest comparison is with asdf, the closest in design. Both are plugin-based multi-runtime managers. The differences are in implementation and reach. asdf's plugins are shell scripts; vfox's are Lua scripts running inside a Go binary, which means a plugin author works against a Lua API rather than shell conventions. vfox also ships first-class Windows support with PowerShell and Clink integrations, while asdf's documentation has historically centred on Unix shells. If your team is mixed Windows and macOS, that matters more than plugin language.

Against nvm the difference is narrower but clearer. nvm manages Node.js only, and its version resolution is tied to Node.js conventions. vfox manages Node.js as one plugin among many and reads .nvmrc anyway, so migrating a Node-only repository to vfox is close to free. The reason to stay on nvm is that it is the default in most Node.js documentation and CI images, and a Node-only team gains little from a multi-runtime tool. sdkman is the JVM-world equivalent: strong Java and Kotlin coverage, weaker outside it. vfox's pitch is that you stop choosing.

Maintenance, releases and licence

The repository is not archived, and the most recent release listed is v1.0.11 on 2026-04-29, with v1.0.10 on 2026-04-15 and v1.0.8 on 2026-04-03. The last push to the default branch is the same date as v1.0.11, 2026-04-29. Three releases in April 2026 indicate a period of active release work, but that is the most recent signal available and roughly four and a half months have passed since. There is no published roadmap in the README, so upgrade cost is hard to estimate beyond the release list. Practically, the cost sits in the plugins: a core upgrade can change the plugin API, and each plugin in the registry then needs to catch up. Pin the core version in your tooling and test the plugins you depend on before moving.

On licensing, the core is Apache-2.0, copyright Han Li and contributors. Apache-2.0 permits commercial use and modification and includes a patent grant, which is friendlier than MIT for corporate review. It does not, however, say anything about the plugins you install from the registry. Those are separate repositories with their own licences, and the README does not state what they are. If your organisation has a licence allowlist, check each plugin individually. This is a description of the licence text, not legal advice.

Editorial conclusion

Adopt vfox if you keep several language runtimes on one machine and want one command set for all of them, including on Windows, where nvm and fvm do not cover the same ground. Skip it if you only ever need one Node.js version, or if you cannot add an eval line to your shell startup file, because the activate hook is what makes version switching work. Before committing, verify three things yourself: that the plugin you need exists in the registry (vfox available lists what is published), that your shell's activate syntax is the one shown in the README, and that the runtime you install actually resolves through the PATH shim after vfox use. The Apache-2.0 licence on the core tool does not automatically cover third-party plugins, so check each plugin's own repository before you ship it in a locked-down environment.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes