Running a Python Trading Bot on SuperFunded × TradeLocker in Live Production: The Full MQL-Free Tech Stack

The old assumption that "automated trading on a prop firm = an MT4/MT5 EA" is already half-outdated.

We're currently running a trading bot written in Python in live production on a SuperFunded TradeLocker account. We use no MetaTrader at all. No TradingView webhook, no signal bridge either. This setup calls TradeLocker's official API directly from Python.

This article walks through the tech stack, design, and operational setup of the bot that's actually running. It's written for people who "don't want to write MQL but still want a bot running" or who want to know "can I automate trading on a firm that uses TradeLocker?"

⚠️ Whether automated trading is allowed, and under what conditions, varies by firm. SuperFunded allows EAs/automated trading (HFT and arbitrage are banned), but always check the official rules before running anything. See the 19-firm EA rules comparison here.

Why TradeLocker lets you write this in Python

Automated trading on MT4/MT5 assumes the MQL language and a terminal running persistently, but TradeLocker's philosophy is different.

• An official REST API is publicly available (covering order placement, closing, position lookup, account status, and price data)
• The official Python library tradelocker installs via pip
• Since it connects directly to the broker's execution server, a persistently running terminal isn't required

In other words, instead of "attach an EA to a chart and leave the PC running 24/7," you can write the bot as an ordinary Python program and deploy it with ordinary server operations.

Connecting only takes this much:

from tradelocker import TLAPI

tl = TLAPI(
    environment="https://live.tradelocker.com",  # demo uses demo.tradelocker.com
    username="your@email.com",
    password="********",
    server="YOUR_SERVER",   # the server name provided by your firm
)

The library handles fetching and auto-refreshing the JWT token for you.

The tech stack of the bot in live production

Here's the actual configuration of the bot running on SuperFunded. It was originally written as a time-window-based gold strategy in MQL5 as an EA, then ported to Python.

The key point is making the state store swappable. For local verification it's state.json; in serverless production it's Firestore — the same code lets you choose the runtime environment.

The core of the design: "state reconciliation"

When running a bot on a prop account, the scariest thing is double orders and orphaned positions. With drawdown rules in play, "I ended up holding twice the intended lot size" can kill the account instantly.

Rather than an imperative "place the order when the time comes" model, this bot is designed to compare the "state that should exist" against the "state that actually exists" every tick, and only execute the difference. It's the same idea as a Kubernetes reconcile loop.

Every tick:
  1. Compute the set of positions that should currently be held (a pure function)
  2. Query the account's actual positions (get_all_positions)
  3. Execute the diff:
     - Should exist but doesn't, and no entry made today → place a market order (with SL)
     - Exists but shouldn't → close it
     - 2+ positions share the same tag → close the excess (insurance against double orders)

With this design, the bot itself becomes nearly stateless, which means:

• It's safe even after a restart, since it queries the current state before acting
• Running it once a minute serverless doesn't cause double orders (idempotent)
• It never touches positions you opened manually

strategy_id stands in for MagicNumber

On MT4/MT5, MagicNumber identifies which EA owns a position, but on TradeLocker you can attach a strategy_id tag at order time and read it back when querying positions:

# Tag the order at placement time (SL is specified as an absolute price)
tl.create_order(
    instrument_id, quantity=lot, side="buy", type_="market",
    strategy_id="mybot_1",
    stop_loss=sl_price, stop_loss_type="absolute",
)

# Filter for just your own positions by tag when querying
df = tl.get_all_positions()
mine = df[df["strategyId"].str.startswith("mybot_", na=False)]

This lets you safely coexist with manual trades and other strategies.

Watch out for the official library's automatic retries

The tradelocker package automatically retries a failed POST up to 3 times on a communication error. This is convenient, but if a retry fires after a timeout, the order can end up going through twice. As a safeguard, the bot checks the position count for the same strategy_id on the tick right after placing an order, and automatically closes any excess if there are 2 or more. If you're going to coexist with a prop firm's drawdown rules through automated trading, this kind of "insurance layer" is essentially mandatory.

Serverless operation: runs almost entirely within GCP's free tier

There's no need to run a VM continuously. Since this strategy trades only during a fixed time window, I set it up so that Cloud Scheduler fires a Cloud Run Job once a minute, only during the trading window.

• A single run takes a few seconds (connect → reconcile → exit)
• State is a single Firestore document
• Fewer than 100 invocations per day → essentially within GCP's free tier
• Since the SL sits on the broker's side, the bot doesn't need to stay running while a position is open

Not needing the "few-thousand-yen-a-month Windows VPS" that was standard for running MT4/MT5 EAs is one of the hidden big advantages of the TradeLocker × Python approach.

The safety gate for live order placement

To prevent accidents, live-environment order placement is locked behind a triple gate of environment variables:

TL_ENV=live AND TL_DRY_RUN=false AND TL_CONFIRM_LIVE=YES

Unless all three line up, it won't start. In DRY-RUN mode, no orders are placed — it only logs what it would do — so the workflow is to run it on demo for a few days first before promoting it to production.

Gotchas (things we actually hit in live production)

1. Account-state key names are server-defined: the keys in the dict returned by get_account_state() depend on the broker's configuration. balance is nearly universal, but the equity equivalent is sometimes projectedBalance, so it's safer to pull from a list of candidate keys rather than hard-coding one.
2. Symbol names differ by firm: some accounts have gold as XAUUSD, others as GOLD. Check first whether it resolves via get_instrument_id_from_symbol_name().
3. Order rejection right after the weekend: early Monday, before the market reopens, orders get rejected. Building in "retry on the next tick if rejected" lets it automatically catch up once trading resumes (this happens naturally if you use the reconciliation design).
4. Spread guard: spreads widen right after reopening or during thin-liquidity hours. It's a good idea to check the ask-bid spread before placing an order and skip it if the spread exceeds a threshold.

Automating the P&L record too: the tracker now supports TradeLocker

To go along with this live deployment, our own P&L tracker now supports TradeLocker as well. It's a Python script that periodically pulls balance, floating equity, and daily P&L via the official API and sends it to prop-memo.com — just drop it in the same .env and on the same machine as the bot to get it running (it's record-only and never places orders).

👉 TradeLocker tracker setup guide

It feeds into the same API key and the same P&L page as the MT4/MT5 EA version and the cTrader cBot version, so even when running multiple firms — "EAs for MetaTrader firms, Python for SuperFunded" — you can manage your P&L in one place.

Summary: TradeLocker-based firms are a target for "code-first" traders

• SuperFunded allows EAs/automated trading (HFT and arbitrage are banned), and TradeLocker's official Python API is usable
• No MQL, no persistent terminal, no Windows VPS required. You can write the bot with ordinary Python engineering
• If you're going to run this on a prop account, an idempotent state-reconciliation design plus insurance against double orders is essentially mandatory
• With a Cloud Run Job + Scheduler setup, it runs for almost nothing

Firm selection now needs to account for not just "can I use an EA" but "which platform, and how can I actually automate it." For SuperFunded's rule details, see the complete guide; for EA policies across firms, see the 19-firm comparison.

Last updated: July 9, 2026