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

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

Octop एक household या छोटी टीम के लिए एक self-hosted AI assistant है। Octop को केवल एक साधारण chat front end के बजाय self-host करने का कारण यह है कि यह उपयोगकर्ताओं को एक-दूसरे से अलग रखता है। Open WebUI आपको एक model के सामने एक browser interface देता है। Octop प्रत्येक उपयोगकर्ता के लिए admin role, एक private workspace और credentials का एक set जोड़ता है, साथ ही specialist agents की एक library भी देता है जिसे प्रत्येक उपयोगकर्ता हर task के अनुसार बदल सकता है। यही वह अंतर है जो एक 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 के लिए नए हैं, तो Docker Compose basics for a VPS से शुरुआत करें।
• 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 को उसी सर्वर पर चलाने की योजना बना रहे हैं, तो सर्वर का आकार model की आवश्यकतानुसार रखें।

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

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

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

हम किसी महत्वपूर्ण सर्वर पर इसकी अनुशंसा नहीं करते हैं, जिसका एक ठोस कारण यह है: वह स्क्रिप्ट रिपॉजिटरी में मौजूद नहीं है। इसे Tencent Cloud Object Storage बकेट से सर्व किया जाता है। इसके बारे में कुछ भी git tag या commit द्वारा कवर नहीं किया गया है, इसलिए आप आज की स्क्रिप्ट की तुलना पिछले सप्ताह की स्क्रिप्ट से नहीं कर सकते हैं, और कोई ऐसा इतिहास नहीं है जो किसी बदलाव की व्याख्या करे। बकेट कल अलग बाइट्स सर्व कर सकता है और प्रोजेक्ट में इसका कोई रिकॉर्ड नहीं रहेगा। परिणाम को सीधे 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 करना।

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 पर छोड़ने के बजाय किसी स्पष्ट स्थान पर सेट करें, और पहली बार 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 केवल YAML में ${...} placeholders को भरने के लिए docker/.env को पढ़ता है। यदि आप उस file में कोई key जोड़ते हैं, तो वह container तक नहीं पहुँचती जब तक कि उसे Compose file में environment: के अंतर्गत सूचीबद्ध न किया गया हो। OCTOP_ACCESS_TOKEN_TTL को केवल .env में जोड़ने से कुछ नहीं होगा, यह चुपचाप विफल हो जाएगा। दूसरा विकल्प यह है कि उन्हीं keys को mounted data directory के अंदर ~/.octop/env में लिखें, जिसे Octop startup पर load करता है। Docker Compose में env files और secrets के लिए guide विस्तार से बताती है कि ये दोनों तंत्र एक समान क्यों नहीं हैं।

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 चलाता है और शुरुआती credentials को data volume में लिखता है:

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

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

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

ऊपर दी गई ports: लाइन VPS के हर इंटरफेस को bind करती है। जैसे ही container start होता है, dashboard default password के साथ cleartext में public internet पर उपलब्ध हो जाता है। Octop का अपना OCTOP_BIND_HOST default 127.0.0.1 है; Compose file इसे बदलकर 0.0.0.0 कर देती है क्योंकि process को अपने network namespace के बाहर से traffic स्वीकार करना होता है। वह override सही है। पब्लिश किया गया port ही वह हिस्सा है जो आपको expose करता है।

docker/docker-compose.yml में ports: लाइन को edit करें ताकि mapping केवल loopback पर ही listen करे:

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

इसे केवल एक plain override file से ठीक करने का प्रयास न करें। Compose कई files से ports सूचियों को replace करने के बजाय उन्हें जोड़ (concatenate) देता है, जिससे अंत में आप दोनों mappings को पब्लिश कर देते हैं और दूसरा mapping bind होने में विफल हो जाता है। यदि आप upstream file को untouched रखना चाहते हैं, तो sequence पर !override tag का उपयोग करें, जो append करने के बजाय replace करने का documented तरीका है। Compose द्वारा कई files को merge करने की व्याख्या उन merge नियमों के बाकी हिस्सों को कवर करती है।

Loopback पर bind करना उस समस्या को भी हल करता है जिसका सामना आपको firewall के साथ करना पड़ता। Docker अपने published-port नियमों को ufw द्वारा प्रबंधित chains से पहले nat table में लिखता है, इसलिए ufw deny 8088 पब्लिश किए गए container port को नहीं रोकता है। 127.0.0.1 पर bind किया गया port बाहर से कभी भी पहुँच योग्य नहीं होता है, चाहे 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 लंबे टूल रन को कवर करता है, क्योंकि 60 सेकंड की डिफ़ॉल्ट सीमा एजेंट को कार्य के बीच में ही रोक देती है और upstream timed out (110: Connection timed out) लॉग करती है।

Proxy के पीछे JWT auth कैसे काम करता है

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

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

WebSocket URL में token ले जाता है। endpoint WS /agents/{id}/chat/ws?token=<jwt> है, क्योंकि browser JavaScript, WebSocket handshake पर Authorization header सेट नहीं कर सकता। TLS transit के दौरान उस token की सुरक्षा करता है। यह इसे आपके अपने logs से सुरक्षित नहीं करता: nginx डिफ़ॉल्ट रूप से पूरी request line, जिसमें query string भी शामिल है, को access_log में लिखता है, इसलिए एक वास्तविक user का सक्रिय token सर्वर पर एक plaintext file में चला जाता है। arguments के बिना path को log करें। $uri वह normalized path है जिसमें से query string पहले ही हटा दी गई है, इसलिए इसे 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 डिफ़ॉल्ट रूप से 86400 पर सेट होता है, इसलिए login के बाद token 24 घंटे तक वैध रहता है। इसे अमान्य करने का एकमात्र प्रलेखित तरीका octop admin rotate-jwt-secret है, जो ~/.octop/secrets/jwt_secret पर संग्रहीत signing key को rotate करता है और सभी के लिए हर सक्रिय token को तुरंत अमान्य कर देता है। इसलिए जब कोई टीम छोड़ता है, तो प्रक्रिया यह है: user को delete करें, secret को rotate करें, और फिर बाकी users को फिर से login करने के लिए कहें। यदि यह कठिन लगता है, तो lifetime को कम कर दें, और variable को environment: सूची के साथ-साथ .env में भी जोड़ना याद रखें:

OCTOP_ACCESS_TOKEN_TTL=28800

Brute force को संभाला गया है: OCTOP_LOGIN_MAX_ATTEMPTS डिफ़ॉल्ट रूप से 5 विफलताओं पर सेट है और OCTOP_LOGIN_LOCKOUT_SECONDS 900 पर, इसलिए एक locked-out user केवल पंद्रह मिनट प्रतीक्षा करता है, न कि किसी टूटे हुए install को देखता है। Octop का अपना user store है और v0.9.19 पर कोई प्रलेखित OIDC समर्थन नहीं है, इसलिए यदि आपको वास्तविक single sign-on की आवश्यकता है, तो आप इसके सामने एक authenticating proxy लगा सकते हैं, जिसके लिए एक self-hosted Authentik server का उपयोग किया जाता है।

Octop को एक मॉडल बैकएंड पर पॉइंट करें

Providers को डैशबोर्ड में प्रत्येक एजेंट के लिए कॉन्फ़िगर किया जाता है, और octop provider list आपको दिखाता है कि क्या सेट है। Octop, OpenAI-compatible APIs, DashScope (Qwen) और Ollama के लिए प्रीसेट के साथ आता है, और क्रेडेंशियल्स आपके अपने SQLite डेटाबेस की providers टेबल में स्टोर होते हैं। आपके द्वारा चुना गया विकल्प यह तय करता है कि आप कितना भुगतान करेंगे और क्या डेटा सर्वर से बाहर जाएगा।

Ollama के साथ एक लोकल मॉडल। कुछ भी सर्वर से बाहर नहीं जाता है, और आप टोकन के बजाय RAM खर्च करते हैं। वायरिंग का वह विवरण जो अक्सर लोगों को उलझाता है: एक कंटेनर 127.0.0.1:11434 पर होस्ट के Ollama तक नहीं पहुँच सकता, क्योंकि वह पता कंटेनर का अपना लूपबैक होता है। सर्विस में एक होस्ट गेटवे एंट्री जोड़ें:

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

फिर प्रोवाइडर बेस URL को http://host.docker.internal:11434/v1 पर सेट करें, जो Ollama का OpenAI-compatible पाथ है, और API की फ़ील्ड में कोई भी नॉन-एम्प्टी स्ट्रिंग डाल दें, क्योंकि Ollama इसे इग्नोर करता है लेकिन OpenAI क्लाइंट्स खाली स्ट्रिंग भेजने से मना कर देते हैं। इसके काम करने के लिए Ollama को लूपबैक से बाहर भी लिसन करना चाहिए, जिसका अर्थ है इसकी systemd यूनिट में OLLAMA_HOST=0.0.0.0:11434। यह जोखिम भरा हिस्सा है: Ollama में कोई ऑथेंटिकेशन नहीं होता है, इसलिए पब्लिक IP पर खुला 11434 पोर्ट किसी के लिए भी एक मुफ़्त मॉडल सर्वर बन सकता है जो इसे स्कैन करता है। केवल Docker की प्राइवेट रेंज, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp को अनुमति दें, और बाकी को डिनाई करें। VPS पर Ollama चलाना मॉडल साइजिंग को कवर करता है, और Ollama और vLLM की तुलना यह बताती है कि Ollama कब सही सर्वर नहीं रह जाता है।

लोकल-मॉडल के लिए एक और चेतावनी, क्योंकि यह Octop में बग जैसा दिखता है लेकिन है नहीं। एजेंट टूल्स को कॉल करके काम करते हैं, और सिस्टम प्रॉम्प्ट के साथ टूल डेफिनिशन और हिस्ट्री एक बड़ा प्रॉम्प्ट बन जाते हैं। Ollama मॉडल्स को एक सीमित डिफ़ॉल्ट कॉन्टेक्स्ट विंडो के साथ सर्व करता है, इसलिए प्रॉम्प्ट का शुरुआती हिस्सा, जहाँ टूल डेफिनिशन होते हैं, विंडो से बाहर हो जाता है। इसके बाद मॉडल टूल्स को कॉल करना बंद कर देता है या ऐसे टूल्स का आविष्कार कर लेता है जो मौजूद ही नहीं हैं। num_ctx को 16k या 32k तक बढ़ाएं और ऐसा मॉडल चुनें जो फंक्शन कॉलिंग में वास्तव में अच्छा हो।

एक सेल्फ-होस्टेड गेटवे। Octop और बाकी सब के बीच एक सेल्फ-होस्टेड LiteLLM गेटवे रखें, इससे आपको एक बेस URL, प्रति यूज़र एक अलग की, स्पेंड लिमिट्स और एक सिंगल लॉग मिलता है। आप Octop में कुछ भी एडिट किए बिना इसके पीछे का मॉडल भी बदल सकते हैं।

एक पेड API। सबसे अच्छी क्वालिटी, एक स्पष्ट ट्रेड-ऑफ़ के साथ: बातचीत का कंटेंट आपके सर्वर से बाहर निकलकर प्रोवाइडर तक पहुँचता है, जो कि सेल्फ-होस्टिंग के मुख्य उद्देश्य के विपरीत है। की को docker/.env में OPENAI_API_KEY के रूप में डालें, जिसे Compose फ़ाइल पहले से ही पास करती है।

आप जो भी चुनें, Compose फ़ाइल में OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY और LANGFUSE_BASE_URL भी शामिल हैं, ताकि आप अपने खुद के Langfuse इंस्टेंस पर ट्रेसेस भेज सकें और यह देख सकें कि एजेंट वास्तव में क्या कर रहे हैं, बजाय इसके कि चैट विंडो से अंदाज़ा लगाया जाए।

Users, roles, और shared agent library

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

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

इतनी तेजी से release होने वाले project को upgrade करना

[
  {
    "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 version अपने पिछले tag के 3 दिन बाद आया है। यह गति project के लिए एक अच्छा संकेत है, लेकिन 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 लें, क्योंकि database migrations startup पर चलते हैं और pre-1.0 project पर एक failed 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 वापस आ जाएगा, लेकिन केवल tarball ही database को वापस ला सकता है।

उस tarball में octop.db, config.json, JWT signing secret और credential.txt होते हैं, इसलिए यह उतना ही संवेदनशील है जितना कि स्वयं सर्वर। इसे mode 600 पर रखें और इसकी एक प्रति सर्वर से बाहर सुरक्षित रखें। बड़े install के लिए, project 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 tag या commit के अंतर्गत नहीं आती है। आप यह तुलना नहीं कर सकते कि यह आज क्या करती है और पिछले सप्ताह क्या करती थी, और इसे bash में पाइप करने का अर्थ है कि आप इसे पढ़ने से पहले ही चला देते हैं। यह आपके पैकेज मैनेजर के बाहर, अपने स्वयं के Python 3.12 वातावरण के साथ होस्ट पर इंस्टॉल भी हो जाती है। इसे पहले डाउनलोड करें और पढ़ें, या किसी चेक-आउट किए गए टैग से Docker Compose के साथ डिप्लॉय करें।

क्या Octop भुगतान किए गए API के बजाय स्थानीय मॉडल का उपयोग कर सकता है?

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

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

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

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

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