NordBastion का ध्रुवीय-भालू शुभंकर रात में एक तिजोरी जैसे नॉर्डिक कक्ष में एक पत्थर की बेंच पर, एक बंद लैपटॉप के पास बैठा, cyan होलोग्राफ़िक लूप और घड़ी के आकारों के नीचे एक सर्वर रैक को देखते हुए

हाउ-टू · 25 मिनट व्यावहारिक अभ्यास·2026 में अपडेट

VPS पर AI एजेंट को 24/7 चलाएं।
लैपटॉप से हटकर, उस मेटल पर जो कभी सोता नहीं।

VPS पर AI एजेंट को 24/7 चलाने के लिए आपको चार चीज़ें चाहिए, इनमें से कोई भी कमाल की नहीं है: एक बॉक्स जो चालू रहे, एक सुपरवाइज़र जो उसे restart करे, ऐसे secrets जो कभी image में न जाएँ, और एक स्पेंड कैप — साथ ही एक ऐसा host जिसे आपकी पहचान की ज़रूरत न हो।

संक्षेप में

01
ज़्यादातर एजेंट किसी hosted model API के इर्द-गिर्द I/O-bound गोंद भर हैं। inference आपके बॉक्स पर नहीं होता, इसलिए बॉक्स छोटा रहता है: 2 vCPU और 4 GB एक single-loop एजेंट को आसानी से संभाल लेते हैं।
02
Uptime एक सुपरवाइज़र की समस्या है, हार्डवेयर की नहीं। एक systemd unit या एक Docker restart policy — जो enable हो, और असली reboot पर परखी गई हो — बस इतना ही काफ़ी है।
03
दो चीज़ें हैं जो वाकई काटती हैं: एक secret जो image layer में पक्का हो गया हो, और एक ऐसा एजेंट जिसकी कोई spend ceiling न हो और वह पूरी रात किसी metered API के खिलाफ़ लूप करता रहे।

अध्याय 1

आपका लैपटॉप एक deployment क्यों नहीं है। चार तरह की विफलताएँ, सभी उबाऊ।

जो एजेंट आपकी मशीन पर काम करता है वह एक चलने वाला एजेंट है, कोई deploy किया हुआ एजेंट नहीं। यह फ़र्क़ चार बेरौनक समस्याओं का है, इनमें से कोई भी prompt engineering से जुड़ी नहीं है।

स्लीप। ढक्कन बंद करते ही प्रोसेस सस्पेंड हो जाता है। पावर मैनेजमेंट ढक्कन बंद होने से बहुत पहले ही बैकग्राउंड काम को थ्रॉटल करने लगता है, जिससे इस विफलता का सबसे बुरा रूप सामने आता है: एक एजेंट जो चलता तो है, पर देर से और अनियमित ढंग से।

IP का बार-बार बदलना। घर या कैफ़े का कनेक्शन हर बार दोबारा जुड़ने पर आपको एक नया पता दे देता है। जो कुछ भी IP से rate-limited है, जिस किसी webhook को एक स्थिर callback चाहिए, जो भी allowlist आपने रजिस्टर की है — वह सब बीच-बीच में टूटता रहता है।

रीबूट। ऑपरेटिंग-सिस्टम के अपडेट अपने ही शेड्यूल पर मशीन को restart कर देते हैं। जब तक एजेंट किसी service manager के साथ रजिस्टर न हो, वह वापसी में एक डेस्कटॉप पर लौटता है, किसी चलते हुए लूप पर नहीं। ज़्यादातर लोगों को यह एक हफ़्ते बाद पता चलता है।

जगह बदलना। आप यात्रा करते हैं, मशीन बदलते हैं, फिर से इंस्टॉल करते हैं। जो कुछ भी सिर्फ़ आपकी shell history में जीता है वह reproducible नहीं है — मार्च की किसी दोपहर सेट किया गया एजेंट दरअसल किसी deployment प्रक्रिया के बिना ही है।

एक सर्वर इन्हीं चार चीज़ों को ठीक करता है और कुछ नहीं — न सहीपन, न लागत, न सुरक्षा। यह आपको एक ऐसा runtime देता है जिसकी विफलताएँ ठीक करना अब आपका काम है। जो कोई भी इसे इससे ज़्यादा बताकर बेचे, उस पर शक करें।

अध्याय 2

बॉक्स का आकार तय करना। किस एजेंट आकार के लिए कौन-सा VPS टियर।

स्वाभाविक झुकाव over-provision करने का होता है, क्योंकि आर्टिफ़िशियल इंटेलिजेंस भारी-भरकम लगता है। जब तक model किसी और के हार्डवेयर पर चल रहा है, यह भारी नहीं है: hosted API को कॉल करने वाला एजेंट अपना समय नेटवर्क I/O का इंतज़ार करने में बिताता है। एक तीसरा आकार — मॉडल को खुद चलाना — यहाँ दायरे से बाहर है; उस वर्कलोड को virtual machine से ज़्यादा एक GPU चाहिए।

पहला आकार — single loop। एक प्रोसेस, एक polling या scheduled loop, एक hosted model API, और SQLite में state। यही ज़्यादातर indie एजेंट और monitoring bots की तस्वीर है, और यह वाकई छोटा है।

दूसरा आकार — छोटा स्टैक। एजेंट के साथ Postgres, एक Redis-backed queue, एक worker और एक vector store। अब मेमोरी ही असली सीमा बन जाती है — in-process लोड किया गया embedding model अपने लिए एक-दो गीगाबाइट अलग से माँगता है।

कैटलॉग के सामने रखकर देखें: Sentinel (NB-V1 — 2 vCPU, 4 GB RAM, 120 GB NVMe, 1 Gbps, असीमित bandwidth, $3.90/month) पहले आकार को आराम से, बल्कि गुंजाइश के साथ, पूरा करता है। जैसे ही Postgres और एक queue तस्वीर में आते हैं, दूसरे आकार के लिए ईमानदार न्यूनतम Garrison (NB-V2 — 4 vCPU, 8 GB, 240 GB, $7.90/month) है। Ravelin (NB-V3 — 8 vCPU, 16 GB, 480 GB, 2.5 Gbps, $16.90/month) कई एजेंटों के एक बॉक्स साझा करने के लिए है। Local inference का ठिकाना dedicated hardware है।

योजनाएँ मासिक आधार पर चलती हैं, और लंबी अवधि की प्रतिबद्धता पर छूट मिलती है — तीन महीने पर 10%, छह पर 20%, बारह पर 30%। अगर आपका एजेंट किसी Python प्रोसेस के बजाय Windows-only ट्रेडिंग क्लाइंट है, तो इसी स्थिति के लिए remote-desktop टियर मौजूद हैं।

अध्याय 3

Deploy का रास्ता — करीब पंद्रह मिनट में VPS पर एक AI एजेंट चलाएं।

बॉक्स को Ubuntu 24.04 LTS या Debian 13 के साथ provision करें — दोनों ऑर्डर के समय उपलब्ध हैं, साथ ही Ubuntu 22.04, Debian 12, AlmaLinux 9 और Rocky Linux 9 भी। आपको root credentials मिलते हैं; इनके साथ पहला काम यही है कि इनका इस्तेमाल करना बंद कर दें। अगर SSH key authentication आपके लिए अनजाना इलाक़ा है, तो पहले नीचे दी गई hardening गाइड पढ़ लें।

1 — एक service user बनाएं। adduser --system --group --home /srv/agent agent। एजेंट को root के रूप में नहीं चलना चाहिए और उसके पास कोई interactive shell नहीं होनी चाहिए। अभी एक कमांड, और बाद में अगर एजेंट का बुलाया कोई tool उसी के खिलाफ़ मोड़ दिया जाए तो नुकसान का दायरा छोटा रहता है।

2 — कोड को बॉक्स पर लाएं। /srv/agent में git clone करें, या अगर सर्वर पर कोई deploy key नहीं छोड़ना चाहते तो rsync इस्तेमाल करें। dependencies को pin करें: एक lockfile ही वह फ़र्क़ है जो एक redeploy को दोहराने-लायक बनाता है, बनिस्बत उस redeploy के जो आपको चौंका दे।

3 — environment तैयार करें। python3 -m venv /srv/agent/.venv चलाएं, फिर उसी virtualenv के pip से lockfile के ज़रिए इंस्टॉल करें। या फिर uv इंस्टॉल करें और उसे interpreter और lockfile दोनों संभालने दें। दोनों में से कोई भी ठीक है; दोनों को मिलाना ठीक नहीं।

4 — इसे एक बार हाथ से चलाएं। sudo -u agent /srv/agent/.venv/bin/python -m agent --once। सीधे service unit पर जाने के लिए इस चरण को न छोड़ें। यहाँ दस में से नौ विफलताएँ एक गुम environment variable या आपके लैपटॉप के सापेक्ष किसी path की होती हैं, और ये दोनों journald के मुक़ाबले टर्मिनल में कहीं ज़्यादा साफ़ दिखती हैं।

5 — इसे एक सुपरवाइज़र को सौंप दें। अगला अध्याय। यही वह चीज़ है जो आपके चलाए गए स्क्रिप्ट को मशीन की अपनी एक सर्विस में बदल देती है। अगर यह पूरा क्रम पंद्रह मिनट से काफ़ी ज़्यादा लंबा खिंच गया, तो लगभग हमेशा इसकी वजह आपकी development मशीन पर कोई अघोषित निर्भरता होती है — कोई global binary, आपकी shell profile में पड़ा कोई credential, या repository के बाहर का कोई path।

अध्याय 4

इसे 24/7 ज़िंदा रखना। systemd, Docker, और crash-loop का जाल।

किसी SSH सेशन में शुरू किया गया प्रोसेस सेशन खत्म होते ही मर जाता है, और reboot के बाद वापस नहीं आता। supervision कोई विकल्प नहीं है, और आपके पास दो उचित रास्ते हैं।

systemd, एक अकेले प्रोसेस के लिए। /etc/systemd/system/agent.service में एक unit, जिसमें User=agent, WorkingDirectory=/srv/agent, ExecStart virtualenv के interpreter की ओर इशारा करता हो, Restart=always और RestartSec=5 हों। फिर systemctl daemon-reload, फिर systemctl enable --now agent। यही enable है जो reboot में बचा रहता है; बिना enable किए सिर्फ़ start करना ही तीन हफ़्ते बाद एजेंट को खो देने का सबसे आम तरीका है।

Docker, चीज़ों के एक समूह के लिए। जब एजेंट के साथ अन्य घटक भी हों — एक database, एक queue, एक headless browser — तो उन्हें एक ही Compose फ़ाइल में बयान करें, हर सर्विस पर restart: unless-stopped के साथ। unless-stopped, always से एक अहम बात में अलग है: जिस container को आपने जानबूझकर रोका था, वह daemon के restart होने पर भी रुका ही रहता है।

crash-loop का जाल। systemd डिफ़ॉल्ट रूप से restarts को rate-limit करता है। इंटरवल के भीतर पर्याप्त बार crash हो जाए तो unit failed स्थिति में चली जाती है और कोशिश करना बंद कर देती है — एक ऐसा एजेंट जो ख़ामोशी से मर चुका लगता है, जबकि unit फ़ाइल साफ़ कहती है Restart=always। बेरोकटोक फिर से कोशिश करने के लिए StartLimitIntervalSec=0 सेट करें, और RestartSec बढ़ा दें ताकि टूटा हुआ एजेंट रातभर एक कोर घुमाता न रहे।

Liveness, health नहीं है। नौ घंटे से किसी socket read पर अटका हुआ लूप भी systemd की हर कसौटी पर एक चलता हुआ प्रोसेस ही दिखता है। एक heartbeat उजागर करें: WatchdogSec वाला एक watchdog, एक Docker HEALTHCHECK, या एक timestamp फ़ाइल जिसे एजेंट हर cycle में छूता है और एक timer जो इसके बासी पड़ते ही अलर्ट करे।

अध्याय 5

Secrets। वह environment फ़ाइल जिसे image तक कभी नहीं पहुँचना चाहिए।

एक एजेंट के पास किसी web application से कहीं ज़्यादा ख़तरनाक सामग्री होती है। एक model API key खर्च करने का एक साधन है; एक trading key में leverage होता है; और एक wallet key खुद फंड ही है। और किसी web app के उलट, एजेंट ऐसे टेक्स्ट पर काम करता है जो उसने खुद नहीं लिखा, जिससे एजेंट के key रखने और किसी हमलावर के key रखने के बीच की सीमा पतली हो जाती है।

उन्हें image से बाहर रखें। किसी Dockerfile में ENV और ARG के मान image layers में लिख दिए जाते हैं, और image हासिल करने वाला कोई भी उन्हें docker history से पढ़ सकता है। Compose में env_file: का, या systemd unit में EnvironmentFile= का इस्तेमाल करें, और फ़ाइल को build context के बाहर रखें।

उन्हें repository से बाहर रखें। .gitignore और .dockerignore पहले ही commit में डालें, पचासवें में नहीं। जो key कभी भी commit हो चुकी हो वह commit को दोबारा लिख देने के बाद भी compromised रहती है, क्योंकि वह ऑब्जेक्ट clones और forks में बचा रह जाता है। history को दोबारा लिखने के बजाय key को rotate करें।

फ़ाइल जहाँ तक पहुँच सकती है, उसे सीमित करें। environment फ़ाइल का स्वामित्व service user को दें और mode 600 सेट करें। एक non-root service user के साथ मिलकर, बॉक्स पर कहीं और compromised हुई कोई dependency आपकी keys को डिस्क से यूँ ही नहीं पढ़ सकती।

हर key का दायरा issuer के स्तर पर तय करें। हर एजेंट के लिए एक key, और प्रोवाइडर की दी सबसे संकरी permissions के साथ — जहाँ सिर्फ़ पढ़ना काफ़ी हो वहाँ read-only, exchange keys पर withdrawal बंद, और सर्वर तक IP-allowlisted। एक स्थिर IP लैपटॉप से हटने का एक खामोश फ़ायदा है: allowlisting आख़िरकार मुमकिन हो जाती है। अगर एक ही credentials कई लोगों को चाहिए, तो साथी गाइड में बताए self-hosted vault के पीछे उन्हें रख दें।

अध्याय 6

शेड्यूलिंग। Loops, timers, और वह timezone जो आपको काटती है।

लगातार चलते रहने का मतलब तीन अलग-अलग architectures हो सकते हैं, और ग़लत को चुन लेना दोहरे काम और छूटे हुए runs की एक आम वजह है।

resident loop। एक लंबे समय तक चलने वाला प्रोसेस जो cycles के बीच सोता है। समझने में सबसे आसान, और सही default। इसकी कमज़ोरी है state: restart पर memory में सब कुछ खो जाता है, इसलिए जो कुछ भी crash से बचना चाहिए उसकी जगह SQLite या Postgres में है, किसी variable में नहीं।

scheduled run। एक प्रोसेस जो शुरू होता है, काम की एक इकाई करता है और बाहर निकल जाता है। यहाँ OnCalendar वाला एक systemd timer बेहतर औज़ार है, मुख्यतः Persistent=true की वजह से: downtime के बाद, persistent timer उस छूटे हुए run को चला देता है, जबकि cron उसे बस छोड़ देता है।

queue। एक producer tasks को queue में डालता है, workers उन्हें निपटाते हैं। जिस पल tasks पूरे होने से तेज़ी से आने लगें, आपको यही चाहिए होता है। यह आपको retries, dead-letter handling और एक concurrency ceiling भी देता है।

जो भी चुनें, दो नियम। हर task को idempotent बनाएं — crash पर restart करने वाला supervisor tasks को दोबारा चलाएगा, और दोबारा चलाया गया task दोहरी पोस्ट या दोहरा ऑर्डर नहीं करना चाहिए। और सर्वर की घड़ी को UTC में ही रहने दें, कन्वर्ज़न सिर्फ़ किनारों पर करें: साल में दो बार एक घंटे खिसक जाने वाला शेड्यूल ढूँढने में थका देने वाली बग है।

अध्याय 7

एजेंट को tools देना। उसी बॉक्स पर एक tool सर्वर।

बिना tools वाला एजेंट बस एक chat loop है। tools ही वह चीज़ हैं जो उसे किसी repository को पढ़ने, किसी database को query करने, कोई ऑर्डर देने या कोई issue दर्ज करने देते हैं — और जब एजेंट किसी सर्वर पर रहने लगे, तो tools को भी वहीं रहना चाहिए।

Model Context Protocol उन tools को उजागर करने का आम तरीका बन चुका है, और निजी तौर पर चलाया गया एक सर्वर एजेंट के बगल में रखना आसान है: वही बॉक्स, वही निजी इंटरफ़ेस, किसी सार्वजनिक एक्सपोज़र की ज़रूरत नहीं। साथी गाइड इसे ठीक से समझाते हैं — एक remote MCP सर्वर होस्ट करना TLS, streamable-HTTP transport, OAuth और agent card को क़दम-दर-क़दम बताता है, जबकि बिना-ID होस्टिंग वाला पहलू उसी स्टैक को पहचान के नज़रिए से समझाता है।

पहले इसे localhost से bind करें। अगर इस्तेमाल करने वाला सिर्फ़ उसी मशीन पर मौजूद एजेंट है, तो tool सर्वर के पास किसी सार्वजनिक port के लिए कोई वजह नहीं। loopback पते से bind करें और certificate को छोड़ दें। इसे सार्वजनिक रूप से तभी उजागर करें जब किसी दूसरी मशीन को इसकी ज़रूरत हो — और तब इसे TLS और authentication दोनों चाहिए, इनमें से एक नहीं।

tools को उतना ही अधिकार दें जितने से काम चल जाए। एजेंट यह फ़ैसला टेक्स्ट के आधार पर करता है कि कौन-सा tool बुलाना है, और उस टेक्स्ट का कुछ हिस्सा बाहर से आता है। जो एजेंट web pages या inboxes पढ़ता है, उसके लिए prompt injection कोई काल्पनिक ख़तरा नहीं है: यही अपेक्षित हालत है। जो tool सिर्फ़ पढ़ सकता है, उसे बहलाकर लिखवाया नहीं जा सकता। जहाँ किसी tool को लिखना ही पड़े, वहाँ विध्वंसक रास्तों के लिए किसी इंसान की पुष्टि ज़रूरी बना दें।

अगर आप अपने लिए नहीं बल्कि दूसरे लोगों के एजेंटों के लिए tools बना रहे हैं, तो machine API और एजेंट-केंद्रित सतह बताते हैं कि यह प्लेटफ़ॉर्म किसी एजेंट को सीधे provisioning कैसे उपलब्ध कराता है।

अध्याय 8

Observability और लागत। क्या log करें, और बेकाबू हालात का kill-switch।

असली एजेंट deployments में दो तरह की विफलताएँ हावी रहती हैं, और इनमें से कोई भी crash नहीं है। एक वह एजेंट है जो बिल्कुल ठीक चलता है और कुछ भी उपयोगी नहीं देता। दूसरा वह एजेंट है जो बिल्कुल ठीक चलता है और एक ही रात में चार अंकों का API बिल बना देता है।

बनावट को log करें, सामग्री को नहीं। Timestamp, task id, step count, बुलाए गए tool names, token totals, duration, outcome। यही हर उस परिचालन सवाल का जवाब देता है जो आप वाकई पूछेंगे। पूरे prompts और completions दरअसल उस हर चीज़ की एक ट्रांसक्रिप्ट हैं जो एजेंट से कभी करने को कहा गया, वह भी plaintext में, किसी और की इमारत में रखी एक डिस्क पर।

retention की सीमा तय करें। जब तक आप न रोकें, journald बढ़ता ही रहता है। journald.conf में SystemMaxUse और MaxRetentionSec आकार और उम्र दोनों पर एक सीमा लगा देते हैं। वरना एक बातूनी एजेंट हफ़्तों में डिस्क भर देता है, और भरी हुई डिस्क एक साफ़-सुथरे crash के मुक़ाबले कहीं ज़्यादा उलझे तरीक़ों से विफल होती है।

खर्च पर नियंत्रण की तीन परतें। प्रोवाइडर के स्तर पर, API key पर एक hard cap — यही एकमात्र सीमा है जिसे आपके कोड की कोई bug बायपास नहीं कर सकती, और यही वह है जिसे लोग छोड़ देते हैं। एजेंट के भीतर, हर run के लिए एक token counter और एक abort थ्रेशोल्ड। एजेंट के इर्द-गिर्द, एक अधिकतम step count और एक wall-clock timeout, ताकि खुद से बहस करता कोई model चार हज़ार के बजाय बीस iterations के बाद रुक जाए।

kill-switch को ज़रूरत पड़ने से पहले ही बना लें। एक ऐसा कमांड जो सब कुछ रोक दे: systemctl stop agent, या docker compose down। सुनिश्चित करें कि इसके लिए किसी ख़ास key वाले लैपटॉप की ज़रूरत न पड़े। एक बुरी रात और एक बुरे महीने के बीच का फ़र्क़ बस इतना है कि किसी बेकाबू हालात को रोकने में दस सेकंड लगते हैं या एक घंटा।

अध्याय 9

पहचान की न्यूनतम सीमा। host क्या जानता है — और किससे यह आपकी रक्षा नहीं कर सकता।

एक एजेंट credentials रखने वाला एक लंबे समय तक चलने वाला प्रोसेस है, जो लगातार एक स्थिर पते से आपकी ओर से काम करता है। यही किराए के रिकॉर्ड को किसी static वेबसाइट के मुक़ाबले कहीं ज़्यादा दिलचस्प बना देता है: यह हर घंटे, महीनों तक, ऐसे काम कर रहा होता है जो आप तक जोड़े जा सकते हैं।

यहाँ न्यूनतम सीमा है साइनअप के लिए एक ईमेल पता और एक पासवर्ड, आठ assets में भुगतान — Bitcoin, Ethereum, दो chains पर Tether, Monero, Litecoin, TRON और Solana — और किसी भी चरण में कोई पहचान दस्तावेज़ नहीं। डेटा सेंटर चार नॉर्डिक संवैधानिक व्यवस्थाओं में बैठे हैं: Stockholm, Helsinki, Oslo और Reykjavík। operating doctrine बताता है कि क्या रिटेन किया जाता है; network पेज routing को कवर करता है।

अब वह सीमा, जो pitch से कहीं ज़्यादा मायने रखती है। जो host कोई पहचान नहीं माँगता, वह किराए का रिकॉर्ड हटा देता है। यह inference की परत को छूता तक नहीं: आपका एजेंट किसी model provider से हर कॉल पर एक स्थिर IP से, किसी अकाउंट से जुड़ी key के साथ प्रमाणित होता है। अगर वह अकाउंट आपके क़ानूनी नाम पर है — और ज़्यादातर लोगों के लिए यही सच है — तो पहचान वहीं स्थापित हो जाती है, चाहे मेटल कोई भी किराए पर ले। host की परत एक कड़ी हटाती है: एक असली कड़ी, और बस एक ही।

आगे जो आता है वह बेरौनक है। Compartmentalise करें: एक एजेंट, एक सर्वर, एक key, एक wallet। बॉक्स को तीसवें दिन नहीं, पहले ही दिन harden करें — पहले-घंटे की चेकलिस्ट उस मशीन पर बिताया गया एक सार्थक घंटा है जो महीनों तक बिना निगरानी चलेगी। अगर एजेंट को किसी निजी नेटवर्क तक पहुँचना ज़रूरी हो, तो services को उजागर करने के बजाय उसे सर्वर पर एक tunnel से terminate करें — tunnel गाइड इसका configuration बताती है। और उस wallet से क्रिप्टो में भुगतान करें जो आपके एजेंट के ट्रेड करने वाले wallet से अलग हो।

इनमें से कुछ भी असाधारण नहीं है, और इनमें से कुछ भी गारंटी नहीं है। यह बस उस साधारण अनुशासन की बात है जो तब लागू होता है जब कोई चीज़ आपके सोते समय आपकी ओर से काम कर रही होती है — निरंतर परिचालन का मतलब बस इतना ही है। बाक़ी क्लस्टर गाइड सूची पर है।

FAQ · VPS पर एजेंट

प्रश्न, उत्तरित।

सात सवाल जो डेवलपर किसी एजेंट को localhost से हटाने से पहले पूछते हैं — और उसके बाद पहले महीने में भी।

AI एजेंट को 24/7 चलाने के लिए मुझे कितना VPS चाहिए?

जितना लोग सोचते हैं उससे कम, क्योंकि inference प्रोवाइडर के हार्डवेयर पर होता है, आपके नहीं। जो एजेंट किसी hosted model API को कॉल करता है और polling loop चलाता है, वह एक I/O-bound प्रोसेस है: Sentinel टियर (2 vCPU, 4 GB RAM, 120 GB NVMe, $3.90/month) आराम से पूरा पड़ता है। जैसे ही आप Postgres, एक queue और एक local embedding model जोड़ते हैं, Garrison (4 vCPU, 8 GB, $7.90/month) पर अपग्रेड करें।

एजेंट को चलता रखने के लिए मुझे systemd इस्तेमाल करना चाहिए या Docker?

दोनों काम करते हैं; बस विफल होने के तरीके अलग हैं। Restart=always वाली एक systemd unit किसी एक प्रोसेस के लिए सबसे छोटा रास्ता है और मुफ़्त में journald, resource limits और boot ordering देती है। जब एजेंट के साथ अन्य सर्विसें भी हों तो restart: unless-stopped वाला Docker बेहतर है, क्योंकि Compose पूरे सेट को एक ही फ़ाइल में बयान कर देता है। जो बात ज़्यादा मायने रखती है वह यह है कि आप इसे वाकई enable करें, और चल पड़ने से पहले एक reboot में इसे परख लें।

कुछ crash के बाद मेरा एजेंट restart होना क्यों बंद कर देता है?

क्योंकि systemd restarts को rate-limit करता है। StartLimitBurst और StartLimitIntervalSec एक छोटी सी विंडो के भीतर सीमित संख्या में restarts की अनुमति देते हैं; इस सीमा को पार करते ही unit failed स्थिति में चली जाती है और वहीं टिकी रहती है, जो बिल्कुल एक ख़ामोश मौत जैसी दिखती है। या तो असली crash को ठीक करें — यही सही जवाब है — या फिर limiter को बंद करने के लिए StartLimitIntervalSec=0 सेट करें और RestartSec=10 भी, ताकि crash-loop में फँसा एजेंट बार-बार कोशिश करके कोर न जलाता रहे।

मैं API keys कहाँ रखूँ?

ऐसी फ़ाइल में जिसे container image कभी नहीं देखती। एक environment फ़ाइल build context के बाहर रखें, जिसे systemd unit में EnvironmentFile= से या Compose में env_file: से संदर्भित किया जाए, स्वामित्व service user का हो और mode 600 सेट हो। किसी secret के लिए Dockerfile में कभी ENV या ARG इस्तेमाल न करें: ये मान image layers में पक्के हो जाते हैं और docker history से पढ़े जा सकते हैं। पहले commit से पहले ही फ़ाइल को .gitignore और .dockerignore में जोड़ दें।

मैं एजेंट को एक ही रात में मेरा पूरा API बजट उड़ाने से कैसे रोकूँ?

तीन परतें, और आपको तीनों चाहिए। प्रोवाइडर के स्तर पर: API key पर एक hard spend cap, यही एकमात्र सीमा है जिसे आपके कोड की कोई bug बायपास नहीं कर सकती। एजेंट के भीतर: हर run में tokens या calls गिनें और एक थ्रेशोल्ड के ऊपर जाने पर रोक दें। एजेंट के इर्द-गिर्द: हर task के लिए एक step ceiling और एक wall-clock timeout। यह काम कोई host आपके लिए नहीं कर सकता — VPS किराए की क्षमता है, किसी और के API पर बजट का पहरेदार नहीं।

एजेंट के logs में मुझे कभी क्या नहीं लिखना चाहिए?

पूरे prompts और completions, कच्चे tool arguments, API keys, wallet सामग्री और जो कुछ भी किसी उपयोगकर्ता ने टाइप किया हो। इसके बजाय run की बनावट लॉग करें: timestamp, task id, step count, tool names, token totals, duration, outcome। एक बहुत बातूनी agent log असल में उस हर चीज़ की एक ट्रांसक्रिप्ट है जो एजेंट से कभी करने को कहा गया, वह भी plaintext में, ऐसी डिस्क पर जिस पर आपका भौतिक नियंत्रण नहीं है।

क्या एक KYC-मुक्त host मेरे एजेंट को अनाम बना देता है?

नहीं, और यहाँ सटीक होना ज़रूरी है। बिना-ID साइनअप और क्रिप्टो भुगतान का मतलब बस इतना है कि host के पास सर्वर से जोड़ने के लिए कोई कानूनी पहचान नहीं है। यह model provider के मामले में कुछ नहीं बदलता: आपका एजेंट उस API से हर कॉल पर एक स्थिर सर्वर IP से, किसी अकाउंट से जुड़ी एक key के साथ प्रमाणित होता है। host की परत ज़ंजीर की एक कड़ी हटाती है — किराए का रिकॉर्ड — और बस यही हटती है।

metal प्राप्त करें

एक KYC-मुक्त VPS किराए पर लें, क्रिप्टो में भुगतान करें, आज रात ही एजेंट को अपने लैपटॉप से हटा दें।

Sentinel — 2 vCPU, 4 GB RAM, 120 GB NVMe, असीमित bandwidth, $3.90/month — एक single-loop एजेंट को उसके साथ चलने वाले tool सर्वर की गुंजाइश समेत संभाल लेता है। साइनअप के लिए बस एक ईमेल पता और एक पासवर्ड; किसी भी चरण में कोई दस्तावेज़ नहीं।

एजेंट होस्टिंग का विवरण Monero से भुगतान करें VPS catalogue देखें

अंतिम review · 2026-08-24 · स्रोत · systemd.service, systemd.timer और journald.conf के manual pages, Docker restart-policy और Compose दस्तावेज़, Model Context Protocol विनिर्देश (specification), NordBastion कैटलॉग · आवृत्ति · वार्षिक

Part of the series