A prop firm's first scaling problem is rarely the traders. It is a number in a server config. Platforms that descend from the installed-server generation size capacity per instance: so many concurrent accounts, so many ticks per second, so many open positions before the box starts queueing. When you pass that number, the fix is structural. You provision a second server, decide which accounts move, schedule a window, move them, and hope the credentials, histories and open positions arrive intact.
Founders discover this in the month their marketing finally works. That is the worst possible month for a maintenance window.
What actually breaks when a firm outgrows one instance
The migration itself is the visible part. Underneath it sit four costs that do not appear in any vendor quote.
The first is account identity. Trader logins on server-based platforms usually carry the server address with them. Move the account and the login changes, which means an email to every affected trader, a support queue for the ones who miss it, and a fresh crop of tickets from people who saved the old server in their terminal. The second is history. Evaluation businesses live on trade history: consistency scoring, drawdown baselines, minimum trading days. A migration that loses or reindexes closed trades quietly damages the evidence you would need in a payout dispute.
The third is your risk system. If positions reach your rules engine through a bridge or a plugin bound to an instance, the bridge has to be repointed and revalidated. During the gap, enforcement is blind. A firm running trailing drawdown on live accounts cannot afford a blind hour, which is why the sync path matters as much as the platform, a point argued in detail in how eTrader and the rules engine are wired together.
The fourth is the calendar. Migration windows land on weekends, and weekends are when your operations staff are thinnest and your gold and index traders are already annoyed about the gap risk.
The test that matters for a launch decision is not "can this platform handle 10,000 accounts". It is "what do I personally have to do when account 2,001 signs up". If the honest answer involves a window, a spreadsheet of account numbers and an email to traders, you have bought a growth tax.
Why the rented cloud platforms already solved half of this
Here is the concession, and it is a real one. DXtrade, Match-Trader, TradeLocker and cTrader's hosted deployments are not installed-server products in the way MT4 was. They are operated by their vendors on shared infrastructure, and for the founder that means the capacity question is genuinely the vendor's problem. A firm launching on any of them will not be shopping for a second box at 2,000 accounts. Anyone telling you otherwise is selling something.
So the scaling argument for eTrader is not "we are managed and they are not". It is narrower and more useful: what does scaling do to your bill, your credentials and your rules enforcement, given that all of you are on someone else's servers.
Growth that changes one number instead of one architecture
eTrader runs on hundreds of servers worldwide in clusters with automatic failover, operated and scaled by SINGUARD. A firm hosts nothing and administers nothing, so the account you issue after a good ad week is provisioned by the CRM in the same call as the first account you ever issued. The trader still opens a link. There is no server address in the credential, so there is nothing to reissue and nothing to email.
The commercial side follows the same shape. Pricing is a monthly platform fee plus a fee per trading account issued, so the variable cost tracks accounts actually opened rather than a tier you had to guess at launch. That is worth more to a young firm than it sounds: tiered licensing forces you to buy the firm you hope to become, and a firm that overshoots has burned cash it needed for acquisition. The full structure is broken down in the eTrader pricing article.
Enforcement scales with it rather than beside it. Positions sync from the terminal into the Prop Firm CRM rules engine every 500 milliseconds regardless of how many accounts are open, because the sync is native to the platform rather than a bridge you sized yourself. Nobody has to repoint anything when the account count doubles.
The failover question nobody asks until the first outage
Single-instance platforms concentrate risk by construction. One node holds a set of accounts, and if that node has a problem, those accounts are down while the rest of your firm trades normally, which is somehow worse for support than a full outage because half your traders think it is their internet. Clustered operation moves the account to another node instead. The mechanism, and what to ask a vendor about it, is covered in uptime and clustered platforms.
None of this makes uptime a promise. Every platform has bad days, SINGUARD included, and any vendor quoting you a nines figure in a first call should be asked for the measurement method before you write it into a business plan.
Three questions to put to every platform vendor
Ask what happens to a trader's login when the account is moved between instances. If the answer contains the phrase "new server", price the support load. Ask what your risk system reads and how often, and whether that path is native or a bridge you are responsible for. Ask how the bill changes between 500 and 5,000 accounts, and get the answer as arithmetic rather than a tier name.
For a founder still weighing MetaTrader against the newer options, the scaling answer sits underneath a policy answer that has to be settled first, and that one is laid out in the current state of MetaTrader access for prop firms. Platform choice for a new firm is a bet on the month things go right. Choose the stack that does the least when that month arrives.
"Nobody plans a platform migration for the month their ads finally work, but that is exactly the month a per-server platform asks for one."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- Per-instance platforms tie capacity to a box, so growth becomes an account migration with new logins, a maintenance window and a support queue.
- The hidden costs are trader credentials, trade history used for consistency scoring, and the period your rules engine is blind while a bridge is repointed.
- DXtrade, Match-Trader, TradeLocker and hosted cTrader already remove the second-box problem, so judge them on billing shape and enforcement path instead.
- eTrader runs on managed clusters with per-account pricing and a native 500ms position sync, so account 2,001 is provisioned exactly like account one.
Frequently Asked Questions
Does a prop firm ever need to migrate accounts on eTrader?
Firms do not provision or size servers on eTrader. SINGUARD operates the clustered infrastructure and scales it, so adding accounts is a CRM action rather than an infrastructure project. Traders open a link, and the credential carries no server address to reissue.
Are the rented cloud platforms worse at scaling than eTrader?
Not on the capacity question. DXtrade, Match-Trader, TradeLocker and hosted cTrader are vendor-operated, so the second-server problem does not fall on the firm. The differences that remain are how the bill changes as accounts grow and whether your risk system reads positions natively or through a bridge you maintain.
What should a founder ask a platform vendor about growth?
Ask what happens to a trader login when an account is moved, what path the risk engine uses to read positions and at what interval, and what the monthly bill looks like as arithmetic at 500 accounts and at 5,000 accounts rather than as a tier name.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.