Which VPS are you using for algo trading — server location, specs, and cost?

Algos, strategies, code
24

Did you find any noticeable latency when used?

25

I havent measured, its not something that is very noriceable, but there will likely be a small latency…
@quancradle can shed more on this…

1 Like
26

An easy way to evaluate latency is to run a simple test from your system. Open Command Prompt and run:

ping -4 -n 10 api.kite.trade

You’ll see a response like:

Pinging api.kite.trade [104.16.33.50] with 32 bytes of data:
Reply from 104.16.33.50: bytes=32 time=6ms TTL=59
Reply from 104.16.33.50: bytes=32 time=5ms TTL=59
Reply from 104.16.33.50: bytes=32 time=6ms TTL=59
...
Reply from 104.16.33.50: bytes=32 time=5ms TTL=59

Ping statistics for 104.16.33.50:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 5ms, Maximum = 8ms, Average = 6ms

Now repeat the same test with VPN connected. The difference between the two results will give you a clear idea of the added latency.

A few important points:

  • Routing via a proxy typically has slightly lower latency than a VPN.
  • For most retail traders (e.g., with limits <10 orders/sec and 2–3 ticks/sec), this latency difference is negligible in practice.
  • VPN latency can vary depending on:
    • your internet connection quality
    • your physical location
    • background activities like downloads or streaming
  • When routing through our gateway, you may even see a lower latency than your ISP. That is very much possible as it will depend on how close you are to the DigitalOcean/Azure network ingress points.

For accurate results, make sure no heavy network usage is happening on your machine during your test.

If you’d like to evaluate this on your own setup, feel free to reach out—we’re happy to provide a free trial gateway server so you can measure real-world latency from your environment.

27

For NSE algo trading, I would recommend you go for a VPS with an Indian server for it. Don’t choose any other than Mumbai if your broker has its servers in Mumbai. This will be beneficial in terms of speed, as latency matters more than additional cores.

If you are considering that provider with Mumbai VPS, then options like DedicatedCore or DomainRacer are fitting. The Forex VPS is in the Mumbai data center with a static IPv4 that fits well for a broker. Just remember to check with your broker for any specific API/network requirements they have.

28

@VijayNair @quancradle @Matti @saakshi5 Finally what are you using? i am planning to execute alogs

29

Hostinger is good

30

google free trial using last 6 months free

31

I am still with QuanCradle

I found this recently

1 Like
32
  1. Digital Ocean
  2. Linode
  3. Vultr
    Have used Digital Ocean and Linode - But not for trading
33

I am using a Windows VPS for algo trading for mt4 /mt5, and my EAs are running 24/7. I usually choose a VPS location close to my broker to keep latency low. I also look for NVMe storage, a dedicated CPU, and good uptime.

34

I am using Oracle Cloud Free tier account

35

Before the specific VPS, the useful thing is how to decide, because most retail algos need far less than people assume, and over-spending on the server does not make a strategy better.

Location matters, but less than you think. For a strategy acting on 1-minute or slower signals, sitting in the same building as the exchange buys you milliseconds you will never notice. Put the server in an Indian region (Mumbai) so your network path to the broker is short and stable, and stop there. Genuine co-location only earns its cost if microseconds are actually your edge, which for the vast majority of retail strategies they are not.

Specs: reliability over horsepower. A basic 2 vCPU / 4 GB instance runs most single-strategy Python algos comfortably. You are not doing heavy compute in the live loop, you are waiting on the network and reacting. Spend the money you save on making it not fall over.

What actually decides whether it works is not the specs:

  • The process must auto-restart if it dies (systemd, pm2, a supervisor, or a container that restarts).
  • On restart it must reconnect and reconcile against the broker before doing anything, so it never re-sends an order it already placed.
  • Handle the daily token expiry so it does not silently go dead before the open.
  • Log enough that when something breaks at 9:30, you can tell what happened.
  • A kill switch that halts everything past a set loss.

Cost: a small cloud VM in a Mumbai region is a few hundred rupees a month, plenty for a single strategy. AWS, GCP and Azure all have a Mumbai region; a small DigitalOcean or Linode box works just as well. Do not pay for a fancy machine to solve a latency problem you probably do not have.

Short version: small instance in an Indian region, then put your effort into the reliability layer (auto-restart, reconnect-and-reconcile, kill switch). That, not the VPS spec, is what separates an algo that runs for a year from one that quietly breaks on a bad day.

(I build custom trading systems for a living at Trade Vectors, so this is what we deal with daily — purely the engineering, not a view on what to trade.)

1 Like