Trading bot के लिए सही VPS कैसे चुनें: पूरी गाइड

ट्रेडिंग बॉट के लिए VPS की आवश्यकताएं

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

यह एक इंजीनियरिंग गाइड है। यहाँ दी गई कोई भी जानकारी वित्तीय सलाह नहीं है, और किसी भी रणनीति पर चर्चा नहीं की गई है।

Uptime का अर्थ restart discipline है, न कि sales page पर लिखा कोई नंबर

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

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 स्थिति में छोड़ देता है, जो कि ठीक वही व्यवहार है जो आप 03:00 बजे नहीं चाहेंगे। इसे 0 पर सेट करने से rate limit अक्षम हो जाती है, इसलिए crash-loop में फंसा bot शांत होने के बजाय प्रयास करना जारी रखता है। RestartSec=10 उस loop को exchange पर बार-बार reconnect करने से रोकता है।

भरोसा करने से पहले 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 होता रहता है। दैनिक रिपोर्ट जैसे scheduled jobs के लिए timers सहित, पूर्ण unit file की संरचना systemd service के रूप में प्रोग्राम चलाना में दी गई है।

घड़ी को UTC पर सेट करें और सुनिश्चित करें कि यह सिंक्रोनाइज़्ड है

Exchange APIs अनुरोधों को एक टाइमस्टैम्प के साथ साइन करती हैं और 5 सेकंड या उससे कम की विंडो के बाहर के किसी भी अनुरोध को अस्वीकार कर देती हैं। घड़ी में समय का अंतर (drift) ऐसे एरर पैदा करता है जो ऑथेंटिकेशन फेलियर जैसे दिखते हैं, इसलिए लोग समय की जाँच करने से पहले घंटों तक कीज़ रोटेट करते रहते हैं। Binance-स्टाइल APIs पर संदेश स्पष्ट होता है: Timestamp for this request was 1000ms ahead of the server's time।

सर्वर को UTC पर सेट करें। लोकल टाइम ज़ोन में डेलाइट सेविंग का बदलाव होता है, जो ट्रेडिंग सेशन के बीच में समस्या पैदा कर सकता है।

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu में systemd-timesyncd होता है, जो एक SNTP (सिंपल नेटवर्क टाइम प्रोटोकॉल) क्लाइंट है। यह लॉग के लिए ठीक है, लेकिन उन कार्यों के लिए कमजोर है जिन्हें कुछ मिलीसेकंड के भीतर सटीक रहना होता है, क्योंकि यह केवल एक सर्वर को पोल करता है और घड़ी को लगातार नियंत्रित (discipline) नहीं करता है। इसके बजाय chrony का उपयोग करें:

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

chronyc tracking से पढ़ने के लिए लाइन System time है, उदाहरण के लिए System time : 0.000031415 seconds fast of NTP time। कुछ मिलीसेकंड से कम का कोई भी मान स्वस्थ है। यदि यह Leap status : Not synchronised दिखाता है, तो chrony अभी तक किसी सर्वर तक नहीं पहुँचा है, आमतौर पर इसलिए क्योंकि आउटबाउंड UDP 123 ब्लॉक है। एक मिनट प्रतीक्षा करें, फिर फ़ायरवॉल नियमों को बदलने से पहले दोबारा जाँचें।

API keys को उन जगहों से दूर रखें जहाँ आप copy-paste करते हैं

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

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

दूसरा, secret को code directory से बाहर रखें। /opt/tradingbot के अंदर मौजूद कोई भी चीज़ देर-सवेर git repository या backup archive में चली ही जाती है। इसे 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 के सादे KEY=value lines होते हैं। Mode 640 और group bot का मतलब है कि केवल service user ही इसे पढ़ सकता है और कोई अन्य नहीं। sudo -u bot cat /etc/tradingbot/api.env के साथ इसकी पुष्टि करें और फिर किसी अन्य user के साथ जाँचें, जहाँ इसे Permission denied के साथ fail होना चाहिए।

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

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

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

अपने ब्रोकर को पता चलने से पहले ही जान लें कि सर्विस डाउन है

systemctl status यह बताता है कि प्रोसेस चल रही है। यह यह नहीं बताता कि बॉट वास्तव में कुछ कर रहा है। यदि कोई प्रोसेस मृत websocket के कारण retry loop में फंसी है, तो भी वह systemd द्वारा किए जाने वाले हर चेक को पास कर लेगी।

इसके बजाय heartbeat का उपयोग करें। Uptime Kuma में push monitors होते हैं: यह उम्मीद करता है कि आपका बॉट एक निश्चित समय पर किसी URL को कॉल करेगा, और कॉल न आने पर अलर्ट भेजता है। इस कॉल को अपने main loop के अंत में रखें, उस हिस्से के बाद जो यह साबित करता है कि बॉट जीवित है, जैसे कि market data का सफलतापूर्वक पढ़ा जाना।

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

मॉनिटर अंतराल (monitor interval) को अपने loop समय से लगभग दोगुना रखें ताकि सामान्य jitter के कारण आपको अनावश्यक अलर्ट न मिले। मॉनिटर को बॉट वाले सर्वर से अलग सर्वर पर चलाएं, क्योंकि यदि मॉनिटर उसी के साथ बंद हो जाता है जिसकी वह निगरानी कर रहा है, तो वह कोई रिपोर्ट नहीं दे पाएगा। सेटअप की जानकारी Uptime Kuma के साथ self-hosted status monitoring में दी गई है।

डिस्क अलर्ट भी जोड़ें। verbose logs लिखने वाला बॉट कुछ ही हफ्तों में root filesystem को भर देगा, और डिस्क फुल होने पर डेटाबेस राइट रुक जाता है, न कि नेटवर्क कॉल, इसलिए इसके लक्षण अजीब होते हैं। journalctl --vacuum-time=14d और /etc/systemd/journald.conf में एक SystemMaxUse= लाइन journal के आकार को सीमित रखती है।

ईमानदारी की बात: latency का मुख्य कारण आपका host नहीं है

यहीं पर trading VPS उत्पादों का बाज़ार तकनीकी होने के बजाय केवल मार्केटिंग रह जाता है। मार्केटिंग पेजों पर सब-मिलीसेकंड के आंकड़े दिए जाते हैं और यह संकेत दिया जाता है कि host ही वह बाधा है जो आपके और trade fill के बीच खड़ी है। लगभग हर retail bot के लिए, ऐसा नहीं है।

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

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

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

किसी भी सर्वर को लेने से पहले उसे चलाकर देखें। यदि connect 0.180 seconds है, तो आप गलत महाद्वीप पर हैं, और इसे ठीक करना आवश्यक है। यदि connect 0.004 seconds है और ttfb 0.140 seconds है, तो शेष देरी broker की processing के कारण है, और host बदलने से इसमें कोई सुधार नहीं होगा।

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

आपके द्वारा चुने गए host में जो मायने रखता है वह है भूगोल, स्थिर नेटवर्किंग, और पर्याप्त memory ताकि OOM killer को कभी हस्तक्षेप न करना पड़े। जुलाई 2026 तक, कुछ सौ symbols को memory में रखने वाला एक single-strategy Python bot 2 GB RAM और 2 vCPU में आराम से चलता है। यदि आप local database में tick history रखते हैं, तो memory बढ़ाएं।

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

1. systemctl is-enabled tradingbot, enabled प्रिंट करता है और सर्विस sudo reboot के बाद भी चलती रहती है।
2. chronyc tracking सिस्टम टाइम ऑफसेट को कुछ मिलीसेकंड से कम रिपोर्ट करता है।
3. API key में ट्रेडिंग की अनुमति है, विड्रॉल की अनुमति नहीं है, और यदि एक्सचेंज सुविधा देता है तो IP allowlist सेट है।
4. sudo systemctl kill -s SIGKILL tradingbot के साथ प्रोसेस को किल करने पर यह RestartSec के भीतर वापस आ जाती है।
5. जब आप जानबूझकर बॉट को रोकते हैं, तो हार्टबीट मॉनिटर एक अंतराल के भीतर आपको पेज (अलर्ट) भेजता है।
6. लॉग्स सीमित हैं और df -h में रूट फाइलसिस्टम के पास पर्याप्त जगह उपलब्ध है।

असली फंड्स का उपयोग करने से पहले पूरे सेटअप को एक सप्ताह तक एक्सचेंज के सैंडबॉक्स या पेपर मोड में चलाएं। इस सप्ताह के दौरान ऊपर दी गई हर एक आइटम कम से कम एक बार फेल होगी, और यही इस सप्ताह का उद्देश्य है।

FAQ

क्या ट्रेडिंग बॉट के लिए low-latency या bare metal सर्वर की आवश्यकता होती है?

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

ट्रेडिंग बॉट को कितनी RAM और CPU की आवश्यकता होती है?

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

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

सर्वर की घड़ी exchange की signing window से बाहर हो गई है, जो आमतौर पर कुछ सेकंड की होती है। chrony इंस्टॉल करें, पुष्टि करें कि chronyc tracking एक छोटा System time offset और एक synchronised leap status दिखाता है, और मशीन को UTC पर सेट करें ताकि daylight saving बदलाव से समय न बदले। API key को rotate करने से clock की समस्या ठीक नहीं होती।

मैं अपने बॉट को रात भर बिना मेरी जानकारी के बंद होने से कैसे रोकूँ?

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

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

आप ऐसा कर सकते हैं, लेकिन जिस दिन इसकी सबसे अधिक आवश्यकता होगी, monitoring आपको गलत जानकारी देगी, क्योंकि जो outage बॉट को गिराती है, वह monitor को भी साथ ले जाती है। alerting को एक अलग मशीन पर रखें, आदर्श रूप से किसी अलग provider या region के साथ, और बॉट के सर्वर का उपयोग केवल बॉट और उसके logs के लिए करें।