What programming languages does TradingHost support?

TradingHost is designed to be language-agnostic. Users can deploy trading projects written in Python, JavaScript, TypeScript, Rust, Go, C#, Java, C++, or other languages, provided the project can be packaged, configured and run inside a supported containerised runtime.

Is TradingHost only for Python strategies?

No. Python is an important language for trading research, backtesting and automation, but TradingHost is not limited to Python. TradingHost is designed to run trading systems in any suitable programming language, provided the project can be deployed and run inside the TradingHost runtime model.

Can I deploy a compiled trading binary?

Yes, where supported by the runtime configuration. A compiled trading service, execution worker or custom binary can fit the TradingHost model if it can be packaged, configured and started inside the runtime.

What runs inside a TradingHost runtime?

A TradingHost runtime runs your trading project inside a managed container. Inside that container, TradingHost runs a strategy runner that starts and controls the configured strategy processes. Your code, dependencies and runtime configuration are brought together inside the runtime so your strategies can run continuously.

Can one TradingHost runtime run multiple strategies?

Yes. A TradingHost runtime is designed to support multiple strategies inside the same container, where the project structure and plan allow it. Each strategy can be managed as an individual process by the TradingHost runner.

Can different strategies use different languages?

Where the project structure and runtime configuration support it, yes. For example, a runtime may include multiple strategy processes or services, each started according to its own runtime command. The practical support depends on how the project is packaged, configured and deployed.

If I update one strategy, do the others keep running?

Where supported, yes. If you push a GitHub update that affects one strategy, TradingHost can target that strategy process without necessarily restarting every other strategy in the same runtime. This means one strategy can be updated, restarted or recovered while other strategies continue running where possible.

Does TradingHost restart the whole container when one strategy restarts?

Not necessarily. TradingHost is designed so the strategy runner inside the container can restart an individual strategy process directly. That means the affected strategy can often be restarted without restarting the whole container.

Why is that better than restarting the container?

Restarting the whole container interrupts everything inside it. Restarting a strategy process targets only the affected strategy. For multi-strategy traders, this can reduce disruption, speed up recovery, and make live iteration cleaner.

Is TradingHost the same as a VPS?

No. A VPS gives you a remote machine to manage. TradingHost gives you a trading-specific runtime for deploying, controlling and observing strategy processes from GitHub. You do not need to manually manage desktop sessions, process restarts, scattered log files, credentials stored in local files, or ad hoc deployment steps.

Does TradingHost store my broker or exchange API keys?

TradingHost does not need custody of your broker or exchange API keys. Sensitive credentials should live in your GitHub-controlled secret workflow, such as GitHub repository secrets, GitHub environment secrets, or your own approved secret management process.

Where should API keys and secrets live?

API keys and sensitive values should live in your GitHub-controlled workflow. Your strategy should read the values it needs at runtime according to the deployment configuration you choose. TradingHost provides the runtime layer around the strategy process, not custody of your broker or exchange credentials.

Does TradingHost write or provide the strategy?

No. TradingHost provides the runtime and deployment layer. You bring your own strategy logic, or start from a project template that provides structure and configuration examples.

Is TradingHost a broker or exchange?

No. TradingHost is not a broker or exchange. Your strategy code connects directly to broker or exchange APIs using the credentials, libraries, language and execution method you choose.

Does TradingHost connect directly to my Binance account?

Your strategy code connects to Binance using the API method you choose. TradingHost does not act as the broker or exchange. It provides the runtime, logs and deployment workflow around your code.

Does TradingHost need withdrawal permissions?

No. Trading strategies should not require withdrawal permissions. TradingHost does not require withdrawal access to your exchange account. You should only grant the minimum permissions your strategy needs.

Can I run CCXT inside a TradingHost runtime?

Yes, CCXT-based projects are a natural fit for TradingHost runtimes. Your strategy can use CCXT to connect to supported crypto exchanges, while TradingHost provides the runtime, logs and deployment lifecycle around the project. For more detail, see /frameworks/ccxt/.

Can I run Freqtrade inside a TradingHost runtime?

TradingHost is designed to support framework-based trading projects such as Freqtrade, where the project structure and runtime configuration allow it. For more detail, see /frameworks/freqtrade/.

Can I run a custom Rust, Go or C++ trading system?

Yes, where supported by the runtime configuration. TradingHost is language-agnostic. A custom Rust, Go, C++ or other compiled trading system can run inside a TradingHost runtime if it can be packaged, configured and started as a supported runtime process.

Can my strategy expose a dashboard or API?

Yes, where supported by runtime configuration. If your project exposes a local dashboard, API, webhook listener or metrics endpoint, TradingHost can assign external access and map it to the internal port used by your application. For more detail on the runtime networking surface, see /platform/runtime/.

Can I deploy from Cursor or Claude Code?

TradingHost is being designed for MCP-compatible AI development workflows. That means supported AI IDEs and agents may be able to inspect deployments, review logs, trigger redeployments, restart strategies and manage runtime workflows through TradingHost tools. For more detail, see /platform/mcp/.

What happens if one strategy crashes?

TradingHost can detect that the strategy process has stopped and expose the relevant logs and health information. Where supported, the runtime runner can restart the affected strategy process without restarting the entire container. Other strategies inside the same runtime can continue running where possible. You are still responsible for writing safe strategy logic, handling errors properly, avoiding duplicate order behaviour, and building appropriate risk controls into your trading system.

What happens if the whole container fails?

If the underlying container fails, the runtime may need to be restarted at container level. The strategy-level runner is designed to reduce unnecessary container restarts, but it does not eliminate every possible runtime failure scenario.

Does TradingHost guarantee trading performance?

No. TradingHost provides the runtime and deployment layer. It does not guarantee strategy profitability, execution quality, broker uptime, exchange uptime, fills, latency, or trading performance.

Read time … min

Cloud Runtime for Automated Trading Strategies

Deploy trading projects from GitHub into always-on TradingHost runtimes built for broker and exchange-connected strategies.

Deploy →

Key runtime benefits

GitHub-native deployment
Language-agnostic runtime
Multi-strategy, strategy-level control
No TradingHost custody of broker keys
MCP-ready for AI workflows

Section 01 · Definition

What is a TradingHost runtime?

A TradingHost runtime is the cloud environment where your automated trading systems run. Instead of code on a laptop, a home server, a generic VPS or a permanently open desktop terminal, you deploy your trading project from GitHub into a TradingHost-managed runtime.

The runtime brings together the container, the strategy runner, runtime configuration, logs, health signals, region selection and lifecycle controls, so your strategy code has a controlled, observable place to run on managed Kubernetes-orchestrated container infrastructure with a 99.99% infrastructure SLA covering network, data centre and power.

Runtime definition

A TradingHost runtime is a managed cloud environment for running automated trading strategies from GitHub. It provides the container, process runner, runtime configuration, logs, region selection and lifecycle controls around user-owned trading code.

Section 02 · Language-agnostic by design

Bring your own language, framework and trading stack

TradingHost runs the project, not the language. If your trading system can be packaged, configured and run as a long-running process inside a container, it can run on TradingHost.

Different traders use different stacks for different reasons. Python for research, TypeScript for web-connected workflows, Rust and C++ where performance matters, C# and Java in parts of the broker ecosystem.

Language-agnostic definition

TradingHost is a language-agnostic runtime for automated trading systems. Users can deploy trading projects written in any language that can be packaged and run inside a supported containerised runtime.

Example runtime languages

And any other language that runs in a container.

For framework-specific pages, see Frameworks

Section 03 · Multi-strategy + strategy-level control

Run multiple strategies, control them individually

A TradingHost runtime is a container that wraps a managed strategy runner. The runner launches and supervises one or more strategy processes, and can act on any one of them without restarting the rest.

That distinction matters for live trading. A container-level restart is blunt: every strategy inside the container is interrupted. A strategy-level restart is precise.

Runtime container

TradingHost runner

Strategy A

Live

Strategy B

Live

Strategy C

Live

Multi-strategy definition

A TradingHost runtime can run multiple strategy processes inside one managed container. The runner controls each strategy individually, so restart, stop, inspect and update can target one strategy without disrupting the others.

Section 04 · From GitHub repo to live runtime

How runtime deployment works

TradingHost is built around a GitHub-native deployment model.

You connect your GitHub account, select a repo, choose the strategy or strategies you want to run, configure the runtime, select a region, and deploy into a managed TradingHost runtime.

STEP 01
Connect GitHub
Sign in with GitHub and choose an existing repo, or create a new repo from a TradingHost project template. Your repo can contain one strategy or multiple strategy definitions in the language you choose.
STEP 02
Define how the project runs
TradingHost needs to know how your project should be built and started. This may be a runtime configuration file, project template, Dockerfile, package script, compiled binary, framework command or supported deployment convention.
STEP 03
Select your strategy or strategies
Choose the strategy, project entry point, or configured strategy group you want TradingHost to run. For multi-strategy projects, the runtime runner manages each strategy individually.
STEP 04
Configure environment and secrets
Wire up the environment values your project needs. API keys live in your own secret store. See the secrets section below.
STEP 05
Choose a region
Select the runtime location that best matches your broker, exchange, market data provider, or latency requirement.
STEP 06
Deploy
TradingHost starts your project inside a managed container and launches the configured strategy processes through the TradingHost runner. Logs, health and runtime state are streamed back to your dashboard.
STEP 07
Iterate
Push changes to GitHub, redeploy the affected strategy, inspect logs, update runtime configuration and restart individual strategies. Where supported, one strategy can be updated without unnecessarily disrupting the others.

Section 05 · Secrets and credentials

You hold the keys. TradingHost runs the code.

TradingHost does not custody broker or exchange API keys. Keeping credentials in your own secret store narrows the blast radius if any single system is compromised, keeps the audit trail under your control, and means revoking access never has to involve us.

Use any secret store you already trust. Your strategy reads the values it needs at runtime through that workflow; TradingHost provides the runtime environment around the strategy, not the secret store itself.

Compatible secret stores

GitHub Actions secrets: Repository secrets, environment secrets and organisation secrets, surfaced to your strategy through the GitHub-driven deploy.
HashiCorp Vault: Self-hosted or HCP-managed secrets engine with policy-scoped access.
AWS Secrets Manager: Managed secret store with rotation, IAM policies and audit logging.
Doppler: Dev-friendly secrets manager with environment overlays and CI integrations.
1Password Secrets Automation: Vault-backed secret delivery for CI and runtime workloads.
Infisical: Open-source secrets management with end-to-end encryption.
Bitwarden Secrets Manager: Vault-style secret delivery from the Bitwarden ecosystem.

For setup guides per provider, see Secrets

Section 06 · Runtime vs VPS

Runtime instead of traditional VPS management

A VPS gives you a remote machine to manage. TradingHost gives you a managed runtime for deploying, controlling and observing trading strategies from GitHub. The runner, dashboard, secrets boundary and lifecycle controls are already wired up.

Traditional VPS

Remote desktop or SSH access
Manual setup, dependencies, restarts
One strategy update can disrupt others
Credentials often stored in local files
Logs scattered across the machine
Hard to standardise across strategies

TradingHost runtime

GitHub-based deployment
Containerised, language-agnostic runtime
Strategy-level start, stop, restart
Update one strategy without restarting the rest
Secrets stay in your own secret store
Logs and health visible in the dashboard

Section 07 · Honesty

What the runtime does not do

TradingHost provides the runtime layer. The strategy, broker connection, and trading decisions remain yours.

TradingHost does not act as your broker or exchange.
TradingHost does not provide trading strategies or financial advice.
TradingHost does not require withdrawal permissions from your exchange account.
TradingHost does not custody your broker or exchange API keys.
TradingHost does not guarantee strategy performance, broker uptime, or market connectivity. Risk management, testing, and monitoring remain the user’s responsibility.

Deploy your first runtime

Connect GitHub, pick a region, and run your strategy in an always-on TradingHost runtime.

Deploy

Cloud Runtime for Automated Trading Strategies

What is a TradingHost runtime?

Bring your own language, framework and trading stack

Run multiple strategies, control them individually

How runtime deployment works

Connect GitHub

Define how the project runs

Select your strategy or strategies

Configure environment and secrets

Choose a region

Deploy

Iterate

You hold the keys. TradingHost runs the code.

Runtime instead of traditional VPS management

Traditional VPS

TradingHost runtime

What the runtime does not do

Where to go next

Deploy your first runtime