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. Major third-party platforms' hosted deployments are not installed-server products in the way a legacy desktop terminal 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 hosted 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 is hosted in the cloud by SGHK and managed by your firm, built to scale across clustered servers and regions as firms grow. A firm hosts nothing and installs 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. There is no licence tier to guess at launch, and the feed, hosting and apps are included in the platform. That is worth more to a young firm than it sounds: fixed licence tiers force you to buy the firm you hope to become, and a firm that overshoots has burned cash it needed for acquisition. Pricing is quoted for your firm on a call, and what is included is set out 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 outage 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. On a hosted platform the machine is not yours to fix: if an eTrader server stops taking orders, SGHK answers the firm within 30 minutes, 24/7, on WhatsApp, calls and email. What to ask a vendor about it is covered in platform uptime on a managed platform.
None of this makes uptime a promise. Every platform has bad days, SGHK 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 a legacy platform 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 legacy-platform 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."
— The SGHK Team
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.
- major third-party platforms already remove the second-box problem, so judge them on billing shape and enforcement path instead.
- eTrader is hosted by SGHK, includes the feed and apps, and has 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. SGHK hosts it on clustered infrastructure built to scale, and your firm manages its own accounts, 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. major third-party platforms 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 SGHK
SGHK is a FinTech company that designs and builds its own software for the trading industry: the eTrader trading platform, Launch your Broker and Launch your Prop Firm. Every product is written, hosted and supported in-house and licensed to trading firms, with the CRMs branded to them, all hosted by us in the cloud, managed by each firm and built to scale across clustered servers as our clients grow. Everything is encrypted, and each firm is the only one with access to its data and its clients' data.