WeCore
Automation

Running Trading Strategies on Your Own Cloud Server

Why traders run automated strategies on their own VPS: uptime, latency, control and privacy, how to choose region and size, security basics, monitoring and provider costs.

WeCore·Published ·5 min read

An automated strategy is only as good as the computer running it. A home PC that shuts down, updates in the middle of a trading day or loses its internet connection can leave a position open with nobody watching. That is why many traders move their trading engine to a cloud server, a VPS, in their own account. This article covers why, how to choose, and how to keep the server secure and monitored.

What a VPS is and why traders care

A VPS, or virtual private server, is a virtual computer running in a cloud provider's data center. You get CPU, memory, storage and a network connection, and you pay the provider for usage, usually monthly or hourly. The server runs all the time, sits on a fast and stable network, and does not depend on power or internet at home.

The main reasons to use one:

  • Uptime: the server does not turn off when you close your laptop, and it does not run surprise system updates mid-session if you manage them properly.
  • Latency: a server in a region close to the exchange or broker servers shortens the time it takes for an order to arrive.
  • Control: the server is in your account. You choose the region, the size and when to shut it down.
  • Privacy and separation: your strategy and data run in a separate environment, not on a machine also used for browsing, games and work.

Latency: how much it really matters

Most retail traders do not need millisecond speed. But the difference between a home PC on unstable Wi-Fi and a server in a professional data center can be significant, especially during high volatility. Every delay in the chain, from receiving the signal to sending the order, is time in which the price can move. The link between time and fill price is explained in the article on slippage and execution costs.

CME Group's markets are based mainly in the Chicago area, and broker and platform servers are usually in the United States. So a region in the central or eastern United States is often a reasonable choice. Still, check where your broker's or platform's servers are, because that is what decides it.

Choosing region and size

When you create a server with a cloud provider, there are two main decisions:

  1. Region: pick the data center closest to the execution servers. If you are not sure, ask the support team of the platform you use what they recommend.
  2. Size: the amount of CPU and memory. An engine running one strategy on a few symbols does not need a huge server. Start modest, watch utilization, and scale up only if needed. A server that is too small and hits 100% CPU will cause delays; one that is too big just costs more.

It is also wise to pick an operating system version with long-term support, and to leave free disk space for logs.

Security basics

A server connected to a trading account is a target. The basic rules:

  • Updates: install security updates regularly, but schedule them outside your trading hours.
  • SSH keys instead of passwords: logging in with a cryptographic key is far safer than a password. Disable password login if you can.
  • Least privilege: every service runs with the permissions it needs and no more. Do not run everything as the administrator user.
  • Firewall: open only the ports you need. Everything else stays closed.
  • Secrets: broker credentials and keys are not kept in plain files or screenshots, and are not sent in chats.
  • Backups: keep a backup of your configuration so you can rebuild a server quickly.

Some platforms connect your cloud account by having you authorize on the provider's own website, without handing over a password or token. This is the better approach, because you can revoke the authorization at any time from your provider account.

Monitoring: knowing before it hurts

The server runs on its own, which is exactly why you need to know what is happening on it. Things worth monitoring:

  • Is the engine running: a periodic check that the process is alive and connected to the broker.
  • Resources: CPU, memory and disk usage. A full disk is a common cause of crashes.
  • Broker connection: repeated disconnections are a sign of trouble.
  • Positions: reconciliation between what the engine thinks is open and what is actually open in the account.
  • Alerts: get notified when something unusual happens, not only when you happen to look.

Most important of all: have a plan for when something goes wrong. How to close positions manually, how to stop the engine, and who to contact. These principles are part of any algorithmic trading setup.

Costs

The server lives in your account with the cloud provider, so the bill comes from the provider directly. Cost depends on server size, region and traffic. A few points:

  • Check the provider's current pricing before choosing a size.
  • A running server keeps billing even when you are not trading; if you stop using it, delete it from your provider account.
  • Backups and snapshots may be billed separately.
  • Set a budget alert in your provider account to avoid surprises.

Setup checklist

  • Did you pick a region close to the execution servers?
  • Does the size fit the load, with headroom?
  • SSH key login only, and an active firewall?
  • Updates scheduled outside trading hours?
  • Monitoring and alerts active?
  • An emergency plan for manual flattening?
  • A budget alert set with the provider?

Key takeaways

  • A cloud server offers uptime, lower latency, control and separation compared with a home PC.
  • Choose a region close to execution servers and a moderate size, scaling as needed.
  • Basic security: updates, SSH keys, least privilege, firewall.
  • Monitoring and an emergency plan are part of the system, not an add-on.
  • The cost is paid to the cloud provider; a running server keeps billing.

WeCore can run your trading engine on a cloud server in your own DigitalOcean or Linode account, connected by authorizing on the provider's site, with the server billed by the provider. Details are in the guide to running WeCore on your own server.

Sources and further reading