How to Build an Automated EA Update System for MetaTrader in 5 Steps

by

Step 1: Set Up a Remote Version Manifest

Building a reliable automated EA update system for MetaTrader starts with a single source of truth — a remote version manifest. Rather than having your Expert Advisor attempt to fetch and compare full binary files on every startup, a lightweight manifest file lets the EA check a small text string before committing to a large binary download, saving bandwidth and processing power. That efficiency gain matters in live trading environments where network calls must be fast and non-blocking.

A JSON manifest is the recommended format because it is human-readable, easy to parse with MQL5 string functions, and simple to update remotely. A well-structured manifest typically contains three fields:

  • version — A semantic version string (e.g., "1.4.2") that the EA compares against its own compiled constant to determine whether an update is available.
  • url — The direct download path to the latest compiled .ex4 or .ex5 binary, which the EA will fetch only when a newer version is confirmed.
  • changelog — A brief human-readable summary of what changed, useful for logging and optional in-chart notifications to the trader.

Here is a sample manifest structure:

{
  "version": "1.4.2",
  "url": "https://your-host.com/releases/MyEA_v1.4.2.ex5",
  "changelog": "Fixed position sizing logic; improved risk management on partial fills."
}

Hosting the manifest on a high-availability static platform is essential. GitHub Pages and AWS S3 are both practical options — both support HTTPS (required by MetaTrader's WebRequest() function), offer low latency, and allow instant file updates without server management overhead. GitHub Pages tends to work better for individual MetaTrader developers who already maintain a code repository, while AWS S3 is often more effective for teams managing multiple EA releases.

With the manifest in place, the next step is writing the version check logic inside your EA — including how to configure MetaTrader's allowed URLs and handle the comparison correctly.

Step 2: Implement the Version Check Logic

With your remote manifest in place, the next task is writing the MQL code that fetches and compares version strings. This is where your MT4 and MT5 auto-update script comes to life — pulling the remote version number and deciding whether a download is warranted.

The core function to use is WebRequest(), which sends an HTTP GET request to your manifest URL and returns the response into a string buffer. You can call this inside OnInit() for a check at startup, or wrap it inside a timer callback using EventSetTimer() to poll periodically during a live session.

Important caveat: WebRequest() is synchronous, meaning it blocks execution until the server responds. If called during high volatility when the terminal is under load, it can cause the UI to hang momentarily. A timer-based approach, polling every few minutes rather than every tick, tends to work better for live environments.

Before any network call will succeed, you must whitelist your domain. Follow these steps to configure the terminal:

  1. Open MetaTrader 4 or MetaTrader 5 and navigate to Tools → Options → Expert Advisors.
  2. Check the box labeled Allow WebRequest for listed URLs.
  3. Click the + button and paste your manifest server domain exactly as it appears in your code.
  4. Click OK to save and restart the terminal if prompted.

Once the request succeeds, parse the response string to extract the remote version value. Then apply a straightforward comparison: if remote_version > current_version, the EA flags that an update is available and proceeds to the next stage. String-based semantic versioning (for example, "2.1.0") requires careful numeric parsing — splitting on the dot separator and comparing each segment as an integer avoids false positives from lexicographic ordering.

With the mismatch confirmed, your EA has everything it needs to trigger the file retrieval — which is exactly what the next step addresses.

Step 3: Download the New Executable

Once version check logic confirms a mismatch, the update pipeline moves into its most technically sensitive phase: fetching the new binary and writing it to disk. This step is where remote expert advisor deployment becomes a real operational concern, because MQL places strict boundaries on where and how file data can be written.

Follow this sequence precisely to handle binary data without corrupting the executable or triggering a sandbox violation.

  1. Gate the download behind a confirmed mismatch. Call your version comparison function first and exit early if versions match. Initiating a download on every tick or timer event wastes bandwidth and risks partial writes that corrupt the stored binary.
  2. Open an HTTP connection to your hosted .ex4 or .ex5 file using WebRequest(), passing the full URL of the versioned binary. Confirm the server returns HTTP 200 before reading any response data into your buffer array.
  3. Open the destination file using FILE_BIN | FILE_WRITE flags in FileOpen(). The FILE_BIN flag is mandatory — omitting it causes MQL to interpret the byte stream as text and silently corrupt the executable structure during the write operation.
  4. Write the full response buffer in a single FileWriteArray() call rather than looping through smaller chunks. Then call FileClose() immediately. Leaving the file handle open longer than necessary increases the window for incomplete writes if the terminal is interrupted.
  5. Target only the /Files subfolder inside the MetaTrader data directory. Because MQL cannot directly overwrite its own running executable in the /Experts folder due to Windows file locking, the /Files folder acts as the required staging area for all downloaded binaries.
  6. Verify file size after writing. Call FileSize() on the newly written file and compare it against a known byte count published in your remote manifest. A size mismatch signals a failed or truncated download — discard the file and log the error rather than proceeding with a corrupt binary.

At this point the new executable sits safely in the sandbox staging area, validated and ready to be moved into the active /Experts folder. But moving a file while the EA is still running presents its own problem — one that requires a smarter handoff mechanism. The next step introduces a bridge script pattern designed specifically to handle that transition cleanly.

Step 4: The Hot-Swap Script Bridge

With the new binary downloaded to a staging path, you face the core engineering obstacle: MetaTrader 4 and MetaTrader 5 both hold an active file lock on any compiled .ex4 or .ex5 file that is currently running. You cannot overwrite it directly from within the terminal. The solution is a bridge pattern — your EA generates an external script, exits or deactivates itself, and the script completes the file swap in a separate process.

This is where using a simple Windows Batch file or PowerShell script generated on-the-fly is the most reliable way to bypass file locks. The MQL5 code to download and replace ex5 files hands off responsibility to a lightweight shell process that operates entirely outside the terminal environment.

Here is how to implement the full bridge sequence:

  1. Generate the script content as a string. Inside your EA’s update function, construct a PowerShell or Batch command string that issues a Move-Item (PowerShell) or move /Y (Batch) instruction from the staging path to the live EA path. Include a short Start-Sleep 3 delay so the terminal has time to release the lock after the EA removes itself.
  2. Write the script to disk using FileOpen and FileWrite. Save the generated content to a known location such as MQL5/Files/update_bridge.ps1. This file is temporary and should be deleted by the script itself after the swap completes — add a Remove-Item call at the end of the script string before writing it.
  3. Call ShellExecuteW via shell32.dll. Declare the import at the top of your EA file, then invoke it with the "runas" or "open" verb, targeting powershell.exe with your script path as the parameter. Set the nShowCmd argument to SW_HIDE (integer 0) to prevent a console window from appearing on the trader’s screen.
  4. Remove the EA from the chart immediately after launching the script. Call ExpertRemove() or set the EA’s AutoTrading context to inactive. This releases the file lock before the bridge script’s delay expires, ensuring the move command does not encounter a permissions error.
  5. Confirm the swap path is correct. Verify that the destination path in the script matches the exact subfolder the terminal loads EAs from — typically MQL5/Experts/ for MetaTrader 5 or MQL4/Experts/ for MetaTrader 4. A path mismatch will silently place the updated file in the wrong directory.

Once the bridge script runs successfully, the updated binary sits in the correct EA folder with a fresh file timestamp. What happens next — how MetaTrader detects that change and reloads the EA — is handled by the re-initialization process covered in the following step.

Step 5: Automatic Re-initialization

With the hot-swap script executed and the new binary in place, the final step is confirming that MetaTrader actually loads the updated code and that you, the trader, receive confirmation it did so cleanly. This step closes the loop on your MQL4 MQL5 cloud update mechanism by combining platform-native reload behavior with a programmatic notification.

Triggering the reload relies on a straightforward MetaTrader behavior: when the file name of the compiled EA remains the same, MetaTrader will reload the updated code the next time the EA is initialized. In practice, removing the EA from the chart and reattaching it — or toggling AutoTrading off and on — is sufficient to trigger that initialization cycle without a full terminal restart.

  1. Toggle AutoTrading off, then on from the MT4 or MT5 toolbar immediately after the hot-swap script completes. This forces the EA to deinitialize and reinitialize, loading the replacement binary from disk.
  2. Log the build number inside OnInit() using Print() so the Experts tab records the version string of the newly loaded EA on every startup.
  3. Send a Push Notification via SendNotification() once OnInit() confirms the new build number matches the manifest target — this delivers an instant alert to your MetaTrader mobile app.
  4. Write a local log entry to a timestamped text file using FileWrite(), recording the update timestamp and version for your audit trail.
  5. Trigger a terminal restart when a clean-state initialization is required — for example, after structural changes to global variables — by calling the OS-level restart command from your external script before relaunching MT4 or MT5.
  6. Verify the reload by having OnInit() compare the running build against the manifest one final time and halt with a descriptive alert if a mismatch persists.

Three professional touches tend to separate robust update systems from fragile ones. First, gate all trading logic inside OnInit() behind a version-match check, so an incomplete swap cannot silently run stale code. Second, include a rollback flag in your manifest so the hot-swap script can restore the previous binary if the new OnInit() fails to confirm. Third, route all notifications through a dedicated MT4 or MT5 profile configured with your push-notification credentials, keeping update alerts separate from trade alerts.

Before the system goes live, one area deserves careful attention: transport security. Every binary your system downloads and every manifest it reads travels over a network connection, and that connection needs to be hardened against tampering — which is exactly what the next section covers.

How to Ensure Your Update System is Secure

Pulling all five steps together into a hardened, production-ready workflow means thinking about both reliability and security in the same breath. The procedure itself is straightforward, but skipping the security layer — particularly around WebRequest MT4 security and its MT5 equivalent — exposes your EA binary to interception. Follow this consolidated sequence every time you ship an update.

  1. Set up the manifest. Host a versioned JSON manifest on your server and always use HTTPS. Always use HTTPS for the manifest and file download to prevent Man-in-the-Middle (MITM) attacks — plain HTTP leaves your version metadata and binary vulnerable to tampering in transit.
  2. Enable WebRequest. Whitelist your HTTPS endpoint in MetaTrader’s allowed URLs list so the EA can poll the manifest without triggering a security block. Restrict permissions to exactly the domains your update system requires.
  3. Download the binary. Fetch the new compiled file to a staging path inside the MQL4/Files or MQL5/Files sandbox, verifying a checksum immediately after download to confirm the file was not corrupted or substituted.
  4. Execute the hot-swap. Run the bridge script to release the file lock, move the staged binary into the Experts directory, and overwrite the previous version atomically.
  5. Verify reload. Confirm the EA reinitializes with the correct version string logged to the journal and that all open position state, risk management parameters, and trade management rules are restored without manual intervention.

Completing this cycle consistently delivers measurable value. In practice, professional traders running systematic and algorithmic trading strategies recover hours each week that were previously lost to manual redeployment, and they eliminate the execution gap that appears when an EA runs on outdated logic during a live session. The compounding effect across months of trading automation is significant.

The Bottom Line

  • Security is non-negotiable. HTTPS at every network call is the baseline; checksum verification is the second layer every serious EA development workflow must include.
  • Automation reduces human error. Removing manual file transfers from your update process eliminates the most common source of version mismatch in live trading environments.
  • The system scales. A single manifest-and-hot-swap architecture can serve one EA or an entire suite without architectural changes.
  • Custom implementation matters. If building and hardening this pipeline is beyond your current capacity, MQL UI Studio's custom MQL4 and MQL5 programming services can design and deliver a secure, trader-centric update system built around your specific trading workflow — reach out to discuss a solution tailored to your strategy.