How to Manage Multiple Flutter SDK Versions on One PC with FVM

If you build more than one Flutter app, you have already felt the friction: Project A needs an older engine for a plugin pin, Project B tracks stable, and Project C matches whatever the client’s CI YAML demands. The old workaround is keeping a zip per version and swapping PATH by hand—which works until you mis-type a path at midnight.

FVM (Flutter Version Manager) is the pragmatic fix: it installs several SDKs, then selects per project so flutter inside that folder resolves to the version you pinned.

When you eventually ship those apps against an API on a small VPS, boring infra should stay copy-paste—I still keep the Nginx on Ubuntu install and firewall snippet next to Flutter work so renewals and proxy edits do not turn into improvisation.

What FVM solves for multi-project Flutter work

FVM is exactly what it sounds like: a version manager for Flutter. You keep one laptop, many SDKs, and each repo declares which line it expects—similar spirit to nvm for Node, just aimed at the Dart toolchain and engine artifacts you download with Flutter releases.

On macOS or Linux the install story differs; if you are not on Windows, start from the official FVM installation docs and come back—the fvm install / fvm use flow below stays the same once the binary is on your PATH.

For Android debugging ergonomics—getting localhost backends through an emulator—see forward an emulator port with adb; it is the other half of “device talks to my machine” once builds are consistent.

Install FVM on Windows with Chocolatey

This walkthrough targets Windows because that is still the most common desk I see on beginner-heavy teams. Prerequisite: Chocolatey. If you do not have it yet, install it from chocolatey.org/install—that is the supported path Chocolatey documents today.

Notice the install is one line once Chocolatey works:

choco install fvm

That drops the fvm executable somewhere your shell can see; restart the terminal if fvm --version fails immediately after install.

Pin versions with fvm install and fvm use

Only two commands do most of the day-to-day work after setup.

Pull a new engine build:

fvm install <version>

Bind the current project folder to that build:

fvm use <version>

Run fvm use inside the Flutter project root—the tool writes the metadata and symlink dance it needs next to your pubspec.yaml. If you are unsure what landed, list everything FVM knows about:

fvm list

That prints installed versions and the paths you will paste into editors. By default you should expect a .fvm folder inside the project that points at the cached SDK; treat the path fvm list echoes as the source of truth when something looks “almost right” in Android Studio.

Find SDK paths, then wire VS Code and Android Studio

Most of the time tooling auto-detects FVM once the project is pinned, but when it does not, aim editors manually at the SDK path you copied from fvm list.

VS Code — set dart.flutterSdkPath in settings.json (workspace settings are fine if you only want it for one repo):

{
  "dart.flutterSdkPath": "<version-path>"
}

Replace <version-path> with the full folder fvm list prints—no guessing.

Android Studio — open Settings → Languages & Frameworks → Flutter and paste the same Flutter SDK path. Older posts sometimes typo “Framerworks”; the menu is Frameworks.

If you maintain the Linux side of the same stack—scheduling cleanup or backups on the box that serves your API—pair this mobile setup with Linux crontab scheduling so housekeeping survives reboots the same way FVM survives repo hops. When that box is fresh Ubuntu and needs Nginx plus UFW without a treasure hunt, the single-page install snippet is what I paste first.

That is the whole circuit: Chocolatey → FVM → fvm install / fvm use → editors pointed at the listed path. You keep one PC, many Flutter versions, and fewer “wrong engine” surprises when CI runs the same fvm pins you do locally. When the API you exercised in the emulator graduates to a real Ubuntu host, Nginx plus UFW in one bash slab is still what I open next to this tab.

Frequently asked questions

What is FVM and why bother instead of keeping Flutter in separate folders?

FVM is Flutter Version Manager. It downloads SDKs once, stores them in a managed layout, and rewires each project with metadata and symlinks so flutter resolves to the version that project pinned. You stop maintaining a personal spreadsheet of unzip folders and PATH exports.

How do I install FVM on Windows for this workflow?

Install Chocolatey using the official installer script, then run choco install fvm. Open a new shell, confirm fvm runs, and proceed to fvm install for whatever channels you need.

Where does FVM store Flutter SDKs on disk?

Use fvm list. It shows every installed version and the filesystem paths FVM associates with them. Expect a project-local .fvm directory that points into the cache for the version you selected with fvm use.

How should VS Code and Android Studio point at an FVM-managed Flutter SDK?

Grab the directory path from fvm list for the version your project uses. Put that value in VS Code as dart.flutterSdkPath, and in Android Studio under Settings → Languages & Frameworks → Flutter as the Flutter SDK path. Both must match or analysis and Gradle will disagree in subtle ways.

When is FVM the wrong tool?

If you only ever compile against one Flutter forever, a single global SDK on PATH is simpler. FVM shines when CI, clients, or plugins force different engine lines across repositories and you want your laptop to mirror that matrix without drama.