ٹریڈنگ bots کے لیے VPS میں اصل اہم چیزیں کیا ہیں؟

VPS کو trading bots کے لیے کن چیزوں کی ضرورت ہوتی ہے

trading bots کے لیے VPS کو چار چیزوں کی بنیاد پر پرکھا جاتا ہے: کیا process بند ہونے کے بعد دوبارہ شروع ہو جاتا ہے، کیا system clock درست ہے، کیا API (application programming interface) keys چوری کرنا مشکل ہے، اور کیا bot رکنے پر آپ کو بروقت اطلاع مل جاتی ہے۔ retail bot کے لیے raw speed اس فہرست میں بہت نیچے آتی ہے، کیونکہ order path کا سست حصہ آپ کا broker اور اس تک network distance ہے، نہ کہ وہ host جہاں آپ کا Python چل رہا ہو۔

یہ ایک engineering guide ہے۔ اس میں موجود کوئی بات financial advice نہیں ہے، اور کسی strategy پر بحث نہیں کی گئی۔

ری اسٹارٹ کی باقاعدہ پالیسی uptime کا اصل معیار ہے، sales page پر درج عدد نہیں

دنیا کا ہر host 99.9 percent uptime کی تشہیر کرتا ہے۔ یہ عدد hypervisor کی دستیابی بیان کرتا ہے، آپ کے bot کی نہیں۔ کوئی bot unhandled exception، کبھی reconnect نہ ہونے والے websocket، یا OOM (out of memory) killer کی وجہ سے بند ہو سکتا ہے، جبکہ server پورے وقت چلتا رہتا ہے۔ اس لیے مفید سوال یہ ہے کہ آپ کا process بند ہونے کے بعد اگلے دس seconds میں کیا ہوتا ہے۔

bot کو systemd service کے طور پر چلائیں اور restart کی ذمہ داری init system کو دیں۔ ایک unit file یہ کام چھ lines میں کرتی ہے۔

[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 وہ line ہے جسے لوگ اکثر نظرانداز کر دیتے ہیں۔ پہلے سے systemd دس seconds میں 5 restarts کے بعد کوشش ترک کر دیتا ہے اور unit کو ہمیشہ کے لیے failed state میں چھوڑ دیتا ہے۔ 03:00 بجے آپ کو بالکل یہی رویہ نہیں چاہیے۔ اسے 0 پر set کرنے سے rate limit غیر فعال ہو جاتی ہے، اس لیے crash-loop میں پھنسا bot خاموش ہونے کے بجائے دوبارہ چلنے کی کوشش کرتا رہتا ہے۔ RestartSec=10 اس loop کو exchange پر مسلسل reconnects کی بھرمار کرنے سے روکتا ہے۔

فائل پر اعتماد کرنے سے پہلے اس کی جانچ کریں، پھر اسے 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 کی ساخت، جس میں daily report جیسے scheduled jobs کے لیے timers بھی شامل ہیں، systemd service کے طور پر program چلانا میں بیان کی گئی ہے۔

گھڑی کو UTC پر سیٹ کریں اور ثابت کریں کہ یہ ہم وقت ہے

Exchange APIs درخواستوں پر timestamp سے دستخط کرتی ہیں اور مقررہ window سے باہر کی درخواستیں مسترد کر دیتی ہیں، جو اکثر 5 seconds یا اس سے کم ہوتی ہے۔ گھڑی میں drift ایسی errors پیدا کرتی ہے جو authentication failures معلوم ہوتی ہیں، اس لیے لوگ وقت چیک کرنے سے پہلے کئی گھنٹوں تک keys rotate کرتے رہتے ہیں۔ Binance-style APIs پر message واضح ہوتا ہے: Timestamp for this request was 1000ms ahead of the server's time۔

Server کو UTC پر سیٹ کریں۔ مقامی time zones daylight saving کی ایسی چھلانگ پیدا کرتے ہیں جو trading session کے دوران واقع ہو سکتی ہے۔

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu میں systemd-timesyncd شامل ہوتا ہے، جو SNTP (simple network time protocol) client ہے۔ یہ logs کے لیے کافی ہے، لیکن ایسی کسی بھی چیز کے لیے کمزور ہے جسے چند milliseconds کے اندر رہنا ہو، کیونکہ یہ ایک server سے polling کرتا ہے اور clock کو مسلسل discipline نہیں کرتا۔ اس کے بجائے 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 تک نہیں پہنچا، عموماً اس لیے کہ outbound UDP 123 blocked ہے۔ ایک منٹ انتظار کریں، پھر firewall rules میں تبدیلی کرنے سے پہلے دوبارہ چیک کریں۔

API keys ان مقامات پر نہ رکھیں جہاں آپ انہیں copy کرتے ہیں

لیک ہونے والی exchange key، لیک ہونے والی SSH key سے زیادہ خطرناک ہوتی ہے، کیونکہ withdrawal permission اسے فوراً رقم میں تبدیل کر دیتی ہے۔ زیادہ تر خطرے کو دو عادات سے کم کیا جا سکتا ہے۔

پہلی بات، bot key کو کبھی withdrawal permission نہ دیں۔ جہاں exchange یہ سہولت فراہم کرے، وہاں key کو اپنے server کے IP address سے bind کریں۔ یہ واحد control ہے جو چوری شدہ 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 میں سادہ KEY=value lines ہوتی ہیں۔ ان میں quotes یا export شامل نہ کریں۔ bot group کے ساتھ mode 640 رکھنے سے service user اسے پڑھ سکتا ہے، جبکہ کوئی اور user اسے نہیں پڑھ سکتا۔ sudo -u bot cat /etc/tradingbot/api.env سے تصدیق کریں، پھر کسی دوسرے user کے طور پر بھی یہی آزمائیں؛ وہاں یہ Permission denied کے ساتھ fail ہونا چاہیے۔

bot کو root یا اپنے login user کے طور پر نہیں چلنا چاہیے۔ ایسا system account بنائیں جس میں shell نہ ہو اور جس کے پاس log in کرنے کے لیے home directory بھی نہ ہو:

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 پر پہلے دس منٹ میں شامل ہیں۔

اپنے broker سے پہلے معلوم کریں کہ یہ بند ہے

systemctl status بتاتا ہے کہ process چل رہا ہے۔ اس سے یہ ثابت نہیں ہوتا کہ bot کوئی کام کر رہا ہے۔ کسی dead websocket کے خلاف retry loop میں پھنسا ہوا process، systemd کی ہر ممکنہ جانچ میں کامیاب ہو سکتا ہے۔

اس کے بجائے heartbeat استعمال کریں۔ Uptime Kuma میں push monitors موجود ہیں۔ یہ توقع کرتا ہے کہ آپ کا bot مقررہ وقفے سے ایک 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 کے تقریباً دوگنا پر set کریں، تاکہ معمولی jitter کی وجہ سے آپ کو page نہ کیا جائے۔ monitor کو bot سے مختلف server پر چلائیں، کیونکہ جو 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 اعداد و شمار پیش کرتے ہیں اور یہ تاثر دیتے ہیں کہ fill تک پہنچنے میں اصل رکاوٹ host ہے۔ تقریباً ہر retail bot کے لیے ایسا نہیں ہوتا۔

آپ کا order public internet کے ذریعے bot سے exchange یا broker endpoint تک جاتا ہے۔ اس راستے پر physical distance اور آپ کے provider اور ان کے provider کے درمیان peering کا سب سے زیادہ اثر ہوتا ہے۔ Frankfurt میں موجود server جب Tokyo کے endpoint سے رابطہ کرتا ہے تو round trip میں تقریباً 250 milliseconds لگتے ہیں، چاہے CPU کتنا ہی تیز ہو۔ اس کے بعد broker کے اپنے systems queue، risk checks اور rate limits شامل کرتے ہیں، جو retail account کے لیے عموماً دسیوں یا سیکڑوں 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 پر commitment سے پہلے یہ command چلائیں۔ اگر connect 0.180 seconds ہے تو آپ غلط continent میں ہیں، اور اسے درست کرنا فائدہ مند ہوگا۔ اگر connect 0.004 seconds اور ttfb 0.140 seconds ہے تو باقی تاخیر broker کی processing کی وجہ سے ہے، اور host تبدیل کرنے سے اس پر کوئی اثر نہیں پڑے گا۔

تو host کب اہم ہوتا ہے؟ جب آپ venue کے ساتھ colocated یا cross-connected ہوں اور queue position کے لیے مقابلہ کر رہے ہوں۔ یہ مختلف budget والا مختلف کاروبار ہے۔ Host اس وقت بھی اہم ہوتا ہے جب bottleneck آپ کا اپنا code ہو۔ مثلاً ایسا bot جو ہر tick پر پوری history پر indicators دوبارہ calculate کرتا ہے، ہر loop میں CPU کے 200 milliseconds استعمال کر سکتا ہے۔ یہ حقیقی latency ہے جسے آپ بغیر کسی اضافی لاگت کے کم کر سکتے ہیں۔ تیز server تلاش کرنے سے پہلے loop کا profile بنائیں۔

آپ کے منتخب کردہ host میں اصل اہم چیزیں geography، stable networking، اور اتنی memory ہیں کہ OOM killer کو کبھی مداخلت کا موقع نہ ملے۔ July 2026 تک، چند سو symbols کو memory میں رکھنے والا single-strategy Python bot 2 GB RAM اور 2 vCPU میں اطمینان سے چلتا ہے۔ اگر آپ tick history کو local database میں رکھتے ہیں تو memory بڑھائیں۔

پیداوار پر فعال کرنے سے پہلے مختصر فہرست

1. systemctl is-enabled tradingbot، enabled دکھاتا ہے، اور service sudo reboot کے بعد بھی چلتی رہتی ہے۔
2. chronyc tracking، system time کا offset چند milliseconds سے کم دکھاتا ہے۔
3. API key کے پاس trading کی اجازت ہے، withdrawal کی اجازت نہیں ہے، اور اگر exchange یہ سہولت فراہم کرتا ہو تو IP allowlist بھی configured ہے۔
4. sudo systemctl kill -s SIGKILL tradingbot سے process ختم کرنے پر یہ RestartSec کے اندر دوبارہ چل جاتا ہے۔
5. جب آپ bot کو جان بوجھ کر روک دیتے ہیں تو heartbeat monitor ایک interval کے اندر آپ کو alert بھیج دیتا ہے۔
6. Logs کی حد مقرر ہے، اور df -h میں root filesystem پر کافی خالی جگہ موجود ہے۔

اصل funds استعمال کرنے سے پہلے پورے نظام کو exchange کے sandbox یا paper mode میں ایک ہفتہ چلائیں۔ اس ہفتے کے دوران اوپر دی گئی ہر شرط کم از کم ایک بار ناکام ہوگی۔ یہی اس ہفتے کا مقصد ہے۔

FAQ

کیا trading bot کو کم تاخیر والے یا bare metal server کی ضرورت ہوتی ہے؟

صرف اس وقت، جب آپ اسی venue پر موجود دیگر خودکار participants کے ساتھ execution speed میں مقابلہ کر رہے ہوں۔ ایسی صورت میں عموماً عام مقصد کے VPS کے بجائے colocation درکار ہوتی ہے۔ retail bot کے لیے round trip پر جغرافیائی فاصلے اور broker کی اپنی processing کا زیادہ اثر ہوتا ہے۔ اس لیے API endpoint کے قریب server منتخب کریں، اور کسی زیادہ تیز server کے لیے ادائیگی کرنے سے پہلے curl اور mtr سے پیمائش کریں۔

trading bot کو کتنی RAM اور CPU درکار ہوتی ہے؟

زیادہ تر single-strategy bots network-bound ہوتے ہیں اور events کے درمیان idle رہتے ہیں۔ July 2026 تک، 2 vCPU اور 2 GB RAM چند سو instruments کو track کرنے والے Python bot کے لیے کافی ہیں۔ جب آپ tick history کو process میں رکھتے ہیں یا local database چلاتے ہیں تو memory رکاوٹ بن سکتی ہے۔ اس لیے اندازہ لگانے کے بجائے free -h اور journal میں OOM kill messages monitor کریں۔

exchange API timestamp error کے ساتھ requests کیوں reject کرتی ہے؟

Server clock exchange کی signing window سے باہر drift کر گئی ہے، جو عموماً چند seconds ہوتی ہے۔ chrony install کریں، تصدیق کریں کہ chronyc tracking میں معمولی System time offset اور synchronised leap status دکھائی دے رہا ہے، اور machine کو UTC پر set کریں تاکہ daylight saving کی تبدیلی سے وقت کبھی نہ بدلے۔ API key rotate کرنے سے clock کا مسئلہ حل نہیں ہوتا۔

میں اپنے bot کو رات کے وقت، اپنی اطلاع کے بغیر بند ہونے سے کیسے روکوں؟

اسے systemd کے تحت Restart=always اور StartLimitIntervalSec=0 کے ساتھ چلائیں، تاکہ crash loop مستقل طور پر رکنے کے بجائے retry کرتا رہے۔ پھر heartbeat شامل کریں، جو bot ہر کامیاب loop کے اختتام پر بھیجے۔ restart process کو سنبھالتا ہے۔ heartbeat اس صورت کا پتا دیتا ہے جب process زندہ ہو لیکن stuck ہو۔

کیا میں bot اور اپنی monitoring کو اسی VPS پر چلا سکتا ہوں؟

آپ چلا سکتے ہیں، لیکن جس دن اس کی ضرورت ہوگی monitoring آپ کو غلط صورتِ حال دکھائے گی، کیونکہ bot کو بند کرنے والی outage monitor کو بھی بند کر دے گی۔ Alerting کو الگ machine پر رکھیں، بہتر ہے کہ مختلف provider یا region میں ہو، اور bot کے server کو صرف bot اور اس کے logs کے لیے استعمال کریں۔