FeaturesCopierAnalyticsWebhooksPricingPartnershipBlog
Sign inGet started

EA trade copier vs cloud trade copier: which to run

8 min readMetaKit

A follower account sat with an open XAUUSD position for six hours after the master had closed it, because the follower's terminal had lost connection at 02:10 and the slave EA on that chart had no way to say so. The master was up $40. The follower was down $600. Nobody noticed until the morning.

That's not a bug in a particular product. It's a property of one of the two ways a trade copier can be built. If you're choosing the best MT5 trade copier for your setup, the architecture decides more than the brand does, so this is about the two architectures, not vendors.

Architecture one: the EA copier

An EA copier is two Expert Advisors. A master EA sits on a chart in the master account's terminal and watches for position changes. A slave (or receiver) EA sits on a chart in the follower's terminal and places matching orders. Between them is a transport: shared memory or a file on the same machine, or a socket if the terminals are on different boxes.

It's a popular design for good reasons:

  • Free or cheap. Plenty of one-time-purchase and open-source copiers exist. No monthly fee.
  • Local latency is excellent. Master and slave on one VPS in the broker's data centre, talking over a local pipe, can go from master fill to follower order in well under 100 milliseconds. No cloud copier beats that on the same hardware, and this post won't pretend otherwise.
  • You hold the credentials. Both terminals are yours. No third party ever sees a password.
  • It runs your custom logic. Because it's MQL5 on a chart, you can modify it. Want to skip copies during a news window you compute yourself? Edit the EA.

And the structural costs:

  • Both terminals must be running. The master's and the follower's. If either is closed, logged out, disconnected, or has AutoTrading off, copying stops. Silently, unless you built something to notice.
  • Copy dies with the terminal. A Windows Update reboot, a crash, a modal dialog: the EA is unloaded and the link is gone until the chart is reattached. The VPS post walks through how much of your time this eats.
  • Cross-VPS adds hops. The local-latency advantage evaporates the moment the follower runs on a different machine, because now you have a socket over the public internet, a firewall rule, and a reconnect routine.
  • Configuration lives in EA inputs. Lot mode, multiplier, symbol suffix, slippage tolerance: all set in the EA's properties dialog, per chart, per terminal. Changing a setting across ten followers is ten RDP sessions. There is no API, so nothing else in your stack can read or change it.

Architecture two: the cloud copier

A cloud (hosted) copier runs both accounts in terminals the vendor operates. The master's terminal emits events when positions change; the copier engine sizes, maps, and dispatches; the follower's terminal executes. You interact with it through a dashboard or an API, never through a chart.

This is how MetaKit's copier works: each account is its own isolated hosted terminal, a watcher inside the master's terminal detects changes, and a copier links a source_account_id to a follower_account_id.

What it buys:

  • Nothing on your side to keep alive. No VPS, no terminal, no watchdog. The vendor's job is making sure the terminal is logged in.
  • Terminal health is visible. The account has a status. When it drops, you get an account.error webhook. When it recovers, account.connected.
  • Copy outcomes are recorded. Every copy, skip, and orphan is an event with a reason. copier.trade_copied carries latency broken into detection, dispatch, and execution milliseconds. copier.trade_skipped and copier.orphan tell you what didn't happen and why.
  • API-configurable. Lot mode, filters, symbol map, slippage guard, and state are fields on a resource. Changing a setting across ten followers is a loop.

What it costs:

  • A third party holds credentials. The follower needs the master (trader) password to place trades. Read-only accounts, connected with the investor password, can be masters but not followers. Passwords are write-only on our side and never returned, but they are held.
  • A monthly fee. At MetaKit, $10 per full account (the copier itself is included, no extra charge); a read-only master is $5.
  • Network latency. Events cross a network between terminals and engine. It's small, but it's not a local pipe.
  • No custom MQL5 on the chart. The copier's logic is the copier's logic. If you need bespoke rules, an EA is more flexible.

The failure modes that differ

This is the section to read if you skip the rest. The question for each failure is not "does it happen" (it happens to both) but "who notices, and how fast".

The follower's terminal crashes or reboots. EA copier: the slave EA is gone. The master keeps trading. Positions opened after the crash are never copied, and positions the master closes stay open on the follower. Nobody is told. Cloud copier: the follower's status flips to error, a webhook fires, the copier logs copier.error for anything it couldn't execute, and when the terminal comes back the next master action is copied. Positions that closed on the master while the follower was down still need attention, which is why an account.error webhook should page someone.

Windows Update. EA copier: the VPS reboots, the terminal may or may not auto-start, the EA may or may not reattach, AutoTrading may or may not be enabled. Four coin flips at 03:40. Cloud copier: not your machine.

Symbol mismatch. The master trades XAUUSD, the follower's broker calls it GOLD or XAUUSD.r. EA copier: depends on the EA; the good ones have a suffix or mapping input, the bad ones just fail the order and log to the Experts tab of a terminal nobody's watching. Cloud copier: the copy is skipped with a copier.trade_skipped event naming the reason, and the fix is a PUT /v1/copiers/{id}/symbol-map with the mapping. Both architectures need the map; only one tells you it's missing.

Disconnected follower, connected terminal. The sneaky one. The terminal is open but the broker connection dropped. EA copier: the slave EA's OrderSend returns an error, retries, gives up. If it logs, it logs locally. Cloud copier: this is exactly what status: error and the account.error webhook exist for, and equity monitors skip evaluation while the account isn't connected so you don't get false alarms on top.

The pattern: an EA copier fails locally and quietly. A cloud copier fails with a status and an event. Neither prevents the failure. One of them tells you.

Latency, honestly

An EA copier with both terminals on one machine can be faster than any cloud copier. Local shared memory has no network in it, and if you're copying a scalping strategy on a VPS colocated with your broker, that matters and you should keep it.

MetaKit's number is that follower fills land consistently under a second after the master fill, and every successful copier.trade_copied event reports its own latency.total so you can check that claim against your own accounts rather than take it on faith. For swing and intraday strategies, sub-second is indistinguishable from instant. For a strategy that lives or dies on 50 milliseconds, it isn't, and the local EA wins.

There's a subtlety in the other direction. An EA copier across two VPSs (a common setup when master and follower are with different brokers) pays a public-internet hop plus whatever the socket bridge adds, and it no longer has a latency advantage. Cross-machine EA setups are often slower than a cloud copier, with worse failure reporting on top.

Who should stay on an EA copier

Not everyone should move, and it would be dishonest to write this as if they should.

Stay on an EA copier if:

  • You need sub-100ms copy latency and can put both terminals on one box.
  • Your rules are custom enough that you're editing MQL5 anyway.
  • You will not hand a trader password to a third party. Full stop.
  • You have one master and one or two followers, on one machine you already maintain, and it's been fine.
  • The monthly fee is the deciding factor and your time is free.

Consider a cloud copier if:

  • Master and follower are on different brokers or different machines.
  • You have more followers than you can check by hand, or followers that belong to other people.
  • You want to know, within seconds, when a follower stops copying.
  • Copier settings need to be changed by code, or by a dashboard you build.
  • You've already been burned by the six-hour orphan.

Setting one up over the API

If the second list describes you, a copier at MetaKit is one request after both accounts are connected:

curl -X POST https://api.metakit.cloud/v1/copiers \
  -H "Authorization: Bearer $METAKIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "source_account_id": 3,
        "follower_account_id": 5,
        "lot_mode": "multiplier",
        "lot_value": 0.5,
        "filters": { "max_lot": 2 },
        "symbol_map": { "XAUUSD": "XAUUSD.r" }
      }'

lot_mode is fixed, multiplier, or proportional (balance-ratio sizing). A copy that fills further from the master's price than the slippage tolerance you set in the dashboard is closed again. Set the copier's state to monitor to stop opening new copies while still closing existing ones with the master, and note that deleting a copier leaves already-copied positions open, on purpose. The copier setup walkthrough covers the rest, including webhooks for the events above, and llms.txt has every field.

Whichever you pick, add one thing today: something that tells you when the follower stops copying. On an EA that's an alert you build. On a cloud copier it's a webhook you subscribe to. The six-hour orphan doesn't care which architecture you chose; it only cares whether anyone was watching.

← All posts