Testing, Backtesting and Deploying MT5 Expert Advisors on a VPS

A MetaTrader 5 Expert Advisor that only exists as a pretty Strategy Tester graph is a research artefact. Production is a versioned binary on a VPS, with the same broker as live, someone who can disable AutoTrading, and a trail of logs when the market does something rude on a Sunday open. This article is the path from tester to VPS that we use when clients hire us to treat EAs as software.

DayDecoder is in Ahmedabad; we work with founders and CTOs in the US, UK, Europe and Australia. We do not operate your account, and we do not promise a backtest will survive contact with spreads. For the build itself, start with building MT4/MT5 Expert Advisors in MQL5.

What the Strategy Tester is good for

Use it to catch: inverted stop and take profit, lots that ignore volume step, trading on the wrong session, looking-ahead on forming bars, and crashes in OnInit. Use every-tick modelling when the rule cares about intra-bar touches. Use 1-minute OHLC only if you can live with the error, and write that down.

Variable spreads and real ticks, when the broker or a tick vendor supplies them, are closer to life than a fixed 10-point spread from 2014. They are still not your Monday morning book. Commission and swap settings must match the account you will actually open. A tester graph with zero costs is fiction.

What optimisation usually does

The optimiser will happily find inputs that fit noise. More inputs make this worse. A professional sequence looks like:

1. Freeze the rule. If you change the idea every time the graph dips, you are not testing an EA; you are diary-writing.
2. A small, justified input set (session, risk percent, maybe one indicator period).
3. In-sample for development, out-of-sample for a single confirmation. If out-of-sample collapses, you learned something. You did not “need more passes”.
4. Walk-forward windows if you have enough history to do it without overlapping your test into your live hope.
5. A note of every pass you discarded and why, so you do not secretly keep the pretty one.

We will not publish a “minimum profit factor” or a recovery-factor target. Those numbers on the internet are marketing. Your risk committee, if you have one, sets constraints such as max drawdown you can operationally stand, not a slogan.

Visual mode and unit checks

Run visual mode on ugly days: news spikes, rollover, thin Asian session if you trade then. Click a deal and read the log line. If you cannot explain a fill from the log, you cannot support the EA.

Where logic is pure (session filter, lot rounding), test it with fixed fixtures. MQL is awkward for this; some teams extract those functions to a small C++ or Python twin. The twin is not the EA. It is a guard rail. Keep them in the same git repo.

Demo is a different product than the tester

Open a demo with the same broker, leverage, and symbol suffix you intend to use. Run for enough time to see a rollover, a weekend, and at least one disconnect. Compare:

• Spread at your entry hours versus tester assumptions.
• Rejects and requotes.
• Whether hedging vs netting matches the code path you wrote.
• Swap on positions held overnight, if you hold.

Demo liquidity is still not live. It is a dress rehearsal for operations: VPS, restarts, and whether anyone actually looks at the logs.

VPS: pick for operations, then latency

For many EAs, “the VPS stayed up and the terminal stayed logged in” beats “the VPS is 0.4 ms from the matcher”. High-frequency ambitions are a different design, often the wrong one on MetaTrader retail infrastructure.

Windows is the path of least pain for MT5. Linux with Wine exists; we only recommend it if your team can support it. Cloud VMs (a small instance in cloud and DevOps terms) work if you treat RDP hardening as part of the job.

Do not run the live EA on a founder’s laptop, a shared office PC, or a VPS that also mines or hosts random Docker toys. No Python research notebooks on the live box; see the Python bridge article if you need a second process, isolated.

Deploy checklist

• Git tag, compiled .ex5 checksum recorded.
• Inputs exported and stored with the tag (the set file).
• Magic numbers unique; documented in your runbook.
• Journal and expert logs redirected or rotated so a week of ticks does not fill the disk.
• Who gets the VPS alert if the box dies. A phone, not a hope.
• How to flatten: click-by-click, including “AutoTrading off” and whether a Python brain must be stopped too.
• Broker support hours vs your overlap with India / US / UK / AU. Sunday gaps happen when people are asleep somewhere.

Going live without a ceremony

If you go live at all, start with a size that tests operations, not income. Watch rejects. Compare a sample of live deals to what the spec said. If they disagree, turn it off. Increasing lots because a week was pleasant is how people meet leverage.

Keep a paper or demo twin on the same VPS build if you can afford the mess; it is a canary for “we deployed the wrong binary”. Version drift between office and VPS is a classic defect.

Aftercare

EAs rot when brokers change symbols, contract sizes, or server names. Build a quarterly review: still the same suffix? Still the same min lot? Terminal still supported? That is maintenance, billable, honest. A “set and forget income bot” is a slogan, not a support contract.

We have 10+ years of shipping and maintaining software for 103 customers. Trading stacks need the same hygiene as any production app: backups, access control, and a human. Email contact@daydecoder.com if you want a runbook and a VPS build, not a miracle file from a forum.

Data quality: the tester is only as honest as the ticks

If your history is a short downloaded fragment with holes, the tester will invent a calm market. Download from the broker you will use, or from a vendor you can name, and look at the tick volume. A session with zero ticks in the middle of London is a hole, not a holiday. Document the from/to dates of every report. When someone later says “it worked in 2024”, you need to know which 2024 file they meant.

Modelling quality percentages in MT5 are a hint, not a certificate. If quality is poor, say so in the report rather than turning up the font size on the equity curve. We would rather ship a dull report than a glossy one that omits the quality line.

Journal, experts folder and disks that fill up

Live terminals write logs. Tick data, screenshots you enabled by mistake, and “verbose debug” left on after a session will fill a small VPS. Then the terminal fails in a way that looks like a strategy problem. Rotate logs. Keep a week. Ship copies off-box if you need history. Put the disk alert next to the “is AutoTrading on” alert. They are equally production.

The Experts and Files folders are part of the deploy. A DLL you copied once by hand will not be on the next VPS. If the EA needs files (calendars, pause flags), the runbook says where they live and who may write them. Permissions on that folder are part of security: a shared RDP user who can overwrite your pause file is a second trader you did not hire.

Broker builds, server names and the silent migrate

Brokers rename trade servers, change suffixes, and push terminal updates. An EA that hard-codes a server string or a symbol without suffix logic will one day sit flat and look “safe” while the book is on EURUSD.r. After any terminal update, run the smoke: init, a demo order if policy allows, log line with version. If AutoTrading turned off because of an update prompt nobody clicked, that is an ops failure, not an act of markets.

Keep the installer of the exact terminal build you certified, or a note of the version. Blind “update” on a live VPS is not hygiene. It is unscheduled change.

People: nights, weekends and who is on call

Someone reachable during your trading window, with access, who knows the flatten path without calling the agency’s founder at a wedding. Write the overlap with India, UK, US, Australia explicitly. If nobody can be reached from Friday close to Sunday open, the spec should say the EA must not hold through, or you accept the gap risk in writing. Silence is also a decision.

A go-live rehearsal

On demo, the week before any live money: restart the VPS, restart the terminal, disable and enable AutoTrading, fill the disk 90% then rotate logs, change nothing about the EA binary, and confirm the log still prints the git tag. If any step surprises you, you were not ready. Live should be the same rehearsal with smaller size, not a new personality for the software.

Write down the broker’s dealing desk hours and your own. If you cannot flatten during their outage, the spec should already have said “no holds over that window” or you explicitly accept the risk. Surprises here are not “the market”. They are calendar. After the rehearsal, keep the notes with the git tag so the next person is not improvising from memory.

FAQ

Which tester modelling mode should we use?

Every tick if stops and intra-bar logic matter. Faster modes are for smoke tests. If someone only shows you “open prices only” equity curves, ask what they hid.

Is a broker’s “free VPS” fine?

Sometimes. Read the uptime, whether you can snapshot, and who else has access. Free often means you cannot treat it as yours. We prefer a VPS you control, with your passwords, when the account matters.

Can you guarantee the live results will match the backtest?

No. Anyone who does is selling fiction. We can work to make the code faithful and the operations boring. Markets and brokers do the rest.

How often should we re-optimise?

On a schedule that is in the spec, with out-of-sample rules, or not at all. Re-fitting after every losing week is a process for producing overfit EAs.

Do you host the VPS and the account?

We can set up infrastructure you own. We do not want custody of client trading accounts. You (or your licensed firm) hold the relationship with the broker.