Trading bot के लिए VPS में क्या सचमुच मायने रखता है

ट्रेडिंग bot को VPS से क्या चाहिए

ट्रेडिंग bot के लिए VPS का मूल्यांकन चार बातों पर किया जाता है: प्रक्रिया बंद होने के बाद फिर शुरू होती है या नहीं, सिस्टम की घड़ी सही है या नहीं, API (application programming interface) keys को चुराना कठिन है या नहीं, और प्रक्रिया रुकने पर आपको पता चलता है या नहीं। किसी retail bot के लिए कच्ची गति इस सूची में बहुत नीचे है, क्योंकि आपके order path का धीमा भाग आपके broker और उससे दूरी है, न कि वह host जिस पर आपका Python चल रहा है।

यह एक engineering guide है। इसमें financial advice नहीं दी गई है और किसी strategy पर चर्चा नहीं की गई है।

Uptime बिक्री पृष्ठ पर दी गई संख्या नहीं, बल्कि restart अनुशासन है

दुनिया का हर host 99.9 प्रतिशत uptime का दावा करता है। यह आंकड़ा hypervisor को दर्शाता है, आपके bot को नहीं। किसी unhandled exception, दोबारा कभी connect न होने वाले websocket या OOM (out of memory) killer के कारण bot बंद हो जाता है, जबकि server पूरे समय चालू रहता है। इसलिए उपयोगी प्रश्न यह है कि आपका process बंद होने के बाद के दस सेकंड में क्या होता है।

Bot को systemd service के रूप में चलाएँ और restart का नियंत्रण init system को दें। एक unit file यह काम छह पंक्तियों में करती है।

[Unit]
Description=Trading bot
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/tradingbot
EnvironmentFile=/etc/tradingbot/api.env
ExecStart=/opt/tradingbot/venv/bin/python -m tradingbot
Restart=always
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tradingbot

[Install]
WantedBy=multi-user.target

StartLimitIntervalSec=0 वह पंक्ति है जिसे लोग अक्सर छोड़ देते हैं। डिफ़ॉल्ट रूप से systemd 10 सेकंड में 5 restart के बाद प्रयास करना बंद कर देता है और unit को हमेशा के लिए failed state में छोड़ देता है। 03:00 बजे आपको ठीक यही व्यवहार नहीं चाहिए। इसे 0 पर सेट करने से rate limit अक्षम हो जाती है। इसलिए crash-loop में फँसा bot शांत रहने के बजाय प्रयास करता रहता है। RestartSec=10 उस loop को exchange पर बार-बार reconnect करके अत्यधिक network traffic भेजने से रोकता है।

File पर भरोसा करने से पहले उसकी जाँच करें, फिर उसे start करें:

sudo systemd-analyze verify /etc/systemd/system/tradingbot.service
sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
systemctl status tradingbot

enable वह भाग है जो reboot के बाद भी बना रहता है, और kernel updates का अर्थ reboot होता है। यह देखने के लिए कि bot चुपचाप बंद तो नहीं हो रहा, systemd से restart counter पूछें:

systemctl show tradingbot -p NRestarts
journalctl -u tradingbot --since "24 hours ago" | tail -50

एक सप्ताह के बाद NRestarts=0 स्वस्थ bot को दर्शाता है। NRestarts=812 का अर्थ है कि आप ऐसे process पर trading कर रहे हैं जो पूरी रात reconnect करता रहा। पूरे unit file anatomy में daily report जैसे scheduled jobs के लिए timers भी शामिल हैं। इसका विवरण systemd service के रूप में program चलाना में दिया गया है।

घड़ी को UTC पर सेट करें और साबित करें कि वह सिंक्रनाइज़ है

Exchange APIs अनुरोधों पर timestamp से हस्ताक्षर करते हैं और एक समय-सीमा के बाहर के अनुरोध अस्वीकार कर देते हैं। यह सीमा अक्सर 5 seconds या उससे कम होती है। घड़ी के drift से authentication failure जैसी errors आती हैं। इसलिए लोग समय जाँचने से पहले घंटों तक keys बदलते रहते हैं। Binance-style APIs पर संदेश स्पष्ट होता है: Timestamp for this request was 1000ms ahead of the server's time।

Server को UTC पर सेट करें। Local time zones से daylight saving का बदलाव होता है, जो trading session के बीच में हो सकता है।

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu में systemd-timesyncd पहले से उपलब्ध है। यह SNTP (simple network time protocol) client है। Logs के लिए यह पर्याप्त है। लेकिन कुछ milliseconds की सीमा में समय बनाए रखने वाले कामों के लिए यह कमजोर है, क्योंकि यह एक server से poll करता है और clock को लगातार नियंत्रित नहीं करता। इसके बजाय chrony का उपयोग करें:

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

chronyc tracking से पढ़ी जाने वाली line System time है, उदाहरण के लिए System time : 0.000031415 seconds fast of NTP time। कुछ milliseconds से कम मान स्वस्थ है। यदि यह Leap status : Not synchronised पढ़ता है, तो chrony अभी तक किसी server से connect नहीं हुआ है। इसका सामान्य कारण outbound UDP 123 का blocked होना है। एक minute प्रतीक्षा करें। फिर firewall rules में बदलाव करने से पहले दोबारा जाँच करें।

API keys को उन स्थानों से बाहर रखें जिन्हें आप कॉपी करते हैं

लीक हुई exchange key, लीक हुई SSH key से अधिक खतरनाक होती है, क्योंकि withdrawal permission मिलने पर वह तुरंत धन तक पहुंच दे सकती है। अधिकतर जोखिम को 2 आदतों से नियंत्रित किया जा सकता है।

पहली, किसी bot key को withdrawal permission कभी न दें। Exchange इसका समर्थन करता हो, तो key को अपने server के IP address से bind करें। यह वह एकमात्र नियंत्रण है जो चोरी हुई key को लगभग बेकार बना देता है।

दूसरी, secret को code directory से बाहर रखें। /opt/tradingbot के अंदर की कोई भी चीज़ देर-सबेर git repository या backup archive में चली जाती है। Secret को root-owned file में रखें, जिसे केवल systemd पढ़ सके:

sudo install -d -m 750 -o root -g bot /etc/tradingbot
sudo install -m 640 -o root -g bot /dev/null /etc/tradingbot/api.env
sudo nano /etc/tradingbot/api.env

इस file में बिना quotes और बिना export वाली plain KEY=value lines होती हैं। Group bot के साथ mode 640 रखने पर service user इसे पढ़ सकता है और कोई अन्य user नहीं पढ़ सकता। sudo -u bot cat /etc/tradingbot/api.env से इसकी पुष्टि करें। फिर किसी अन्य user के रूप में भी जांचें; वहां यह Permission denied के साथ विफल होना चाहिए।

Bot को root या अपने login user के रूप में नहीं चलना चाहिए। बिना shell और बिना home directory वाला system account बनाएं, जिससे login न किया जा सके:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/tradingbot --create-home bot

इन flags के पीछे का कारण और ProtectSystem=strict वास्तव में कितनी सुरक्षा देता है, यह unprivileged user के रूप में services चलाना में बताया गया है। Server baseline के बाकी हिस्से, SSH keys और firewall, नए VPS पर पहले 10 मिनट में शामिल हैं।

अपने ब्रोकर से पहले पता लगाएँ कि यह बंद है

systemctl status बताता है कि process चल रही है। यह नहीं बताता कि bot कोई काम कर रहा है। बंद websocket के विरुद्ध retry loop में अटकी process, systemd की सभी जाँचों में सफल हो सकती है।

इसके बजाय heartbeat का उपयोग करें। Uptime Kuma में push monitors होते हैं। यह अपेक्षा करता है कि आपका bot तय schedule पर किसी URL को call करे। Call आना बंद होने पर यह alert भेजता है। यह call अपने main loop के अंत में रखें। इसे उस हिस्से के बाद रखें जो bot के सक्रिय होने की पुष्टि करता है, जैसे market data का सफल read।

curl -fsS "http://monitor.example.com:3001/api/push/YOUR_TOKEN?status=up&msg=loop_ok"

Monitor interval को अपने loop time से लगभग दोगुना रखें। इससे सामान्य jitter के कारण अनावश्यक page नहीं आएगा। Monitor को bot से अलग server पर चलाएँ। यदि monitor उसी चीज़ के साथ बंद हो जाए जिसे वह monitor करता है, तो वह कोई report नहीं भेजेगा। Setup का विवरण Uptime Kuma के साथ self-hosted status monitoring में दिया गया है।

Disk alert भी जोड़ें। Verbose logs लिखने वाला bot कुछ ही सप्ताह में root filesystem भर सकता है। Disk भरने पर database write रुकता है, network call नहीं। इसलिए symptoms असामान्य दिखाई देते हैं। journalctl --vacuum-time=14d और /etc/systemd/journald.conf में मौजूद SystemMaxUse= line journal को सीमित आकार में रखते हैं।

ईमानदार बात: latency का अधिकांश हिस्सा आपके host पर निर्भर नहीं होता

यहीं trading VPS products का बाज़ार तकनीकी होना बंद कर देता है। Marketing pages sub-millisecond आंकड़े दिखाते हैं और यह संकेत देते हैं कि host ही आपके और order fill के बीच मुख्य बाधा है। लगभग हर retail bot के लिए ऐसा नहीं है।

आपका order public internet के माध्यम से bot से exchange या broker endpoint तक जाता है। इस मार्ग पर physical distance और आपके provider तथा उनके provider के बीच peering का सबसे अधिक प्रभाव होता है। Frankfurt का server, Tokyo के endpoint से बात करते समय, CPU कितना भी तेज़ हो, लगभग 250 milliseconds का round trip time देगा। इसके बाद broker के अपने systems queue, risk checks और rate limits जोड़ते हैं। Retail account के लिए इनकी अवधि आमतौर पर tens या hundreds of milliseconds में होती है।

अनुमान लगाने के बजाय इसे मापें। curl किसी वास्तविक endpoint के लिए connection और first-byte times दिखाता है:

curl -s -o /dev/null -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://api.kraken.com/0/public/Time
mtr -rwzc 100 api.kraken.com

किसी candidate server को चुनने से पहले यह command वहाँ चलाएँ। यदि connect 0.180 seconds है, तो server गलत महाद्वीप पर है। इसे बदलना उपयोगी होगा। यदि connect 0.004 seconds और ttfb 0.140 seconds हैं, तो शेष delay broker की processing के कारण है। Host बदलने से इस delay पर कोई प्रभाव नहीं पड़ेगा।

तो host कब महत्वपूर्ण होता है? जब आप venue के साथ colocated या cross-connected हों और queue position के लिए प्रतिस्पर्धा कर रहे हों। यह अलग budget वाला अलग business है। Host तब भी महत्वपूर्ण होता है जब आपका अपना code bottleneck हो। उदाहरण के लिए, हर tick पर पूरी history में indicators फिर से calculate करने वाला bot हर loop में CPU के 200 milliseconds खर्च कर सकता है। यह ऐसी वास्तविक latency है जिसे आप बिना अतिरिक्त खर्च के नियंत्रित कर सकते हैं। तेज़ server लेने से पहले loop को profile करें।

आपके चुने हुए host में geography, stable networking और पर्याप्त memory महत्वपूर्ण हैं, ताकि OOM killer को कभी process समाप्त करने का अवसर न मिले। July 2026 तक, memory में कुछ hundred symbols रखने वाला single-strategy Python bot 2 GB of RAM और 2 vCPU में आसानी से चलता है। यदि आप tick history को local database में रखते हैं, तो memory बढ़ाएँ।

प्री-लाइव संक्षिप्त चेकलिस्ट

1. systemctl is-enabled tradingbot, enabled प्रिंट करता है और सेवा sudo reboot के बाद भी चलती रहती है।
2. chronyc tracking, कुछ मिलीसेकंड से कम का सिस्टम समय अंतराल दिखाता है।
3. API key के पास ट्रेडिंग की अनुमति है, निकासी की अनुमति नहीं है, और यदि एक्सचेंज यह सुविधा देता है तो IP allowlist भी कॉन्फ़िगर है।
4. sudo systemctl kill -s SIGKILL tradingbot से process को बंद करने पर वह RestartSec के भीतर फिर से शुरू हो जाता है।
5. जब आप bot को जानबूझकर रोकते हैं, तो heartbeat monitor एक interval के भीतर आपको page भेजता है।
6. Logs की सीमा निर्धारित है और df -h में root filesystem पर पर्याप्त खाली स्थान है।

वास्तविक धन का उपयोग करने से पहले पूरे सिस्टम को एक सप्ताह तक एक्सचेंज के sandbox या paper mode में चलाएँ। उस सप्ताह में ऊपर दिए गए प्रत्येक बिंदु में कम से कम एक बार समस्या आती है। यही इस सप्ताह का उद्देश्य है।

FAQ

क्या trading bot को कम latency वाले या bare metal server की आवश्यकता है?

केवल तब, जब आप उसी venue पर अन्य automated participants के विरुद्ध execution speed में प्रतिस्पर्धा कर रहे हों। ऐसी स्थिति में सामान्यतः general purpose VPS के बजाय colocation का उपयोग किया जाता है। Retail bot के लिए round trip पर geography और broker की अपनी processing का अधिक प्रभाव होता है। इसलिए API endpoint के निकट server चुनें और किसी तेज़ विकल्प के लिए भुगतान करने से पहले curl और mtr से माप लें।

trading bot को कितनी RAM और CPU की आवश्यकता होती है?

अधिकांश single-strategy bot network-bound होते हैं और events के बीच idle रहते हैं। July 2026 तक, 2 vCPU और 2 GB RAM कुछ सौ instruments को track करने वाले Python bot के लिए पर्याप्त हैं। जब आप tick history को process में रखते हैं या local database चलाते हैं, तब memory constraint बन जाती है। इसलिए अनुमान लगाने के बजाय free -h और journal में OOM kill messages पर नज़र रखें।

timestamp error के साथ मेरा exchange API requests को अस्वीकार क्यों करता है?

Server clock exchange की signing window से बाहर drift कर गई है। यह सामान्यतः कुछ seconds का अंतर होता है। chrony install करें। पुष्टि करें कि chronyc tracking में छोटा System time offset और synchronised leap status दिख रहा है। Machine को UTC पर सेट करें, ताकि daylight saving change से समय कभी न बदले। API key rotate करने से clock की समस्या ठीक नहीं होती।

मुझे कैसे पता चले बिना रात भर bot के बंद होने से कैसे रोकूँ?

इसे systemd के अंतर्गत Restart=always और StartLimitIntervalSec=0 के साथ चलाएँ। इससे crash loop स्थायी रूप से रुकने के बजाय retry करता रहेगा। इसके बाद heartbeat जोड़ें, जिसे bot प्रत्येक सफल loop के अंत में भेजे। Restart process को संभालता है। Heartbeat उस स्थिति का पता लगाता है जिसमें process alive है, लेकिन stuck है।

क्या मैं bot और अपना monitoring एक ही VPS पर चला सकता हूँ?

आप ऐसा कर सकते हैं, लेकिन जिस दिन इसकी आवश्यकता होगी उस दिन monitoring आपको गलत जानकारी देगी। इसका कारण यह है कि bot को बंद करने वाला outage monitor को भी बंद कर देगा। Alerting को अलग machine पर रखें। आदर्श रूप से अलग provider या region का उपयोग करें। Bot के server का उपयोग केवल bot और उसके logs के लिए करें।