द्वारे Matt Connor 2026-10-20

VPS वर Octop self-host करण्याची Docker पद्धत

Docker Compose आणि v0.9.19 tag वापरून VPS वर Octop deploy करा. प्रत्येक वापरकर्त्याचे isolation, OpenAI-compatible backend, TLS आणि curl installer का टाळावा ते जाणून घ्या.

Octop म्हणजे काय आणि ते self-host का करावे

Octop हा घरासाठी किंवा छोट्या टीमसाठी self-hosted AI assistant आहे. साध्या chat front end ऐवजी Octop self-host करण्याचे कारण म्हणजे तो वापरकर्त्यांना एकमेकांपासून वेगळे ठेवतो. Open WebUI तुम्हाला model समोरील browser interface देते. Octop प्रत्येक वापरकर्त्यासाठी admin role असलेली accounts, private workspace, credential set आणि कामानुसार वापरकर्ता बदलू शकणाऱ्या specialist agents ची library देते. यामुळे एक VPS एका वापरकर्त्याऐवजी पाच लोकांना सेवा देऊ शकतो.

हा प्रकल्प github.com/TencentCloud/Octop येथे आहे. ही एकच process आहे. ती web dashboard, command line interface, chat channels (Feishu, DingTalk, QQ, Discord, WeCom) आणि scheduled jobs उपलब्ध करून देते. या सर्वांच्या मागे ~/.octop/ अंतर्गत असलेला एकच SQLite database आहे. खालील सर्व माहिती 5 August 2026 रोजी प्रकाशित झालेल्या v0.9.19 tag वर आधारित आहे. तुम्ही अजून platforms मधील निवड करत असाल, तर VPS वर चालवता येणाऱ्या Open WebUI alternatives ची तुलना अधिक व्यापक पर्याय समजावते.

तुम्ही यावर संपूर्ण संध्याकाळ खर्च करण्यापूर्वी एक गोष्ट स्पष्ट असावी. हे मार्गदर्शक लिहिले गेले तेव्हा Octop हे pre-1.0 software होते. ते vendor च्या GitHub organisation मधून प्रकाशित झाले होते आणि August 2026 पर्यंत त्याच्या repository ला सुमारे 900 stars होते. त्यानंतर 14 September 2026 रोजी त्याने v1.0.0 tag केले. 20 October 2026 रोजी उपलब्ध सर्वात नवीन tag v1.0.2 आहे. हा 18 October 2026 रोजी प्रकाशित झालेला stable release आहे आणि त्यापूर्वी 1.0.2 beta tags ची मालिका आली होती. 20 October 2026 रोजी repository ला सुमारे 10,400 stars होते. खालील पायऱ्या v0.9.19 वर आधारित आहेत आणि 1.x वर पुन्हा तपासलेल्या नाहीत. हे software वेगाने बदलते, हे version numbers वरून दिसते. येथे stable upgrade path ची कोणतीही हमी नाही. एखादा tag निश्चित करा, changelog वाचा आणि backups ठेवा.

सुरुवात करण्यापूर्वी आवश्यक गोष्टी

Docker Engine आणि Compose plugin असलेला Ubuntu 24.04 चालणारा VPS. Compose नवीन असल्यास VPS साठी Docker Compose ची मूलभूत माहिती पासून सुरुवात करा.
git, कारण तुम्ही image pull करण्याऐवजी release tag checkout करणार आहात.
VPS कडे निर्देश करणारे domain name, कारण याच्या समोर TLS (transport layer security) वापरायचे आहे.
OpenAI API शी संवाद साधणारा model backend: स्थानिक Ollama, self-hosted gateway किंवा paid key.

Octop स्वतः हलके आहे. हा एक Python process आणि SQLite file आहे. मुख्य संसाधनांचा वापर model backend करतो. त्यामुळे model त्याच server वर चालवणार असल्यास, त्या model साठी server चा आकार निश्चित करा.

curl installer ची शिफारस का करत नाही

README मध्ये एक ओळीतील install command दिली आहे:

curl -fsSL https://finnie-1258344699.cos.ap-guangzhou.myqcloud.com/octop/install.sh | bash

ज्या server ची काळजी आहे त्यावर आम्ही ही पद्धत वापरण्याची शिफारस करत नाही. याचे एक स्पष्ट कारण आहे: ही script repository मध्ये नाही. ती Tencent Cloud Object Storage bucket मधून उपलब्ध केली जाते. तिच्यावर कोणताही git tag किंवा commit लागू होत नाही. त्यामुळे आजची script मागील आठवड्यातील script शी diff करता येत नाही. बदल का झाला हे स्पष्ट करणारा कोणताही history देखील उपलब्ध नाही. उद्या bucket मधून वेगळे bytes उपलब्ध होऊ शकतात आणि project मधील कोणत्याही नोंदीत ते दिसणार नाही. परिणाम थेट bash मध्ये pipe केल्यामुळे तुम्ही एकही ओळ वाचण्यापूर्वी machine ती script चालवते.

ही installer container ऐवजी host वरही लिहिते. Python 3.12 मिळवण्यासाठी ती uv वापरते आणि तुमच्या package manager ला माहीत नसलेले environment तयार करते. त्यामुळे नंतर ते काढणे हे manually करावे लागते.

यासाठी दोन चांगले पर्याय आहेत. Script fetch करा, ती वाचा आणि मग run करा. यासाठी तीस seconds लागतात: curl -fsSL <url> -o install.sh, त्यानंतर less install.sh आणि मग bash install.sh. किंवा Docker वापरा. या guide चा उर्वरित भाग त्याबद्दल आहे. PyPI package (pip install octop) हा किमान versioned artifact आहे. तो एखाद्या release ला pin करता येतो.

Docker Compose सह Octop v0.9.19 वर pin करून deploy करा

v0.9.19 सोबत आलेली Compose फाइल repository मधून image build करते. त्यामुळे या मार्गदर्शकात आवृत्ती pin करणे म्हणजे git tag checkout करणे. प्रकाशित images उपलब्ध आहेत. v0.9.19 tree मध्ये आधीपासून docker-publish.yml workflow आहे. तो 15 July 2026 रोजी v0.9.8 मध्ये जोडला गेला. हा workflow image build करतो आणि प्रत्येक v* tag साठी तो Docker Hub वर push करतो. 20 October 2026 पर्यंत प्रकल्प GitHub च्या container registry वरही प्रकाशित करतो (docker pull ghcr.io/tencentcloud/octop:1.0.2). Checkout केलेल्या tag मधून build करणे अजून अधिक अचूक pin आहे. कारण registry tag वर विश्वास ठेवण्याऐवजी तुम्ही वाचलेला नेमका code compile करता. बहुतेक self-hosted प्रकल्पांमध्ये यापेक्षा कमी प्रक्रिया पुरेशी असते. उदाहरणार्थ, self-hosted AFFiNE workspace प्रकाशित image tag pin करते आणि तुमच्या VPS वर काहीही build करत नाही. खालील clone, checkout आणि build प्रक्रिया openGym deployment guide मध्ये दाखवलेल्या प्रक्रियेसारखीच आहे. त्यामुळे ती एकदा सेट केली असल्यास तिची रचना तुम्हाला आधीच माहीत आहे.

git clone https://github.com/TencentCloud/Octop.git
cd Octop
git checkout v0.9.19

ही फाइल परिभाषित करत असलेली service आहे. येथे फक्त महत्त्वाचे भाग दिले आहेत:

services:
  octop:
    build:
      context: ..
      dockerfile: docker/Dockerfile
    image: octop:latest
    container_name: octop
    restart: unless-stopped
    ports:
      - "${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"
    volumes:
      - ${OCTOP_DATA:-~/.octop}:/data/.octop
    environment:
      - HOME=/data
      - OCTOP_BIND_HOST=0.0.0.0
      - OCTOP_PORT=${OCTOP_PORT:-8088}
      - OCTOP_DEFAULT_PASSWORD=${OCTOP_DEFAULT_PASSWORD:-octop}
      - OCTOP_ADMIN_USERNAME=${OCTOP_ADMIN_USERNAME:-admin}
      - OPENAI_API_KEY=${OPENAI_API_KEY:-}

build: block कडे लक्ष द्या. image: octop:latest हे तुमच्या स्वतःच्या build चे नाव आहे, registry reference नाही. त्यामुळे येथे latest म्हणजे तुम्ही अलीकडे compile केलेले काहीही असू शकते. Data path स्पष्ट ठिकाणी सेट करा. तो default वर सोडू नका. पहिल्या boot पूर्वी admin account साठी खरा password सेट करा. हे docker/.env मध्ये ठेवा:

OCTOP_PORT=8088
OCTOP_ADMIN_USERNAME=admin
OCTOP_DEFAULT_PASSWORD=<a long random password>
OCTOP_DATA=/srv/octop-data

येथील एक महत्त्वाचा सापळा लक्षात ठेवा. YAML मधील ${...} placeholders interpolate करण्यासाठीच Compose docker/.env वाचते. तुम्ही त्या file मध्ये जोडलेली key Compose file मधील environment: अंतर्गत सूचीबद्ध नसेल, तर ती container पर्यंत पोहोचत नाही. फक्त .env मध्ये OCTOP_ACCESS_TOKEN_TTL जोडल्यास काहीही होत नाही. हे कोणतीही सूचना न देता घडते. पर्याय म्हणून mounted data directory मधील ~/.octop/env मध्ये त्याच keys लिहा. Octop startup वेळी त्या load करते. Docker Compose मधील env files आणि secrets वरील मार्गदर्शक या दोन यंत्रणा एकसारख्या का नाहीत, हे स्पष्ट करते.

ते build करून सुरू करा:

docker compose -f docker/docker-compose.yml up -d --build
docker compose -f docker/docker-compose.yml ps
curl http://127.0.0.1:8088/api/health

निरोगी instance health check ला {"ok":true,"started_at":...,"db":...,"users_loaded":0,"agents_running":0} सारखा JSON object परत करते. यापेक्षा वेगळे काही मिळाल्यास browser तपासण्यापूर्वी docker compose -f docker/docker-compose.yml logs -f octop वाचा.

आत्ताच build केलेल्या image ला अर्थपूर्ण नाव द्या. कारण पुढील --build octop:latest overwrite करेल आणि दोन्हीमध्ये फरक ओळखण्याचा कोणताही मार्ग उरणार नाही:

docker image tag octop:latest octop:0.9.19

पहिल्या boot वेळी octop init चालते आणि सुरुवातीची credentials data volume मध्ये लिहिते:

docker exec -it octop cat /data/.octop/credential.txt

Default values admin / octop आहेत. त्या फक्त पहिल्या init वेळी लागू होतात. लोक वारंवार विचारतात त्या प्रश्नामागची यंत्रणा हीच आहे: container एकदा सुरू झाल्यानंतर OCTOP_DEFAULT_PASSWORD बदलल्यास काहीही बदलत नाही, कारण account आधीच तयार झालेले असते. त्याऐवजी dashboard मधून password बदला.

पोर्ट 8088 सार्वजनिक करू नका

वरील ports: ओळ VPS वरील प्रत्येक interface शी bind होते. Container सुरू होताच dashboard cleartext मध्ये, default password सह, सार्वजनिक internet वर उपलब्ध होते. Octop चा स्वतःचा OCTOP_BIND_HOST default 127.0.0.1 आहे; Compose file मध्ये तो 0.0.0.0 असा override केला आहे, कारण process ने स्वतःच्या network namespace बाहेरील traffic स्वीकारणे आवश्यक आहे. हा override योग्य आहे. तुम्हाला धोक्यात आणणारा भाग म्हणजे published port.

docker/docker-compose.yml मधील ports: ओळ संपादित करून mapping फक्त loopback वर ऐकेल अशी करा:

    ports:
      - "127.0.0.1:${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"

हे plain override file वापरून दुरुस्त करण्याचा प्रयत्न करू नका. Compose अनेक files मधील ports lists एकत्र करते; त्या replace करत नाही. त्यामुळे दोन्ही mappings प्रकाशित होतात आणि दुसरी mapping bind होण्यात अपयशी ठरते. Upstream file अपरिवर्तित ठेवायची असल्यास sequence वर !override tag वापरा. Append करण्याऐवजी replace करण्याची ही documented पद्धत आहे. Compose अनेक files कशा merge करते याचे स्पष्टीकरण या merge rules विषयी उर्वरित माहिती देते.

Loopback शी bind केल्याने firewall शी संबंधित समस्या देखील दूर होते. Docker published-port rules ufw व्यवस्थापित करत असलेल्या chains च्या आधी nat table मध्ये लिहितो. त्यामुळे ufw deny 8088 published container port थांबवत नाही. Docker Engine 28.0.0 किंवा त्यानंतरच्या आवृत्तीत 127.0.0.1 शी bind केलेला port ufw च्या configuration कडे दुर्लक्ष करून बाहेरून reachable होत नाही. म्हणून हा दुसऱ्या क्रमांकाचा पर्याय नसून योग्य उपाय आहे. जुन्या Engine releases मध्ये तुमच्या provider च्या switch वरील इतर machines सारख्या त्याच L2 segment वरील hosts ना localhost वर प्रकाशित केलेले ports reachable होत. त्यामुळे `docker version` चालवा आणि server वर 28 पेक्षा कमी आवृत्ती असल्यास upgrade करा.

Reverse proxy सह TLS समोर ठेवा

Caddy हा सर्वात सोपा मार्ग आहे, कारण तो स्वतःहून ACME (automatic certificate management environment) द्वारे प्रमाणपत्राची विनंती करतो आणि स्वतंत्रपणे सांगण्याची गरज नसताना WebSocket requests proxy करतो:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

Octop WebSocket द्वारे chat stream करत असल्यामुळे nginx साठी अधिक काळजीपूर्वक configuration आवश्यक आहे:

server {
    listen 443 ssl;
    server_name octop.example.com;

    ssl_certificate     /etc/letsencrypt/live/octop.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/octop.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8088;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

तेथील प्रत्येक ओळ विशिष्ट काम करते. Chat WS /api/agents/{id}/chat/ws वर चालतो. त्यामुळे proxy_http_version 1.1 आणि दोन upgrade headers नसतील, तर nginx upgrade प्रयत्नाला 400 Bad Request ने उत्तर देतो. Dashboard नेहमीप्रमाणे load होतो, पण तुम्ही पाठवलेला प्रत्येक message page वर कोणतीही error न दाखवता कायम अडकून राहतो. proxy_buffering off महत्त्वाचे आहे, कारण human-in-the-loop resume endpoint text/event-stream परत करतो. Proxy buffer मध्ये साठवलेले SSE (server-sent events) streaming पद्धतीने येण्याऐवजी शेवटी एकाच वेळी येतात. दीर्घकाळ चालणाऱ्या tool runs साठी proxy_read_timeout आवश्यक आहे. 60 second चा default timeout agent ला task पूर्ण होण्यापूर्वीच थांबवतो आणि logs मध्ये upstream timed out (110: Connection timed out) नोंदवतो.

प्रॉक्सीमागे JWT प्रमाणीकरण कसे कार्य करते

Octop bearer token द्वारे प्रमाणीकरण करते; cookie द्वारे नाही. POST /api/auth/login हे {access_token, role, user, ...} परत करते आणि त्यानंतरच्या विनंत्यांमध्ये Authorization: Bearer <access_token> पाठवले जाते. Reverse proxy साठी ही चांगली बाब आहे: cookie domain, Secure flag किंवा चुकीचे कॉन्फिगर होऊ शकणारा SameSite नियम येथे नसतो. त्यामुळे http://127.0.0.1:8088 वर कार्य करणारे session https://octop.example.com वरही त्याच प्रकारे कार्य करते.

प्रत्यक्ष वापरकर्ते जोडण्यापूर्वी दोन परिणाम लक्षात ठेवणे आवश्यक आहे.

WebSocket मध्ये token URL मध्ये पाठवले जाते. Endpoint WS /api/agents/{id}/chat/ws?token=<jwt> आहे, कारण browser JavaScript ला WebSocket handshake वर Authorization header सेट करता येत नाही. TLS या token चे network traffic मधील संरक्षण करते. मात्र ते तुमच्या स्वतःच्या logs पासून त्याचे संरक्षण करत नाही: nginx पूर्ण request line, त्यातील query string सहित, defaultनुसार access_log मध्ये लिहितो. त्यामुळे प्रत्यक्ष वापरकर्त्याचा कार्यरत token server वरील plaintext file मध्ये साठतो. Arguments शिवाय path log करा. $uri हा query string आधीच काढलेला normalised path आहे. त्यामुळे तो http block मध्ये ठेवा आणि server मधून reference करा:

log_format octop_noargs '$remote_addr [$time_local] '
                        '"$request_method $uri $server_protocol" '
                        '$status $body_bytes_sent';
access_log /var/log/nginx/octop.log octop_noargs;

प्रत्येक session साठी logout उपलब्ध नाही. OCTOP_ACCESS_TOKEN_TTL चे default मूल्य 86400 आहे. त्यामुळे login केल्यानंतर token 24 तास वैध राहतो. एखादा token invalid करण्याचा documented एकमेव मार्ग octop admin rotate-jwt-secret आहे. यामुळे ~/.octop/secrets/jwt_secret येथे साठवलेली signing key बदलते आणि सर्व विद्यमान tokens सर्व वापरकर्त्यांसाठी तत्काळ invalid होतात. त्यामुळे एखादी व्यक्ती team मधून बाहेर पडल्यावर क्रम असा ठेवा: त्या वापरकर्त्याला delete करा, secret rotate करा आणि उर्वरित वापरकर्त्यांना पुन्हा login करण्यास सांगा. हे अवघड वाटत असल्यास lifetime कमी करा. तसेच variable environment: list मध्ये आणि .env मध्येही जोडा:

OCTOP_ACCESS_TOKEN_TTL=28800

Brute-force प्रयत्न हाताळले जातात: OCTOP_LOGIN_MAX_ATTEMPTS चे default मूल्य 5 failures आणि OCTOP_LOGIN_LOCKOUT_SECONDS चे default मूल्य 900 आहे. त्यामुळे locked-out वापरकर्ता broken install समजून पाहत बसत नाही; तो फक्त पंधरा मिनिटे प्रतीक्षा करतो. Octop कडे स्वतःचा user store आहे आणि v0.9.19 मध्ये documented OIDC support नाही. त्यामुळे तुम्हाला वास्तविक single sign-on आवश्यक असल्यास त्याच्या समोर authenticating proxy ठेवा. self-hosted Authentik server यासाठीच वापरता येतो.

मॉडेल backend कडे Octop निर्देशित करा

Dashboard मध्ये प्रत्येक agent साठी providers configure केले जातात आणि octop provider list मध्ये सध्या काय सेट केले आहे ते दिसते. Octop मध्ये OpenAI-compatible APIs, DashScope (Qwen) आणि Ollama साठी presets दिलेले आहेत. Credentials तुमच्या स्वतःच्या SQLite database मधील providers table मध्ये साठवले जातात. या निवडीमुळे तुमचा खर्च आणि server च्या बाहेर जाणारी माहिती बदलते.

Ollama वापरून स्थानिक मॉडेल. कोणतीही माहिती server च्या बाहेर जात नाही. त्याऐवजी tokens साठी पैसे देण्याऐवजी RAM वापरली जाते. येथे एक महत्त्वाचा wiring तपशील आहे: container ला host वरील Ollama च्या 127.0.0.1:11434 पर्यंत पोहोचता येत नाही, कारण तो address container च्या स्वतःच्या loopback कडे निर्देश करतो. Service मध्ये host gateway entry जोडा:

    extra_hosts:
      - "host.docker.internal:host-gateway"

त्यानंतर provider चा base URL http://host.docker.internal:11434/v1 असा सेट करा. हा Ollama चा OpenAI-compatible path आहे. API key field मध्ये कोणतीही रिकामी नसलेली string द्या. Ollama ती दुर्लक्षित करते, पण OpenAI clients रिकामी key पाठवण्यास नकार देतात. हे कार्य करण्यासाठी Ollama ने loopback पलीकडेही listen केले पाहिजे. यासाठी त्याच्या systemd unit मध्ये OLLAMA_HOST=0.0.0.0:11434 आवश्यक आहे. हा धोकादायक भाग आहे: Ollama मध्ये authentication नाही. त्यामुळे public IP वर उघडा 11434 port ठेवला, तर प्रथम scan करणाऱ्या कोणासाठीही तो विनामूल्य model server ठरतो. फक्त Docker ची private range, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp, परवानगी द्या आणि उर्वरित traffic नाकारा. VPS वर Ollama चालवणे यात model sizing समजावले आहे. Ollama आणि vLLM ची तुलना यात Ollama योग्य server कधी राहत नाही हे स्पष्ट केले आहे.

स्थानिक model बाबत आणखी एक इशारा आवश्यक आहे. हे Octop मधील bug सारखे दिसते, पण ते bug नाही. Agents tools call करून काम करतात. System prompt, tool definitions आणि history मिळून मोठा prompt तयार होतो. Ollama models साठी माफक default context window वापरतो. त्यामुळे tool definitions असलेला prompt चा सुरुवातीचा भाग window मधून बाहेर पडतो. त्यानंतर model tools call करणे थांबवतो किंवा अस्तित्वात नसलेली tools तयार करतो. num_ctx हे 16k किंवा 32k पर्यंत वाढवा आणि function calling मध्ये प्रत्यक्ष चांगले असलेले model निवडा. वाक्याच्या मध्यावर थांबणारे उत्तर ही उलट समस्या आहे आणि तिच्यासाठी वेगळी setting, num_predict, वापरली जाते. त्यामुळे उत्तरे truncated येत असल्यास agent ला दोष देण्यापूर्वी num_predict कुठे सेट केले आहे आणि done_reason मध्ये काय आहे ते तपासा. Shortlist ऐवजी एखाद्या विशिष्ट candidate पासून सुरुवात करायची असल्यास Nemotron 3.5 Lightning वापरून पाहता येईल. त्या लेखात pull करण्यासाठी अचूक tag, आवश्यक RAM आणि CPU-only कार्यक्षमता पुरेशी राहते का हे दिले आहे.

Self-hosted gateway. Octop आणि इतर सर्व घटकांच्या मध्ये self-hosted LiteLLM gateway ठेवल्यास एक base URL, प्रत्येक user साठी स्वतंत्र key, spend limits आणि एकच log मिळतो. Octop मध्ये काहीही संपादित न करता gateway मागील model देखील बदलता येतो.

Paid API. गुणवत्ता सर्वोत्तम असते, पण त्यासाठी स्पष्ट तडजोड करावी लागते: conversation content तुमच्या server मधून बाहेर जाऊन provider पर्यंत पोहोचते. Self-hosting करण्यामागील मुख्य कारणांपैकी हेच एक आहे. Key docker/.env मध्ये OPENAI_API_KEY या स्वरूपात द्या. Compose file ती आधीच पुढे pass करते.

तुम्ही कोणताही पर्याय निवडला तरी Compose file मध्ये OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY आणि LANGFUSE_BASE_URL देखील असतात. त्यामुळे traces तुमच्या स्वतःच्या Langfuse instance कडे पाठवता येतात आणि chat window वरून अंदाज बांधण्याऐवजी agents प्रत्यक्ष काय करत आहेत ते पाहता येते.

वापरकर्ते, भूमिका आणि सामायिक agent library

पहिल्या boot वेळी तयार केलेले admin खाते इतर खाती तयार करून त्यांचे व्यवस्थापन करते. प्रत्येक वापरकर्त्याला स्वतःचे agents, workspace आणि credentials मिळतात. ही विलगीकरण व्यवस्था browser कडे असलेल्या token मुळे लागू राहते. यासोबत skills आणि sub-agents चा एक सामायिक pool असतो, जो कोणताही वापरकर्ता वापरू शकतो. कुटुंबासाठी हे चालवण्याचा मुख्य फायदा हाच आहे: एक व्यक्ती चांगला research agent एकदाच तयार करते आणि इतर कोणालाही तो पुन्हा तयार करावा लागत नाही.

tooling वापरताना काळजी घ्या. Octop मध्ये tool approval आणि shell command guardrails असल्याचे सांगितले जाते. दोन्ही प्रत्यक्षात उपलब्ध आहेत. मात्र shell commands चालवणारा agent ते commands तुमचा data volume mounted असलेल्या Octop container मध्ये चालवतो. Guardrails मुळे निष्काळजी prompt मुळे होणारी संभाव्य हानी कमी होते. मात्र ते sandbox boundary नाहीत. त्यामुळे ज्याला तुम्ही shell access देणार नाही अशा कोणत्याही वापरकर्त्यासाठी tool approval सुरू ठेवा. इतर पर्यायांचा विचार करत असल्यास, self-hosted AI agents ची तुलनात्मक माहिती प्रत्येक पर्यायात ही बाब कशी हाताळली जाते याची तुलना करते.

जलद गतीने releases देणाऱ्या प्रकल्पाचे upgrade

तक्ताDays between Octop releases, v0.9.16 to v0.9.19 (repository tags, 7 August 2026)

version

days_since_previous_release

v0.9.16

v0.9.17

v0.9.18

v0.9.19

या तक्त्यामागील डेटा

[
  {
    "version": "v0.9.16",
    "days_since_previous_release": 2
  },
  {
    "version": "v0.9.17",
    "days_since_previous_release": 3
  },
  {
    "version": "v0.9.18",
    "days_since_previous_release": 1
  },
  {
    "version": "v0.9.19",
    "days_since_previous_release": 3
  }
]

7 August 2026 पर्यंत repository मधील tag dates अशा आहेत. नऊ दिवसांत 4 tagged releases आले. त्यांपैकी दोन releases मधील अंतर किमान 1 day होते. तसेच v0.9.19 हा tag त्याच्या आधीच्या tag नंतर 3 days ने आला. ही cadence प्रकल्पासाठी चांगली बाब आहे. पण latest चालवण्यासाठी ती पुरेसे कारण नाही. ते स्वीकारण्यापूर्वी बदल वाचा:

cd Octop
git fetch --tags
git tag --sort=-creatordate | head
NEW_TAG=$(git tag --sort=-creatordate | head -1)
git log --oneline "v0.9.19..$NEW_TAG"

$NEW_TAG मध्ये नेमके काय आहे हे checkout करण्यापूर्वी तपासा. या प्रकल्पाच्या tags मध्ये stable releases सोबत v1.0.2b9 सारखे betas देखील आहेत. 20 October 2026 रोजी नवीनतम tag stable v1.0.2 आहे. तो 18 October 2026 रोजी प्रकाशित झाला. v0.9.19 पासून v1.0.0, जो 14 September 2026 रोजी release झाला, हा टप्पा पार होतो. त्यामुळे हा log मोठा आहे आणि तो काळजीपूर्वक वाचणे आवश्यक आहे.

प्रत्येक वेळी आधी backup घ्या. Startup वेळी database migrations चालतात. इतक्या जलद releases देणाऱ्या प्रकल्पातील migration अयशस्वी झाल्यास त्यातून बाहेर पडण्याची जबाबदारी तुमची असते:

docker compose -f docker/docker-compose.yml stop
sudo tar czf octop-backup-$(date +%F).tgz -C /srv octop-data
docker compose -f docker/docker-compose.yml start

त्यानंतर नवीन tag checkout करा आणि docker compose -f docker/docker-compose.yml up -d --build वापरून पुन्हा build करा. काही चूक झाल्यास जुना tag checkout करून पुन्हा build केल्याने code परत मिळतो. मात्र database फक्त tarball मधूनच परत मिळतो.

त्या tarball मध्ये octop.db, config.json, JWT signing secret आणि credential.txt असतात. त्यामुळे ते server इतकेच संवेदनशील आहे. त्याचा mode 600 ठेवा आणि त्याची एक copy server च्या बाहेर ठेवा. मोठ्या installation साठी प्रकल्प docker/docker-compose.postgres.yml देखील देतो. ते SQLite ऐवजी pgvector सह PostgreSQL चालवते.

अपयशाच्या स्थिती आणि दिसणारे संदेश

Health check ला कधीही उत्तर मिळत नाही. curl http://127.0.0.1:8088/api/health अडकते किंवा विनंती नाकारते. docker compose -f docker/docker-compose.yml logs -f octop वाचा. First init दरम्यान बंद होणारा container सहसा data directory मध्ये लिहू शकत नाही. त्यामुळे OCTOP_DATA साठी सेट केलेल्या स्थानाचा ownership तपासा.

Dashboard लोड होते, पण chat अडकते. पृष्ठावर कोणतीही error दिसत नाही आणि कधीही reply येत नाही. Browser console उघडा आणि wss://octop.example.com/api/agents/.../chat/ws शी अयशस्वी connection शोधा. Proxy upgrade पुढे पाठवत नाही. proxy_http_version 1.1 तसेच Upgrade आणि Connection headers जोडा.

संपूर्ण reply काही सेकंद उशिराने एकाच वेळी दिसतो. Streaming कार्यरत आहे, पण buffering सुरू आहे. proxy_buffering off सेट करा.

bind: address already in use. 8088 आधीच दुसरी प्रक्रिया वापरत आहे. sudo ss -tlnp | grep 8088 तिचे नाव दाखवते. मूळ entry संपादित करण्याऐवजी override file मध्ये दुसरी ports entry जोडल्यासही हेच घडते.

योग्य password नाकारला जातो. 5 चुकीचे प्रयत्न केल्यावर 900 सेकंदांचा lockout लागू होतो. पुन्हा install करण्याऐवजी तो कालावधी पूर्ण होईपर्यंत प्रतीक्षा करा.

.env मधील नवीन password लागू झाला नाही. ही credentials फक्त first init वेळी लागू होतात. Dashboard मध्ये password बदला.

Agent reply देतो, पण tool कधीही चालवत नाही. हे जवळजवळ नेहमी local model ची समस्या असते: tool definitions साठी context window खूप लहान असते किंवा model function calling मध्ये कमकुवत असतो. num_ctx वाढवा आणि tool use साठी तयार केलेले model वापरून पाहा.

FAQ

Octop हे Open WebUI चा पर्याय आहे का?

त्यात असलेली अतिरिक्त वैशिष्ट्ये तुम्हाला आवश्यक असतील तरच. Open WebUI हे model समोरील chat interface आहे आणि एका व्यक्तीसाठी किंवा परस्परविश्वास असलेल्या कुटुंबासाठी ते काम चांगले करते. Octop मध्ये admin role असलेली accounts, प्रत्येक वापरकर्त्यासाठी स्वतंत्र workspaces आणि credentials, तसेच specialist agents ची बदलता येणारी library मिळते. त्यामुळे अनेक लोक एकाच server चा वापर करू शकतात, पण त्यांना एकच history share करावी लागत नाही. तुमच्यासाठी एकच account पुरेसे असेल, तर Open WebUI हा अधिक सोपा आणि बराच अधिक परिपक्व पर्याय आहे.

Octop चे curl install script का वापरू नये?

हे script repository ऐवजी Tencent Cloud Object Storage bucket मधून दिले जाते. त्यामुळे ते कोणत्याही git tag किंवा commit च्या नियंत्रणाखाली नसते. ते आज काय करते आणि मागील आठवड्यात काय करत होते यांची तुलना तुम्ही करू शकत नाही. तसेच ते bash मध्ये pipe केल्यास ते वाचण्यापूर्वीच execute होते. हे script तुमच्या package manager च्या बाहेर, स्वतःच्या Python 3.12 environment सह host वर install करते. ते आधी download करून वाचा किंवा checked-out tag मधून Docker Compose वापरून deploy करा.

Octop सशुल्क API ऐवजी local model वापरू शकते का?

होय. Octop हे OpenAI-compatible APIs वापरते आणि त्यामध्ये Ollama preset उपलब्ध आहे. त्यामुळे container मध्ये extra_hosts: ["host.docker.internal:host-gateway"] जोडून आणि host वर OLLAMA_HOST=0.0.0.0:11434 सेट केल्यानंतर ते http://host.docker.internal:11434/v1 कडे निर्देशित करता येते. Docker च्या address range साठी firewall मध्ये port 11434 उघडा, कारण Ollama मध्ये स्वतःचे authentication नाही. Ollama मधील num_ctx हे 16k किंवा त्याहून अधिक करावे लागू शकते. Agent prompts मधील tool definitions मुळे default context window ची मर्यादा ओलांडते आणि त्यानंतर model tools कॉल करणे थांबवते.

मला reverse proxy आवश्यक आहे का, की port 8088 उघडू शकतो?

तुम्हाला proxy आवश्यक आहे. Octop ची उपलब्ध Compose file कोणत्याही interface वर 8088 प्रकाशित करते आणि TLS वापरत नाही. त्यामुळे passwords आणि bearer tokens इंटरनेटवर cleartext स्वरूपात पाठवले जातील. Published port 127.0.0.1:8088:8088 वर बदला आणि certificate सह Caddy किंवा nginx समोर ठेवा. nginx वापरत असल्यास WebSocket upgrade headers forward करा आणि proxy_buffering off सेट करा. अन्यथा page load होईल, पण chat कोणताही प्रतिसाद न देता शांतपणे अडकून राहील.

Octop production साठी तयार आहे का?

August 2026 पर्यंत ते pre-1.0 अवस्थेत होते आणि दर आठवड्याला अनेक tagged releases प्रकाशित होत होते. 14 September 2026 रोजी त्याने v1.0.0 tag केले. त्यानंतर 18 October 2026 रोजी stable v1.0.2 प्रकाशित करण्यापूर्वी 1.0.2 beta tags ची मालिका प्रकाशित झाली. हा वेग अजूनही जास्त आहे. त्यामुळे त्याला स्थिर झालेले software न मानता आशादायक software म्हणून पाहा. Exact tag pin केल्यास, प्रत्येक upgrade पूर्वी commit log वाचल्यास आणि प्रत्येक rebuild पूर्वी data volume चा backup घेतल्यास कुटुंबासाठी किंवा छोट्या अंतर्गत team साठी त्याचा वापर करता येतो. ते latest वर चालवू नका आणि सध्या त्यात customer data ठेवू नका.

हा लेख उपयुक्त होता का?

#octop#self-hosting #ai-assistant #docker-compose #ollama