CPU cores
Most strategies written by retail traders tend to be I/O heavy, and most Python algo scripts are single-threaded. Because of that, throwing a lot of CPUs at the problem is usually overkill. You’ll just end up paying more without getting any real benefit.
Only go for higher CPU counts if you’re running many strategies simultaneously. A reasonable rule of thumb is 1 core for every ~2 strategies, assuming they’re doing some meaningful calculations. If the strategies are lightweight (simple calculations, lots of sleep() calls, etc.), you can easily run 3–4 strategies per core without issues.
RAM
RAM depends entirely on how much data you keep in memory. If your strategies load a lot of historical data for lookback calculations, memory usage per strategy can grow quickly. The easiest approach is to start with a 4GB machine and monitor it. If your memory usage is constantly above ~70%, then upgrade.
I’d strongly suggest not going below 4GB, even if you think you don’t need it. There are a few practical reasons for this, especially when running multiple Python processes.
Server location
For server location, the key factor is where your broker’s API servers are hosted, not the exchange itself. Since you’re communicating with the broker API (not NSE directly), the latency that matters most is between your VPS and the broker servers. So if your broker hosts their APIs in Bangalore, it makes sense to run your VPS there too.
Providers
Now when it comes to providers, this is where people often underestimate the impact.
There are plenty of cheap VPS providers out there. Personally, I’d avoid them if you’re planning to run serious trading systems. The difference in reliability, networking stability, and security between providers like AWS, Azure, or GCP vs ultra-cheap hosts is significant.
A lot of traders go for something like a $6–$20 DigitalOcean server. While those can work for basic setups, they typically run on shared CPU cores. That means multiple VMs share the same physical hardware. If one of the neighboring VMs suddenly runs a heavy workload, your VM performance can dip unexpectedly.
This is one of those things people don’t notice immediately, but it can show up as random latency, delayed execution, or strategies missing trades.
If you’re running only a couple of simple strategies and not doing heavy computations every second, those cheaper options can still work. It’s just a tradeoff decision.
A similar concept exists with burstable VMs on AWS/Azure/GCP. These are the cheapest instances because they run on a CPU baseline model. For example, you might get a baseline of ~20% CPU performance unless you’ve accumulated CPU credits.
The upside is that if your VM runs 24/7, it will accumulate credits during idle hours, and during market hours your CPU can run at full capacity. So these can actually be a pretty good fit for trading workloads.
That said, the best overall option is usually general-purpose instances with dedicated vCPUs (no bursting). They’re reasonably priced and give consistent performance. Once you get into 4 cores or higher, the pricing across AWS, Azure, GCP and DigitalOcean is surprisingly similar.
You can also reduce costs by stopping or deleting the VM when markets are closed, while keeping the OS disk and public IP reserved, so you don’t have to rebuild your environment each time.
Security
Another thing that many people underestimate is security.
If your VPS is running 24/7 with a public IP, it will constantly get scanned by bots looking for weak servers. It’s honestly only a matter of time before someone tries to break in.
And if your server gets compromised, the first things attackers will usually find are broker API keys, access tokens, and credentials sitting in config files or environment variables. Once those are exposed, someone could place orders on your account. At that point you’re not just dealing with a server issue — you could be losing actual trading capital.
So basic server hygiene is extremely important:
- Use SSH keys instead of password logins
- Disable root login over SSH
- Configure proper firewall rules
- Protect against SSH brute-force attacks (fail2ban or similar)
- Ensure correct file permissions for configs containing API keys
- Avoid randomly installing unverified packages or trading tools
- Keep your OS and dependencies patched
Most algo traders focus heavily on strategy logic but ignore infrastructure security. But once your trading stack lives on an always-online machine, infrastructure security becomes part of your trading risk management.
Windows VM
One more thing worth mentioning — if you’re planning to run a Windows VM, your CPU and RAM requirements will increase noticeably compared to a Linux server. Windows itself consumes a decent amount of resources even when idle, so you’ll end up needing a larger machine just to keep things running smoothly.
It also introduces additional security considerations. RDP (Remote Desktop Protocol) is one of the most heavily targeted services on the internet. There are automated bots constantly scanning public IP ranges looking for exposed RDP ports and weak credentials.
It’s not that Windows is inherently weaker than Linux — it’s just a much bigger target surface. Attackers focus on it more because there are simply more poorly configured Windows servers out there, and historically they’ve been easier to exploit in many environments.
With Windows setups, the probability of misconfiguration is generally higher, especially for traders who are primarily focused on strategy development rather than server administration. On top of that, many Windows-based tools and trading utilities tend to install additional services and dependencies, which can introduce more potential vulnerabilities over time.
If you’re comfortable with it, Linux VMs are usually the better choice for algo setups. They’re lighter on resources, easier to lock down from a security standpoint, and you also save on Windows licensing costs while reducing your overall attack surface.
Public IP
Yes, brokers generally accept VPS public IPs. By default, every VPS comes with a public IP. The only caveat is that if you delete the VM and recreate it, you’ll likely get a new IP. That’s why they call it dynamic.
However, if your VM stays up continuously, the IP usually remains the same even across reboots, so you can register that with your broker without any issues.
If you plan to delete/recreate VMs frequently, then it makes sense to explicitly reserve a static IP. Most cloud providers offer this as an add-on. In DO, it is free as long as it is attached to the VM. In Azure/AWS/GCP, there is an additional cost.
Trading from multiple locations
One situation where things get tricky is if you want to trade from both your local machine and a VPS. In that case, brokers will usually require both IPs to be registered — your home static IP and your VPS IP.
A simpler approach is to use a gateway setup.
This is exactly the problem we built the Quancradle Trading Gateway to solve. It provides:
- a security hardened, fully managed, dedicated VM with a fixed IP,
- a VPN service optimized for low latency, high performance,
- and a secure forward proxy for order routing
With this setup, your orders can originate from anywhere — your laptop, a VPS, multiple VPS instances, or even backup machines — but all your traffic exits through the same gateway IP.
So from the broker’s perspective, everything appears to come from a single registered IP.
It makes life much simpler if you’re running hybrid setups (local + cloud) or if you frequently spin up new VPS machines.
Another practical benefit is that you don’t have to pay for static IPs on both your home ISP and your cloud VPS. Even if you trade from both locations, all order traffic goes through the gateway, so the broker only sees one fixed IP.