LEAN: the CLI needs Docker, and the Dockerfile needs your build output

Four of the five CLI commands are Docker commands wearing a Python name

The command line tool is one pip package:

pip install lean

Five commands appear in the readme. `lean project-create` creates a new project containing starter code, and it is the only one that needs nothing but Python. The other four are Docker work by another name. `lean research` runs a local Jupyter Lab environment using Docker, `lean backtest` backtests a project locally using Docker, `lean optimize` optimizes a project locally using Docker, and `lean live` starts live trading a project locally using Docker. So installing the tool is the cheap half of the story. A reader on Windows or Linux without a container runtime will scaffold a project successfully and hit the wall at the first backtest; the full command list is in a separate cheat sheet PDF.

The Dockerfile copies your compiled output instead of compiling anything

Building the engine image is not a compile. The container definition inherits a base and copies binaries you were expected to produce beforehand:

#
#   LEAN Docker Container 20200522
#   Cross platform deployment for multiple brokerages
#

# Use base system
FROM quantconnect/lean:foundation

MAINTAINER QuantConnect <[email protected]>

#Install debugpy and PyDevD for remote python debugging
RUN pip install --no-cache-dir ptvsd==4.3.2 debugpy~=1.6.7 pydevd-pycharm~=231.9225.15

# Install vsdbg for remote C# debugging in Visual Studio and Visual Studio Code
RUN wget https://aka.ms/getvsdbgsh -O - 2>/dev/null | /bin/sh /dev/stdin -v 17.10.20209.7 -l /root/vsdbg

COPY ./DataLibraries /Lean/Launcher/bin/Debug/
COPY ./Lean/Data/ /Lean/Data/
COPY ./Lean/Launcher/bin/Debug/ /Lean/Launcher/bin/Debug/
COPY ./Lean/Optimizer.Launcher/bin/Debug/ /Lean/Optimizer.Launcher/bin/Debug/
COPY ./Lean/Report/bin/Debug/ /Lean/Report/bin/Debug/
COPY ./Lean/DownloaderDataProvider/bin/Debug/ /Lean/DownloaderDataProvider/bin/Debug/

# Can override with '-w'
WORKDIR /Lean/Launcher/bin/Debug

ENTRYPOINT [ "dotnet", "QuantConnect.Lean.Launcher.dll" ]

Read the COPY lines. Five of them take sources such as `./Lean/Launcher/bin/Debug/` and `./Lean/Optimizer.Launcher/bin/Debug/` and drop them at matching paths inside the image. No compiler runs in there. So the build fails unless you already built the launcher, the optimizer launcher, the report project and the data downloader on the host, with that exact output layout. The first COPY is shaped differently from the rest, its source being `./DataLibraries` with no `Lean/` prefix while every other source carries one, so the build context has to satisfy both shapes. What a Docker user actually does here is package a directory they compiled themselves.

A 2020 container pins three debuggers against a dotnet 10 target

The container header is dated 20200522 and its debugging stack is pinned in full. Python remote debugging gets `ptvsd==4.3.2 debugpy~=1.6.7 pydevd-pycharm~=231.9225.15`, C# remote debugging gets vsdbg version 17.10.20209.7 unpacked into `/root/vsdbg`, and the file describes itself as cross platform deployment for multiple brokerages. Meanwhile both source build recipes, macOS and Linux, ask for dotnet 10. That distance has a concrete effect on anyone who wants to attach an editor to a running container. The debuggers inside the image are pinned to fixed versions in the Dockerfile itself. Pinning versions buys reproducibility, and the price paid by a reader is that the container you are told to use is a fixed and dated debugging environment, not a current one.

Four Dockerfiles split foundation, Jupyter, and ARM by hand

The repository ships four container definitions: `Dockerfile`, `DockerfileJupyter`, `DockerfileLeanFoundation`, and `DockerfileLeanFoundationARM`. The plain `Dockerfile` begins from `quantconnect/lean:foundation` instead of from a language runtime, so the foundation image is itself built from this repository and published, and the ARM variant is a separate file with its own build. The Jupyter file matters on its own, because `lean research` is the one CLI command whose entire purpose is a notebook environment. The existence of a dedicated ARM foundation file suggests ARM hosts use a different foundation image from the default one.

The readme routes you to the CLI and outsources IDE setup to two other files

The source install section opens by telling you not to use it. For most users it strongly recommends the LEAN CLI, which it calls prebuilt and says runs on all platforms. Two links then carry the real editor setup, `.vscode/readme.md` and `.vs/readme.md`, one per IDE. So this page is a router rather than a setup guide. The local source route is still written out for anyone who wants it, either the zip of the latest master or a clone:

git clone https://github.com/QuantConnect/Lean.git
cd Lean

Both routes land in the same repository, but the ownership differs. The CLI route hands environment management to Docker, and the IDE route hands it to two files that are not on this page. Anyone planning a setup should expect to leave this page for at least one more document, and should read the linked IDE guide for the platform before assuming the generic commands apply.

Windows builds a solution, macOS builds a directory, and only Windows mentions restore

Three platform recipes, three different shapes. Windows asks for Visual Studio, opening `QuantConnect.Lean.sln` in it, notes that building the solution should trigger the NuGet package restore, and then runs with F5. macOS carries a note that Visual Studio for Mac has been discontinued and points to Visual Studio Code, the C# Dev Kit extension, and the dotnet 10 SDK, followed by a command line build:

dotnet build

Linux, for Debian and Ubuntu, installs dotnet 10 and names the solution explicitly:

dotnet build QuantConnect.Lean.sln

Both command line recipes then start the engine the same way, by changing into `Launcher/bin/Debug` and running `dotnet QuantConnect.Lean.Launcher.dll`. Two things follow from that. The macOS command has no project argument while the Linux one does, though the macOS recipe also calls this building the solution. And package restore is mentioned only in the Windows path.

Release tags stop in 2017 while master was pushed on 2026-10-01

Versions and branch activity point in opposite directions here. The three newest releases are v2.4.0.1 for R-Support, Visual Studio Integration and Python Updates dated 2017-08-08, v2.4.0.0 for Python Library Support dated 2017-05-01, and v2.3.0.3 for Free Streaming Live Data with IEX dated 2017-03-16. All three fall inside five months and the list stops there, while the default branch master was pushed on 2026-11-02. The readme backs the branch rather than the tags by linking the zip of the latest master, and two status badges at the top of the page track the Build & Test Lean and Regression Tests workflows, so per commit signal exists where per version signal does not. For anyone pinning a deployment the consequence is direct. The newest tag is years behind the code you would otherwise read, so pinning by version number buys you 2017, and pinning by branch buys you movement you have not reviewed. Pin a commit and read the badges for that commit.

Python sits in its own project while the root mixes CI, benchmarks, and a stray HTML file

Python support is delegated in a single sentence, pointing at the Algorithm.Python project for a full explanation of the installation process rather than covering it here. The root directory shows how much sits outside the engine itself. The strategy surfaces are `Algorithm/`, `Algorithm.CSharp/`, `Algorithm.Framework/`, and `AlgorithmFactory/`, and the rest of the layout runs `Api/`, `Brokerages/`, `Common/`, `Compression/`, `Configuration/`, `Data/`, `Engine/`, `Indicators/`, `Queues/`, `Messaging/`, `Logging/`, `ToolBox/`, `Report/`, `Research/`, `DownloaderDataProvider/`, plus two optimizer directories, `Optimizer/` and `Optimizer.Launcher/`. Beside them sit `mypy.ini`, `run_benchmarks.py`, `compare_benchmarks.py`, `run_syntax_check.py`, `find_datasource_repos.py`, `ci_build_stubs.sh`, `rebase_organization_branches.sh`, a `.travis.yml` next to a `.github/` directory, and one stray `google9161359af9633398.html`. Two of those carryovers matter. Two continuous integration systems coexist with no statement of which is authoritative, and that stray HTML file sits in the project root.

Editorial conclusion

Use LEAN if you intend to own the engine source and accept the running cost of dotnet 10, Docker, or a from source build. Stay away if you were expecting a hosted product with market data and execution included; this repository is the engine. Verify three things before you commit a deployment: that you can build the four projects whose compiled output the Dockerfile copies, that you know which foundation image your CPU architecture needs, and exactly which commit you pinned, given that the newest release tag dates from 2017 while the default branch was pushed on 2026-11-02.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. QuantConnect/Lean on GitHub
4. README
5. Releases