FVM

FVM is a free tool for managing Flutter SDK versions separately for each project. It suits Flutter developers and teams that need a shared version pin across development and CI; its narrow focus is useful, though IDE setup outside VS Code takes extra configuration.

Overview

FVM lets projects use different installed Flutter SDK versions, switching between them without downloading Flutter again. A project’s .fvmrc records its chosen version and can also hold project-specific settings and flavors, giving teammates a common reference for builds.

This is a dedicated Flutter SDK manager rather than a general environment manager. Its MIT license and open-source community model suit teams comfortable with community-led software. Documentation and GitHub feedback are the stated support routes.

Key features

Project pins and team consistency

Pinning a version per project is valuable when a team maintains multiple Flutter apps or needs development environments to match CI. The shared .fvmrc helps reduce version drift, provided developers and automation use the project’s configured SDK rather than another Flutter installation.

SDK cache and automation

FVM can identify SDKs that no project references, preview cleanup candidates, and remove unused versions with fvm cleanup. That offers a more deliberate way to reclaim space than deleting SDKs without checking whether projects still rely on them. Its commands are intended for CI/CD automation, making it suitable for workflows that need to select the project’s pinned version.

IDE and developer integrations

FVM can detect VS Code and update .vscode/settings.json so the Dart Code extension uses the project-managed SDK. Android Studio and IntelliJ do not receive the same automatic settings update; developers must point those IDEs to the FVM SDK path themselves. That makes FVM a smoother fit for VS Code-oriented teams than for teams expecting uniform IDE configuration.

JSON API commands expose installed SDKs, releases, cleanup data, environment context, and project configuration for scripts and integrations. The Dart MCP server can be directed to .fvm/flutter_sdk so AI assistants use the project’s pinned SDK. Custom Flutter repositories are supported through fork configuration.

Pricing

FVM is free, with no trial or paid tier to compare. The free plan is the whole product rather than a capped entry tier, and its MIT license permits open-source use. There are no seat or usage quotas to weigh against a subscription.

Platforms

FVM supports macOS, Linux, and Windows, with standalone packages for macOS x64 and arm64, Linux x64, arm64, and riscv64, and Windows x64 and arm64. Installation options include a shell script, Homebrew, Chocolatey, Pub, and standalone GitHub packages. The project also documents Melos monorepo configuration and Android Studio and IntelliJ setup.

FVM keeps known project-root paths in a machine-local projects.json file and does not scan disks for projects. Those paths are absolute, so the record is local to the machine rather than a portable team inventory.

Who it's for

FVM is best for Flutter developers or teams maintaining projects that need different SDK versions, especially when consistent local and CI builds matter. It is also a practical choice for teams that want to manage installed SDK clutter or use scripts against project-specific SDK configuration. Developers who rely on Android Studio or IntelliJ should be prepared to configure the SDK path separately.

Pros and cons

• Project-specific versions: Different projects can pin different Flutter SDKs, avoiding repeated reinstalls when switching work.
• Shared configuration: The .fvmrc gives teammates and automation a common project version to follow.
• Controlled cleanup: Previewing unused SDK candidates before running cleanup helps avoid removing versions still referenced by projects.
• Multiple integration paths: VS Code settings updates, JSON API commands, and CI/CD-friendly commands support common development and automation workflows.
• IDE setup is uneven: Android Studio and IntelliJ require a separate SDK-path configuration rather than the automatic VS Code settings update.
• Focused scope: FVM manages Flutter SDK versions, so teams seeking a broader environment manager will need another tool.

Alternatives

For a wider selection of tools in this category, browse Development Environment Managers.

• GHCup is a free tool for installing and managing the Haskell toolchain; choose it for Haskell rather than Flutter SDK version management.
• ActiveState Platform offers a free organization plan for public projects and a paid organization plan with custom pricing; choose it if that public-project plan fits your needs.
• devenv is free and MIT-licensed, requires Nix, and works on Linux, macOS, and WSL; choose it if you want an environment tool built around Nix.
• Flox has a free Personal plan with the Flox CLI, catalog access, unlimited public environments, and three private FloxHub environments; choose it if those environment features match your work.
• frum is a free, MIT-licensed Ruby version manager; choose it for Ruby rather than Flutter.
• Jabba is a free Java version management tool under the Apache License 2.0; choose it for Java SDKs.
• vfox is a free tool under the Apache 2.0 license; choose it if that license and tool are a better fit for your needs.
• DDEV is free and open source under the Apache 2.0 license; choose it if you prefer that project.

Verdict

Choose FVM if your work centers on Flutter and you want project-pinned SDK versions that can be shared with teammates and used in CI without reinstalling Flutter for each switch. Its strongest reason to choose is the combination of per-project configuration and installed-SDK cleanup at no cost. Look elsewhere if you need a general environment manager or expect Android Studio and IntelliJ configuration to be automatic.