dvm: A Rust-based Deno version manager with a .dvmrc workflow

What dvm actually does and who needs it

dvm solves a narrow but real problem: you have more than one Deno version installed, and you need to switch between them without editing PATH by hand. The README describes it as an easy way to manage multiple active deno versions. That is the entire scope. It does not manage Node, Python, or any other runtime. It does not offer a daemon or a background service. The target user is a Deno developer who works on projects that require different Deno releases, or who wants to test a new Deno version without losing the old one. If you only ever use one Deno version, dvm adds nothing but a new tool to learn. The tool is written in Rust, which shows in the binary name in the help output: dvm.exe. That detail suggests a focus on speed and single-file distribution, though the README does not provide performance numbers.

How dvm stores and switches versions

The mechanism is simple. When you first run dvm, it creates a ~/.dvm directory if it does not exist. All installed Deno versions go into that directory. The list command shows installed versions, and an asterisk marks the one currently in use. Switching is done with dvm use, which accepts a version number like 1.1.0. If that version is not installed, dvm prints a message telling you to run dvm install first. The README shows that exact failure message. The use command also accepts a semver range or an alias, though the help text is truncated in the README. The key design choice is that dvm does not touch your system Deno installation. It keeps its own copies under ~/.dvm and changes the active one by updating environment variables or symlinks, depending on the platform. The README does not specify the exact mechanism beyond the PowerShell profile note for Windows.

Getting dvm running: installers and prerequisites

There are two official install paths. On macOS or Linux, you run curl -fsSL https://raw.githubusercontent.com/justjavac/dvm/main/install.sh | sh. On Windows, you run irm https://raw.githubusercontent.com/justjavac/dvm/main/install.ps1 | iex in PowerShell. Both installers download a release binary from the releases page. The shell installer has a hard dependency on the unzip program. If unzip is missing, the installer fails with a clear error message. The README suggests brew install unzip on macOS and apt-get install unzip -y on Debian or Ubuntu. The Windows installer requires PowerShell because dvm uses the PowerShell profile to set environment variables. That is a notable constraint. If you do not use PowerShell as your shell on Windows, or if your profile is locked down by group policy, the installer may not work as expected. After installation, dvm -V verifies the version.

The .dvmrc workflow for per-project versions

The most interesting feature is the .dvmrc file. By default, dvm writes its active version to a home folder config. But if you add the --local flag to dvm use, it writes a .dvmrc file in the current directory. From then on, running dvm use or dvm install with no version argument reads the version from .dvmrc. The README shows the exact output: No version input detect, try to use version in .dvmrc file, then Using semver range: 1.17.0. This is a clean way to pin a Deno version per project. A teammate who clones the repository can run dvm use and get the right version without reading a wiki page. The .dvmrc file is plain text, so it can be committed to version control. The limitation is that dvm does not auto-switch when you enter a directory, unlike some version managers that hook into shell prompts. You must run dvm use manually. The README does not mention any shell hook or automatic detection.

A genuine limitation: the unzip and PowerShell requirements

The README lists two caveats that are real friction points. The first is unzip. On a minimal Linux container, unzip is often not installed, so the curl pipe to sh fails immediately. That is a poor first-run experience for a tool that claims to be easy. The installer could bundle a fallback, but it does not. The second is PowerShell on Windows. The README states that dvm uses the PowerShell profile to set environment variables, and it is required. That means on Windows you are tied to PowerShell as your shell. If you use cmd, Git Bash, or Windows Terminal with a different default, you may need to adjust. Also, modifying the PowerShell profile is a side effect that some users dislike. The failure mode is clear: the installer errors out, and you are left to manually extract a zip and set PATH yourself. The README does not describe a manual fallback, so you are on your own.

Comparing dvm to other version managers

The closest alternative is nvm for Node.js, but that is a different runtime. For Deno specifically, the official Deno installer can install a specific version, but it does not manage multiple versions side by side. Another alternative is to download Deno binaries manually and manage symlinks yourself. That works but is error-prone. The real difference is that dvm centralizes the workflow: install, list, use, alias, and uninstall are all subcommands. The .dvmrc file is a distinctive feature that manual symlink management lacks. If you already use fnm for Node, you might wonder if it supports Deno. Fnm is Node-only, so you would need a separate tool for Deno. The practical comparison is: dvm is a dedicated Deno tool, and it does not try to be a polyglot runtime manager. That focus is both a strength and a limitation. You get a small, focused tool, but you cannot replace your Node version manager with it.

Maintenance and license considerations

The repository is archived: no, and the last push was 2026-08-25, which is the same day as the v1.10.1 release. That indicates active maintenance. The releases are frequent enough: v1.10.1 in August 2026, v1.10.0 in August 2026, and v1.9.3 in February 2025. The gap between v1.9.3 and v1.10.0 is about 18 months, which suggests the project is not on a strict schedule. The license is MIT, which is permissive. You can bundle dvm in your own tools or modify it without many restrictions. The README includes a bundled LICENSE file. For upgrade cost, the installer scripts are simple, so updating dvm likely means rerunning the same curl command. The README does not describe an update subcommand, so you need to reinstall to get a new version. That is a minor cost, but it is worth knowing.

Editorial conclusion

Adopt dvm if you work with multiple Deno versions and want a per-project version pin via .dvmrc, especially on macOS or Linux where the shell installer is straightforward. Avoid it if you need a Windows-native experience without PowerShell profile changes, or if you prefer a version manager that also handles other runtimes. Before adopting, verify that your CI and local machines have unzip available, and test that the PowerShell installer's profile modification works in your environment. If you need a single tool for Node and Deno, consider nvm or fnm for Node plus dvm for Deno, but that adds complexity. The project is actively maintained with recent releases, and the MIT license is permissive.

Frequently asked questions

Official sources

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