Live Trading

Live trading nodes enable you to deploy live algorithms to our professionally-managed, co-located servers. You need a live trading node for each algorithm that you deploy to our co-located servers. Several models of live trading nodes are available. More powerful live trading nodes allow you to run algorithms with larger universes and give you more time for machine learning training. Each security subscription requires about 5MB of RAM. The following table shows the specifications of the live trading node models:

Refer to the Pricing page to see the price of each live trading node model.

To view the status of all of your organization's nodes, see the Resources panel of the IDE. When you deploy an algorithm, it uses the best-performing resource by default, but you can select a specific resource to use.

The CPU nodes are available on a fair usage basis while the GPU nodes can be shared with a maximum of two members. Depending on the server load, you may use all of the GPU's processing power. GPU nodes perform best on repetitive and highly-parallel tasks like training machine learning models. It takes time to transfer the data to the GPU for computation, so if your algorithm doesn't train machine learning models, the extra time it takes to transfer the data can make it appear that GPU nodes run slower than CPU nodes.

You need a live trading node for each simultaneous algorithm that you deploy. We do not support sub algorithms or sharing a server with multiple algorithms. The tier of your organization determines the number of live trading nodes the organization can have. The following number of live trading nodes are available for each tier:

To deploy multiple algorithms using a single brokerage, create sub-accounts in your brokerage account so that each algorithm has its own set of brokerage connection credentials.

Members often use 8-32GB of RAM in backtesting and are concerned that their algorithms will not work in live trading since live trading nodes have 512MB to 4GB of RAM. Backtesting nodes have more RAM because data is injected into your algorithm roughly 100,000x faster during backtests than live trading. You use more RAM in backtesting because many data objects are cached to achieve such fast speed. In live trading, 512MB to 4GB of RAM is sufficient for almost all use cases.

Use the deployment wizard in the Algorithm Lab to deploy your algorithms to live trading. The deployment wizard lets you select a brokerage, enter your brokerage credentials, select a data provider, select a live trading node, set up notifications, and configure automatic algorithm restarts.

Most of the brokerages automatically load your cash holdings, position holdings, and submitted orders so that you can view your portfolio state on the live results page. For brokerages that don't automatically load your holdings, you can enter your cash and position holdings in the deployment wizard.

If you have unsupported assets in your brokerage account when you deploy, Lean can't calculate the portfolio value correctly, so margin calculations are wrong. To avoid issues, if your account has unsupported assets, Lean automatically exits on deployment. For a list of supported assets, see the asset class dataset listing.

Automatic restarts use best efforts to restart your algorithm if it fails due to a runtime error or an API disconnection. Automatic restarts reduce the risk of your algorithm missing a trade during periods of downtime. If you enable automatic restarts when you deploy your algorithm and your algorithm fails, your algorithm will try five times to restart. After five unsuccessful restarts, your algorithm won't attempt to restart again. To prevent restarts due to coding bugs, algorithms only automatically restart if they have been running for at least five minutes.

Your code is stored in a database, isolated from the internet. When the code leaves the database, it is compiled and obfuscated before being deployed to the cloud. If the cloud servers were compromised, this process makes it difficult to read your strategy.

As we've seen over recent years, there can never be any guarantee of security with online websites. However, we deploy all modern and common security procedures. We deploy nightly software updates to keep the server up to date with the latest security patches. We also use SSH key login to avoid reliance on passwords. Internally, we use processes to ensure only a handful of people have access to the database and we always restrict logins to never use root credentials.

See our Security and IP documentation for more information.

If you have multiple deployments, use a notebook in the Research Enviroment to programmatically deploy, stop or liquidate algorithms.