vfox is a version manager whose real work happens in your shell rc file

Step two is the install, and the Nushell line has nothing under it

The quick start is five numbered steps, and the second one is doing more work than step one. Whatever installation route you choose, vfox has to be hooked into your shell by appending an eval of its activation output to the right dotfile:

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

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

# For Clink:
# 1. Install clink: https://github.com/chrisant996/clink/releases
#    Or Install cmder: https://github.com/cmderdev/cmder/releases
# 2. Find script path: clink info | findstr scripts
# 3. copy internal/shell/clink_vfox.lua to script path

# For Nushell:

Fish is the odd one out, using a pipe into source rather than an eval. PowerShell is handled in two steps so the profile file exists before the line is appended. Clink does not use an eval at all and instead asks you to copy a Lua file from the repository into the script directory Clink reports. And the last heading in that block, for Nushell, is followed by nothing: the shell is named and then the page stops. Under the block the page reminds you to restart your shell, which is the other half of what this step costs.

Fish completion is a manual step unless a package manager did it

Completion is treated as part of the install, and the way you get it depends on how you installed the binary. The page states that Homebrew, DEB and RPM packages install it automatically. For an archive or source installation, you run two commands from the extracted archive or the repository directory yourself:

mkdir -p ~/.config/fish/completions
cp completions/vfox.fish ~/.config/fish/completions/vfox.fish

That is the whole manual procedure, and the reason it is called out separately is that the completion file lives in the repository under a completions directory rather than in a system path. It is also the only place the fish path is spelled out, which is a reminder that the activation line and the completion are two different mechanisms: one changes what the shell can resolve at runtime, the other teaches the shell what commands exist. The advertised completion support is wider than fish alone, covering Bash, ZSH, Fish, Powershell and Clink.

Three commands go from no runtime to a running one

The rest of the quick start is short enough to read as a contract. You add a plugin, you install a version, you switch to it, and then the runtime answers for itself:

$ vfox add nodejs

$ vfox install [email protected]

$ vfox use [email protected]
$ node -v
21.5.0

Note the addressing scheme, a runtime name and a version joined by an at sign, which is the same idea as the version files other tools use and is why those files can be read as input. Nothing here installs a Node distribution by hand, sets an environment variable by hand, or asks you to restart the IDE. The final `node -v` line is there because the whole point of the activation step in the previous section is that a switched version is visible to the shell you are standing in, so the check is the runtime reporting its own version rather than vfox confirming a state.

It reads the config files other managers already wrote

The migration story is three file names. vfox supports existing config files `.node-version`, `.nvmrc` and `.sdkmanrc`, so a project that already pins a version for another manager does not need editing to be understood here. On top of that sits the behaviour that makes a version manager worth having: it automatically switches runtime versions as you traverse your project, meaning the version in effect follows the directory you are in rather than a setting you remember to change. The page also puts three scopes side by side, different versions for different projects, different versions for different shells, and a global version, which is the distinction most tools of this kind make badly. The claimed advantage over its named alternatives, which are nvm, fvm, sdkman and asdf-vm, is that one command set covers all of them rather than one per runtime.

Plugins live in a separate registry repository

The binary ships without any runtime support, and the way you find out what exists is a command rather than a page on the site: once vfox is installed, `vfox available` lists the plugins you can add, with the documentation site holding the longer descriptions. That split has a second half. Plugin contributions do not go to this repository at all, they go to a public registry kept in its own repository, which is where a runtimes plugin is expected to be developed and reviewed. The main repository keeps only what the tool itself needs, and its own examples directory holds a plugins folder, which is where you would look for the shape a plugin is expected to take. Runtime coverage is described broadly in the repository description, naming Java, Node.js, Golang, Python, Flutter and .NET among others, but the authoritative list is whatever `vfox available` prints for the version you have installed.

The binary embeds a Lua interpreter and four decompression libraries

The dependency list explains more about the design than the feature list does. The module is `github.com/version-fox/vfox` on Go 1.24.0, and the command line is built on the third version of the urfave CLI library. A Lua interpreter is a direct dependency, which is what a plugin system that can be extended without recompiling the binary usually looks like. Alongside it sit four archive and decompression libraries, one for seven zip, one for xz, one general purpose compression library that also brings brotli and lz4, and a Windows specific one, which together cover what a runtime download can arrive as. An HTML parser is in the list as well. Interactive terminals are handled by a cursor library and a keyboard library, progress bars and coloured terminal output have their own dependencies, and system information comes from a process and hardware utility library. Two configuration formats are compiled in, TOML and YAML.

Releases are still 1.0.x, with a five month gap in the middle

Version history is short and irregular. The three most recent releases are v1.0.10 on 2026-04-15, v1.0.11 on 2026-04-29 and v1.0.12 on 2026-09-06, so two patches two weeks apart and then a five month silence before the next one. The default branch was pushed on 2026-10-04, which is a month after the last tag. The repository is a Go project with the usual release machinery: a GoReleaser configuration, an install script, a packaging directory, and an Inno Setup directory, which is what produces a Windows installer. A `CNAME` file at the root points the documentation site at a custom domain, and there is a coverage service configuration alongside it. Documentation exists in English and Chinese, there is a code of conduct and a contributing guide, and the copyright line reads Apache 2.0 with a 2026 date and an individual name rather than a company.

Editorial conclusion

vfox is worth installing if your work spans projects that pin different runtime versions and you already recognise the shape of nvm or sdkman, because it reads the config files those tools leave behind and gives every runtime one command set. It is a poor fit if you want the manager to stay out of your shell startup files, since the documented setup is an eval line appended to a dotfile and the fish completion is a second manual step unless a package manager handled it. Before you start, check four things. Which runtimes you actually need plugins for, since the binary ships none of them and `vfox available` is the only catalogue. Which version files your existing projects already carry, since `.node-version`, `.nvmrc` and `.sdkmanrc` are read but not rewritten. Which shells you actually use, and note that the page lists Nushell as a heading with no activation snippet. And whether you are comfortable with a project whose releases are still numbered 1.0.x, with the newest at v1.0.12 from 2026-09-06 and the branch pushed on 2026-10-04.

Frequently asked questions

Official sources

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