Projects

A cloud-focused workflow (local development, cloud execution) with the CLI might look like this:

1. Open a terminal in one of your organization workspaces.
2. Run lean cloud pull to pull remotely changed files.
3. Start programming locally and run backtests in the cloud with lean cloud backtest "<projectName>" --open --push whenever there is something to backtest. The --open flag means that the backtest results are opened in the browser when done, while the --push flag means that local changes are pushed to the cloud before running the backtest.
4. Whenever you want to create a new project, run lean project-create "<projectName>" --push and lean cloud push --project "<projectName>" to create a new project containing some basic code and to push it to the cloud.
5. When you're finished for the moment, run lean cloud push to push all locally changed files to the cloud.

The advantage of this workflow is that you can use all the tools in your local development environment to write your code (i.e. autocomplete, auto-formatting, etc.) while using QuantConnect's computing infrastructure and data when running your code. This advantage means you don't need to have a powerful computer and you don't need to have your own data, since that's all provided by us. The downside to this workflow is that you need a constant internet connection because without an internet connection the CLI can't communicate with the cloud.

A locally-focused workflow (local development, local execution) with the CLI might look like this:

1. Open a terminal in one of your organization workspaces.
2. Run lean project-create "<projectName>" to create a new project with some basic code to get you started.
3. Work on your strategy in . / <projectName>.
4. Run lean research "<projectName>" to start a Jupyter Lab session to perform research.
5. Run lean backtest "<projectName>" to run a backtest whenever there's something to test. This command runs your strategy in a Docker container containing the same packages as the ones used on QuantConnect.com, but with your own data.
6. Whenever you want to debug a strategy in your local development environment, see Debugging.

With this workflow, you are not limited to the computing power that's available in QuantConnect's infrastructure, because everything runs locally. On the other hand, this also means you must have all your required data available locally. To download some of QuantConnect's data for local usage, see Downloading Data.

A mixed workflow (local development, local debugging, and cloud execution) with the CLI might look like this:

1. Open a terminal in one of your organization workspaces.
2. Run lean cloud pull to pull remotely changed files.
3. Start programming on your strategies.
4. Whenever you want to debug a strategy in your local development environment, see Debugging.
5. Whenever you want to backtest a strategy, run lean cloud backtest "<projectName>" --open --push to push local changes to the cloud, run a backtest in the cloud, and open the results in the browser once finished.
6. When you're finished for the moment, run lean cloud push to push all locally changed files in the organization workspace to the cloud.

The advantage of this workflow is that you can use your local development environment and its debugging tools when writing your algorithms while using QuantConnect's infrastructure and data in backtesting and live trading. Although this does require you to have a local copy of the data that your strategy needs, it doesn't require you to maintain your own infrastructure and data feeds in live trading. To download some of QuantConnect's data for local usage, see Downloading Data.