द्वारे Matt Connor 2026-08-07 · अपडेटेड 2026-08-31

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 असते. प्रत्येक वापरकर्ता कामानुसार या agents मध्ये switch करू शकतो. यामुळेच एक VPS पाच लोकांना सेवा देऊ शकतो, केवळ एका व्यक्तीला नाही.

हा project 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 रोजी released झालेल्या v0.9.19 tag वर आधारित आहे. तुम्ही अजून platforms मधील निवड करत असाल, तर VPS वर चालवता येणाऱ्या Open WebUI alternatives ची तुलना अधिक व्यापक आढावा देते.

तुम्ही यासाठी संपूर्ण संध्याकाळ खर्च करण्यापूर्वी एक गोष्ट स्पष्ट असणे आवश्यक आहे. Octop हे pre-1.0 software आहे. ते एका vendor च्या GitHub organisation मधून published झाले आहे आणि August 2026 पर्यंत त्याला सुमारे 900 stars आहेत. हे software वेगाने बदलते, हे version numbers वरूनही दिसते. स्थिर 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 deploy करा आणि v0.9.19 वर pin करा

August 2026 पर्यंत pull करण्यासाठी कोणतीही published image उपलब्ध नाही. दिलेली Compose file repository मधून image build करते. त्यामुळे version pin करण्यासाठी git tag checkout करावा लागतो. बहुतेक self-hosted प्रकल्पांपेक्षा ही एक पायरी अधिक आहे. उदाहरणार्थ, self-hosted AFFiNE workspace published 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

ही file परिभाषित करत असलेली 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 केलेली image. 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 त्या keys 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 {"status":"ok","version":"..."} सह health check ला प्रतिसाद देते. इतर कोणताही प्रतिसाद मिळाल्यास 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 स्पष्ट मजकुरात, default password सह सार्वजनिक इंटरनेटवर उपलब्ध होते. 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 वर listen करेल:

    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 करण्याचा हा दस्तऐवजीकरणात नमूद केलेला मार्ग आहे. Compose अनेक files कशा merge करते याचे स्पष्टीकरण या merge नियमांबद्दलची उर्वरित माहिती देते.

Loopback शी bind केल्याने firewall संदर्भातील अन्यथा येणारी समस्या देखील सुटते. Docker published-port rules ufw व्यवस्थापित करत असलेल्या chains च्या आधी nat table मध्ये लिहिते. त्यामुळे ufw deny 8088 published container port थांबवत नाही. 127.0.0.1 शी bind केलेला port ufw च्या configuration मध्ये काहीही असले तरी बाहेरून कधीही reachable होत नाही. म्हणून हा योग्य उपाय आहे; दुय्यम पर्याय नाही.

reverse proxy वापरून TLS समोर ठेवा

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

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

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

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;
    }
}

त्या configuration मधील प्रत्येक ओळ विशिष्ट काम करते. Chat WS /agents/{id}/chat/ws वर चालते. त्यामुळे proxy_http_version 1.1 आणि दोन upgrade headers नसतील, तर nginx upgrade प्रयत्नाला 400 Bad Request ने उत्तर देतो. Dashboard नेहमीप्रमाणे लोड होते; मात्र तुम्ही पाठवलेला प्रत्येक message पानावर कोणतीही 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 मर्यादा agent चे काम पूर्ण होण्यापूर्वी थांबवते आणि 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 /agents/{id}/chat/ws?token=<jwt> आहे, कारण browser JavaScript ला WebSocket handshake वर Authorization header सेट करता येत नाही. TLS हा token network मध्ये पाठवताना सुरक्षित ठेवतो. मात्र तो तुमच्या स्वतःच्या logs पासून सुरक्षित ठेवत नाही: nginx पूर्ण request line, query string सहित, access_log मध्ये default पद्धतीने लिहिते. त्यामुळे प्रत्यक्ष वापरकर्त्यासाठी कार्यरत token सर्व्हरवरील 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 invalidate करण्याची दस्तऐवजीकृत एकमेव पद्धत octop admin rotate-jwt-secret आहे. यामुळे ~/.octop/secrets/jwt_secret येथे साठवलेली signing key बदलते आणि सर्व वापरात असलेले tokens तात्काळ invalidate होतात. हा बदल सर्व वापरकर्त्यांना लागू होतो. त्यामुळे एखादी व्यक्ती team मधून निघून गेल्यावर क्रम असा ठेवा: user delete करा, secret rotate करा आणि उर्वरित वापरकर्त्यांना पुन्हा login करण्यास सांगा. हा उपाय कठीण वाटत असल्यास lifetime कमी करा. तसेच variable environment: यादीत आणि .env मध्येही जोडा:

OCTOP_ACCESS_TOKEN_TTL=28800

Brute-force प्रयत्नांची हाताळणी उपलब्ध आहे: OCTOP_LOGIN_MAX_ATTEMPTS चे default मूल्य 5 failures आणि OCTOP_LOGIN_LOCKOUT_SECONDS चे 900 आहे. त्यामुळे lock-out झालेला user चुकीची installation समजण्याऐवजी फक्त पंधरा मिनिटे प्रतीक्षा करतो. Octop कडे स्वतःचा user store आहे आणि v0.9.19 मध्ये OIDC support दस्तऐवजीकृत नाही. त्यामुळे खरे single sign-on आवश्यक असल्यास Octop समोर 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 देणाऱ्या प्रकल्पाचे upgrading

ChartDays 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

The data behind this chart

[
  {
    "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
  }
]

ही repository मधील tag dates आहेत, ज्या 7 August 2026 पर्यंत मोजल्या आहेत. नऊ दिवसांत 4 tagged 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"

प्रत्येक वेळी प्रथम backup घ्या. Startup वेळी database migrations चालतात. Pre-1.0 प्रकल्पातील 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 वापरून rebuild करा. काही बिघडल्यास जुना tag checkout करून rebuild केल्याने code परत मिळतो. मात्र database फक्त tarball मधूनच परत मिळतो.

त्या tarball मध्ये octop.db, config.json, JWT signing secret आणि credential.txt असतात. त्यामुळे तो serverइतकाच संवेदनशील आहे. त्याचा mode 600 ठेवा आणि त्याची एक प्रत 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 वाचा. पहिल्या initialization दरम्यान container बंद होत असेल, तर तो सहसा data directory मध्ये लिहू शकत नाही. त्यामुळे OCTOP_DATA मध्ये सेट केलेल्या स्थानाची ownership तपासा.

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

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

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

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

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

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

FAQ

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

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

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

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

Octop सशुल्क API ऐवजी स्थानिक 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 call करणे थांबवते.

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

तुम्हाला proxy आवश्यक आहे. Octop ची उपलब्ध Compose file प्रत्येक interface वर 8088 प्रकाशित करते आणि TLS वापरत नाही. त्यामुळे passwords आणि bearer tokens internet वर 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 साठी तयार आहे का?

हे pre-1.0 आहे आणि August 2026 पर्यंत दर आठवड्याला अनेक tagged releases प्रकाशित करत आहे. त्यामुळे ते स्थिर झाले आहे असे न मानता आशादायक प्रकल्प म्हणून त्याकडे पाहा. Exact tag pin करून, प्रत्येक upgrade पूर्वी commit log वाचून आणि प्रत्येक rebuild पूर्वी data volume चा backup घेऊन ते कुटुंबासाठी किंवा लहान internal team साठी वापरता येते. ते latest वर चालवू नका आणि सध्या त्यात customer data ठेवू नका.

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