The infrastructure behind TradingHost’s always-on trading runtime
TradingHost, one of Think Huge’s own brands, turns a GitHub push into a live trading strategy in seconds. No server to manage. Underneath, it runs on the same Kubernetes-native infrastructure Think Huge builds for every partner.
What TradingHost Does
A trader writes a strategy, saves it to GitHub, and TradingHost runs it 24/7 next to their broker.
1. Connect
Link a GitHub repository. Every push to main is what runs.
2. Build
Write the strategy in any language, in your own editor, with AI tools like Cursor, Claude or ChatGPT. A native MCP server lets the AI deploy and monitor directly.
3. Run
Pick a location. The strategy goes live in its own container, with logs streaming to a dashboard.
Works with any broker or exchange that has a public API. TradingHost is the runtime only; the strategy makes its own venue connection.
The Infrastructure Challenge Underneath
Trading code is small software with unforgiving requirements.
It cannot go down. An offline strategy with an open position is a financial loss, and markets run around the clock.
It has to be close to the venue. Every extra millisecond to the broker is slippage.
It needs capacity at the peak, not the average. Market opens and news releases are when every strategy wants CPU at once. General-purpose clouds share whatever is left.
It has to isolate every customer. Tens of thousands of traders, none of whom may see another’s code or credentials.
Some traders want their own server for this and manage it themselves. Others want to hand over the code and never think about the machine. TradingHost is built for the second group.
How Think Huge Powers TradingHost
Every deployment is its own container. Orchestration provisions it on push, redeploys it on the next push, and restarts it if the process dies. If hardware fails, the runtime is rescheduled onto healthy infrastructure. If a region degrades, the trader redeploys to the other in seconds.
Isolation is enforced at the infrastructure layer, not inside the container.
Containers sit in Equinix LD4 (London) and NY4 (New York), a cross-connect from the major broker and exchange endpoints, on network paths tuned for trading rather than general web traffic.
Every workload on the platform is a trading workload. Capacity is reserved for the peaks, so there are no noisy neighbours when the market opens.
The layer carries a 99.99% infrastructure SLA covering network, data centre and power.
TradingHost joins FXVM, ForexVPS.net, PingPlayers and AlgoBuilder on the same stack Think Huge sells to partners.
There is no lighter internal version.
Four Think Huge layers, each available to partners in its own right.
End-User Compute
One isolated environment per trader, provisioned on demand and placed next to the venue they trade against. Destroyed cleanly when no longer needed.
Orchestration
Kubernetes-native placement, scaling and lifecycle management. Turns a GitHub push into a running strategy and restarts it when something fails.
Networking & Connectivity Systems
The short network paths between a container and its broker.
Backup & Resilience
The failover and rescheduling model behind the 99.99% SLA.
Trading Platforms & Brokers
Execution & Latency
Kubernetes-native orchestration
Automatic redeploy on every push to GitHub main.
Isolated containers per customer
One or many strategies per container.
Equinix LD4 and NY4
London and New York.
Any language in a Linux container
Python, TypeScript, Rust, Go, C++ and C#.
Strategy framework templates
CCXT, Freqtrade, Jesse, Hummingbot, Backtrader, vectorbt and NautilusTrader.
Native MCP server
For Claude, Cursor and ChatGPT.
Any broker or exchange
With a public API.
99.99%
infrastructure SLA
ISO
9001 and ISO/IEC 27001
24/7
support, not a third party
Same orchestration and network
Think Huge builds for every partner.
Isolation enforced at the infrastructure layer
Not inside the container.
Broker credentials stay in the customer’s own secret store
Never committed or logged.
Think Huge runs its own brands
On the infrastructure it sells.
