"How many terminals can I run?" is the wrong question. The right one is: which resource runs out first — RAM or CPU — and how much headroom you leave for the days everything happens at once. Get the binding constraint wrong and you don't crash cleanly; you get a terminal that quietly skips ticks while still looking green.
The two limits
Every MetaTrader terminal you add consumes two things, and they run out at different rates:
- RAM — a modern MT4/MT5 terminal with a couple of charts and one EA sits around 250–450 MB idle. Heavy indicators, many symbols in Market Watch, deep history and multiple charts push a single terminal well past 700 MB.
- CPU — mostly quiet, but it spikes on every new tick, on optimizations and backtests, and when several terminals recalculate on the same candle close. A tick-heavy symbol like a volatile index during the London open costs far more CPU than a sleepy cross at 3am.
Your real capacity is the lower of the two ceilings, not the average. A box with plenty of RAM can still choke on CPU when every terminal recalculates at the same instant, and vice versa.
A worked example
Take a common trading VPS: 4 vCPU, 8 GB RAM. Reserve 20% for the OS and antivirus, leaving 6.4 GB and roughly 3.2 usable cores. Assume each terminal averages 350 MB and 0.15 of a core when idle-trading:
max by RAM = 6.4 GB ÷ 0.35 GB ≈ 18 terminals · max by CPU = 3.2 ÷ 0.15 ≈ 21 terminals
RAM binds first, so the honest ceiling is about 18 terminals — not 21, and certainly not the 23 you'd get if you ignored headroom entirely. Now change one input: load a heavy multi-symbol EA that pulls 600 MB per terminal. RAM capacity collapses to roughly 10 terminals while CPU barely moves. Same box, nearly half the count, because the binding resource shifted. This is why a single per-terminal figure lies — you have to measure both under your real EAs.
Where people go wrong
Running dozens of EAs across MT4 and MT5 exposes the same recurring mistakes:
- Sizing for the calm average. The box that hums along at 40% for six hours can hit 100% in the ninety seconds after a major news release, when every EA reacts to the same tick.
- Forgetting the terminal is not the only process. The OS, Windows Update, antivirus scans and your remote-desktop session all take RAM and CPU. Budget for them or they will surprise you.
- Counting idle cost only. Trade execution, chart redraws and history syncs are burstier than the idle number suggests. Measure a terminal while it is actually opening and managing positions, not while flat.
- Running optimizations on the live box. A single strategy-tester optimization will saturate every core it is allowed and starve your live terminals of ticks. Keep testing on a separate machine.
- Too many thin terminals. Ten logins with one chart each carry ten copies of the terminal's fixed overhead. Consolidating EAs onto fewer terminals with more charts is often lighter — provided each EA keeps a unique magic number so they don't manage each other's trades.
Leave headroom on purpose
Running a VPS at 95% "because it fits" is how you get frozen terminals, missed ticks and an EA that silently stops trading without throwing a single error. Size for the worst simultaneous moment, not the calm average:
- Keep 15–20% of both RAM and CPU free as a permanent buffer.
- Stagger heavy tasks — history downloads, restarts, updates — outside your active session hours.
- Watch the swap file. Once Windows starts paging RAM to disk, latency on every terminal climbs and you have already lost.
- Re-measure after any EA change. New logic, more symbols or a bigger history window all move the numbers.
Use the estimator
The VPS Capacity Estimator does exactly this arithmetic. Enter your CPU cores, total RAM, your measured RAM per terminal and CPU load per terminal, and a safety-headroom percentage. It returns a recommended terminal count and — the part that matters — tells you whether RAM or CPU is the binding constraint, so you know whether the next upgrade should buy cores or memory rather than guessing.
Takeaway
Don't cram the box. Measure both resources under your real EAs, find the one that runs out first, leave real headroom for the simultaneous worst case, and re-check whenever your setup changes. The number of terminals that stay genuinely responsive is always fewer than the number that "technically fits" — and that gap is exactly where silent failures live.
