How Many MT5 Terminals Can Run on a VPS?

Why the number varies

MetaQuotes describes the mechanism in the platform's settings documentation. When "multiple indicators and large amount of data to be displayed are used simultaneously", the documentation warns, "computer free resources (CPU load and free RAM) can exhaust very soon".

That statement is about data and computation, not about the number of windows. Both the terminal process and the work inside it consume resources. The workload is the part that varies most between setups, which is why a terminal count on its own is not enough to size a machine.

What consumes the machine

A chart is a data window: it holds price data in memory and redraws when ticks arrive. Adding charts adds cost. Whether the same number of charts costs more when spread across several terminals than when concentrated in one is not something MetaQuotes documents, and it is measurable on your own machine — see the method below.

Indicators. Cost depends on what an indicator computes and how often. A moving average over a short window is arithmetic on a small amount of data. An indicator that recalculates across a long history on every tick does substantially more work. The difference between two charts is not visible in the interface, which is why measurement matters more than counting.

History depth. The platform exposes a Max. bars in chart setting, which the platform settings documentation describes as controlling "the amount of data displayed on the charts", with a minimum of 5,000 bars, and notes that "the amount of bars shown in the chart is limited by the computer resources".

The setting bounds what is displayed rather than everything held. The same page states that "indicators can access more bars than specified in 'Max bars in chart' parameter for more efficient calculation", and that "older bars are not removed immediately from the data cache when the new ones appear". Raising the value can increase resource use; it does not map one-to-one onto data held per chart. Changing it requires a platform restart to take effect.

Symbols and tick rate. How often the tick-driven components run depends on how often ticks arrive, which varies by instrument and by time of day. Your own instruments during your own sessions are the only relevant sample; a generalisation about which hours are busy will not hold across instruments, brokers and asset classes.

Expert advisor behaviour. This is the widest variable. Total cost depends on both how often code runs and how much work each invocation does, so a once-per-bar routine is not automatically cheaper than a per-tick one. Cost follows what the code does, not what category the strategy belongs to. The interface does not report it, so it has to be measured.

Memory, and what disconnecting hides

Each terminal is a separate process with its own memory. The platform start documentation states that "two copies of the platform cannot run from the same directory", and that running several means installing "the appropriate number of programs in different directories".

There is a second effect that can make a machine look healthier than it is. Microsoft's Terminal Server walkthrough notes that when a session is disconnected, "the processes and all virtual memory space will remain and be paged off to the physical disk, if physical memory is required for other processes".

So free-RAM readings taken while you are disconnected can understate what the workload needs. Reading the commit charge alongside free memory gives a fuller picture. Microsoft describes the system commit charge as "the total committed or 'promised' memory of all committed virtual memory in the system", measurable on the Task Manager Performance tab or through the \Memory\Committed Bytes counter, in its introduction to page files.

Memory and CPU

Both can become the binding constraint, and the mapping is not clean. Charts, indicators, history and expert advisors can each pressure memory and CPU in different proportions, and history handling adds storage activity as well. Optimisation and tick-level backtests are demanding, but which resource they strain depends on the run: on the data volume held, on how much is computed, and on how much is read from and written to disk. There is no general rule about which limit arrives first, and assuming one sends you looking in the wrong place.

The distinction worth watching is between sustained load and short spikes. Sustained high CPU points at sizing. For workloads whose indicators or EAs calculate at bar close, brief spikes at that moment are expected behaviour; a workload that recalculates continuously will not show that pattern. A spike matters when it is long enough that work queues behind it — which you can observe as chart redraws falling behind incoming ticks, and which an average will not show you.

As an illustration only, and not a measurement: a machine reporting a modest average with regular spikes near saturation at every bar close has less headroom than the average implies. Whether that describes your machine is a question for the readings, not for the example.

How to measure your own case

1. Take an idle baseline. Before starting anything, record free memory, free disk, commit charge and CPU on the bare machine.
2. Add one terminal and let it settle. Start a single terminal with your real chart set, indicators and EAs. Readings taken while history is still downloading are not representative.
3. Sample across representative periods. Record during a quiet period for your instruments and during the busiest period you normally run. You need both: the quiet sample establishes the baseline the busy one is measured against, and neither alone describes the machine.
4. Add the next terminal and repeat. Do not assume increments are linear in either direction. Measure each step rather than extrapolating from the first.
5. Leave headroom. Reserve capacity for Windows updates, your own Remote Desktop session, and periods when several workloads are busy at once. A machine sized exactly to its observed peak has no margin.

Task Manager and Resource Monitor are suited to manual spot checks. For readings repeated across hours or days, Performance Monitor or equivalent logging is the better tool, because it records counters over time rather than showing a moment. Microsoft's guidance on troubleshooting performance problems in Windows covers the counter-based approach.

Reading the early signals

Each row below is an observation. None of them identifies a cause on its own, and the third column is the next step rather than a conclusion.

The last two are the most frequently over-read. A sluggish remote session is consistent with either your own connection or a loaded server. Neither it nor a reconnect entry identifies broker-path latency, resource saturation, or any single cause on its own; each is a prompt to check the next thing. Why those are separate measurements is covered in what actually affects trading VPS latency.

Changes worth trying before adding capacity

• Lower Max. bars in chart to the shallowest history your indicators need, and restart the platform so the change takes effect.
• Close charts nothing reads.
• Consider moving optimisation and backtest runs off the machine that executes. That relocates the load rather than removing it, so it needs capacity somewhere, and neither workload is universally safe to interrupt.
• Disable news retrieval if nothing consumes it. The settings documentation notes that with the option disabled, "news will not be received in the platform".

Record what you measured

A capacity reading is only reusable if you can reconstruct what produced it. Alongside the numbers, note the chart count per terminal, which indicators were attached, the Max. bars in chart value in force, which EAs were running, and the period the sample covers.

Without that context, a figure from three months ago cannot be compared against one taken today. If consumption has risen, you cannot tell whether the workload grew, the history depth changed, or something unrelated to the platform is now running on the machine. With it, the comparison is straightforward and the next sizing decision starts from evidence rather than from memory.

The same record shortens a rebuild, because it describes the machine you are trying to recreate.

What this article does not tell you

It gives no terminal count per plan size and no memory figure per terminal. Publishing either would mean presenting a measurement of one workload as though it described yours.

The method above produces a number for your charts, your indicators, your history depth and your EAs. That number is the one worth having.

Current specifications are on the hosting plans for MetaTrader workloads and the full plan comparison. If nothing is installed yet, the installation and verification sequence comes first.