Read time … min

TradingHost or a VPS for algorithmic trading?

A VPS gives you a remote machine. TradingHost gives you a deployment runtime for trading strategies. This page covers when to pick each.

VPS hosting has been the default for retail and small institutional algorithmic trading for over a decade. TradingHost is a purpose-built runtime layer that replaces the parts of VPS management that aren’t trading-specific.

Section 01 · At a glance

At a glance

AspectVPSTradingHost
Server provisioningYou pick a region, OS, RAM and disk; TH starts there.Pick a region; resources are managed by the platform.
Deployment workflowSSH, file copy, manual restart.GitHub-native; push to deploy.
Process supervisionsystemd, PM2, screen, tmux, or your own scripts.Strategy runner manages each process individually.
Logs and observabilityTail files; you build the pipeline.Streamed live in dashboard; readable through MCP.
Health checksRoll your own or wire a third-party uptime monitor.Built into the runtime.
Region selectionProvider-specific list; no broker proximity guidance.Proximity-tuned for trading venues.
Resource controlsFull machine; you size and pay for the whole VPS.Per-runtime; scale resources independently.
RestartsManual or scripted; container-level if you containerise.Strategy-level: restart one without disrupting others.
Secrets handlingFiles on disk; .env files; you decide.GitHub-controlled secret workflow; never copies to disk.
AI workflow supportNo native MCP; depends on what you install.Native MCP for Cursor, Claude Code, CLI agents.

Section 02 · The structural difference

A VPS is a machine. TradingHost is a runtime.

A VPS gives you root on a remote Linux box. Everything else, the operating system, the process supervisor, the deployment pipeline, the log rotation, the secrets, the monitoring, is yours to assemble.

TradingHost gives you a deployment runtime designed for long-running trading workloads. You connect a GitHub repo, pick a region close to your venue, and deploy. The runtime supervises your strategy processes, exposes logs and health, and gives you strategy-level controls without container-wide disruption.

The difference shows up most clearly when you list what you manage on each side.

What a VPS gives you

  • Remote machine to manage
  • Operating system updates
  • Dependency installation and versioning
  • Process supervision (systemd, PM2, screen)
  • Manual or scripted restarts
  • Log file rotation and retention
  • Deployment discipline (manual or CI)
  • Process and host monitoring
  • Credential storage on disk
  • Network and firewall configuration

What TradingHost gives you

  • GitHub-native deployments
  • Streamed runtime logs
  • Built-in health checks
  • Repeatable releases
  • Region selection tuned to trading venues
  • Per-runtime resource controls
  • Strategy-level restarts and updates
  • GitHub-controlled secret workflow
  • Native MCP for AI IDE workflows
  • Cleaner separation: code, runtime, deployment

Section 03 · Where each makes sense

The honest answer is, it depends

A VPS isn’t wrong; it’s just generic. TradingHost is the right answer when your workload is trading-specific and you want the runtime layer to know that.

A VPS still makes sense

Pick a VPS when you need a generic Linux box.

  • You need full OS-level control or a non-containerised stack.
  • Your workload isn’t trading and doesn’t need trading-specific tuning.
  • You have existing automation invested in raw VM management.
  • You depend on Windows-only software (e.g. classic MetaTrader 4 builds tied to a desktop session).
  • You’re running short-lived experiments where region proximity to a venue doesn’t matter.

TradingHost makes sense

Pick TradingHost when you want a runtime tuned for trading.

  • You want GitHub-driven deployments, not SSH and file copies.
  • You need region proximity to specific exchanges or brokers.
  • You’re running multi-strategy projects where strategy-level restart matters.
  • You want streamed logs, health checks and observability without building the pipeline.
  • Your strategy code is or can be containerised.
  • You’re using AI IDEs (Cursor, Claude Code, Copilot) and want native MCP integration.

Section 04 · Migration path

How to move off a VPS

For most strategies the migration is a one-afternoon job. Multi-strategy stacks and MetaTrader-flavoured setups need slightly more care, but the path is the same.

  1. STEP 01

    Audit your existing VPS strategy stack

    List every strategy, supervised process, log path, secret file, cron job and external dependency on the VPS. This is the inventory you’ll port across.

  2. STEP 02

    Move secrets to a GitHub-controlled workflow

    Lift API keys, broker credentials and config out of files on disk. GitHub repository secrets or environment secrets become the source of truth that TradingHost reads at runtime.

  3. STEP 03

    Pick a TradingHost framework runtime, or bring your own

    CCXT, Freqtrade and Hummingbot have ready-to-deploy framework runtimes. For custom strategies, your repo connects directly. The runtime model handles the build.

  4. STEP 04

    Deploy and run side-by-side

    Run the same strategy on the VPS and on TradingHost in parallel. Compare logs, fills, latency and behaviour for a sanity period. Trading-critical migrations should never cut over blind.

  5. STEP 05

    Cut over and decommission

    Once the TradingHost deployment matches expected behaviour, point production traffic to it and shut down the VPS. The runtime takes over restart, log retention, monitoring and region selection.

Deploy →

Section 06 · FAQ

FAQ

A VPS is a generic Linux machine you manage yourself. TradingHost is a deployment runtime designed for trading workloads, with GitHub-native deployments, region selection, runtime logs, health checks, secret handling and strategy-level controls built in.

Yes. Many traders run TradingHost in parallel during migration; some keep niche workloads (Windows-only software, non-containerised stacks) on a VPS indefinitely while moving the rest to TradingHost.

TradingHost runs Linux containers. Classic MetaTrader builds tied to a Windows desktop session aren’t a fit. MT5 strategies that run as headless services (or talk to MT5 over a bridge) can run on TradingHost; the typical migration is to move the strategy logic to a containerised process and keep the MT bridge on a venue-side host where appropriate.

TradingHost runtimes are priced per runtime, not per VM. For most single-strategy or small multi-strategy setups, a TradingHost runtime is comparable to or cheaper than a small VPS, with the runtime layer included. See pricing for current plans.

For a single containerised strategy, an afternoon. For multi-strategy stacks with bespoke supervisor scripts and on-disk secrets, a couple of days of careful work plus a side-by-side validation period.

No. TradingHost builds your container from the repo on managed Kubernetes infrastructure. You commit code (and a Dockerfile if your project needs custom build steps) to GitHub; the build runs server-side.

TradingHost regions are tuned for trading-venue proximity (EU for FX/CFD broker connectivity, US-East for North-American exchanges). See regions for the current list and broker-proximity guidance.

Yes. TradingHost has native MCP support so AI IDEs (Cursor, Claude Code, GitHub Copilot, CLI agents) can inspect deployments, review logs and manage runtimes directly. On a VPS, AI tooling depends on whatever you install and configure yourself. See MCP support for the full picture.