A VPS moves your trading terminal away from your home computer’s power and internet connection. It can improve operational continuity, but reliable EA operation still depends on the operating system, MT4, the broker connection and the EA itself. It does not make a strategy profitable.
This is the foundation of the VPS & MT4 Stability series. Continue with MT4 configuration and resource optimization, then failures, backups and safe recovery. For ongoing supervision between incidents, continue with Guide 4: EA monitoring, quotes and alerts.
What a VPS does for MT4
A virtual private server (VPS) is a virtual machine hosted on a provider’s physical infrastructure. A Windows VPS has its own operating-system environment and allocated CPU, memory and storage. You connect remotely to install and manage MT4; the terminal runs there rather than on your laptop.
The physical host and some resources may be shared with other customers. A dedicated server reserves physical hardware; a cloud server describes how infrastructure is provisioned and managed and may also be a virtual machine. These labels overlap. None, by itself, proves that MT4 will remain available or that an EA will trade correctly.
A home computer can run an EA continuously if its power, network, operating system and terminal remain available. A VPS reduces dependence on your home setup and can offer a suitable route to the broker, but introduces a provider, remote-access arrangements and maintenance responsibilities.
“24/7 hosting” refers to the environment’s availability. Forex symbols have trading sessions, weekends and broker maintenance periods. An EA may correctly remain idle when the market is closed or its rules produce no signal.
How quotes become a trade request
- The broker’s trading server sends quotes through the network to MT4 on the VPS.
- MT4 supplies data and events to the EA. The EA evaluates its programmed rules and risk checks.
- If permitted, the EA sends a trading request through MT4 and the network to the broker.
- The broker processes the request and returns a result. The EA must interpret that result and manage any orders it owns.
This is a two-way flow, not a one-way chain that ends at the EA. The VPS hosts the operating system, MT4 and the EA; it is not an additional broker or execution venue. A break in data, permissions or program operation can interrupt the process even while the VPS is reachable.
Home computer, Windows VPS or MetaTrader hosting?
| Environment | Practical role | Main responsibility or limit |
|---|---|---|
| Home computer | Local setup, testing and operation when continuously available | You manage electricity, internet, sleep, updates and MT4. |
| Windows VPS | Full remote desktop with MT4 and compatible vendor utilities | You manage Windows, security, startup, EA files and terminal state; confirm DLL and license requirements. |
| MetaTrader virtual hosting | A hosted terminal environment migrated from local MT4 | No remote desktop; DLL calls are prohibited and scripts are not migrated. Changes need deliberate synchronization. |
| Dedicated or cloud infrastructure | Another way to provide computing capacity for the same workload | Check the actual OS, allocation, management and availability design. A cloud label is not automatic failover for an EA. |
Choose by the EA’s dependencies and your ability to operate the environment. Integrated hosting and a Windows VPS have different workflows; instructions for one should not be applied blindly to the other.
Why MT4 or an EA can stop working
| Interruption | Effect | First check |
|---|---|---|
| Home power or internet failure | A locally running terminal loses operation or its broker connection. A healthy remote environment can continue independently. | Where is the intended trading copy actually running? |
| Sleep, hibernation or Windows restart | Local applications stop running during the interruption; a reboot does not prove MT4 has reopened correctly. | OS state, restart history and the tested startup procedure. |
| MT4 closed, frozen or EA removed | The affected trading logic cannot operate normally. | Terminal responsiveness, intended charts and EA initialization messages. |
| AutoTrading or EA trading permission disabled | On ordinary MT4, analysis may continue while EA trade operations are blocked. | Both terminal and EA permissions; also settings that disable trading after account, profile, symbol or timeframe changes. |
| Wrong account, server or read-only login | Quotes or account information may be visible without the intended trading access. | Account number, broker server, trading password and Journal messages. |
| Broker connection, licensing or dependency failure | MT4 may lose data or the EA may fail even though Windows is available. | Connection state, symbol quotes, Experts, Journal and the vendor’s documented dependencies. |
Use the MT4 EA errors guide to interpret specific messages. Do not change lot size or remove protective filters merely to force a test trade.
What a VPS can and cannot protect
A functioning remote environment can keep the EA available when your home computer is off. Suitable infrastructure may reduce local outages and network delay. It cannot remove market risk, fix an invalid strategy, guarantee a fill, eliminate slippage or keep a broker’s server available.
Orders and protective levels already accepted by the broker are separate from logic still running inside MT4. Server-side Stop Loss and Take Profit can remain active when your terminal is offline. The built-in MT4 Trailing Stop needs the terminal to run; its last accepted Stop Loss remains at the broker. Virtual stops and EA-managed exits require the relevant EA, data and trading access.
Check the actual open and pending orders. An intended stop in an EA’s settings is not proof that a server-side Stop Loss was placed. Stopping the EA does not automatically close positions or cancel pending orders. A Stop Loss is also not a guarantee of its execution price.
Latency, ping and VPS location
Ping is a measure of network round-trip delay to the tested endpoint. MetaTrader hosting displays a ping between its virtual server and your broker’s trading server. The responsiveness of Remote Desktop reflects another route: your computer to the VPS. A generic website speed test does not measure the EA’s broker route.
Geographical proximity can help, but routing, congestion and the chosen broker endpoint also matter. Compare measurements from the intended VPS to the intended trading server during relevant trading hours. Repeated measurements and connection interruptions are more informative than the lowest single reading.
Illustrative example, not a benchmark: a route measured at 35 ms instead of 8 ms has a higher measured network delay. The difference is not a promised 27 ms improvement in order execution: EA processing, terminal scheduling, broker processing and changing prices also affect the result. Lower ping does not establish a strategy’s statistical edge.
For requested versus filled prices, use the separate slippage, latency and requotes guide.
Basic requirements: size the actual workload
There is no universal VPS specification for every EA. A small single-chart workload differs from several terminals with heavy custom indicators. Start with the vendor’s compatibility requirements, then observe your intended workload with capacity left for peaks, updates and log growth.
| Requirement | What to establish before deployment |
|---|---|
| CPU and memory | Normal and peak usage with the intended terminals, charts and EAs. Shared vCPU counts alone do not describe sustained performance. |
| Storage | Space for Windows, MT4, history, logs and updates. Fast storage does not compensate for a full disk. |
| Operating system and dependencies | A supported, appropriately licensed Windows environment for the chosen setup; compatibility with the EA, libraries and vendor activation rules. |
| Network | A usable, stable connection to the correct broker server, not just to a public test website. |
| Operations | Secure access, provider support, maintenance terms, a tested restart procedure and access to your configuration if the VPS is unavailable. |
For Windows VPS workloads, use Task Manager to inspect resource pressure; integrated hosting has its own resource monitoring. Avoid running heavy optimization alongside a live trading workload without assessing the impact. Detailed resource tuning belongs to Guide 2.
Prepare the EA before moving it
- Verify the EA’s intended behavior on demo, including how it resumes after a restart. A successful installation is not proof of profitability.
- Record the intended broker account and server, exact symbol, timeframe, EA version and dependency files.
- Save the approved Inputs as a
.setfile where the EA supports this, and verify risk settings in the deployed copy. - Confirm the documented Magic Number and order-management scope, especially if positions already exist.
- Check DLL, WebRequest and licensing requirements. Allow only trusted dependencies and required URLs.
- Know how to pause the actual trading copy and how existing orders will be managed during a pause.
Use the EA installation guide for the precise file workflow. Backup design and recovery drills belong to Guide 3.
Deploy on a Windows VPS
- Connect securely. Obtain the provider’s connection details and use a trusted remote-access client. Confirm you are on the intended VPS.
- Install the intended MT4. Use the broker’s official installer and connect to the correct broker server with trading access. An investor password provides read-only access.
- Install the EA and dependencies. In MT4, use
File → Open Data Folder; place files in their documented folders, then refresh or restart as required. - Attach and configure. Use the intended symbol and timeframe, load and verify Inputs, and check both MT4’s
AutoTradingand the EA’s trading permission. Enable DLL or WebRequest access only when required and trusted. - Verify operation. Check initialization, incoming quotes, logs and intended order ownership. Keep the other trading copy paused unless the design explicitly supports concurrent instances.
- Test unattended operation on demo. Disconnect remote access, reconnect and inspect MT4. Test a controlled OS restart separately and verify the account, charts, Inputs, permissions and EA state afterward.
Disconnecting Remote Desktop normally leaves the Windows session and applications running. Signing out ends that session; provider session-timeout policies can also end a disconnected session. Check the actual policy and test it. A Startup-folder shortcut runs after user sign-in; it does not, by itself, prove unattended recovery after a reboot.
Keep Windows security updates, arrange maintenance and repeat the checks afterward. Do not assume a provider’s “automatic restart” restores a working EA environment.
Deploy with MetaTrader virtual hosting
Connect local MT4 to the intended trading account. In Navigator, use Register a Virtual Server for that account with a valid MQL5.community account. Review the location, subscription and service terms before migration. Renting hosting alone does not deploy the EA.
Prepare the local account, required charts with the intended EAs attached, EA Inputs and dependencies. Choose the migration mode for your use: Experts for EAs and indicators; All if the intended environment also includes signal copying. Inspect the remote logs afterward.
Migration is one-way: local to hosted terminal, not continuous two-way synchronization. Repeat it after relevant configuration changes. DLL calls are forbidden; scripts and non-standard symbol/timeframe charts are not migrated.
Automated trading is always allowed in the hosted terminal, even if local permissions were off. Migration disables local AutoTrading to reduce duplication. The local toolbar button does not stop the hosted EA. Use Stop Server in the hosting controls and verify the remote status before activating a replacement.
The hosted environment has no Remote Desktop. Check its last synchronization, operating status and requested terminal/EA logs rather than the local chart alone. A migration message proves a transfer was attempted; confirm the deployed environment actually initialized as intended.
Keep one intended trading instance
Two terminals connected to the same account can both send trade requests. A Magic Number identifies orders for EA logic; it is not a server-side lock between terminals. Assigning different numbers does not fix accidentally running the same strategy twice.
Before a handover, save the configuration, reconcile open and pending orders, stop the old trading copy, then start and verify the intended copy. Preserve the EA’s documented ownership identifiers when it must resume management of existing positions. See the Magic Number guide.
If a VPS is unreachable, failure to connect by Remote Desktop does not prove that MT4 has stopped. Confirm its operating state through the provider or hosting controls before enabling a replacement. A separate local terminal can be used for read-only observation; do not accidentally enable trading in it.
Monitor four layers, not just VPS uptime
| Layer | Evidence to check |
|---|---|
| VPS / operating system | Availability, unexpected restarts, CPU and memory pressure, free storage and remote-session policy. |
| MT4 / account | A responsive terminal, intended account and server, connection state and trading permissions. |
| Market data | Updates for the required symbol, last quote time and the relevant trading session. Closed markets and illiquid periods need context. |
| EA / order management | Expected version and Inputs, available status or heartbeat, initialization and errors, plus ownership and management of actual orders. |
For technical monitoring, IsConnected() reports the terminal’s server connection; it does not prove fresh quotes or healthy EA logic. MODE_TIME represents the last incoming tick time for a symbol. Quote-age comparisons need consistent clock/time-zone handling and market-session awareness. There is no universal stale-quote timeout for every symbol.
Check Experts and Journal after deployment, changes, restarts and broker maintenance. Use the logs guide for timestamps and error context. Choose a review frequency that matches how quickly an unmanaged position could matter, rather than relying on occasional login.
Test notifications end to end. An alert sent by the same MT4 cannot reliably announce that MT4 has completely stopped. Independent monitoring or a missing-heartbeat check can cover that gap. Standard trade notifications are not a complete rejected-order or outage monitor, and a quiet EA may simply have no trading signal.
Maintenance and a final readiness check
Use unique credentials, restrict remote access through the provider’s available controls, keep software maintained and store account details securely. Do not put passwords in support tickets or public logs. Record changes and recheck the environment after updates.
This checklist confirms operational preparation, not future trading results. Further demo observation is needed after deployment; do not infer strategy quality from a successful restart.
Common VPS and MT4 questions
Can I close my laptop after deployment?
Yes, if the intended EA is actually running in the verified remote environment. Closing a laptop that still hosts the EA can stop its operation. On a Windows VPS, distinguish disconnecting Remote Desktop from signing out.
Does switching off AutoTrading locally stop integrated hosting?
No. Stop the hosted terminal through its hosting controls and confirm its status. Check existing orders separately.
Does no trade mean the EA has failed?
No. Check market sessions, data, permissions, initialization and the strategy’s signal rules. Do not force trades to demonstrate that the VPS works.
Is a dedicated or cloud server automatically safer?
No. Its value depends on the actual availability design, workload, maintenance and tested terminal recovery. Changing a hosting label does not remove the checks in this guide.
Official references and scope
Platform behavior was checked against official documentation. Workload sizing, deployment checks and monitoring choices here are practical guidance; they are not a provider benchmark or measured EA result.