Your strategy is coded, it backtests well, and it places orders correctly. Then Windows restarts for an update at 11 a.m. and your position sits open with no stop-loss watching it.
Everything about how to run a trading bot 24x7 comes down to one shift: moving execution off the machine you use for everything else, and onto something whose only job is to stay running. Here is what that actually involves in India.
Why a laptop always loses eventually
It is not that a laptop cannot run Python. It is that a laptop is a general-purpose machine with priorities other than your trade:
- Sleep and hibernation stop your script mid-session, often silently.
- OS updates reboot without asking, usually at the worst possible time.
- Home broadband drops for a few seconds. A WebSocket that is not handling reconnects will simply stop receiving data while your code keeps running happily.
- A changing IP address is a problem in itself, which the next section covers.
None of these are frequent. All of them are certain over enough months, and each one lands while a position is open.
The static IP requirement
Under SEBI's algo trading framework, orders routed through a broker API are expected to come from a static IP registered with the broker, so that automated order flow is traceable to an identified source.
Home broadband almost always gives you a dynamic IP that changes periodically — which is precisely the situation registration is designed to prevent. This is the practical reason nearly every serious retail algo setup in India runs on a small cloud server rather than a home machine: it comes with a fixed IP you can register.
The registration itself is done through your broker. The process differs between brokers and changes from time to time, so check their current documentation rather than following a blog post from two years ago. The details are covered in the static IP guide.
How much server do you actually need
Much less than people expect. A Python strategy tracking a handful of instruments is not computationally heavy — it spends most of its time waiting for ticks.
The smallest tier at most providers is usually enough to begin with: roughly 1 vCPU and 1 GB of RAM, which lands around a few hundred rupees a month. What matters more than raw specs:
- Location. A data centre in or near India keeps latency to the exchange low. A cheap server in another continent adds delay to every order.
- A fixed public IP you can register with your broker.
- Predictable uptime rather than the cheapest possible price.
Latency matters far less than beginners assume unless you are doing genuinely high-frequency work. For most retail strategies, being in the right country is enough; being in the same building as the exchange is not the constraint on your returns.
Making it survive a reboot
Getting the bot running once is easy. Getting it to come back on its own is the part people skip.
On a Linux server the standard answer is a service definition that starts your script at boot and restarts it if it crashes. Something along these lines:
[Unit]
Description=Trading bot
After=network-online.target
[Service]
Type=simple
User=trader
WorkingDirectory=/home/trader/bot
ExecStart=/usr/bin/python3 /home/trader/bot/main.py
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.targetTwo habits worth building alongside it. Log everything — every signal, every order sent, and every response received, with timestamps. When something goes wrong at 9:20 a.m., the difference between a two-minute fix and a lost session is whether you can see what happened. And keep a kill switch: one command that stops all activity immediately, tested before you need it.
Monitoring: know before your broker tells you
A bot that has silently stopped looks exactly like a bot with no trading signals. You need something that distinguishes the two.
The simplest version that works: have your script send a short message — Telegram or WhatsApp — when it starts each morning, when it places or exits a position, and if it hits an exception. If the morning message does not arrive by 9:10, you know before the market opens rather than at 3:30.
Also worth checking daily: that your access token is valid before the session begins, and that the wallet or subscription your API depends on has not lapsed. Both are silent failure modes that only announce themselves when an order is rejected.
The order this actually happens in
Deployment is the last step, not the first. The sequence that avoids expensive lessons:
- Backtest the strategy honestly against historical data.
- Paper trade it against live ticks without capital at risk.
- Go live with small size on your own machine, watching it.
- Only then move it to a server and let it run unattended.
Skipping to step four with an untested strategy does not save time. It just automates a mistake and removes the person who would have noticed. If you want the full path from a strategy idea to a deployed system, that is what our Python algo trading course covers end to end.
Frequently Asked Questions
Can I run a trading bot on my laptop?
While learning, yes. For live unattended trading, no - sleep mode, OS updates and broadband drops will interrupt a session eventually, and home connections rarely give the static IP that broker API registration expects. A small cloud server solves both.
What VPS specs do I need for algo trading?
Far less than most people assume. Around 1 vCPU and 1 GB RAM handles a typical Python strategy tracking a few instruments. Location in or near India and a fixed public IP matter more than raw processing power.
Why does a trading bot need a static IP?
So automated order flow can be traced to an identified source. Under SEBI's algo framework, orders placed through a broker API are expected to come from a static IP registered with the broker, and home broadband usually has a changing dynamic IP.
How do I know if my bot has stopped running?
Build alerting in from the start. Have the script message you on Telegram or WhatsApp when it starts each morning, on every order, and on any exception. A silent bot and a bot with no signals look identical otherwise.
Does server latency matter for retail algo trading?
Much less than beginners assume, unless you are running genuinely high-frequency strategies. Being hosted in India rather than another continent is enough for most retail strategies; co-location is not what limits their results.
Related Reading
- Vultr VPS setup for algo trading
- Static IP and broker registration
- Angel One SmartAPI Python tutorial
- Kite Connect Python tutorial
- Algo Trading with Python - complete course
Disclaimer: TheFinBaba provides educational content only - this is not investment advice. Trading involves risk of loss.