VPS वर Agentlas OS self-host कसे करावे

Agentlas OS नेमके काय आहे

Agentlas OS हे open source agent runtime आहे. हे specialist agents डिस्कवर packages म्हणून ठेवते आणि प्रत्येक task साठी तात्पुरता orchestrator तयार करते. Linux VPS वरील तुमच्या स्वतःच्या user account मध्ये ते install करून self-host करता येते. ही service नाही. यात daemon, listening port, web interface किंवा repository मध्ये container image नाही.

या शेवटच्या वाक्यामुळे या पृष्ठावरील इतर सर्व बाबी ठरतात. बहुतेक multi-agent systems कायम सुरू असलेली supervisor process चालवतात आणि agents तिच्याकडे ठेवतात. Agentlas याच्या उलट पद्धतीने काम करते: specialists हे स्थिर files असतात आणि orchestrator केवळ task सुरू असतानाच अस्तित्वात असतो. त्यामुळे idle hub साठी memory नव्हे, तर disk space खर्च होते.

प्रकल्प त्याच्या open core ला Hephaestus म्हणतो. Commands, paths आणि environment variables मध्ये तुम्हाला हेच नाव दिसेल. Repository agentlas-ai/Agentlas-OS आहे, ते Apache-2.0 license अंतर्गत उपलब्ध आहे आणि मुख्यतः Python मध्ये लिहिलेले आहे.

हे प्रकल्प प्रत्यक्षात किती सुरुवातीच्या टप्प्यात आहे?

हे repository 4 June 2026 रोजी तयार करण्यात आले. 12 August 2026 रोजी ते सुमारे दहा आठवड्यांचे असून त्याला अंदाजे 1,150 stars आणि 112 forks आहेत. प्रत्यक्ष कामासाठी वापरायच्या साधनाच्या दृष्टीने हा कालावधी कमी आहे.

प्रकल्पाचे वयापेक्षा release cadence अधिक महत्त्वाचे आहे. Version v1.1.103 8 August 2026 रोजी प्रकाशित झाली आणि v1.2.0 12 August 2026 रोजी release झाली. म्हणजे 1.1 series मध्ये automation द्वारे शंभरपेक्षा अधिक tagged releases प्रकाशित झाल्या आहेत. काही दिवसांत अनेक releases झाल्या आहेत. या वेगाने बदलणारा प्रकल्प Tuesday आणि Thursday यांदरम्यान तुमच्या वापरातील behaviour बदलू शकतो.

म्हणून release pin करा. Installer यासाठी environment variable वाचतो आणि खालील संपूर्ण मार्गदर्शकात तो वापरला आहे. दिवसातून अनेक वेळा release करणाऱ्या प्रकल्पाचे unpinned install केल्यास त्या तासाला main वर जे उपलब्ध असेल ते install होईल.

VPS वर आवश्यक असलेल्या गोष्टी

आवश्यकता कमी आहेत, कारण पार्श्वभूमीत काहीही चालत नाही.

• Linux VPS. Ubuntu 24.04 हा योग्य आधार आहे. Installer uname -s वापरून ऑपरेटिंग सिस्टम ओळखतो आणि Linux साठी non-macOS branch वापरतो. त्यामुळे headless box समर्थित आहे.
• Box वर curl, tar आणि git तसेच कार्यरत Python interpreter.
• raw.githubusercontent.com आणि github.com कडे जाणारी outbound HTTPS कनेक्टिव्हिटी. Installer release archive डाउनलोड करून त्याचा SHA-256 तपासतो. त्यामुळे outbound कनेक्टिव्हिटी नसलेल्या box वर हे install करता येत नाही.
• Host harness. हा प्रत्यक्षात model शी संवाद साधणारा coding agent आहे. Claude Code, Codex, opencode, goose आणि Hermes हे सर्व adapters समर्थित आहेत.

तुम्हाला root आवश्यक नाही. Installer तुमच्या home directory मध्ये आणि ~/.local/bin मध्येच लिहितो. एखादा path writable नसल्यास तो abort न होता warning दाखवतो. तुम्ही अजून box निवडत असाल, तर VPS वर coding agent चालवणे या मार्गदर्शिकेत base image आणि access setup यांची माहिती दिली आहे.

पिन केलेले release install करा

upstream README मध्ये एकच command दिलेला आहे. तो main मधून script थेट bash कडे pipe करतो. तो आधी download करून वाचा. हा script तुमच्या shell configuration मध्ये आणि त्याला सापडलेल्या प्रत्येक agent harness मध्ये बदल करतो. त्यामुळे त्याकडे दहा सेकंद लक्ष देणे योग्य आहे.

curl -fsSL -o install-all-runtimes.sh \
  https://raw.githubusercontent.com/agentlas-ai/Agentlas-OS/main/scripts/install-all-runtimes.sh
less install-all-runtimes.sh
HEPHAESTUS_REF=v1.2.0 bash install-all-runtimes.sh

HEPHAESTUS_REF हा pin आहे. Script मध्ये ही ओळ version="${HEPHAESTUS_REF:-v1.2.0}" अशी आहे. त्यामुळे ते unset ठेवल्यास आज v1.2.0 मिळू शकते, पण पुढील आठवड्यात वेगळी आवृत्ती मिळेल. ते स्पष्टपणे set करा. त्यामुळे October मधील rebuild मध्ये August मध्ये तपासलेलीच आवृत्ती install होईल.

एक महत्त्वाची मर्यादा आहे. वरील script URL main चा मागोवा घेतो, तर HEPHAESTUS_REF script ने download केलेला runtime payload pin करतो. या दोन वेगळ्या गोष्टी आहेत. दोन्ही pin करण्यासाठी main ऐवजी tag मधून script fetch करा. त्या URL मध्ये main च्या जागी v1.2.0 ठेवा.

Run यशस्वी झाल्यावर script त्याने लिहिलेले paths दाखवतो. त्यात या दोन ओळी असतात:

Installed runner: /home/you/.agentlas/runtime/current/bin/hephaestus
Installed shell commands in /home/you/.local/bin (add ~/.local/bin to PATH to use them)

दुसरी ओळ अनेक जण वगळतात. नवीन Ubuntu box मध्ये ~/.local/bin बहुतेक वेळा PATH मध्ये नसतो. त्यामुळे install यशस्वी झालेले असतानाही प्रत्येक hep-* command command not found सह fail होतो. ते दुरुस्त करून पडताळा:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
hep-global status

hep-global status global router ने काय install केले आणि कोणते harnesses सापडले ते दाखवतो. तो अजिबात चालला, तर तुमचे PATH योग्य आहे.

स्थिती कुठे साठवली जाते

तुमच्या home directory अंतर्गत सर्वकाही file म्हणून साठवले जाते. त्यामुळे backup आणि migration सोपे होतात.

• ~/.agentlas/runtime/v1.2.0/ मध्ये runtime स्वतः साठवले जाते आणि ~/.agentlas/runtime/current/ ही active version कडे निर्देश करणारी symlink आहे. दोन pinned versions एकाच वेळी शेजारी ठेवता येतात.
• ~/.local/bin/ मध्ये shell wrappers साठवले जातात: hephaestus, hep-build, hep-network, hep-search, hep-storm, hep-cloud आणि hep-upload.
• ~/.agentlas/networking/memory/ मध्ये टिकाऊ memory साठवली जाते: playbook-registry.json, playbook-candidates.jsonl आणि memory-events.jsonl.
• ~/.agentlas/networking/hub-agents/<slug>/memory/experience.sqlite मध्ये प्रत्येक agent चा owner नुसार मर्यादित केलेला अनुभव साठवला जातो.
• <project>/.agentlas/ontology-runtime.sqlite मध्ये प्रत्येक project ची स्थिती साठवली जाते. त्यामुळे ती server ऐवजी repository सोबत हलते.
• ~/.cache/agentlas/python मध्ये Linux वरील Python cache साठवला जातो. macOS वेगळा path वापरते. uname नुसार installer योग्य branch निवडतो.

Memory documentation मध्ये स्पष्टपणे नमूद केले आहे की secrets, raw credentials आणि पूर्ण transcripts कोणत्याही memory scope मध्ये ठेवू नयेत. Credential values gitignored local files मध्येच ठेवाव्यात. Memory records मध्ये केवळ नावे आणि paths ठेवावेत. ~/.agentlas आणि तुमच्या project मधील .agentlas directories चा backup घेतल्यास नवीन VPS वर पुन्हा रचना उभारता येते.

कोणत्या model backend कडे ते निर्देश करू शकते

संपूर्ण रचनेचा दृष्टिकोन बदलणारा महत्त्वाचा तपशील असा आहे: Agentlas कोणत्याही model API ला थेट call करत नाही. हे काम host harness करतो.

Architecture document मध्ये प्रत्येक harness साठी एका core चे रूपांतर करणारे runtime adapters वर्णन केले आहेत. तसेच model credentials host runtime कडे असतात, असे त्यात नमूद केले आहे. Agentlas दोन interfaces उपलब्ध करून देते, जे harness वापरतो: एक AgentSkills file आणि stdio वरून संवाद साधणारा MCP (model context protocol) server. त्यामुळे "Agentlas कोणत्या models ला support करते" हा प्रश्न प्रत्यक्षात "तुमचा harness कोणत्या models ला support करतो" असा आहे. Claude Code, Codex, opencode, goose किंवा Hermes ज्या models पर्यंत पोहोचू शकतात, ते सर्व models यासाठी वापरता येतात.

Codex-style TOML config मध्ये MCP server नोंदवण्याची पद्धत पुढीलप्रमाणे आहे:

[mcp_servers.hephaestus-network]
command = "~/.agentlas/runtime/current/bin/hephaestus"
args = ["mcp", "serve"]

Install दरम्यान हाच server ~/.cursor/mcp.json, ~/.config/goose/config.yaml आणि इतर harness configs मध्ये आपोआप नोंदवला जातो. एकाच box वर असे अनेक servers जोडत असल्यास, VPS वर MCP servers चालवणे या लेखात stdio आणि process model चे अधिक सविस्तर वर्णन आहे.

स्थानिक self-hosted Ollama endpoint कडे निर्देशित करा

Harness कडे model connection असल्यामुळे Agentlas ला local models कडे निर्देशित करण्यासाठी तुमचा harness Ollama कडे निर्देशित करावा लागतो. Ollama ने यासाठीच v0.15 मध्ये launch subcommand जोडला. 11 August 2026 रोजी तो v0.32.9 मध्येही उपलब्ध आहे. यामुळे कोणतेही environment variables सेट न करता विद्यमान harness ला local models साठी configure करता येते:

ollama pull qwen3-coder:30b
ollama launch opencode

तुम्ही install केलेल्या harness नुसार opencode ऐवजी claude, codex किंवा droid वापरा. त्यानंतर local runtime मार्फत request पाठवा:

~/.agentlas/runtime/current/bin/hephaestus route "summarise the failing tests" --runtime ollama

यशस्वी route केल्यावर निवडलेल्या agent किंवा team चे नाव असलेला JSON decision मिळतो आणि त्यात receipt_id असते. उपयुक्त output मिळत नसेल, तर नेहमीचे कारण context length असते. Routing-heavy sessions साठी किमान 64k context असलेले model वापरावे, असे Agentlas documentation मध्ये सांगितले आहे. त्यात qwen3-coder, gemma3 आणि deepseek-r1 ही उदाहरणे दिली आहेत. Coding tools साठी Ollama चे स्वतःचे मार्गदर्शनही हाच 64k किमान स्तर सांगते. Routing decisions prompt मध्ये agent inventory समाविष्ट करतात. त्यामुळे 8k किंवा 32k context असलेले model ही inventory truncate करते आणि चुकीची निवड करते.

Tagline मध्ये न सांगितलेली एक मर्यादा आहे. Ollama, Gemma आणि DeepSeek यांच्याकडे स्वतःची plugin किंवा command system नाही. त्यामुळे /agentlas slash commands तेथे उपलब्ध नसतात. Local-model setup मध्ये system चालवण्यासाठी MCP server आणि hephaestus route command वापरावा लागतो. ही उपलब्ध सुविधांमधील वास्तविक घट आहे. मात्र model weights तुमच्या स्वतःच्या server वर ठेवण्याची ही प्रामाणिक किंमत आहे.

निष्क्रिय specialists च्या hub साठी लागणारी RAM

काहीही नाही. हेच संपूर्ण उत्तर आहे. यावर विश्वास ठेवण्याऐवजी तुम्ही ते स्वतः सिद्ध करू शकता.

उधार घेतलेले hub specialists प्रक्रिया म्हणून नव्हे, तर package artifacts म्हणून येतात. Specialist म्हणजे agent.md आणि JSON असलेली .agentlas/ directory यांचे संयोजन आहे: triggers आणि capabilities साठी routing-card.json, write boundaries साठी memory-map.json, आणि तो स्वतंत्रपणे चालतो की team म्हणून हे ठरवण्यासाठी mode-map.json. Hephaestus Network चे वर्णन background service शिवाय in-process scheduler असे केले आहे. Tasks दरम्यान हे स्वतः तपासा:

pgrep -af hephaestus
systemctl --user list-units --type=service | grep -i agentlas
du -sh ~/.agentlas

Idle box वर पहिल्या दोन commands काहीही output देत नाहीत, कारण memory मध्ये काहीही resident नसते. तिसरी command parked hub मुळे होणारा एकमेव खर्च दाखवते. तो disk space आहे. तुम्ही ठेवत असलेल्या specialists ची संख्या आणि runtime सोबत येणारे bundled embedding model यानुसार हा खर्च वाढतो.

म्हणून memory संबंधी प्रश्न पूर्णपणे burst वर अवलंबून आहे. Burst म्हणजे तुमचा harness आणि model backend. Harness hosted API शी संवाद साधत असल्यास resident cost काहीशे megabytes व्यापणाऱ्या एका process इतका असतो. तुम्ही weights self-host करत असल्यास मुख्य खर्च weights चा असतो:

[
  {
    "label": "Hosted API model",
    "weights_gb": 0
  },
  {
    "label": "gemma3:4b",
    "weights_gb": 3.3
  },
  {
    "label": "gemma3:12b",
    "weights_gb": 8.1
  },
  {
    "label": "gemma3:27b",
    "weights_gb": 17
  },
  {
    "label": "qwen3-coder:30b",
    "weights_gb": 19
  }
]

हे Ollama च्या model library मधील प्रकाशित download sizes आहेत. Benchmark run मधून घेतलेली मोजमापे नाहीत. वरील प्रत्येक आकड्यावर 64k context साठीचा KV cache अतिरिक्त असतो. Agentlas docs मध्ये प्रथम नमूद केलेल्या model ला, qwen3-coder:30b, context वगळता weights साठी 19 GB जागा लागते. अगदी 27B Gemma variant लाही 17 GB आवश्यक असतात. या आकड्यांच्या तुलनेत Agentlas layer स्वतः budget मध्ये दिसून येत नाही.

एका harness चालवण्याशी तुलना

Hosted API विरुद्ध एक harness चालवल्यास तुमचा VPS एक process चालवतो. Agentlas जोडल्यावर तोच एक process, तसेच files हाताळतो. Orchestrator हा स्वतंत्रपणे दीर्घकाळ चालणारा program नाही. तो disk वरील packages मधून तयार केलेला मोठा prompt असतो आणि त्यानंतर discard केला जातो.

यात बदलणारी किंमत memory ची नसून context ची आहे. अनेक specialist cards आणि त्यांचे routing metadata समाविष्ट करणारा orchestrator, bare harness पेक्षा प्रत्येक task साठी अधिक tokens वापरतो. Hosted API मध्ये याचा परिणाम RAM ऐवजी खर्चावर होतो. Local weights वापरताना परिणाम वेळेवर होतो, कारण मोठ्या prompt मुळे CPU वर prefill अधिक वेळ घेतो किंवा GPU वर अधिक भार पडतो.

म्हणून अशा box साठी sizing advice agent framework वर नव्हे, तर model च्या निर्णयावर आधारित असते. coding agent VPS साठी RAM आणि CPU चे sizing याचे सविस्तर स्पष्टीकरण देते. निष्कर्ष येथेही लागू होतो: तुम्ही चालवणार असलेल्या backend साठी plan निवडा आणि harness साठी आणखी काही gigabytes headroom ठेवा. त्याऐवजी तुलना करण्यासाठी always-on supervisor design हवे असल्यास, Omnigent multi-agent harness त्याचा coordinator resident ठेवतो. हा उलट trade-off आहे आणि idle memory मध्ये तो थेट दिसतो.

अपयशाची कारणे आणि तुम्हाला दिसणारे संदेश

hep-build: command not found स्वच्छ install नंतर लगेच दिसते. Installer ने ~/.local/bin येथे लिहिले. Default Ubuntu image मध्ये हा मार्ग PATH वर नाही. अंतिम ओळीत याची माहिती दिली होती, पण ती ओळ पुढे scroll झाली. वर दाखवलेला export जोडा.

Box पुन्हा build केल्यानंतर वर्तन बदलते. तुम्ही HEPHAESTUS_REF सेट केले नाही. त्यामुळे installer ने त्या दिवशी current असलेला tag default म्हणून वापरला. तो pin करा आणि इतर version numbers च्या शेजारी हा pin नोंदवा.

Local model वर routing चुकीच्या specialist ची निवड करते. Agent inventory साठी model ची context window खूप लहान आहे. 64k किंवा त्याहून अधिक context असलेल्या model वर जा आणि Ollama ची context length त्याच्याशी जुळवा. Default context length coding tools च्या आवश्यकतेपेक्षा कमी असते.

ollama launch ओळखले जात नाही. हा subcommand Ollama v0.15 मध्ये आला. Distribution repository मधील जुनी packages त्यापूर्वीची आहेत. त्यामुळे current Ollama install करा.

तुमच्या अपेक्षेबाहेरील harnesses मध्ये install लिहिले जाते. Script ला आढळणारे प्रत्येक harness ते detect आणि configure करते. ते ~/.claude/, ~/.codex/, ~/.gemini/, ~/.cursor/ आणि इतर ठिकाणी लिहिते. Shared build box वर script चालवण्यापूर्वी ते वाचा आणि यापैकी कोणत्या directories आवश्यक आहेत हे निश्चित करा.

हे सध्या चालवावे का

दिवसातून अनेक वेळा स्वयंचलित releases करणाऱ्या दहा आठवड्यांच्या प्रकल्पावर production workload चालवणे योग्य नाही. याची architecture खरोखरच रंजक आहे, license Apache-2.0 आहे आणि file-based design मुळे uninstall करण्यासाठी दोन directories हटवणे पुरेसे ठरते. त्यामुळे हे वापरून पाहणे स्वस्त आहे; मात्र त्यावर अवलंबून राहणे महागात पडू शकते.

सध्या योग्य पद्धत अशी आहे: v1.2.0 pin करा, पुन्हा तयार करता येईल अशा box वर ते चालवा, ~/.agentlas चा backups मध्ये समावेश ठेवा आणि pin बदलण्यापूर्वी changelog पुन्हा वाचा. या क्षेत्रातील इतर पर्याय कोणते आहेत आणि प्रत्येकाची maturity किती आहे, याचा व्यापक आढावा घेण्यासाठी self-hosted AI agents चा आढावा हा अधिक चांगला प्रारंभबिंदू आहे. Agentlas ज्या harnesses शी जुळवून घेतो, त्यांपैकी एका harness विषयी VPS वर Hermes agent self-host करणे येथे माहिती दिली आहे.

FAQ

Agentlas OS माझ्या VPS वर सर्व्हर म्हणून चालते का?

नाही. Repository मध्ये कोणताही daemon, listening port किंवा container image नाही. Installer ~/.agentlas/runtime/ अंतर्गत runtime आणि ~/.local/bin मध्ये command wrappers लिहितो. Hephaestus Network ही background service नसून in-process scheduler आहे. निष्क्रिय मशीनवर हे पडताळण्यासाठी pgrep -af hephaestus चालवा; ते काहीही output देत नाही. Enable करण्यासाठी कोणतेही systemd unit नाही. येथे self-hosting म्हणजे code आणि state तुमच्या मशीनवर असणे. याचा अर्थ एखादी service listening करत आहे असा नाही.

idle specialists असलेल्या hub साठी किती RAM लागते?

काहीही नाही, कारण idle specialists या processes नाहीत. Specialist म्हणजे agent.md file आणि .agentlas/ directory यांचे संयोजन आहे. त्या directory मध्ये routing-card.json, memory-map.json आणि तत्सम metadata असते. त्यामुळे निष्क्रिय hub साठी फक्त disk space लागते. ते du -sh ~/.agentlas ने मोजा. Memory फक्त task चालू असताना वापरली जाते. ती Agentlas layer वापरत नाही. तुमचा harness process आणि model backend memory वापरतात.

मी कोणते models वापरू शकतो? आणि ते माझ्या Ollama कडे निर्देशित करता येते का?

Agentlas स्वतः model APIs call करत नाही. Credentials आणि connection ची जबाबदारी host harness कडे असते. त्यामुळे समर्थित models म्हणजे तुमचा harness ज्या models ना support करतो ते. Local weights साठी claude, codex किंवा droid यांपैकी योग्य value देऊन ollama launch opencode चालवा. यामुळे कोणतेही environment variables न वापरता harness तुमच्या Ollama server शी configure होते. किमान 64k context असलेले model वापरा, जसे qwen3-coder किंवा gemma3. Routing prompts मध्ये agent inventory असते. लहान context window मध्ये ते मोठ्या प्रमाणात truncate होतात.

मी कोणती version install करावी? आणि येथे pinning महत्त्वाचे का आहे?

12 August 2026 रोजी current असलेली tagged release v1.2.0 install करा. त्यासाठी installer चालवण्यापूर्वी HEPHAESTUS_REF=v1.2.0 सेट करा. Script चा स्वतःचा default version="${HEPHAESTUS_REF:-v1.2.0}" आहे. तो maintainers पुढे tag करतील त्या version चा मागोवा घेतो. येथे pinning नेहमीपेक्षा अधिक महत्त्वाचे आहे. Project ने 1.1 series मध्ये शंभरहून अधिक releases प्रकाशित केल्या आहेत. काही दिवसांत अनेक releases प्रकाशित झाल्या. त्यामुळे काही आठवड्यांनी unpinned rebuild केल्यास तुम्ही test केलेली system मिळेलच असे नाही.