Hermes Agent کے لیے کیا $5 VPS کافی ہے؟

Hermes Agent کیا ہے

Hermes Agent، Nous Research کا self-hosted AI agent ہے جسے February 2026 میں جاری کیا گیا تھا۔ آپ اسے اپنے سرور پر چلاتے ہیں۔ یہ آپ کے projects کی مستقل memory برقرار رکھتا ہے، کام کے دوران اپنی دوبارہ قابلِ استعمال skills لکھتا ہے، اور Telegram اور Discord جیسی chat apps کے ذریعے آپ تک پہنچتا ہے۔ یہ model-agnostic ہے، اس لیے آپ اسے اپنی پسند کے کسی بھی language model کے ساتھ استعمال کر سکتے ہیں۔ یہ اتنا ہلکا ہے کہ $5 VPS، Docker یا SSH کے ذریعے چل سکتا ہے۔ اس architecture میں model کہیں اور چلتا ہے، جبکہ loop، tools اور memory آپ کے server پر چلتے ہیں۔ یہی وجہ ہے کہ Hermes agent harness ہے، model نہیں، اور اسی لیے ایک چھوٹا server کافی ہوتا ہے۔

ہر agent کی قدر اس بات سے پیدا ہوتی ہے کہ وہ آپ کی جانب سے کام کرتا ہے۔ اسی لیے اسے احتیاط سے configure کرنا ضروری ہے۔ جو agent آپ کی باتیں یاد رکھتا ہے، سیکھتا ہے اور tasks چلاتا ہے، وہ ایک مستقل process ہوتا ہے جسے آپ کے server تک حقیقی رسائی حاصل ہوتی ہے۔ یہ guide اسے محفوظ طریقے سے install کرتی ہے۔ یہاں کی hardening وہی ہے جو آپ OpenClaw کو محفوظ طریقے سے چلانے کے لیے بھی لاگو کریں گے۔

ایک کمانڈ سے installation، اور اسے پہلے پڑھنے کی وجہ

Hermes ایک ہی کمانڈ سے install ہو جاتا ہے:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

یہ سہولت بخش ہے، لیکن یہ ایک ایسا طریقہ بھی ہے جس کے ساتھ احتیاط ضروری ہے۔ انٹرنیٹ سے script کو براہِ راست shell میں pipe کرنے سے اس script میں موجود ہر چیز اسی user کے طور پر run ہو جاتی ہے جو اسے چلا رہا ہو۔ اسے حقیقی server پر run کرنے سے پہلے download کریں، اسے پڑھیں، اور root کے بجائے dedicated user کے طور پر run کریں:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh -o hermes-install.sh
less hermes-install.sh

یہ خاص طور پر Hermes پر عدم اعتماد کی بات نہیں ہے۔ یہ وہ عادت ہے جو کسی بھی curl | bash install کو آپ کے setup کا خاموشی سے کمزور ترین حصہ بننے سے روکتی ہے۔

غیر مراعات یافتہ صارف استعمال کریں

Hermes کو اس کے اپنے system account کے تحت چلائیں، کبھی بھی root کے تحت نہیں، تاکہ کوئی bug یا غلط instruction مشین کے باقی حصوں تک نہ پہنچ سکے۔ ایسا صارف بنائیں جس کے پاس login shell نہ ہو:

sudo useradd --system --home /opt/hermes --shell /usr/sbin/nologin hermes

Hermes کو /opt/hermes کے تحت install کریں اور اس account کو اس کا owner بنائیں۔ Official installer اسی user کے لیے installation کرتا ہے جو اسے چلاتا ہے، اس لیے جو script آپ نے download کی ہے اسے hermes user کے طور پر چلائیں، مثلاً sudo -u hermes bash hermes-install.sh۔ اس طرح files آپ کی home directory کے بجائے اسی user کی home directory میں محفوظ ہوں گی۔ اس کی وجہ وہی ہے جو غیر مراعات یافتہ صارف کے طور پر services چلانے کے معاملے میں ہے: agent جس account کے تحت چلتا ہے، وہی اس نقصان کی حد مقرر کرتا ہے جو وہ کر سکتا ہے۔ OS account صرف آدھی تصویر ہے، کیونکہ agent کی اپنی settings یہ طے کرتی ہیں کہ وہ پہلے پوچھے بغیر کتنا کام کر سکتا ہے۔ جب agent ایسی مشین پر چل رہا ہو جس کے سامنے آپ موجود نہ ہوں، تو یہی سوال Claude Code کے permission modes کے پیچھے ہوتا ہے۔ اگر یہ مشین بعد میں صرف آپ کے بجائے مزید لوگوں کے لیے services فراہم کرے، تو OneCLI اس ایک account فی agent کے تصور کو پوری team تک بڑھاتا ہے۔ یہ ہر شخص کو اپنا sandboxed agent دیتا ہے، جبکہ model keys ایک ہی gateway میں رہتی ہیں اور کسی کو انہیں ادھر ادھر copy کرنے کی ضرورت نہیں پڑتی۔

سرور پر firewall نافذ کریں اور اس کے secrets الگ رکھیں

Hermes اپنا کام model اور ان chat apps سے رابطہ کر کے کرتا ہے جنہیں آپ connect کرتے ہیں، اس لیے اسے internet سے inbound connections قبول کرنے کی ضرورت نہیں۔ سرور کے سامنے default-deny firewall لگائیں:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

یہاں IPv6 firewall کے خلا پر توجہ دیں، کیونکہ صرف IPv4 کا احاطہ کرنے والا rule set کسی service کو IPv6 پر exposed چھوڑ سکتا ہے۔ اگر agent کو ایسی چیز تک پہنچنا ضروری ہو جو صرف آپ کے home network پر موجود ہو، مثلاً NAS یا local database، تو subnet router کے ذریعے اس network کی تشہیر اپنے tailnet پر کرنا اسے open inbound port کے بجائے outbound connection کے ذریعے وہاں تک پہنچا دیتا ہے۔ Model API key اور chat tokens کو ایسی file میں رکھیں جسے صرف hermes user پڑھ سکے (mode 600)، اور اسے service میں load کریں؛ اسے command line پر paste نہ کریں، کیونکہ وہ آپ کی shell history میں محفوظ ہو جائے گا۔ ایسی secrets file، self-hosted password manager کے پیچھے موجود admin token کی طرح، ایک چھوٹا مگر high-value target ہے، اور Vaultwarden hardening pass میں بیان کردہ اصول یہاں بھی لاگو ہوتے ہیں: اس ایک file کو محفوظ رکھیں جو باقی سب کچھ unlock کرتی ہے، اور اس کے backups کو بھی اسی سختی سے محفوظ رکھیں۔ File permissions مشین پر موجود دوسرے users کو روکتی ہیں، لیکن اس hosting provider کو نہیں روکتیں جو اس کے بنیادی infrastructure کو چلاتا ہے۔ اس لیے اگر agent کے پاس موجود keys اتنی حساس ہیں کہ یہ حساب بدل جائے، تو encrypted memory اور attestation طے کرتے ہیں کہ آپ کی hosting company انہیں RAM سے پڑھ سکتی ہے یا نہیں۔

Hermes کو سخت security کے ساتھ systemd service کے طور پر چلائیں

systemd unit آپ کے log out کرنے اور reboot کے بعد بھی Hermes کو چلاتی رہتی ہے، crash ہونے پر اسے restart کرتی ہے، اور آپ کو kernel-level sandboxing شامل کرنے دیتی ہے، جو اس کی رسائی کو محدود کرتی ہے۔ NoNewPrivileges، ProtectSystem=strict، PrivateTmp، اور ProtectHome فعال کریں تاکہ compromise محدود دائرے میں رہے۔

یہاں ایک hardened unit تیار کریں، پھر اسے /etc/systemd/system/hermes.service میں copy کریں۔ یہ unit hermes gateway شروع کرتی ہے، جو وہ long-running process ہے جو آپ کی chat apps سے connect ہوتا ہے۔ Service enable کرنے سے پہلے installation کے بعد hermes --help چلائیں تاکہ اپنی version میں command اور binary کے path کی تصدیق ہو جائے:

ان directives کے ساتھ daemon-reload اور enable --now کے steps کی وضاحت program کو systemd service کے طور پر چلانا میں کی گئی ہے:

sudo systemctl daemon-reload
sudo systemctl enable --now hermes

اسی pattern کی کسی دوسرے agent پر مکمل مثال کے لیے dsh کو systemd کے تحت headless چلانا Restart rules اور journalctl commands پر زیادہ تفصیل فراہم کرتا ہے، جن کی ضرورت پہلی مرتبہ service کے رات بھر میں بند ہونے پر ہو گی۔ اس سے بہتر یہ ہے کہ صبح تک انتظار نہ کریں: ایک OnFailure= unit جو alert آپ کے اپنے ntfy server پر بھیجتی ہے، Hermes کے restart کی کوشش ترک کرتے ہی آپ کے phone پر notification پہنچا دیتی ہے۔

اگر آپ native install کے بجائے systemd سے container کی نگرانی کروانا چاہتے ہیں تو KiroCrew کو pinned container کے طور پر فعال رکھنا بھی reboot کے بعد چلنے کا یہی نتیجہ دیتا ہے، جبکہ image version کو تبدیل ہونے سے روکتا ہے۔

اسے مدنظر رکھتے ہوئے سرور کو مزید محفوظ بنائیں

آخر میں بیرونی رسائی کے دروازے کو محفوظ بنائیں۔ SSH میں صرف key-based authentication فعال کریں اور root login غیر فعال کریں، جیسا کہ VPS پر SSH کو محفوظ بنانا میں بیان کیا گیا ہے۔ اس طرح وہ account جس سے آپ سرور manage کرتے ہیں، اندازے سے معلوم نہیں کیا جا سکے گا۔ ایسا agent جو مستقل memory محفوظ رکھتا ہو، تحفظ کا مستحق ہے۔ اس کے لیے سب سے آسان حفاظتی اقدام یہ ہے کہ کوئی بھی اس سرور میں login نہ کر سکے جہاں agent چل رہا ہے۔

سرور کو محفوظ کرنے کے بعد زیادہ تر لوگ اگلی capability کے طور پر web search شامل کرتے ہیں۔ agent کو اپنی SearXNG instance سے منسلک کرنا یہ queries آپ کے اپنے سرور پر رکھتا ہے، لیکن اس کی قیمت یہ ہے کہ agent ایسی pages حاصل کرے گا جن کی کسی نے جانچ نہیں کی۔ Hermes بھی عموماً سرور پر واحد agent نہیں ہوتا۔ اگر آپ وہاں Claude Code بھی چلاتے ہیں تو دو sessions ایک دوسرے کو براہ راست کام سونپ سکتے ہیں، اور ہر handoff کو آپ کے ذریعے route کرنے کی ضرورت نہیں رہتی۔ اگر اگلا agent آپ کی chat apps کے بجائے code پڑھتا ہے تو اسی سرور پر open-kritt کے security scans چلانا اسی طریقے کے مطابق ہے: pinned release، اس کا اپنا account، اور ایک web UI جس تک آپ open port کے بجائے SSH tunnel کے ذریعے پہنچیں۔

اگر آپ packaged agent چلانے کے بجائے اس کے طریقۂ کار کو سمجھنا چاہتے ہیں تو VPS پر اپنا AI agent بنانا اسے مرحلہ وار بیان کرتا ہے۔ اگر اس guide کی اصطلاحات اب بھی نئی ہیں تو AI agents سیکھنے کا مرحلہ وار راستہ loop، tools، memory اور safety کو اس ترتیب سے سمجھاتا ہے جس میں یہ ایک دوسرے پر مبنی ہوتے ہیں۔ یوں Hermes کے فیصلے آپ کو جادوئی نہیں لگیں گے۔

FAQ

کیا میں Hermes Agent کو سستے VPS پر چلا سکتا ہوں؟

ہاں۔ Hermes کو چھوٹے سرور پر چلانے کے لیے بنایا گیا ہے، اور ذاتی، ہمیشہ فعال agent کے لیے $5 کا VPS کافی ہے۔ یہ بھاری network traffic فراہم کرنے کے بجائے language model اور آپ کی chat apps سے رابطہ کرتا ہے، اس لیے وسائل کا کم استعمال کرتا ہے۔ اسے اپنا user، firewall اور systemd service دیں، تو چھوٹا VPS اسے آسانی سے چلا لے گا۔ اگر آپ کے گھر میں پہلے سے کوئی machine موجود ہے، تو پہلے اس کے hardware اور بجلی کے اخراجات کا ماہانہ فیس سے موازنہ کریں، کیونکہ گھر کا Proxmox box اور کرائے کا VPS مختلف پہلوؤں میں بہتر ہوتے ہیں۔

کیا one-line install script چلانا محفوظ ہے؟

curl | bash install سہولت فراہم کرتا ہے، لیکن محفوظ طریقہ یہ ہے کہ script کو download کر کے چلانے سے پہلے پڑھیں، اور اسے root کے بجائے dedicated user کے طور پر چلائیں۔ اس طرح کسی بھی project کا piped installer اس محدود account کی اجازت سے زیادہ کچھ نہیں کر سکتا۔ یہ طریقہ صرف Hermes کے لیے مخصوص نہیں؛ اس نوعیت کے ہر install کے لیے اچھی practice ہے۔

میں Hermes کو root کے بغیر کیسے چلا سکتا ہوں؟

ایسا dedicated system user بنائیں جس کے پاس login shell نہ ہو، Hermes کو اس user کی ملکیت والی directory، مثلاً /opt/hermes، کے اندر install کریں، اور service کو اسی account کے طور پر چلائیں۔ اگر agent کبھی breached ہو جائے، تو نقصان صرف ان resources تک محدود رہے گا جن تک اس account کو رسائی حاصل ہے۔

logout کے بعد Hermes کو چلتا ہوا کیسے رکھوں؟

اسے systemd service کے طور پر چلائیں۔ unit file boot کے وقت Hermes شروع کرتی ہے، crash ہونے پر اسے دوبارہ شروع کرتی ہے، اور SSH session ختم ہونے کے بعد بھی اسے چلتا رکھتی ہے۔ اس دوران systemd کے sandboxing options اس بات کو محدود کرتے ہیں کہ process کن resources تک رسائی حاصل کر سکتا ہے۔ اوپر موجود tool سے hardened unit تیار کریں اور اسے systemctl enable --now hermes کے ذریعے enable کریں۔

کیا Hermes Agent کے لیے GPU ضروری ہے؟

نہیں۔ Hermes agent runtime ہے، language model نہیں، اس لیے یہ چھوٹے CPU-only VPS پر بھی ٹھیک چلتا ہے۔ بھاری computation وہاں ہوتی ہے جہاں model چل رہا ہوتا ہے، جو عموماً وہ hosted API ہوتی ہے جس سے آپ اسے connect کرتے ہیں۔ اگر آپ اسی box پر model کو بھی self-host کرنا چاہتے ہیں، تو machine کا سائز Hermes کے بجائے model کی ضروریات کے مطابق مقرر کریں۔ CPU-only model hosting کے لیے Ollama guide میں دیے گئے اعداد قابل اطلاق ہیں۔