−25%

Windows के सालाना भुगतान पर, 31 अक्टूबर तक। प्लान देखें

EQVPS
शुरू करें

एक VPS पर एक Telegram बॉट 24/7 चलाएँ: aiogram, systemd, polling बनाम webhook

4 जुल॰ 2026 · 6 मिनट पढ़ने में · EQVPS Team

आपने aiogram से एक Telegram बॉट लिखा, इसे स्थानीय रूप से परखा, और यह काम करता है। अब इसे कहीं रहना होगा जो सोता नहीं जब आप लैपटॉप बंद करते हैं। एक छोटा VPS स्वाभाविक घर है — पर एक SSH सत्र में python bot.py और एक ऐसे बॉट के बीच एक अंतर है जो असल में क्रैश, रीबूट, और आपके कनेक्शन गिरने के दौरान चालू रहता है।

यह प्रोडक्शन संस्करण है: एक virtualenv, टोकन आपके कोड से बाहर रखा, एक systemd सेवा जो बॉट को अपने दम पर पुनर्जीवित करती है, और उस सवाल का एक स्पष्ट जवाब जो हर कोई अंततः पूछता है — polling या webhook?

इसे बस अपने लैपटॉप पर क्यों न चलाएँ

एक बॉट को Telegram से एक स्थिर आउटबाउंड कनेक्शन चाहिए। आपका लैपटॉप सोता है, अपडेट के लिए रीबूट होता है, और नेटवर्कों के बीच कूदता है — उनमें से हर एक बॉट को गिराता है, और उपयोगकर्ता ख़ामोशी की एक दीवार से टकराते हैं। एक VPS उस कनेक्शन को चौबीसों घंटे थामता है। यही इसे आपकी मशीन से हटाने की पूरी वजह है, और यही वजह है कि एक Discord बॉट भी एक सर्वर पर रहता है।

अगर आप बस एक न्यूनतम बॉट के साथ सबसे तेज़ संभव "इसे ऑनलाइन करो" रास्ता चाहते हैं, एक-Telegram-बॉट-होस्ट-करें वॉकथ्रू उसे कवर करता है। यह टुकड़ा एक स्तर गहरा जाता है: aiogram, सुरक्षित टोकन संभालना, और यह जानना कि कब स्केल करें।

बॉट, एक virtualenv में

SSH करें और बॉट को उसके अपने venv में अलग रखें — पैकेज सिस्टम-भर इंस्टॉल न करें, यह अपग्रेड और सफ़ाई को बाद में एक गड़बड़ बनाता है:

sudo apt update && sudo apt install -y python3-venv
mkdir ~/tgbot && cd ~/tgbot
python3 -m venv venv && source venv/bin/activate
pip install -U aiogram

एक न्यूनतम aiogram 3 बॉट जो अपना टोकन परिवेश से पढ़ता है, एक हार्ड-कोड की गई स्ट्रिंग से नहीं:

# bot.py
import asyncio, logging, os
from aiogram import Bot, Dispatcher
from aiogram.types import Message
from aiogram.filters import CommandStart

logging.basicConfig(level=logging.INFO)
dp = Dispatcher()

@dp.message(CommandStart())
async def start(m: Message):
    await m.answer("Alive and running on a VPS.")

async def main():
    bot = Bot(os.environ["BOT_TOKEN"])
    await dp.start_polling(bot)

if __name__ == "__main__":
    asyncio.run(main())

टोकन को अपने कोड से बाहर रखें

BotFather टोकन को कभी bot.py में पेस्ट न करें — एक सार्वजनिक रेपो पर एक पुश और यह लीक हो गया। इसे बजाय एक root-पठनीय env फ़ाइल में रखें:

sudo tee /etc/tgbot.env >/dev/null <<'EOF'
BOT_TOKEN=123456:your-token-from-botfather
EOF
sudo chmod 600 /etc/tgbot.env

एक लीक हुआ टोकन BotFather में एक /revoke से ठीक होने से एक क़दम दूर है — पर एक साझा मशीन पर एक लीक हुआ और कुछ भी बदतर है। बॉट के लिए एक समर्पित VPS टोकन के लिए ईमानदारी से आपके रोज़मर्रा के लैपटॉप से ज़्यादा सुरक्षित घर है: अगर यह लीक हो, आप एक टोकन घुमाते हैं, अपना पूरा सेटअप नहीं।

वह हिस्सा जो इसे ज़िंदा रखता है: systemd

यही एक ऐसे बॉट को जो चलता है और एक ऐसे बॉट को जो चलता रहता है अलग करता है। सेवा बनाएँ:

# /etc/systemd/system/tgbot.service
[Unit]
Description=Telegram bot (aiogram)
After=network-online.target
Wants=network-online.target

[Service]
User=botuser
WorkingDirectory=/home/botuser/tgbot
EnvironmentFile=/etc/tgbot.env
ExecStart=/home/botuser/tgbot/venv/bin/python bot.py
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

इसे एक ग़ैर-root उपयोगकर्ता (ऊपर botuser) के रूप में चलाएँ, root नहीं — अगर बॉट कभी समझौता हो, आप इसे बंद चाहते हैं। फिर:

sudo systemctl daemon-reload
sudo systemctl enable --now tgbot

Restart=always के साथ RestartSec=3 का मतलब एक क्रैश — Telegram से एक बुरा अपडेट, एक अनहैंडल्ड अपवाद, एक OOM — बॉट को आपके नोटिस करने तक मृत छोड़ने के बजाय तीन सेकंड में वापस लाता है। इसे लाइव देखें:

journalctl -u tgbot -f

वही आपका पूरा लॉगिंग सेटअप है। कोई लॉग फ़ाइलें घुमाने को नहीं, कोई अतिरिक्त टूलिंग नहीं — journald के पास पहले से है।

डाउनटाइम नाटक के बिना अपडेट करना

जब आप कोड बदलें या aiogram बढ़ाएँ:

cd ~/tgbot && source venv/bin/activate
pip install -U aiogram          # अगर लाइब्रेरी अपग्रेड कर रहे हैं
sudo systemctl restart tgbot
journalctl -u tgbot -n 30 --no-pager   # पुष्टि करें कि यह साफ़ वापस आया

रीस्टार्ट बॉट को एक-दो सेकंड के लिए ब्लिप करता है। एक polling बॉट के लिए वह उपयोगकर्ताओं के लिए अदृश्य है — Telegram अपडेट क़तार में रखता है और बॉट के फिर जुड़ने पर उन्हें पहुँचाता है।

Polling बनाम webhook — ईमानदार संस्करण

यही वह फ़ैसला है जिस पर लोग ज़्यादा सोचते हैं। यहाँ सादा संस्करण है:

Polling (start_polling, जो ऊपर का कोड इस्तेमाल करता है) बॉट से Telegram को एक लंबे-जीवित कनेक्शन पर "कुछ नया?" पूछवाता है। इसे आउटबाउंड इंटरनेट के अलावा कुछ नहीं चाहिए — कोई डोमेन नहीं, कोई TLS नहीं, कोई खुले इनबाउंड पोर्ट नहीं। यह NAT के पीछे ठीक चलता है। बॉट के ज़बरदस्त बहुमत के लिए, यह सही है और आपको यहीं रुकना चाहिए।

Webhook से Telegram अपडेट आपको धकेलता है, यानी आपको एक सार्वजनिक HTTPS एंडपॉइंट उजागर करना होगा। उसे एक डोमेन और एक पहुँच योग्य इनबाउंड पोर्ट चाहिए — तो या एक समर्पित सार्वजनिक IP या सामने एक रिवर्स प्रॉक्सी। ज़्यादा सेटअप, ज़्यादा चीज़ें जो टूटती हैं। प्रतिफल बड़े पैमाने पर कम लेटेंसी और कम ओवरहेड है — हज़ारों समवर्ती उपयोगकर्ता, भारी अपडेट वॉल्यूम।

व्यावहारिक नियम: एक NAT प्लान पर polling से शुरू करें। एक webhook पर सिर्फ़ तब जाएँ जब आप असल में polling से बड़े हो गए हों — और अगर आप जाएँ, तभी एक डेडिकेटेड IP अपनी जगह कमाता है, क्योंकि आपको वह इनबाउंड HTTPS एंडपॉइंट चाहिए।

इसे चलाने में क्या ख़र्च आता है

एक polling बॉट हल्का है। यह Telegram के long-poll पर निष्क्रिय रहता और संदेशों पर प्रतिक्रिया करता है, तो बॉक्स ज़्यादातर इंतज़ार करता है:

  • $3 Nano (2 vCPU / 1 GB) — ज़्यादातर बॉट के लिए ठीक, काफ़ी बातूनी वाले भी।
  • $5 Micro (2 vCPU / 2 GB) — जब बॉट एक डेटाबेस (SQLite/Postgres) रखे, मीडिया संभाले, या बहुत सारे उपयोगकर्ता सर्व करे।
  • ऊँचा सिर्फ़ अगर बॉट ख़ुद असली काम करे — इमेज प्रोसेसिंग, एक स्थानीय मॉडल, भारी प्रति-संदेश लॉजिक।

साइनअप सिर्फ़-ईमेल है और आप Base या Ethereum पर USDC या USDT में चुकाते हैं — कोई कार्ड नहीं, कोई ID नहीं। कार्ड भी काम करता है, पर ऑन-रैंप की ~$27 न्यूनतम है, तो एक $3 प्लान के लिए एक छोटा बैलेंस एक बार भरना और नवीनीकरण को उससे निकलने देना आसान है। यह सिर्फ़-CPU है, दो लोकेशन, जर्मनी और फ़िनलैंड (उपलब्धता ऑर्डर करते समय दिखती है) — एक बॉट के लिए एक ग़ैर-मुद्दा, जानने लायक अगर आपको एक GPU या एक ख़ास क्षेत्र चाहिए।

ईमानदार लब्बोलुआब

एक Telegram बॉट सबसे सस्ती चीज़ों में से एक है जिसे आप स्व-होस्ट कर सकते हैं: एक $3 बॉक्स, एक systemd यूनिट, और polling आपको एक ऐसा बॉट देते हैं जो बिना आपके निगरानी किए क्रैश और रीबूट के दौरान ऑनलाइन रहता है। एक webhook और एक बड़े प्लान की ओर सिर्फ़ तब बढ़ें जब पैमाना असल में मजबूर करे — इसलिए नहीं कि एक ट्यूटोरियल ने कहा कि webhooks "बेहतर" हैं। छोटा बॉक्स लें, टोकन को एक env फ़ाइल में रखें, systemd को अपटाइम संभालने दें, और — किसी भी चीज़ से पहले — नई-VPS सुरक्षा चेकलिस्ट चलाएँ ताकि बॉक्स ख़ुद बंद हो।


अपना होस्ट करने के लिए तैयार? एक Telegram बॉट बमुश्किल संसाधन इस्तेमाल करता है — Nano प्लान ($3/माह) इसे बिना झंझट 24/7 चलाता है।

FAQ

Polling या webhook — मुझे कौन सा इस्तेमाल करना चाहिए?

polling से शुरू करें। यह आउटबाउंड इंटरनेट वाले किसी भी बॉक्स से काम करता है — कोई डोमेन नहीं, कोई खुले पोर्ट नहीं, कोई TLS नहीं — और यह ज़्यादातर बॉट के लिए बहुत है। webhook पर सिर्फ़ तब जाएँ जब आप पैमाने पर (हज़ारों उपयोगकर्ता) चल रहे हों या सबसे कम संभव लेटेंसी चाहिए हो; एक webhook को एक सार्वजनिक HTTPS एंडपॉइंट चाहिए, यानी एक डोमेन और एक पहुँच योग्य इनबाउंड पोर्ट (एक डेडिकेटेड IP, या एक रिवर्स प्रॉक्सी), तो यह ज़्यादा हिलते पुर्ज़े हैं। 95% बॉट के लिए, एक छोटे VPS पर polling सही जवाब है।

क्या एक Telegram बॉट के लिए मुझे एक डेडिकेटेड IP या एक डोमेन चाहिए?

polling के लिए नहीं — बॉट सिर्फ़ Telegram को आउटबाउंड कॉल करता है, तो पोर्ट-फ़ॉरवर्ड किए SSH वाला एक NAT प्लान काफ़ी है। आपको एक सार्वजनिक HTTPS एंडपॉइंट (डोमेन + इनबाउंड पोर्ट, यानी एक डेडिकेटेड IP या रिवर्स प्रॉक्सी) सिर्फ़ तब चाहिए अगर आप webhook मोड में बदलें। ज़्यादातर बॉट को इसकी कभी ज़रूरत नहीं।

एक aiogram बॉट को कौन-से आकार का VPS चाहिए?

सबसे छोटा। एक polling बॉट ज़्यादातर Telegram के long-poll का इंतज़ार करता है, तो 2 vCPU / 1 GB (एक $3 Nano) ज़्यादातर बॉट को आराम से संभालता है। आकार सिर्फ़ तब बढ़ाएँ जब बॉट ख़ुद भारी काम करे — एक डेटाबेस, मीडिया प्रोसेसिंग, या एक स्थानीय मॉडल — जो आपको 2 GB ($5) या ज़्यादा की ओर धकेलता है।

लॉग आउट करने के बाद मैं बॉट को चलता कैसे रखूँ?

इसे Restart=always के साथ एक systemd सेवा के रूप में चलाएँ। अपने टर्मिनल में लॉन्च किया यह तब मर जाता है जब SSH बंद होता है; systemd के तहत यह लॉगआउट झेलता है, क्रैश पर रीस्टार्ट होता है, और रीबूट के बाद वापस आता है। यही एक डेमो और किसी ऐसी चीज़ के बीच रेखा है जिस पर आप भरोसा कर सकें।

टिप्पणियाँ

अभी तक कोई टिप्पणी नहीं। पहले बनें।

एक टिप्पणी छोड़ें

टिप्पणियाँ दिखने से पहले मॉडरेट की जाती हैं।