Cloud Infrastructure for Trading Strategies
No servers to manage. No Kubernetes to learn. No terminals to keep open.
Connect a GitHub repo, choose a region, and your trading strategy runs on TradingHost infrastructure built for always-on workloads. TradingHost manages the compute, orchestration, runtime networking and operational controls beneath your deployment. You stay focused on the strategy.
What you get
- 99.99% infrastructure SLA
- Containerised runtimes
- Multi-region deployment
- Runtime restart controls
- Streaming logs
- GitHub-native workflow
- No customer-managed servers
Section 01 · Managed cloud, in plain English
New to managed cloud infrastructure?
If you have ever run a trading strategy on a VPS, you know the work involved. Logging into a server, installing updates, configuring process supervisors, fighting with terminal sessions, restarting things at 3 a.m. when something breaks. The server is yours to babysit.
Managed cloud infrastructure flips that. You hand the platform a piece of code from your GitHub repo. The platform runs it, keeps it alive, and tells you what is happening. You stop being a sysadmin and go back to being a trader or developer.
That is TradingHost. Your code lives in GitHub. The infrastructure is our problem.
Managed cloud, defined
TradingHost runs your trading code on managed cloud infrastructure. TradingHost manages the compute, orchestration, runtime networking and operational controls beneath your deployment. Customers do not access underlying host servers.
Section 02 · Reliability
99.99% infrastructure SLA for the layer beneath your runtime
TradingHost commits to a 99.99% infrastructure SLA covering network, data centre and power availability, subject to SLA terms and exclusions.
TradingHost provides an infrastructure SLA. Strategy availability also depends on user code, broker and exchange APIs, credentials, dependencies, third-party services and state recovery.
TradingHost’s SLA applies to the infrastructure layer: network, data centre and power availability. It does not guarantee that user code, broker APIs, exchange APIs, GitHub, third-party services, credentials, dependencies or in-memory strategy state will always function correctly.
- Runtime restart controls
- If a strategy process exits unexpectedly, TradingHost can restart it according to the runtime’s restart policy and surface the failure in your logs. The restart behaviour you get depends on how your deployment is configured.
- Infrastructure recovery
- Where supported, the orchestration layer can restart or reschedule affected runtimes when underlying infrastructure events occur. Your strategy must still be designed to recover safely after a restart.
- Multi-region deployment
- You choose which region your runtime lives in. If a region experiences degraded performance, you can redeploy to another in seconds, from the dashboard or from your AI IDE through MCP.
SLA exclusions
The infrastructure SLA does not apply during the following events. The full list lives in our Terms and Conditions.
- Scheduled maintenance and emergency maintenance windows
- Planned migrations
- Account suspension or service termination
- Force majeure events
- Upstream provider failures
- Customer ISP issues
- Software running inside customer runtimes
- Third-party attacks, viruses and server compromises
- User activity errors
Section 03 · At a glance
The shape of TradingHost in ten lines
The full shape of the platform, scannable. Each row points to a section or page that owns the detail.
- Infrastructure
- Managed cloud, container-based.
- What you manage
- Strategy code, trading logic, broker and exchange configuration, and risk controls.
- What TradingHost manages
- Compute, operating system, orchestration, runtime networking and infrastructure operations.
- Server access
- No customer access to underlying host servers.
- Isolation
- Customer runtimes are isolated from other customer runtimes.
- Strategies per runtime
- One or many, depending on deployment configuration.
- Regions
- Multiple, see Regions.
- Need to know Kubernetes?
- No.
- Reliability model
- Runtime restart controls, health visibility, streaming logs and infrastructure SLA.
- SLA
- 99.99% infrastructure SLA covering network, data centre and power, subject to exclusions.
Section 04 · How it works
Three layers, one of which you ever touch
Three layers sit between you and the underlying cloud. You only ever interact with one of them. The separation is the whole point: write trading code, push to GitHub, and your strategy runs. TradingHost manages the compute, orchestration, runtime networking and operational controls beneath your deployment.
Control plane
What you see. The dashboard, the deploy flow, the logs and the MCP server. Every customer interaction lives here.
Runtime
The container your strategy actually runs in. Configured through your GitHub repo and the deploy flow. You never log into it directly.
Infrastructure
Compute, orchestration, runtime networking and operational controls. Managed by TradingHost. Customers do not access underlying host servers.
Section 05 · TradingHost vs a VPS
A VPS gives you a server. TradingHost gives your code a place to run.
TradingHost is not a prettier VPS. It is purpose-built infrastructure for trading code. The dashboard, the runner, the secrets boundary and the lifecycle controls are already wired up.
On a VPS
- You manage the server
- RDP or SSH in
- Install dependencies by hand
- Keep terminal sessions alive
- Hunt for log files
- Patch the OS
- Restart things when they crash
- Server-centric
On TradingHost
- You manage your strategy
- Use the dashboard or MCP
- Define them in your repo
- Strategies run in managed runtimes
- Logs stream to the dashboard
- We handle the OS
- Automatic restarts
- Strategy-centric
Section 06 · What you don't have to do
The list of things that are no longer your job
You don't keep a desktop terminal open. You don't restart things when they crash. We do all of it.
- Operating systems
- Kernel updates
- Security patches
- Container schedulers
- Network configuration
- Firewalls
- Hardware monitoring
- Capacity planning
- Restarts
- Health monitoring
You also don’t need to learn Kubernetes. We use it under the hood because it is the right tool for orchestrating long-running workloads at scale, but you never see it. The user-facing model is your repo, a region and a deploy button.
Section 07 · What you keep doing
The trading decisions stay yours
TradingHost runs the code. The trading decisions, the risk model and the broker connection stay yours.
- Write the strategy
- Connect to your broker or exchange
- Decide on risk controls
- Decide on position sizing and order handling
- Test before going live
- Monitor your trading behaviour
Section 08 · Honesty
The boundary, stated plainly
No daylight between the marketing and the product.
What the 99.99% SLA covers
TradingHost’s SLA applies to the infrastructure layer: network, data centre and power availability. It does not guarantee that user code, broker APIs, exchange APIs, GitHub, third-party services, credentials, dependencies or in-memory strategy state will always function correctly.
Strategy availability also depends on user code, broker and exchange APIs, credentials, dependencies, third-party services and state recovery. The full SLA terms and exclusions live in our Terms and Conditions.
- TradingHost does not give you shell access to the underlying servers.
- TradingHost does not preserve your strategy’s in-memory state across restarts. Strategies should rebuild state from broker APIs or external storage.
- TradingHost does not guarantee specific latency to specific brokers. Latency depends on region selection, network conditions, and the broker’s own infrastructure.
- TradingHost does not act as your broker or exchange. Your strategy connects directly.
FAQ
Frequently asked questions
The 99.99% SLA covers TradingHost infrastructure availability for network, data centre and power, subject to the SLA terms and exclusions. It does not guarantee the uptime of user strategy code, broker APIs, exchange APIs, third-party services, credentials, dependencies or in-memory strategy state.
No. The SLA applies to the infrastructure layer. Your strategy can still fail because of code errors, bad configuration, invalid credentials, broker or exchange outages, rate limits, dependency issues, state recovery problems or user activity errors.
Yes. Customer runtimes are isolated from other customer runtimes. A runtime may run one or more strategies depending on deployment configuration, but strategies from different customer accounts do not share the same runtime environment.
No. A VPS gives you a remote server you have to manage. TradingHost runs your trading code on managed cloud infrastructure. You connect a GitHub repo and we handle the rest.
No. TradingHost uses Kubernetes behind the scenes, but you never touch it. You connect GitHub, choose a region, and deploy.
TradingHost surfaces the failure in deployment status and logs. Depending on the runtime configuration and failure type, the strategy process may be restarted automatically or may require user action.
Where supported, TradingHost can restart or reschedule affected runtimes onto healthy infrastructure. Your strategy must still be designed to recover safely after a restart.
Yes. Pick from supported regions during deployment so your runtime sits close to your broker or exchange. See the Regions page for the current list.
No. In-memory state should never be treated as durable. Your strategy should rebuild its view of the world from broker APIs, external databases, or persisted files.
No. TradingHost is managed infrastructure. You operate everything through the dashboard, MCP, and runtime logs.
Deploy your first strategy
Connect GitHub, choose a region, configure your runtime and deploy your first strategy onto TradingHost infrastructure.