लेखक: Matt Connor 2026-08-07 · अपडेट किया गया: 2026-08-25

Octop AI Assistant को Docker पर कैसे self-host करें

Octop को VPS पर Docker Compose के जरिए deploy करने का तरीका जानें। इसमें per-user isolation, OpenAI-compatible backend, TLS सेटअप और curl installer से बचने की वजह दी गई है।

Octop क्या है, और आप इसे self-host क्यों करेंगे

Octop एक घर या छोटी टीम के लिए एक self-hosted AI assistant है। Octop को केवल एक साधारण chat front end के बजाय self-host करने का कारण यह है कि यह उपयोगकर्ताओं को एक-दूसरे से अलग रखता है। Open WebUI आपको एक model के सामने browser interface देता है। Octop इसमें admin role वाले accounts, प्रत्येक उपयोगकर्ता के लिए एक private workspace और credentials का set, और specialist agents की एक library जोड़ता है, जिसे प्रत्येक उपयोगकर्ता हर कार्य के लिए बदल सकता है। यही वह अंतर है जो एक VPS को एक के बजाय पांच लोगों की सेवा करने में सक्षम बनाता है।

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

इस पर एक शाम खर्च करने से पहले एक बात स्पष्ट होनी चाहिए। Octop एक pre-1.0 software है जिसे एक vendor के GitHub organisation से प्रकाशित किया गया है, और August 2026 तक इसके लगभग 900 stars हैं। यह तेजी से विकसित हो रहा है, जैसा कि इसके version numbers से पता चलता है, और यहाँ दी गई कोई भी जानकारी स्थिर upgrade path का वादा नहीं है। एक tag को pin करें, changelog पढ़ें, और backups रखें।

शुरू करने से पहले आपकी आवश्यकताएं

Ubuntu 24.04 पर चलने वाला एक VPS, जिसमें Docker Engine और Compose plugin इंस्टॉल हो। यदि आप Compose के लिए नए हैं, तो VPS के लिए Docker Compose की बुनियादी जानकारी से शुरुआत करें।
git, क्योंकि आप image pull करने के बजाय एक release tag को checkout करेंगे।
VPS पर पॉइंट करता हुआ एक domain name, क्योंकि आप इसके सामने TLS (transport layer security) चाहते हैं।
OpenAI API के अनुरूप एक model backend: एक local Ollama, एक self-hosted gateway, या एक paid key।

Octop स्वयं हल्का है। यह एक Python process और एक SQLite file है। इसका भार model backend के कारण बढ़ता है, इसलिए यदि आप model को उसी box पर चलाने की योजना बना रहे हैं, तो box का आकार model की आवश्यकतानुसार रखें।

हम curl इंस्टॉलर की अनुशंसा क्यों नहीं करते हैं

README में सबसे पहले एक लाइन का इंस्टॉलेशन कमांड दिया गया है:

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

हम किसी महत्वपूर्ण सर्वर पर इसकी अनुशंसा नहीं करते हैं, जिसका एक ठोस कारण यह है: वह स्क्रिप्ट रिपॉजिटरी में मौजूद नहीं है। इसे Tencent Cloud Object Storage बकेट से सर्व किया जाता है। इसके बारे में कुछ भी git टैग या कमिट द्वारा कवर नहीं किया गया है, इसलिए आप आज की स्क्रिप्ट की तुलना पिछले सप्ताह की स्क्रिप्ट से नहीं कर सकते हैं, और इसका कोई इतिहास नहीं है जो किसी बदलाव की व्याख्या करे। बकेट कल अलग बाइट्स सर्व कर सकता है और प्रोजेक्ट में इसका कोई रिकॉर्ड नहीं रहेगा। परिणाम को सीधे bash में पाइप करने का अर्थ यह भी है कि मशीन स्क्रिप्ट को तब चलाती है जब आपने उसकी एक भी लाइन नहीं पढ़ी होती है।

इंस्टॉलर कंटेनर के बजाय सीधे होस्ट पर लिखता है। यह Python 3.12 को लाने के लिए uv का उपयोग करता है और एक ऐसा वातावरण बनाता है जिसके बारे में आपके पैकेज मैनेजर को कोई जानकारी नहीं होती है, इसलिए बाद में इसे हटाना एक मैन्युअल कार्य बन जाता है।

इसके दो बेहतर विकल्प हैं। स्क्रिप्ट को फेच करें, उसे पढ़ें, और फिर चलाएं, जिसमें आपको तीस सेकंड लगेंगे: curl -fsSL <url> -o install.sh, फिर less install.sh, और फिर bash install.sh। या फिर Docker का उपयोग करें, जो इस गाइड का शेष भाग है। PyPI पैकेज (pip install octop) कम से कम एक वर्शन्ड आर्टिफैक्ट है जिसे आप किसी रिलीज के साथ पिन कर सकते हैं।

Docker Compose के साथ Octop को deploy करना, v0.9.19 पर पिन किया गया

अगस्त 2026 तक pull करने के लिए कोई published image उपलब्ध नहीं है। प्रदान की गई Compose file repository से image को build करती है, इसलिए version को पिन करने का अर्थ है git tag को checkout करना। यह अधिकांश self-hosted projects की तुलना में एक अतिरिक्त चरण है, क्योंकि एक self-hosted AFFiNE workspace जैसे प्रोजेक्ट्स किसी published image tag को पिन करते हैं और आपके VPS पर कुछ भी build नहीं करते हैं। नीचे दी गई clone, checkout और build की प्रक्रिया वही है जिससे the openGym deployment guide गुजरती है, इसलिए यदि आपने उसे एक बार set up कर लिया है, तो आप इसकी कार्यप्रणाली से पहले ही परिचित हैं।

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

यह वह service है जिसे file परिभाषित करती है, जिसे केवल महत्वपूर्ण भागों तक सीमित किया गया है:

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 की गई image को मिलता है, न कि कोई registry reference, इसलिए यहाँ latest का अर्थ है जो भी आपने हाल ही में compile किया है। data path को default पर छोड़ने के बजाय किसी स्पष्ट स्थान पर set करें, और पहली बार 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

यहाँ एक trap बाकी पूरी file से अधिक महत्वपूर्ण है। Compose केवल ${...} placeholders को YAML में interpolate करने के लिए docker/.env को पढ़ता है। आपके द्वारा उस file में जोड़ा गया कोई भी key container तक तब तक नहीं पहुँचता जब तक कि उसे Compose file में environment: के अंतर्गत सूचीबद्ध न किया गया हो। OCTOP_ACCESS_TOKEN_TTL को केवल .env में जोड़ने से कुछ नहीं होता, यह चुपचाप विफल हो जाता है। इसका विकल्प यह है कि उन्हीं keys को mounted data directory के अंदर ~/.octop/env में लिखें, जिसे Octop startup के समय load करता है। guide to env files and secrets in Docker Compose यह बताता है कि ये दोनों तंत्र एक ही क्यों नहीं हैं।

Build करें और इसे start करें:

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

एक healthy instance health check का उत्तर {"status":"ok","version":"..."} के साथ देता है। यदि कुछ और दिखाई दे, तो 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 चलाता है और starting credentials को data volume में लिखता है:

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

defaults admin / octop हैं, और ये केवल पहली बार init करने पर लागू होते हैं। यही वह तंत्र है जिसके बारे में लोग लगातार पूछते हैं: container के एक बार start हो जाने के बाद OCTOP_DEFAULT_PASSWORD को बदलने से कुछ नहीं बदलता, क्योंकि account पहले से ही मौजूद होता है। इसके बजाय dashboard में जाकर password बदलें।

पोर्ट 8088 को पब्लिश न करें

ऊपर दी गई ports: लाइन VPS के हर इंटरफ़ेस को बाइंड करती है। कंटेनर शुरू होते ही डैशबोर्ड डिफ़ॉल्ट पासवर्ड के साथ सार्वजनिक इंटरनेट पर क्लियरटेक्स्ट में उपलब्ध हो जाता है। Octop का अपना OCTOP_BIND_HOST डिफ़ॉल्ट 127.0.0.1 है; Compose फ़ाइल इसे बदलकर 0.0.0.0 कर देती है क्योंकि प्रोसेस को अपने नेटवर्क नेमस्पेस के बाहर से ट्रैफ़िक स्वीकार करना होता है। वह ओवरराइड सही है। पब्लिश किया गया पोर्ट ही वह हिस्सा है जो आपको जोखिम में डालता है।

docker/docker-compose.yml में ports: लाइन को एडिट करें ताकि मैपिंग केवल लूपबैक पर लिसन करे:

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

इसे केवल एक साधारण ओवरराइड फ़ाइल से ठीक करने का प्रयास न करें। Compose कई फ़ाइलों से ports सूचियों को बदलने के बजाय उन्हें जोड़ (concatenate) देता है, जिससे अंततः आप दोनों मैपिंग पब्लिश कर देते हैं और दूसरी मैपिंग बाइंड होने में विफल हो जाती है। यदि आप अपस्ट्रीम फ़ाइल को बिना छुए रखना चाहते हैं, तो सीक्वेंस पर !override टैग का उपयोग करें, जो जोड़ने के बजाय बदलने का दस्तावेजीकृत तरीका है। Compose द्वारा कई फ़ाइलों को मर्ज करने की व्याख्या उन मर्ज नियमों के बाकी हिस्सों को कवर करती है।

लूपबैक पर बाइंड करना उस समस्या को भी हल करता है जिसका सामना आपको अन्यथा फ़ायरवॉल के साथ करना पड़ता। Docker अपने पब्लिश किए गए पोर्ट के नियमों को ufw द्वारा प्रबंधित चेन से पहले nat टेबल में लिखता है, इसलिए ufw deny 8088 पब्लिश किए गए कंटेनर पोर्ट को नहीं रोकता है। 127.0.0.1 पर बाइंड किया गया पोर्ट बाहर से कभी भी एक्सेस नहीं किया जा सकता है, चाहे ufw कुछ भी सोचे, यही कारण है कि यह दूसरा सबसे अच्छा समाधान नहीं बल्कि सही समाधान है।

Reverse proxy के साथ TLS का उपयोग करें

Caddy सबसे सरल विकल्प है, क्योंकि यह ACME (automatic certificate management environment) के माध्यम से स्वयं certificate का अनुरोध करता है और बिना किसी अतिरिक्त निर्देश के WebSockets को proxy करता है:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx के लिए अधिक सावधानी की आवश्यकता है, क्योंकि Octop एक WebSocket पर चैट स्ट्रीम करता है:

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

वहाँ मौजूद प्रत्येक पंक्ति का एक विशिष्ट कार्य है। चैट WS /agents/{id}/chat/ws पर चलती है, इसलिए proxy_http_version 1.1 और दो upgrade headers के बिना, nginx upgrade के प्रयास का उत्तर 400 Bad Request के साथ देता है: डैशबोर्ड सामान्य रूप से लोड होता है और आपके द्वारा भेजा गया प्रत्येक संदेश बिना किसी त्रुटि के हमेशा के लिए अटक जाता है। proxy_buffering off महत्वपूर्ण है क्योंकि human-in-the-loop resume endpoint text/event-stream लौटाता है, और proxy buffer में रखे गए SSE (server-sent events) स्ट्रीम होने के बजाय अंत में एक साथ प्राप्त होते हैं। proxy_read_timeout लंबे समय तक चलने वाले tool runs को कवर करता है, क्योंकि 60 सेकंड की डिफ़ॉल्ट सीमा एक एजेंट को कार्य के बीच में ही रोक देती है और upstream timed out (110: Connection timed out) लॉग करती है।

Proxy के पीछे JWT ऑथेंटिकेशन का व्यवहार

Octop कुकी के बजाय bearer token के साथ ऑथेंटिकेट करता है। POST /api/auth/login, {access_token, role, user, ...} लौटाता है और बाद की कॉल्स में Authorization: Bearer <access_token> का उपयोग होता है। रिवर्स प्रॉक्सी के लिए यह अच्छी खबर है: इसमें कोई कुकी डोमेन, Secure फ्लैग या SameSite नियम गलत होने की संभावना नहीं है, इसलिए जो सेशन http://127.0.0.1:8088 पर काम करता था, वह https://octop.example.com पर भी वैसा ही व्यवहार करेगा।

वास्तविक उपयोगकर्ताओं को इस पर लाने से पहले दो परिणामों को जानना आवश्यक है।

WebSocket URL में टोकन ले जाता है। एंडपॉइंट WS /agents/{id}/chat/ws?token=<jwt> है, क्योंकि ब्राउज़र JavaScript, WebSocket हैंडशेक पर Authorization हेडर सेट नहीं कर सकता। TLS ट्रांज़िट के दौरान उस टोकन की सुरक्षा करता है। यह इसे आपके अपने लॉग्स से सुरक्षित नहीं करता है: nginx डिफ़ॉल्ट रूप से पूरी रिक्वेस्ट लाइन, जिसमें क्वेरी स्ट्रिंग भी शामिल है, को access_log में लिखता है, इसलिए एक वास्तविक उपयोगकर्ता का सक्रिय टोकन सर्वर पर एक प्लेनटेक्स्ट फ़ाइल में चला जाता है। लॉग में केवल पाथ रखें, आर्गुमेंट्स नहीं। $uri वह नॉर्मलाइज्ड पाथ है जिसमें से क्वेरी स्ट्रिंग पहले ही हटा दी गई है, इसलिए इसे http ब्लॉक में रखें और सर्वर से इसे रेफरेंस करें:

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;

इसमें प्रति-सेशन लॉगआउट की सुविधा नहीं है। OCTOP_ACCESS_TOKEN_TTL डिफ़ॉल्ट रूप से 86400 पर सेट होता है, इसलिए लॉगिन के बाद टोकन 24 घंटे तक वैध रहता है। इसे अमान्य करने का एकमात्र प्रलेखित तरीका ~/.octop/secrets/jwt_secret पर संग्रहीत साइनिंग की (signing key) को रोटेट करना है, जो octop admin rotate-jwt-secret के माध्यम से होता है और सभी के लिए हर सक्रिय टोकन को तुरंत अमान्य कर देता है। इसलिए जब कोई टीम छोड़ता है, तो प्रक्रिया यह है: उपयोगकर्ता को हटाएं, सीक्रेट को रोटेट करें, और फिर बाकी उपयोगकर्ताओं को दोबारा लॉगिन करने के लिए कहें। यदि यह भारी लगता है, तो लाइफटाइम को कम करें, और वेरिएबल को environment: लिस्ट के साथ-साथ .env में भी जोड़ना याद रखें:

OCTOP_ACCESS_TOKEN_TTL=28800

ब्रूट फोर्स को हैंडल किया गया है: OCTOP_LOGIN_MAX_ATTEMPTS डिफ़ॉल्ट रूप से 5 विफलताओं पर सेट है और OCTOP_LOGIN_LOCKOUT_SECONDS 900 पर, इसलिए लॉक-आउट हुआ उपयोगकर्ता केवल पंद्रह मिनट प्रतीक्षा करता है, बजाय इसके कि वह एक टूटे हुए इंस्टॉलेशन को देखे। Octop का अपना यूजर स्टोर है और v0.9.19 पर कोई प्रलेखित OIDC सपोर्ट नहीं है, इसलिए यदि आपको वास्तविक सिंगल साइन-ऑन की आवश्यकता है, तो इसके सामने एक ऑथेंटिकेटिंग प्रॉक्सी लगाएं, जिसके लिए एक सेल्फ-होस्टेड Authentik सर्वर का उपयोग किया जाता है।

Octop को एक model backend पर point करें

Providers को dashboard में प्रत्येक agent के लिए configure किया जाता है, और octop provider list आपको दिखाता है कि क्या set है। Octop में OpenAI-compatible APIs, DashScope (Qwen) और Ollama के लिए presets आते हैं, और credentials आपके अपने SQLite database की providers table में store होते हैं। आपके द्वारा चुना गया विकल्प यह तय करता है कि आप क्या भुगतान करेंगे और क्या data server से बाहर जाएगा।

Ollama के साथ एक local model। कुछ भी server से बाहर नहीं जाता है, और आप tokens के बजाय RAM खर्च करते हैं। वह तकनीकी बारीकी जो अक्सर लोगों को परेशान करती है: एक container 127.0.0.1:11434 पर host के Ollama तक नहीं पहुँच सकता, क्योंकि वह address container का अपना loopback होता है। service में एक host gateway entry जोड़ें:

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

इसके बाद provider base URL को http://host.docker.internal:11434/v1 पर set करें, जो Ollama का OpenAI-compatible path है, और API key field में कोई भी non-empty string डाल दें। Ollama इसे ignore करता है, लेकिन OpenAI clients खाली key भेजने से मना कर देते हैं। इसके काम करने के लिए Ollama को loopback से बाहर भी listen करना होगा, जिसका अर्थ है इसकी systemd unit में OLLAMA_HOST=0.0.0.0:11434। यह जोखिम भरा हिस्सा है: Ollama में authentication नहीं होता है, इसलिए public IP पर खुला 11434 port किसी के लिए भी एक मुफ्त model server बन सकता है जो इसे scan करे। केवल Docker की private range, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp को अनुमति दें, और बाकी को deny करें। VPS पर Ollama चलाना model sizing को कवर करता है, और Ollama और vLLM की तुलना यह बताती है कि Ollama कब सही server नहीं रह जाता है।

local-model के लिए एक और चेतावनी, क्योंकि यह Octop में bug जैसा दिखता है लेकिन है नहीं। Agents tools को call करके काम करते हैं, और system prompt के साथ tool definitions और history एक बड़ा prompt बनाते हैं। Ollama models को एक सीमित default context window के साथ serve करता है, इसलिए prompt का शुरुआती हिस्सा, जहाँ tool definitions होती हैं, window से बाहर हो जाता है। इसके बाद model tools को call करना बंद कर देता है या ऐसे tools का आविष्कार कर लेता है जो मौजूद ही नहीं हैं। num_ctx को 16k या 32k तक बढ़ाएं और ऐसा model चुनें जो function calling में वास्तव में अच्छा हो। यदि उत्तर वाक्य के बीच में रुक जाता है, तो यह एक अलग समस्या है और इसके लिए setting num_predict जिम्मेदार है, इसलिए यदि उत्तर truncated (अधूरे) आ रहे हैं तो यह जाँच लेना कि num_predict कहाँ set है और done_reason क्या कहता है बेहतर होगा, इससे पहले कि आप agent को दोष दें। यदि आप shortlist के बजाय किसी विशिष्ट candidate से शुरुआत करना चाहते हैं, तो Nemotron 3.5 Lightning आज़माने लायक है, और वह लेख pull करने के लिए सटीक tag, आवश्यक RAM, और यह जानकारी देता है कि क्या केवल CPU से काम चल पाएगा।

एक self-hosted gateway। Octop और बाकी सब के बीच एक self-hosted LiteLLM gateway रखें, इससे आपको एक base URL, प्रति user एक अलग key, spend limits और एक ही log मिलेगा। आप Octop में कुछ भी edit किए बिना इसके पीछे का 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 पर भेज सकें और यह देख सकें कि agents वास्तव में क्या कर रहे हैं, बजाय इसके कि chat window से अनुमान लगाया जाए।

Users, roles, और shared agent library

प्रथम boot के समय बना admin account अन्य accounts को बनाता और प्रबंधित करता है। प्रत्येक user को अपने स्वयं के agents, workspace और credentials मिलते हैं, और यह अलगाव browser में मौजूद token द्वारा सुनिश्चित किया जाता है। इसके साथ ही skills और sub-agents का एक shared pool होता है जिसे कोई भी उपयोग कर सकता है। यही वह विशेषता है जो इसे परिवार के लिए उपयोगी बनाती है: एक व्यक्ति एक बार एक अच्छा research agent बनाता है, और किसी अन्य को उसे दोबारा बनाने की आवश्यकता नहीं होती।

Tooling का उपयोग करते समय सावधानी बरतें। Octop में tool approval और shell command guardrails की सुविधा है, और ये दोनों प्रभावी हैं। लेकिन, जो agent shell commands चलाता है, वह उन्हें आपके data volume के साथ Octop container के भीतर चलाता है। Guardrails केवल एक लापरवाह prompt से होने वाले नुकसान को कम करते हैं। वे कोई sandbox boundary नहीं हैं, इसलिए यदि आप किसी व्यक्ति को shell का access नहीं देना चाहते, तो उनके लिए tool approval को enable रखें। यदि आप इसकी तुलना अन्य विकल्पों से कर रहे हैं, तो self-hosted AI agents का roundup यह तुलना करता है कि प्रत्येक विकल्प इसे कैसे संभालता है।

इतनी तेजी से release होने वाले प्रोजेक्ट को अपग्रेड करना

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 दिन का रहा है, और v0.9.19 अपने पिछले tag के 3 दिन बाद आया है। यह गति प्रोजेक्ट के लिए एक अच्छा संकेत है, लेकिन 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"

हर बार, सबसे पहले बैकअप लें, क्योंकि 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 करने से कोड वापस मिल जाएगा, लेकिन केवल tarball ही database को वापस ला सकता है।

उस tarball में octop.db, config.json, JWT signing secret और credential.txt होते हैं, इसलिए यह सर्वर जितना ही संवेदनशील है। इसे mode 600 पर रखें और इसकी एक कॉपी सर्वर से बाहर सुरक्षित रखें। बड़े इंस्टॉलेशन के लिए, यह प्रोजेक्ट docker/docker-compose.postgres.yml भी प्रदान करता है, जो SQLite के बजाय pgvector के साथ PostgreSQL चलाता है।

विफलता के प्रकार और उनसे संबंधित संदेश

हेल्थ चेक कभी जवाब नहीं देता। curl http://127.0.0.1:8088/api/health हैंग हो जाता है या कनेक्शन अस्वीकार कर देता है। docker compose -f docker/docker-compose.yml logs -f octop पढ़ें। जो कंटेनर शुरुआती इनिशियलाइज़ेशन के दौरान बंद हो जाता है, वह आमतौर पर डेटा डायरेक्टरी में लिख नहीं पाता है, इसलिए उस स्थान की ओनरशिप जाँचें जिसे आपने OCTOP_DATA में सेट किया है।

डैशबोर्ड लोड होता है लेकिन चैट हैंग हो जाती है। पेज पर कोई त्रुटि नहीं है, लेकिन कोई जवाब नहीं आता। ब्राउज़र कंसोल खोलें और wss://octop.example.com/agents/.../chat/ws पर विफल कनेक्शन देखें। प्रॉक्सी अपग्रेड को फॉरवर्ड नहीं कर रहा है। proxy_http_version 1.1 और Upgrade तथा Connection हेडर जोड़ें।

पूरा जवाब एक साथ, कई सेकंड की देरी से आता है। स्ट्रीमिंग काम कर रही है, बफरिंग चालू है। proxy_buffering off सेट करें।

bind: address already in use। 8088 पोर्ट पहले से ही किसी अन्य प्रक्रिया द्वारा उपयोग में है। sudo ss -tlnp | grep 8088 इसका नाम बताता है। यदि आपने मूल फ़ाइल को संपादित करने के बजाय ओवरराइड फ़ाइल में दूसरी बार ports एंट्री जोड़ी है, तो भी आपको यही त्रुटि मिलेगी।

सही पासवर्ड अस्वीकार कर दिया गया है। पांच गलत प्रयासों के बाद 900 सेकंड का लॉकआउट लग जाता है। रीइंस्टॉल करने के बजाय प्रतीक्षा करें।

.env में नया पासवर्ड डालने का कोई असर नहीं हुआ। ये क्रेडेंशियल्स केवल पहली बार इनिशियलाइज़ेशन के समय लागू होते हैं। इसे डैशबोर्ड में बदलें।

एजेंट जवाब देता है लेकिन कोई टूल नहीं चलाता। यह लगभग हमेशा एक लोकल मॉडल की समस्या होती है: कॉन्टेक्स्ट विंडो टूल डेफिनिशन के लिए बहुत छोटी है, या मॉडल फंक्शन कॉलिंग में सक्षम नहीं है। num_ctx बढ़ाएं और टूल उपयोग के लिए बनाए गए मॉडल का प्रयास करें।

FAQ

क्या Octop, Open WebUI का विकल्प है?

केवल तभी, यदि आपको उन सुविधाओं की आवश्यकता है जो यह जोड़ता है। Open WebUI एक मॉडल के सामने एक चैट इंटरफ़ेस है और यह एक व्यक्ति या एक भरोसेमंद परिवार के लिए अपना काम बखूबी करता है। Octop एडमिन रोल वाले अकाउंट्स, प्रति-उपयोगकर्ता वर्कस्पेस और क्रेडेंशियल्स, और विशेषज्ञ एजेंट्स की एक स्विच करने योग्य लाइब्रेरी जोड़ता है, ताकि कई लोग एक ही इतिहास साझा किए बिना एक सर्वर का उपयोग कर सकें। यदि आपके लिए एक ही अकाउंट पर्याप्त है, तो Open WebUI एक सरल और कहीं अधिक परिपक्व विकल्प है।

मुझे Octop के curl इंस्टॉल स्क्रिप्ट का उपयोग क्यों नहीं करना चाहिए?

यह स्क्रिप्ट रिपॉजिटरी के बजाय Tencent Cloud Object Storage बकेट से सर्व की जाती है, इसलिए यह किसी git टैग या कमिट द्वारा कवर नहीं होती है। आप यह तुलना नहीं कर सकते कि यह आज क्या करती है और पिछले सप्ताह क्या करती थी, और इसे bash में पाइप करने से यह आपके पढ़ने से पहले ही रन हो जाती है। यह आपके पैकेज मैनेजर के बाहर, अपने स्वयं के Python 3.12 वातावरण के साथ होस्ट पर इंस्टॉल हो जाती है। इसे पहले डाउनलोड करके पढ़ें, या चेक-आउट किए गए टैग से Docker Compose के साथ डिप्लॉय करें।

क्या Octop पेड API के बजाय लोकल मॉडल का उपयोग कर सकता है?

हाँ। Octop OpenAI-compatible APIs का उपयोग करता है और इसमें Ollama प्रीसेट शामिल है, इसलिए इसे http://host.docker.internal:11434/v1 पर पॉइंट करना काम करता है, बशर्ते आप कंटेनर में extra_hosts: ["host.docker.internal:host-gateway"] जोड़ें और होस्ट पर OLLAMA_HOST=0.0.0.0:11434 सेट करें। फायरवॉल पोर्ट 11434 को Docker की एड्रेस रेंज के लिए खोलें, क्योंकि Ollama में स्वयं का कोई प्रमाणीकरण नहीं है। Ollama के num_ctx को 16k या उससे अधिक बढ़ाने की अपेक्षा रखें, क्योंकि टूल डेफिनिशन वाले एजेंट प्रॉम्प्ट डिफ़ॉल्ट कॉन्टेक्स्ट विंडो को ओवरफ़्लो कर देते हैं और फिर मॉडल टूल कॉल करना बंद कर देता है।

क्या मुझे रिवर्स प्रॉक्सी की आवश्यकता है, या मैं पोर्ट 8088 खोल सकता हूँ?

आपको प्रॉक्सी की आवश्यकता है। Octop की दी गई Compose फ़ाइल बिना TLS के हर इंटरफ़ेस पर 8088 पब्लिश करती है, इसलिए पासवर्ड और बेयरर टोकन इंटरनेट पर प्लेनटेक्स्ट में चले जाएंगे। पब्लिश किए गए पोर्ट को 127.0.0.1:8088:8088 में बदलें और सामने Caddy या nginx को सर्टिफिकेट के साथ रखें। nginx के साथ, WebSocket अपग्रेड हेडर को फॉरवर्ड करें और proxy_buffering off सेट करें, अन्यथा पेज लोड तो हो जाएगा लेकिन चैट कभी रिस्पॉन्स नहीं देगी।

क्या Octop प्रोडक्शन के लिए तैयार है?

यह 1.0 से पहले का वर्जन है और अगस्त 2026 तक प्रति सप्ताह कई टैग्ड रिलीज़ जारी कर रहा है, इसलिए इसे स्थापित के बजाय आशाजनक मानें। यदि आप एक सटीक टैग पिन करते हैं, प्रत्येक अपग्रेड से पहले कमिट लॉग पढ़ते हैं, और हर रीबिल्ड से पहले डेटा वॉल्यूम का बैकअप लेते हैं, तो यह एक परिवार या छोटी आंतरिक टीम के लिए काम करने योग्य है। इसे latest पर न चलाएं, और अभी इसमें ग्राहकों का डेटा न रखें।

#octop#सेल्फ़-होस्टिंग #ai-assistant #docker-compose #ollama