Running the bot as a service
Running python main.py in a terminal you might close is not production deployment. Use a proper service manager so the bot survives terminal disconnects, VPS reboots, and crashes.
systemd (Linux VPS — most common choice)
# /etc/systemd/system/algo-bot.service
[Unit]
Description=Algo Trading Bot
After=network.target
[Service]
Type=simple
User=algobot
WorkingDirectory=/home/algobot/algo-trading-bot
EnvironmentFile=/home/algobot/algo-trading-bot/.env
ExecStart=/home/algobot/algo-trading-bot/.venv/bin/python main.py
Restart=on-failure
RestartSec=10
StandardOutput=append:/home/algobot/algo-trading-bot/logs/service.log
StandardError=append:/home/algobot/algo-trading-bot/logs/service-error.log
[Install]
WantedBy=multi-user.targetsudo systemctl daemon-reload
sudo systemctl enable algo-bot
sudo systemctl start algo-bot
sudo systemctl status algo-bot
journalctl -u algo-bot -f # follow logs liveRestart=on-failure auto-restarts on a crash — combine this with proper startup reconciliation (chapter 66) so a restart correctly resyncs state rather than starting blind.
Scheduling the daily auth flow (chapter 10)
Since Kite tokens expire daily and full headless login needs care (TOTP-based automation, chapter 10), a common pattern is a separate scheduled script that runs shortly before market open:
# /etc/systemd/system/algo-bot-auth.service
[Unit]
Description=Daily auth refresh for algo bot
[Service]
Type=oneshot
User=algobot
WorkingDirectory=/home/algobot/algo-trading-bot
EnvironmentFile=/home/algobot/algo-trading-bot/.env
ExecStart=/home/algobot/algo-trading-bot/.venv/bin/python auth/daily_login.py# /etc/systemd/system/algo-bot-auth.timer
[Timer]
OnCalendar=*-*-* 08:45:00 Asia/Kolkata
Persistent=true
[Install]
WantedBy=timers.targetsudo systemctl enable --now algo-bot-auth.timerChoosing a VPS — practical considerations for Indian market hours
- Region: a VPS geographically close to Indian exchange infrastructure reduces latency (matters more for higher-frequency strategies; largely irrelevant for anything trading on minute-plus timeframes). Mumbai-region cloud availability zones (AWS ap-south-1, etc.) are common choices.
- Uptime SLA — your bot's reliability can't exceed the VPS provider's.
- Never run this on your personal laptop that sleeps, updates, or loses wifi — the entire point of a service + VPS is availability independent of your own machine's state.
Don't skip monitoring the service itself
A systemd service that's "running" isn't the same as your bot being healthy (chapter 92's heartbeat distinction applies at the infrastructure level too) — set up an external uptime check or a periodic "still alive" Telegram ping so a silently-hung process gets noticed.