Installation and IDE Support

After installing the script in a global or user-wide location, you can use it everywhere. If it detects project-specific configuration of the Mill version, it will download and use this exact version.

You can also add the script to your project as mill. This makes it easier for new contributors to build your project, as they don’t have to install Mill before they can start. Anyone who wants to work with the project can simply use the ./mill script directly.

In-project bootstrap scripts are also useful for running Mill in CI/CD, ensuring that your build server like Jenkins or Github Actions has the correct version of Mill present to build, compile or test your code.

You can find this script in the root of the Mill repository, or on each release page. To get the latest version run the following command:

The mill command will automatically use the version specified by the bootstrap script, even if you installed it via other means. The ./mill file has a version number embedded within it, which you can update simply by editing the script.

You can also use lefou/millw as a drop-in replacement for mill. This script is a bit more advanced, and supports running on all major platforms including MS Windows.

The script supports to following sources when determining the best Mill version to use:

Using a system-wide installed millw is probably the robustest way to use Mill on any operating system. It also preserves support of rather old Mill versions next to recent ones, so that updating it or switching to millw initially should be a no-brainer.

Installation via homebrew:

Arch Linux has an Extra package for mill:

Installation via pkg(8):

To get started, download Mill from Github releases, and save it as mill.bat.

If you’re using Scoop you can install Mill via

Mill also works on "sh" environments on Windows (e.g., MSYS2, Cygwin, Git-Bash, WSL); to get started, follow the instructions in the Manual section. Note that:

To get started, download Mill and install it into your HOME ".local/bin" via the following curl/chmod command:

Installing mill via coursier or cs is currently not officially supported. There are various issues, especially with interactive mode.

The Build Server Protocol has the concept of BSP server discovery, which means: A BSP client can connect to any BSP server, as long as there is a connection file under the .bsp/ directory.

To install a BSP connection file .bsp/mill-bsp.json for Mill, run:

Working known clients of the BSP server are IntelliJ IDEA and Metals.

You can fine control some BSP server options by specifying command options:

In case things go wrong, it can be sometimes hard to find the cause. BSP is just a protocol, and as such, issues on the server side (the Mill BSP server) might not well propagated to the BSP client (your IDE).

For that reason Mill BSP server is writing a log file under .bsp/mill-bsp.stderr, where you can find various information about what’s going on. Its content should look familiar, as it contains regular Mill output accompanied by additional BSP client-server communication details.

You can increase the verbosity of that log file, when you run Mill with --debug at installation time (of the BSP discovery file).

A common issue for poor performance can be a mismatch of the JVMs. In such a case the Mill BSP server started by a BSP client like Metals is using a different JVM than mill is using when started from the command line. In such a scenario, every Mill invocation using the other JVM will inadvertently invalidate Mills target caches. This effectively leads to full reevaluation of all invoked Mill targets and appears as "bad performance".

To detect if this is the case,

If this happens, you’re using different JVMs. Unfortunately, this is rather difficult to "defend" programmatically in Mill itself. It is an explicit design goal of Mill, that it should work in different environments. It is evident and likely unintentional that you have two conflicting local environments.

To fix this it’s required to find where this difference stems from. As a starting point,

Once you found and fixed that and the environments are the same, clean and restarting BSP should work as expected.

If you wish to use Bloop as your build server (it is the default metals BSP implementation) with metals / vscode, consider using the mill bloop plugin.

Bloop Plugin

This is preferred to the instructions (currently) on the bloop website.

Please be aware, that the Bloop contrib plugin is maintained by the community and is probably not on a par with the built-in BSP server.

IntelliJ IDEA also supports the BSP protocol. To use this support, just follow the directions in Build Server Protocol (BSP).

Additionally, you can generate IDEA project files directly with Mill. This is probably the preferred way if you work on polyglot projects and need support for other languages like Kotlin or AspectJ, which are currently not specifically configured over BSP.

To generate IntelliJ IDEA project files into .idea/, run:

If your project is hosted on GitHub, GitLab, or Bitbucket, you can use Scala Steward to automatically open a pull request to update your Mill version (in .mill-version or .config/mill-version file), whenever there is a newer version available.

In case you want to try out the latest features and improvements that are currently in the main branch, unstable versions of Mill are available as binaries named #.#.#-n-hash linked to the latest tag.

The easiest way to use a development release is to use one of the Bootstrap Scripts, which support Overriding Mill Versions via an MILL_VERSION environment variable or a .mill-version or .config/mill-version file.