DEV Community: FxSocket

Your trading strategy is probably luck, and here is the math

0xdev — Wed, 21 Oct 2026 09:02:15 +0000

Here is a trading record. 238 closed trades over about four months. Win rate 54.6%. Profit factor 0.99. The equity curve climbs to +$455 by early May, gives it back over the next seven weeks, and claws most of it out again in July before ending where it started.

It looks like a strategy having an ordinary year. It is 238 draws from a distribution whose true mean I set to roughly zero before I generated it.

I built a free tool that reads MetaTrader statements and says that out loud, and this post is mostly about the statistics it runs rather than the tool. The numbers in it come from synthetic data I generated specifically so I would know the right answer in advance, which is the only way to test something like this honestly.

Disclosure: the tool is free and needs no account, and it sits on the site of a paid product I run. Links at the bottom. The math is the point.

Trading is unusually good at fooling you

Most fields where people look for an edge give you fast, cheap feedback. Trading gives you feedback that is slow, expensive, and dominated by noise. Three things combine badly.

The signal is tiny next to the variance. A decent retail strategy might make an average of $5 per trade with a standard deviation of $50 per trade. That ratio, not the size of the edge, decides how long it takes to see anything.

Cumulative sums of noise look like skill. This is the one that does the real damage. Add up fair coin flips, plot the running total, and you get something with trends, plateaus, drawdowns and recoveries. Over 500 flips the total typically wanders about 22 steps from zero in one direction or the other, because the spread of a random walk grows with the square root of its length. Every visual feature a trader reads as structure is produced in abundance by nothing at all.

An equity curve is exactly that cumulative sum. It is the most reached-for chart in trading and the most misleading, because it converts independent draws into a shape, and humans are extremely good at reading shapes and terrible at reading variance.

And then you only ever see the survivors. Take ten thousand people trading with no edge whatsoever. Their results centre on zero, so about sixteen hundred of them finish more than one standard deviation up. Those sixteen hundred have genuinely profitable records of real trades with real money. Some of them will conclude they have found something. Some of them will sell you a course about it. Nothing in their statement distinguishes them from the eight thousand four hundred others, because there is nothing to distinguish.

Statistics is not a nice-to-have on top of trading. It is the only thing standing between a trader and a convincing story.

How many trades you actually need

The quantity that matters is the standard error of the mean: the standard deviation of your per-trade results divided by the square root of how many you have.

const mean = results.reduce((a, b) => a + b, 0) / results.length;
const variance =
  results.reduce((a, b) => a + (b - mean) ** 2, 0) / (results.length - 1);
const sd = Math.sqrt(variance);
const standardError = sd / Math.sqrt(results.length);

Take the $5 average and $50 standard deviation from earlier and watch what the sample size does:

Trades	Standard error	Mean in standard errors	Roughly
100	$5.00	1.0	one run in three looks this good by chance
400	$2.50	2.0	one in twenty
900	$1.67	3.0	one in four hundred

A useful rule falls out of that. To resolve an edge, you need about (2 * sd / mean) ** 2 trades before the result sits two standard errors from zero. At a ratio of ten to one, that is four hundred trades. Most people form a strong opinion about a strategy somewhere around trade forty.

This is not a counsel of despair, it is a calibration. Forty trades is fine for finding out whether your execution works, whether your risk sizing is survivable, whether you can follow your own rules. It is not enough to learn whether the strategy makes money, and treating it as though it were is how people scale up right before the mean reverts.

Win rate and profit factor will not save you

Both are real numbers and both are quoted constantly, and neither answers the question on its own.

Win rate says nothing without the payoff ratio beside it. Ninety percent winners at a one to twenty payoff is a losing system that feels wonderful ninety percent of the time. Ten percent winners at fifty to one is a business. Win rate is the most psychologically available number in trading and close to the least informative, which is an unfortunate combination.

Profit factor (gross won divided by gross lost) does combine the two, but it inherits the whole sample size problem. A profit factor of 1.5 over forty trades is a number with an enormous error bar attached, and nobody ever prints the error bar.

Expectancy, the plain average result per trade, is the one that feeds directly into the test that follows. It is also the one nobody quotes, because it is usually a small and unexciting number.

Testing the edge

The question "is this edge real" has a standard form: how often would pure chance produce an average at least this far from zero, in a sample this size? That is a two-sided t-test, and on a few hundred trades the normal approximation is close enough.

// Abramowitz & Stegun 7.1.26 is plenty for a p-value rounded to 3 places.
function erf(x) {
  const sign = x < 0 ? -1 : 1;
  const z = Math.abs(x);
  const t = 1 / (1 + 0.3275911 * z);
  const y =
    1 -
    ((((1.061405429 * t - 1.453152027) * t + 1.421413741) * t - 0.284496736) *
      t +
      0.254829592) *
      t *
      Math.exp(-z * z);
  return sign * y;
}

const tStat = mean / standardError;
const pValue = 2 * (1 - 0.5 * (1 + erf(Math.abs(tStat) / Math.SQRT2)));

On the record I opened with, the average trade is -$0.19 and the p-value comes back at 0.93. Ninety-three percent of random runs that size look at least that good. Correct answer, since I built it with no edge.

Two things this test does not do, and both matter more than the test itself.

It does not prove the absence of an edge. A high p-value on ninety trades means you have not measured anything yet, not that there is nothing there. Absence of evidence, in a regime engineered to produce very little evidence.

And it is not valid if the record you are testing was selected for looking good. If you tried fifty parameter sets and kept the best, the winner's p-value is meaningless, because you ran fifty tests and reported one. That is the multiple comparisons problem, and backtest overfitting is its natural habitat. The same applies to the trader who shows you their best account out of four. The test assumes you picked the sample before you saw the result, and in trading that assumption is broken more often than it holds.

Sequence luck

Here is the part that changes how people think about their own drawdowns.

Your equity curve is one ordering of your trades. The trades are what your strategy produced, but the order is an accident. Reshuffle them and the path changes completely while the endpoint stays exactly the same. Draw them with replacement instead of just reshuffling and you also get a distribution of endpoints.

function bootstrap(results, paths = 5000, horizon = results.length) {
  const finals = new Float64Array(paths);
  const maxDrawdowns = new Float64Array(paths);

  for (let p = 0; p < paths; p++) {
    let cum = 0, peak = 0, worst = 0;
    for (let i = 0; i < horizon; i++) {
      cum += results[(Math.random() * results.length) | 0];
      if (cum > peak) peak = cum;
      if (peak - cum > worst) worst = peak - cum;
    }
    finals[p] = cum;
    maxDrawdowns[p] = worst;
  }
  return { finals: finals.sort(), maxDrawdowns: maxDrawdowns.sort() };
}

Thirty lines, and it answers a question no single equity curve can. Run it on that same record:

The worst drawdown the account actually lived through: $534
The median worst drawdown across five thousand reorderings: $602
The ninety-fifth percentile: $1,225
Share of reorderings that drew down deeper than the real account ever did: 60%

Sixty percent. The drawdown this trader survived, and would quite reasonably use to size their risk, is shallower than a coin flip among the paths their own trades can produce. The number to plan around is $1,225, and they have never seen anything like it.

This generalises. People calibrate risk against their lived experience, and lived experience is a single draw. Position sizing built on the drawdown you happen to have had is built on the part of the record that is pure sequence luck. The bootstrap is the cheapest possible correction for that, and it needs nothing you do not already have.

Costs move the mean and leave the variance alone

This is why costs are so much more dangerous than they look.

Spread, commission and swap subtract a near-constant amount from every trade. They shift the mean down and barely touch the standard deviation. So their effect is completely invisible in the noise, trade by trade, and absolutely decisive in the only number that compounds.

The record I have been using:

Average trade before costs: +$0.92
Commission and swap: -$1.11 per trade
Average trade after costs: -$0.19

There is a real gross edge in there. It is smaller than the cost of trading. Nothing in the entry logic is broken, and no amount of work on the entry logic fixes it; the fixes are a cheaper broker, fewer trades, or longer holds. A trader looking at a flat equity curve will almost always go hunting in the signal, because the signal is the interesting part. The answer was in the fee column.

Where the result comes from

Totals hide structure. The same record, bucketed by the hour the trade was opened, puts -$330 in the small hours and +$234 in the afternoon. Bucketed by weekday, Tuesday makes $309 and Friday loses $291.

Usual caveat, with feeling: these are the same small samples sliced thinner, so each bucket has a wider error bar than the total. Slicing twenty ways and reporting the worst slice is the multiple comparisons problem again, wearing a different hat. Buckets are for generating a hypothesis you then test on data you have not looked at yet, not for concluding that you should stop trading Fridays.

They are still worth computing, because a bucket that is both large and lopsided is the one kind of finding that survives.

Parsing MetaTrader's exports

Enough statistics. The input to all of this is the HTML statement MetaTrader writes, and it is a more interesting parsing target than it has any right to be.

There are two layouts. MT4 writes a Closed Transactions table keyed by Ticket and Item. MT5 writes a Positions section keyed by Position and Symbol, and then appends Orders and Deals sections after it. Rather than sniff the platform first, I scan every row in the document, recognise either header by its column names, and read the rows that follow until the shape stops matching.

Four things bit me, two of them only after I built realistic fixtures and compared the two formats against each other.

Column names repeat. MT5's Positions header is Time, Position, Symbol, Type, Volume, Price, S/L, T/P, Time, Price, Commission, Swap, Profit. Both Time and Price appear twice, once for the open and once for the close, distinguished by nothing but document order. So the column map takes explicitly named columns first (Open Time, Close Time in MT4) and falls back to positional order for the duplicates.

Balance rows live inside the trade table. MT4 puts deposits and withdrawals in the middle of the closed transactions table, using colspan so the row has five cells where the trades have fourteen. My first version treated a column count mismatch as the end of the section, which meant a single deposit row at the top silently truncated the entire statement to zero trades. A mismatch has to mean "skip this row", never "this section ended".

But something still has to end a section. MT5's Deals header is fourteen columns where Positions is thirteen, within the tolerance I had just widened. Without a guard, every closed trade gets counted a second time from the deals log, with the columns shifted. The fix is that only a row that looks like a header ends a section, whether or not a usable column map comes out of it:

function looksLikeHeader(cells) {
  let hits = 0;
  for (const c of cells) if (HEADER_WORDS.has(normalise(c))) hits++;
  return hits >= 3;
}

Numbers and dates are localised. Statements come out in the terminal's codepage, frequently not UTF-8, so decoding tries UTF-8 first and falls back to windows-1252 when the result is full of replacement characters. Thousands separators may be spaces, including non-breaking ones, and a localised build can emit a decimal comma. The rule that handles every case I found: whichever separator sits last and leaves one to three trailing digits is the decimal one.

Timestamps are their own trap. They are printed in broker server time with no offset, so I build them with Date.UTC from the printed components and read the hour back with getUTCHours. That way the hour-of-day buckets show the clock the trader actually saw, rather than silently shifting by the visitor's timezone. When the same data comes from an API as real instants instead, the chart says so on the axis. Two different clocks quietly mixed into one histogram is a bug that produces plausible output forever.

Browser only, and the one exception

Asking strangers to upload their complete trading history to your server is a lot to ask, and storing it is worse. So the upload path does not have a server. The file is read with the browser's own file reader, parsed with DOMParser, and analysed in the tab. Nothing is transmitted, which means the page can say nothing is transmitted without any asterisks.

That constraint turned out to shape the whole thing. The statistics, the bootstrap, the charts all had to be cheap enough to run on a phone, which ruled out anything heavy and ruled out a charting dependency. Five thousand bootstrap paths over a few hundred trades is a couple of million additions, which is tens of milliseconds, so the limit was never the math.

There is one exception. The tool can also pull closed positions from a trading API instead of a file, and that API serves no CORS headers, so a browser cannot call it. That path goes through a small relay that forwards the key to two read-only endpoints and neither logs nor stores it. I would rather have had no server at all, but the honest version of "we need a relay and here is exactly what it does" beats pretending the constraint does not exist.

The charts ended up as hand-written SVG for the same reason: no dependency, and the whole tool compiles into a single 42 KB route chunk that one of the site's forty-one pages loads. Everything else on the site is untouched by it, which I check at build time rather than hope for.

What the math assumes, and where it breaks

Every technique above rests on two assumptions, and both are breakable.

Independence. The t-test and the bootstrap both assume each trade is a separate draw. Grid and martingale systems violate this flagrantly: their trades are deliberately correlated, which is the entire mechanism, and resampling them scatters a structure that was load-bearing. Overlapping positions in correlated instruments break it more quietly. When independence fails, the test overstates its own confidence, so the p-values look better than they deserve.

Stationarity. Resampling your past trades assumes the future draws from the same distribution. Markets change regime, spreads widen, a broker changes execution. The bootstrap tells you what your trades imply about a world that keeps behaving like the one they came from, which is a narrower claim than it looks.

And the big one, again, because it is the one that gets everybody: none of this is valid on a record that was selected for looking good. Test the strategy you committed to, not the best of the ones you tried.

Try it

The tool is at fxsocket.com/tools/statement-analyzer. Drop in an MT4 or MT5 statement and it runs everything above: expectancy with the test against zero, profit factor, drawdown, the cost breakdown, the buckets, and the bootstrap with the drawdown percentiles. Free, no account, and the file stays in your browser.

If you do not trade MetaTrader, the pieces in this post are a hundred lines of plain JavaScript and port to whatever holds your trade log. The standard error calculation alone would change how a lot of people read their own records.

I would genuinely like to be argued with on two points. First, whether the bootstrap should resample trades or blocks of trades, since block resampling preserves some autocorrelation and I decided the added complexity was not worth it for most retail records. Second, whether a p-value is the right thing to show a trader at all, or whether a confidence interval on expectancy would land better. Comments are open.

Trading leveraged products carries a real risk of loss. Nothing in this post is financial advice.

How We put MetaTrader 4 and 5 behind a REST and WebSocket API

0xdev — Wed, 21 Oct 2026 07:39:15 +0000

Most retail forex and CFD brokers still hand you a MetaTrader 4 or 5 login, and MetaTrader is surprisingly hard to automate from normal code. Your options are roughly:

write MQL and live inside the terminal,
use the official MetaTrader5 Python package, which only covers MT5 and needs a Windows machine with the terminal installed and running next to your script,
or glue something together yourself with an Expert Advisor, files and sockets.

Whichever you pick, you end up keeping Windows machines running around the clock, with a terminal logged in for every account you trade.

FxSocket is what I built instead. You give it a broker login, it starts a dedicated MT4 or MT5 terminal for that account in the cloud, and you get a REST and WebSocket API back. It works with any broker that offers MT4 or MT5, on demo and live accounts, from any language that can make an HTTP request.

Disclosure up front: I built this, and it's a paid product. I've tried to make the post useful even if you never sign up. After the code samples, most of it is about the engineering: API rules that came from worrying about double fills, and how MetaTrader runs headless on Kubernetes.

What you get

A dedicated terminal per account. There's no shared gateway multiplexing everyone's logins; your requests run inside your own MetaTrader instance.
REST endpoints for balance and equity, open positions and pending orders, deal and position history, symbols, quotes, OHLC history and contract specs, plus order send, modify and close, and margin and profit calculators.
One WebSocket per account with six topics: ticks, bar closes, account, positions, trade events and terminal status.
A management API (/v1) to link and unlink accounts, send one order to many accounts at once, and create read-only keys scoped to specific accounts.
Official SDKs for Python (sync and async, Pydantic models) and Node/TypeScript (ESM and CommonJS), both MIT licensed.
An OpenAPI 3 spec and Swagger UI on every account, so you can generate a client for Go, Rust, C# or anything else.

FxSocket is not a broker. Your money stays with your broker, and FxSocket has no way to deposit, withdraw or move it.

From zero to a first order with curl

Grab an API key from the dashboard, then link an account. server is the broker server name exactly as MetaTrader shows it.

export FXSOCKET_API_KEY=fxs_live_...

curl -X POST https://api.fxsocket.com/v1/accounts \
  -H "X-API-Key: $FXSOCKET_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform": "mt5", "server": "VTMarkets-Demo", "login": 1234567, "password": "..."}'

The password is stored encrypted and never returned by the API. (An investor password is enough for read-only access; placing trades needs the master password.) The response, trimmed:

{
  "id": "b5236acf-c39b-4e8b-be64-a96afb7e6086",
  "platform": "mt5",
  "server": "VTMarkets-Demo",
  "login": 1234567,
  "status": "connecting"
}

connecting means a real terminal is booting and logging in to your broker. Poll GET /v1/accounts/{id} until it reads connected, which usually takes a few minutes.

Every per-account route hangs off /mt5/{account_id} (MT4 accounts use /mt4/{account_id} with the same routes):

ACCOUNT=b5236acf-c39b-4e8b-be64-a96afb7e6086

curl -H "X-API-Key: $FXSOCKET_API_KEY" \
  https://api.fxsocket.com/mt5/$ACCOUNT/AccountSummary

{
  "balance": 9686.15,
  "credit": 0.0,
  "profit": 0.0,
  "equity": 9686.15,
  "margin": 0.0,
  "freeMargin": 9686.15,
  "marginLevel": 0.0,
  "leverage": 400,
  "currency": "USD",
  "type": "Demo"
}

A market buy with a stop loss and take profit:

curl -X POST https://api.fxsocket.com/mt5/$ACCOUNT/OrderSend \
  -H "X-API-Key: $FXSOCKET_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"symbol": "EURUSD", "operation": "Buy", "volume": 0.1, "stopLoss": 1.148, "takeProfit": 1.162}'

{
  "success": true,
  "retcode": 10009,
  "retcodeDescription": "Request completed",
  "deal": 211438760,
  "order": 211438761,
  "volume": 0.1,
  "price": 1.15333,
  "bid": 1.15325,
  "ask": 1.15333,
  "comment": ""
}

Internalize this one early: an HTTP 200 doesn't mean the order filled. It means MetaTrader answered. Check success and retcode (10009 is done, 10008 is placed). That distinction ended up shaping a lot of the API (more on that below).

Pending orders use the same route with BuyLimit, SellStop and friends, plus a price. OrderModify changes SL/TP (or a pending order's price), and OrderClose closes by ticket, with an optional volume for a partial close.

Streaming over WebSocket

Each account has one WebSocket. Browsers can't set custom headers on a WebSocket upgrade, so the key goes in the query string:

$ wscat -c "wss://api.fxsocket.com/mt5/$ACCOUNT/ws?api_key=$FXSOCKET_API_KEY"
> {"action": "subscribe", "topic": "prices", "symbol": "EURUSD"}
< {"type": "tick", "symbol": "EURUSD", "data": {"bid": 1.15325, "ask": 1.15333, "last": 0.0, "volume": 0, "time": "2026-06-11T08:55:56.728Z"}}

Topics are prices, bars (per symbol and timeframe), account, positions, trades and terminal. When you subscribe you get a snapshot first, then deltas.

Python SDK

pip install fxsocket

from fxsocket import Client

with Client() as fx:  # reads FXSOCKET_API_KEY
    account = fx.accounts.list()[0]
    term = fx.terminal(account)

    print("equity:", term.account_summary().equity)
    print("EURUSD ask:", term.quote("EURUSD").ask)

    result = term.order_send(
        symbol="EURUSD", operation="Buy", volume=0.10,
        stop_loss=1.148, take_profit=1.162,
    )
    if result.success:
        term.order_modify(result.order, take_profit=1.165)

fx.terminal(account) looks up where that account's terminal lives, so the same code works on the shared cluster and on a private server (more on those later).

Streaming is async-first. A dropped connection reconnects on its own and replays your subscriptions:

import asyncio

from fxsocket import AccountUpdate, AsyncClient, Tick


async def main():
    async with AsyncClient() as fx:
        account = (await fx.accounts.list())[0]
        async with fx.stream(account) as s:
            await s.subscribe_prices("EURUSD")
            await s.subscribe_account()
            async for event in s:
                match event:
                    case Tick():
                        print(event.symbol, event.data.bid, event.data.ask)
                    case AccountUpdate():
                        print("equity", event.data.equity)


asyncio.run(main())

Node / TypeScript SDK

npm install @fxsocket/sdk

import { FxSocket } from '@fxsocket/sdk';

const fx = new FxSocket(); // reads FXSOCKET_API_KEY
const [account] = await fx.accounts.list();

const stream = fx.stream(account);
stream.on('tick', (e) => console.log(e.symbol, e.data.bid, e.data.ask));
stream.on('trade', (e) => console.log('position', e.data.position, 'net', e.data.netProfit));

await stream.connect();
await stream.subscribePrices('EURUSD');
await stream.subscribeTrades();

Stream events are a discriminated union on type, so TypeScript narrows data for you. The stream is also an async iterable if you'd rather use for await.

One order, many accounts

Once you run more than a couple of accounts (copy trading, a stack of prop firm challenges, one strategy spread across brokers), you want one request instead of N. POST /v1/orders fans an order out to several terminals concurrently:

curl -X POST https://api.fxsocket.com/v1/orders \
  -H "X-API-Key: $FXSOCKET_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: signal-4711" \
  -d '{
    "defaults": {"operation": "buy", "symbol": "EURUSD", "stop_loss": 1.148},
    "orders": [
      {"account_id": "6fcb1e23-...", "volume": 0.10},
      {"account_id": "a91b0d47-...", "volume": 0.25, "symbol": "EURUSD.sd"},
      {"account_id": "c73d55e2-...", "volume": 0.05, "symbol": "EURUSDm"}
    ]
  }'

Each leg inherits defaults and can override any field. The per-leg symbol is there for a boring but very real reason: brokers spell instruments differently. EURUSD, EURUSD.sd and EURUSDm are the same pair at three different brokers, so one symbol across mixed brokers will partly fail by design.

The response has one result per leg, in order, and the statuses are where it gets interesting:

`status`	Meaning	Executed?
`filled`	The broker accepted it	Yes
`rejected`	The broker refused it (see `retcode`)	No
`invalid`	The terminal refused the request itself	No
`unavailable`	The terminal is up but not ready to trade	No
`unreachable`	There's no terminal to talk to	No
`timeout`	The deadline ran out	Unknown

Validation is all-or-nothing: one malformed leg rejects the whole batch before anything is sent. Execution isn't. A partial fill across brokers is normal rather than an error, so you get a 200 with a result for every leg.

Closing works by intent rather than by ticket. POST /v1/orders/close takes a selector like {"symbol": "EURUSD", "side": "long"}, looks up matching positions on each account and closes them. You don't have to fetch tickets first from a list that may already be stale by the time you act on it.

Lessons from designing a trading API

A timeout is not a failure

The most important row in that table is the last one. When a request to a broker times out, the order may well have gone through. If your client calls that a failure and retries, you've just doubled your position. That's why timeout is reported as unknown, never as failed.

The batch endpoints take an Idempotency-Key header for the same reason. Replay the identical body with the same key within 15 minutes and you get the original response back, with nothing sent. The same key with a different body gets a 422, and the same key while the first batch is still running gets a 409. If the idempotency store itself is down, the request is refused with a 503 rather than traded without the guarantee.

Make the dangerous thing hard to do by accident

A few rules that came from imagining the worst possible afternoon:

A close needs a symbol, and "everything" has to be typed. An omitted symbol is a 400, never a silent close-all. If you mean every symbol, you send "*".
A close only touches open positions by default, so a routine close doesn't also delete your resting pending orders.
Unknown fields are rejected. /v1 uses snake_case and the terminal routes use camelCase. If someone pastes stopLoss into a /v1 body and it gets silently ignored, they've just opened a position with no stop. So it's a 400 instead.
The SDKs refuse a stop loss of 0 on a modify. MetaTrader reads a zero stop loss as "remove the stop", so the SDK makes you ask for that explicitly with clear_stop_loss=True.

"Done" has more than one shape

MetaTrader returns a result code for every trade request, and the SDKs classify each one as applied, no_change, partial or rejected. no_change (retcode 10025, meaning the SL/TP you asked for is already set) comes back with success: false, yet it's exactly what you want when you re-send a modification after losing the first response. So results also carry is_effective, which is true for both applied and no_change and makes SL/TP updates safe to retry.

Always bound your history requests

On MT5, ask for price history without a date range and the terminal asks the broker for the entire history of that timeframe. On a typical demo account that's around a million M1 bars, which blows straight through the request deadline. Pass a from date and the same call answers in well under a second.

Under the hood: MetaTrader on Kubernetes

MetaTrader is a Windows desktop application. There's no headless mode, and the official ways in are MQL running inside the terminal or (for MT5) a Python package that talks to a terminal on the same Windows machine. Here's how it runs as a service anyway.

One terminal per account, in a container

On the shared cluster, every linked account gets its own pod running the real MetaTrader terminal under Wine, with Xvfb standing in for a display.

A Rust DLL inside the terminal

The bridge is a Rust library loaded into the terminal process. It runs a tokio runtime with an axum server for REST and WebSocket. MQL programs inside the terminal drain a command queue on the terminal's main thread, call MetaTrader's own functions, and pass the results back across the FFI boundary. The OpenAPI spec is generated from the Rust types with utoipa, which is how every account gets an accurate Swagger UI for free.

MQL5 has no "attach this Expert Advisor" function

This one surprised me. To start the trading EA, the bridge opens a chart and applies a chart template that has the EA on it. Streaming uses the same trick: the first subscriber to a symbol's ticks spawns a small event EA on a chart for that symbol, and when the last subscriber leaves, the chart closes. Events fan out through a tokio broadcast channel, and a slow WebSocket client gets dropped messages plus a warning frame instead of stalling everyone else.

Never run two terminals on one login

Brokers treat two concurrent sessions on the same account as a duplicate login and kick one of them, and trade state gets murky. A normal Kubernetes rolling update briefly runs the old and new pod side by side, which is exactly that situation. So terminal Deployments use the Recreate strategy. The cost is a short gap during image rollouts, and I'll take that trade.

Health checks can't depend on the broker

The terminal's own health route needs a live broker session. If the liveness probe used it, a terminal that's simply mid-login (or a broker having a bad minute) would get restarted in a loop. So the Kubernetes probes only check that the port is open, and a reconcile loop checks the real thing every couple of minutes: terminal alive, broker connected, account logged in. The same loop creates missing terminals, heals half-created ones and sweeps up orphans, so a half-finished teardown never leaves broker credentials lying around.

Config changes roll the pod on purpose

A terminal reads its config once, at boot. The pod template carries a hash of that config (credentials, keys, image), so rotating an API key changes the hash, and the next reconcile pass restarts the terminal with the new key.

Broker discovery is its own project

A fresh MT5 install can't resolve arbitrary broker server names. Without that broker's servers.dat, the terminal boots, the API answers, and it never even attempts a login. You just get an account summary full of zeros. So a separate broker search service keeps an index of more than 9,000 broker servers, and each container installs the right file before the terminal starts.

Related lesson: a truncated servers.dat can make the terminal's parser balloon until it OOM-kills a 4 GiB pod in under five seconds. Verify your uploads.

Auth lives in the terminal, not the gateway

The gateway only routes. Each terminal starts with its owner's API key (plus any read-only keys scoped to that account) and checks every request itself. A perfectly valid key for account A, presented at account B's URL, is just a wrong key and gets a 401. There's no permission lookup to misconfigure, because the terminal doesn't know anyone else's keys.

Isolation costs memory

Each terminal reserves 1 GiB, even though steady-state usage sits around 300 to 500 MB. One terminal per account is simple to reason about and hard to get wrong, but memory is the real scaling cost of this design.

Private servers with a fixed IP

Some prop firms want to whitelist the IP your trades come from, and some traders simply want their own box. For that there are private servers: a dedicated server in a region you pick, with a fixed IP that survives reboots, resizes and rebuilds. A new one is live in 5 to 10 minutes and speaks the exact same REST, WebSocket and SDK API.

Pricing

At the time of writing:

Starter: €12 per account per month, full REST and WebSocket access, live and demo accounts
Pro: €549 per month, 60 accounts included
Premium: €949 per month, 110 accounts included
Private server: €17 per month for the first account, plus €14 for each additional account on that server, billed separately from your plan

You can pay by card, or prepay a balance in crypto that covers your accounts as they renew.

Try it

Website: fxsocket.com
Docs: fxsocket.com/docs
Management API reference (Swagger): api.fxsocket.com/v1/docs
Python SDK: PyPI and GitHub
Node SDK: npm and GitHub

You don't need a funded account to try any of this. A free demo account from your MT4 or MT5 broker works with every endpoint in this post. cTrader support is on the roadmap.

If you've automated MetaTrader some other way, I'd like to hear what hurt. And if you think one of the design choices above is wrong, tell me in the comments.

Trading leveraged products carries a real risk of loss. Nothing in this post is financial advice.