The usual advice on this is a list of providers with their specifications, which answers a question nobody actually has. A retail trading bot uses almost no computing power, so the specification is rarely the deciding factor.
What decides it is whether you can get a static IP, where the machine sits, and whether you can keep it running without becoming a system administrator.
The static IP is the requirement, not a feature
Start here because it eliminates options.
Indian brokers require you to register the IP address your API orders originate from. That is part of how automated order flow is tracked, and an order arriving from an unregistered address is refused.
Which means your server needs an IP address that does not change. Most cloud instances get one by default; some shared hosting and some free tiers do not, and a few providers charge separately for it or reassign it when the instance restarts.
Check three things before paying for anything: does the instance get a dedicated IPv4 address, does that address survive a reboot, and does it survive the instance being stopped and started. The third catches people, because some providers release the address when an instance is stopped to save money.
Anything that fails those checks is unusable for this regardless of how good the rest of it looks.
You need far less machine than you think
A retail trading bot subscribing to a few dozen instruments and evaluating rules on candle closes is not a demanding workload. It spends almost all of its time waiting.
The smallest instance most providers sell — one shared CPU and a gigabyte of memory — runs this comfortably. Two gigabytes gives room to store data and run something alongside it, and is the sensible default rather than an upgrade.
Where you would genuinely need more: storing raw tick data across a large instrument list, running heavy backtests on the same machine, or running many strategies at once. The first two are better done on your own computer anyway, where the resources are free.
Spending on a large instance for a trading bot is the most common waste in this whole setup, and it is usually recommended by people who have not measured what the bot actually consumes.
Where to host, and how much latency really matters
Choose a region in India — Mumbai for most providers, since that is where the exchanges and most infrastructure sit. Not because milliseconds decide your strategy, but because a server in Singapore or Europe adds a round trip to every request for no benefit, and because a nearer machine means fewer timeouts to handle.
Be clear about latency though, because it is oversold. Retail systems making decisions on one-minute or five-minute candles are not competing on speed with anybody. The difference between fifteen milliseconds and eighty is irrelevant to that. Genuine low-latency trading involves co-location at the exchange and is not a retail activity in any practical sense.
What actually matters more than latency: uptime, whether the provider's network is reliable during Indian market hours, and how quickly you can restore the machine if something goes wrong.
What a realistic setup costs
For a small instance in an Indian region with a static IP, expect somewhere between five hundred and fifteen hundred rupees a month depending on the provider and the specification. Add your broker's API subscription on top, which is billed separately and is often the larger number.
Two costs people forget. Backups, if you want them, are usually a small percentage on top and are worth taking. And bandwidth, which is generous on most plans and only becomes relevant if you are downloading large amounts of historical data repeatedly — which you should not be, because you should be caching it locally.
Worth putting this next to the arithmetic that decides whether automation makes sense at all: fixed costs of roughly eighteen thousand a year mean a fifty thousand rupee account needs a thirty-six percent return simply to break even. The VPS is a real reason small accounts should not automate yet.
The setup that actually keeps it running
Provisioning the machine is the easy part. Keeping the program alive is where people lose mornings.
Use a process manager rather than a terminal session. Running your bot with nohup and closing the laptop works until the process dies at 11:40 and nothing restarts it. systemd handles start-on-boot, restart-on-crash and logging, and is worth the hour it takes to learn.
Start it on a schedule, not at boot. Your program should begin shortly before the market opens, refresh the daily access token, and stop after the close. A bot running twenty-four hours a day is a bot that can misbehave at three in the morning.
Log to a file, and read it. A system nobody reviews is an open position rather than a strategy.
Get an alert when it dies. A message to your phone when the process exits unexpectedly is a few lines of code and the difference between noticing at 9:20 and noticing at 15:20.
Set the timezone. Cloud instances default to UTC. A schedule that fires at 09:15 UTC starts your bot at 14:45 IST, which is a mistake people make exactly once.
Choosing between providers
Any mainstream provider with an Indian region and a static IP will do this job, and the differences matter less than the setup above. The distinctions worth weighing:
Simple flat-rate providers — the ones selling a fixed instance for a fixed monthly price — are the easiest to reason about. You know the bill in advance and there is no metering to understand.
The large clouds offer more services than you will use and bill in a way that requires attention. Their free tiers are attractive and frequently do not include a persistent static IP, which brings you back to the first section.
Indian providers can be cost-effective and are worth checking for support responsiveness and for whether the IP behaves as required.
Do not choose on price alone at this scale, because the difference between the cheapest and the sensible option is a few hundred rupees a month against a setup that is handling your money.
The account your bot places orders through is the other half of this, and it is where the IP gets registered.
The static IP is registered with your broker
API order flow from an unregistered address is refused. Account free to open
Server setup, process supervision, scheduling and the static IP registration are a full section of our Algorithmic Trading with Python course at Rs 24,900 — one payment, permanent access, free demo on WhatsApp first.
We sell no tips and no signal group, we manage nobody's money, and we promise no returns. Trading carries a real risk of loss.
Disclosure: the account-opening link on this page is under Atul Shrivastava's Zerodha Authorised Person registration (NSE AP Reg: AP2516003481; Zerodha Broking Ltd. SEBI Reg: INZ000031633) and earns a revenue share. TheFinBaba is not a SEBI-registered Investment Adviser — this content is educational, not investment advice.
Frequently Asked Questions
Do I need a static IP for algo trading in India?
Yes. Brokers require you to register the IP your API orders come from, and orders from an unregistered address are refused. Check that the address survives both a reboot and the instance being stopped and started.
What VPS specification do I need for a trading bot?
Far less than most advice suggests. One shared CPU with one to two gigabytes of memory runs a retail bot comfortably, because it spends nearly all its time waiting. Heavy backtesting and raw tick storage are better done on your own computer.
Does VPS latency matter for retail algo trading?
Very little. Systems deciding on one-minute or five-minute candles are not competing on speed. Choose an Indian region to avoid a pointless round trip, then stop thinking about it - genuine low-latency trading means co-location and is not a retail activity.
How much does a VPS for algo trading cost?
Roughly five hundred to fifteen hundred rupees a month for a small instance in an Indian region with a static IP, plus your broker's API subscription billed separately. Those fixed costs are the reason small accounts should not automate yet.
How do I keep my trading bot running on a VPS?
Use a process manager such as systemd for start-on-boot and restart-on-crash rather than a terminal session, start it on a schedule shortly before the open, log to a file you actually read, alert yourself when it exits, and set the machine timezone to IST.
Related Reading
- Running a trading bot 24x7
- Automating the daily broker login
- How much capital do you need for algo trading?
- Static IP for trading - why it is required
- Algorithmic Trading with Python - full syllabus
Disclaimer: TheFinBaba provides educational content only - this is not investment advice. Trading involves risk of loss.
