ద్వారా Matt Connor 2026-10-20

Octop self-hosting: VPSపై multi-user AI assistant

VPSలో Octop v0.9.19ను Docker Composeతో tagకు pin చేసి అమలు చేయండి. ప్రతి వినియోగదారికి వేరు workspace, OpenAI-compatible backend, TLS ఉంటాయి; curl installer ఎందుకు వద్దో తెలుసుకోండి.

Octop అంటే ఏమిటి, దాన్ని స్వయంగా హోస్ట్ చేయడానికి కారణం

Octop అనేది ఒక ఇంటి లేదా చిన్న బృందం కోసం రూపొందించిన self-hosted AI assistant. సాధారణ chat front end కు బదులుగా Octop ను self-host చేయడానికి ప్రధాన కారణం, ఇది వినియోగదారులను పరస్పరం వేరుగా ఉంచడం. Open WebUI మోడల్ ముందు 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 పై పోలిక విస్తృత పరిధిని వివరిస్తుంది.

దీనిపై ఒక విషయం ముందుగానే స్పష్టంగా తెలుసుకోవాలి. ఈ guide రాసిన సమయంలో Octop అనేది 1.0కు ముందు దశలో ఉన్న software. ఇది vendor యొక్క GitHub organisation నుంచి published అయింది. August 2026 నాటికి దీనికి సుమారు 900 stars ఉన్నాయి. అప్పటి నుంచి ఇది 14 September 2026న v1.0.0 tag ను విడుదల చేసింది. 20 October 2026 నాటికి newest tag v1.0.2. ఇది 1.0.2 beta tags వరుస తర్వాత 18 October 2026న విడుదలైన stable release. Repository కు అప్పటికి సుమారు 10,400 stars ఉన్నాయి. దిగువ steps v0.9.19 ఆధారంగా రాయబడ్డాయి. వీటిని 1.xపై మళ్లీ పరీక్షించలేదు. ఈ project వేగంగా మారుతోంది; version numbers కూడా అదే చూపిస్తున్నాయి. ఇక్కడ stable upgrade path ఉంటుందని హామీ లేదు. ఒక tag ను pin చేయండి, 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 లేదా చెల్లింపు key.

Octop స్వయంగా తేలికైనది. ఇది ఒక Python process మరియు SQLite file. ఎక్కువ వనరులు model backend కు అవసరమవుతాయి. కాబట్టి model ను అదే box పై నడపాలని అనుకుంటే, model అవసరాలకు తగిన పరిమాణంలోని box ను ఎంచుకోండి.

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 ద్వారా track చేయబడదు. అందువల్ల ఈరోజు script ను గత వారం script తో diff చేయలేరు. మార్పు ఎందుకు జరిగిందో వివరించే history కూడా ఉండదు. రేపు bucket వేరే bytes ను అందించవచ్చు. ఆ విషయాన్ని project లో ఏదీ నమోదు చేయదు. ఫలితాన్ని నేరుగా bash కు pipe చేస్తే, మీరు ఒక్క పంక్తి కూడా చదవకముందే machine ఆ script ను అమలు చేస్తుంది.

ఈ installer container కు బదులుగా host పై కూడా files రాస్తుంది. ఇది Python 3.12 ను fetch చేయడానికి uv ను ఉపయోగించి, మీ package manager కు తెలియని environment ను నిర్మిస్తుంది. అందువల్ల తరువాత దాన్ని తొలగించడం manual పని అవుతుంది.

రెండు మెరుగైన ఎంపికలు ఉన్నాయి. ముందుగా script ను fetch చేసి చదివి, తరువాత అమలు చేయండి. దీనికి ముప్పై 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 file repository నుంచి image ను build చేస్తుంది. అందువల్ల ఈ guide లో version ను pin చేయడం అంటే git tag కు checkout చేయడం. Published images కూడా అందుబాటులో ఉన్నాయి. v0.9.19 tree లో ఇప్పటికే docker-publish.yml workflow ఉంది. ఇది v0.9.8 లో 15 July 2026న జోడించబడింది. ఇది image ను build చేసి ప్రతి v* tag కోసం Docker Hub కు push చేస్తుంది. 20 October 2026 నాటికి project GitHub container registry (docker pull ghcr.io/tencentcloud/octop:1.0.2)కు కూడా publish చేస్తోంది. అయినప్పటికీ checkout చేసిన tag నుంచి build చేయడం మరింత కచ్చితమైన pin. ఎందుకంటే registry tag ను నమ్మకుండా, మీరు చదివిన code నే compile చేస్తారు. ఇది చాలా self-hosted projects కంటే ఒక దశ ఎక్కువ. ఉదాహరణకు self-hosted AFFiNE workspace published image tag ను pin చేస్తుంది. మీ VPS పై ఏదీ build చేయదు. కింద ఉన్న clone, checkout మరియు build విధానం openGym deployment guide లో చూపినదే. కాబట్టి దాన్ని ఒకసారి setup చేసి ఉంటే, మొత్తం విధానం మీకు ఇప్పటికే తెలుసు.

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 చేసినది. 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

ఈ file లోని మిగతా భాగాల కంటే ఈ విషయం ముఖ్యమైనది. YAML లోని ${...} placeholders ను interpolate చేయడానికి మాత్రమే Compose docker/.env ను చదువుతుంది. ఆ file లో మీరు జోడించే key, Compose file లోని environment: కింద కూడా ఇవ్వకపోతే container కు చేరదు. OCTOP_ACCESS_TOKEN_TTL ను .env లో మాత్రమే జోడిస్తే అది పూర్తిగా పనిచేయదు. ఎలాంటి error లేకుండా విఫలమవుతుంది. ప్రత్యామ్నాయంగా, అదే 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

ఆరోగ్యంగా ఉన్న 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 విలువలు admin / octop. ఇవి మొదటి init సమయంలో మాత్రమే వర్తిస్తాయి. Container ఒకసారి ప్రారంభమైన తర్వాత OCTOP_DEFAULT_PASSWORD ను మార్చినా ఏమీ మారదు. ఎందుకంటే account ఇప్పటికే సృష్టించబడింది. Password ను dashboard లో మార్చండి.

8088 పోర్ట్‌ను public గా publish చేయవద్దు

పై ఉన్న ports: లైన్ VPSలోని ప్రతి interfaceకు bind అవుతుంది. Container ప్రారంభమైన వెంటనే dashboard cleartextలో, default passwordతో public 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పై మాత్రమే listen చేసేలా చేయండి:

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

దీన్ని సాధారణ override fileతో పరిష్కరించడానికి ప్రయత్నించవద్దు. Compose అనేక filesలోని ports listsను replace చేయకుండా కలుపుతుంది. అందువల్ల రెండు mappings publish అవుతాయి, రెండవ 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 లేదా ఆ తరువాతి versionలో 127.0.0.1కు bind చేసిన port, ufwలోని configuration ఏదైనా సరే, బయట నుంచి చేరుకోలేరు. అందుకే ఇది రెండవ-శ్రేణి పరిష్కారం కాకుండా సరైన పరిష్కారం. పాత Engine releasesలో మీ provider switchకు అనుసంధానమైన ఇతర machines వంటి అదే L2 segmentలోని hosts, localhostకు publish చేసిన portsను చేరుకోగలవు. కాబట్టి docker version అమలు చేసి, server 28 కంటే తక్కువ versionను చూపిస్తే upgrade చేయండి.

reverse proxy తో TLS ను ముందుకు ఉంచండి

Caddy అత్యంత సరళమైన మార్గం. ఇది స్వయంగా ACME (automatic certificate management environment) ద్వారా certificate ను అభ్యర్థిస్తుంది. అదనంగా, ప్రత్యేకంగా configuration ఇవ్వకపోయినా WebSockets ను proxy చేస్తుంది:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

Octop chat ను WebSocket ద్వారా 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;
    }
}

అక్కడి ప్రతి line ఒక నిర్దిష్ట పని చేస్తుంది. Chat WS /api/agents/{id}/chat/ws పై నడుస్తుంది. అందువల్ల proxy_http_version 1.1 మరియు ఆ రెండు upgrade headers లేకపోతే, nginx upgrade ప్రయత్నానికి 400 Bad Request తో సమాధానం ఇస్తుంది. Dashboard సాధారణంగా లోడ్ అవుతుంది. కానీ మీరు పంపే ప్రతి message page పై ఎలాంటి error లేకుండా ఎప్పటికీ నిలిచిపోతుంది. proxy_buffering off ముఖ్యమైనది. Human-in-the-loop resume endpoint text/event-stream ను తిరిగి ఇస్తుంది. Proxy buffer లో నిల్వైన SSE (server-sent events) stream అవ్వకుండా చివర్లో ఒకేసారి అందుతాయి. దీర్ఘమైన tool runs కోసం proxy_read_timeout అవసరం. ఎందుకంటే 60 second default agent ను task మధ్యలోనే ఆపేస్తుంది. Logs లో upstream timed out (110: Connection timed out) నమోదు అవుతుంది.

proxy వెనుక JWT authentication ఎలా పనిచేస్తుంది

Octop cookie ద్వారా కాకుండా bearer token ద్వారా authentication చేస్తుంది. POST /api/auth/login, {access_token, role, user, ...} ను తిరిగి ఇస్తుంది. తరువాతి calls లో Authorization: Bearer <access_token> ఉంటుంది. Reverse proxy కోసం ఇది మంచిదే. తప్పుగా అమర్చే cookie domain, Secure flag లేదా SameSite rule ఉండవు. అందువల్ల http://127.0.0.1:8088 పై పనిచేసిన session, https://octop.example.com పై కూడా అదే విధంగా పనిచేస్తుంది.

నిజమైన users ను చేర్చే ముందు తెలుసుకోవాల్సిన రెండు విషయాలు ఉన్నాయి.

WebSocket token ను URL లో పంపుతుంది. Endpoint WS /api/agents/{id}/chat/ws?token=<jwt>. WebSocket handshake సమయంలో browser JavaScript, Authorization header ను సెట్ చేయలేదు. TLS మార్గమధ్యంలోని token ను రక్షిస్తుంది. కానీ మీ స్వంత logs నుంచి దాన్ని రక్షించదు. nginx డిఫాల్ట్‌గా query string తో సహా పూర్తి request line ను access_log లో రాస్తుంది. అందువల్ల నిజమైన user కోసం పనిచేసే 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 డిఫాల్ట్‌గా 86400 కు సెట్ అవుతుంది. అందువల్ల login చేసిన తర్వాత token 24 గంటలపాటు చెల్లుబాటు అవుతుంది. ఒక token ను invalidate చేయడానికి documentation లో ఉన్న ఏకైక మార్గం octop admin rotate-jwt-secret. ఇది ~/.octop/secrets/jwt_secret వద్ద నిల్వ చేసిన signing key ను మార్చి, చెల్లుబాటులో ఉన్న అన్ని tokens ను అందరికీ వెంటనే invalidate చేస్తుంది. కాబట్టి ఎవరైనా team నుంచి వెళ్లిపోయినప్పుడు క్రమం ఇలా ఉండాలి: user ను తొలగించండి, secret ను rotate చేయండి, తరువాత మిగిలిన users ను మళ్లీ login చేయమని చెప్పండి. ఇది ఎక్కువ చర్యలుగా అనిపిస్తే lifetime ను తగ్గించండి. అలాగే variable ను environment: list లో మరియు .env లో కూడా చేర్చాలని గుర్తుంచుకోండి:

OCTOP_ACCESS_TOKEN_TTL=28800

Brute force ను వ్యవస్థ నిర్వహిస్తుంది. OCTOP_LOGIN_MAX_ATTEMPTS డిఫాల్ట్‌గా 5 failures కు, OCTOP_LOGIN_LOCKOUT_SECONDS 900 కు సెట్ అవుతుంది. అందువల్ల lock అయిన user broken install ను పరిశీలించకుండా పదిహేను నిమిషాలు వేచి ఉంటారు. Octop కు స్వంత user store ఉంది. v0.9.19 లో OIDC support గురించి documentation లేదు. కాబట్టి మీకు నిజమైన single sign-on అవసరమైతే, దాని ముందు authentication చేసే proxy ను ఉంచాలి. ఇందుకోసమే self-hosted Authentik server ఉపయోగిస్తారు.

మోడల్ backend కు Octop ను అనుసంధానించండి

Dashboard లో ప్రతి agent కు providers ను configure చేస్తారు. ఏ configuration అమలులో ఉందో octop provider list చూపిస్తుంది. Octop OpenAI-compatible APIs, DashScope (Qwen), Ollama కోసం presets అందిస్తుంది. Credentials మీ స్వంత SQLite database లోని providers table లో నిల్వ ఉంటాయి. ఈ ఎంపిక మీరు చెల్లించే మొత్తాన్ని, server నుంచి బయటకు వెళ్లే డేటాను మారుస్తుంది.

Ollama తో local model. ఏ డేటా server నుంచి బయటకు వెళ్లదు. మీరు tokens కు బదులుగా RAM కోసం ఖర్చు చేస్తారు. చాలామందికి సమస్య కలిగించే wiring వివరమిది: 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 గా సెట్ చేయండి. ఇది Ollama యొక్క OpenAI-compatible path. API key field లో ఖాళీ కాని ఏదైనా string ఉంచండి. Ollama దాన్ని పట్టించుకోదు. కానీ OpenAI clients ఖాళీ key ఉన్నప్పుడు request పంపవు. ఇది పనిచేయాలంటే Ollama loopback కు మించి కూడా listen చేయాలి. అందుకోసం దాని systemd unit లో OLLAMA_HOST=0.0.0.0:11434 ఉండాలి. ఇది ప్రమాదకరమైన భాగం: Ollama కు authentication లేదు. Public IP పై 11434 open గా ఉంటే, ముందుగా 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 గా ఉండని సందర్భాలను వివరిస్తుంది.

Octop లో bug లా కనిపించే మరో local-model సమస్య ఉంది. కానీ అది bug కాదు. Agents tools ను call చేయడం ద్వారా పనిచేస్తాయి. System prompt, tool definitions, history కలిపి పెద్ద prompt అవుతుంది. Ollama models ను తక్కువ default context window తో serve చేస్తుంది. అందువల్ల tool definitions ఉన్న prompt ప్రారంభ భాగం window నుంచి తొలగిపోతుంది. తరువాత model tools ను call చేయడం ఆపవచ్చు. లేదా లేనివి tools గా ఊహించవచ్చు. num_ctx ను 16k లేదా 32k కు పెంచండి. Function calling లో నిజంగా మంచి model ను ఎంచుకోండి. మధ్యలో sentence ఆగిపోవడం దీనికి విరుద్ధమైన సమస్య. అది వేరే setting అయిన num_predict కు సంబంధించినది. అందువల్ల answers truncated గా వస్తే agent ను నిందించే ముందు num_predict ఎక్కడ సెట్ అయిందో, done_reason ఏమి చెబుతుందో పరిశీలించండి. Shortlist కాకుండా నిర్దిష్ట candidate తో ప్రారంభించాలనుకుంటే Nemotron 3.5 Lightning ను ప్రయత్నించవచ్చు. ఆ write-up లో తీసుకోవాల్సిన exact tag, అవసరమైన RAM, CPU-only పనితీరు సరిపోతుందా అనే వివరాలు ఉన్నాయి.

Self-hosted gateway. Octop మరియు మిగతా అన్ని services మధ్య self-hosted LiteLLM gateway ను ఉంచండి. అప్పుడు ఒకే base URL, ప్రతి user కు ప్రత్యేక key, spend limits, ఒకే log లభిస్తాయి. Octop లో ఏదీ మార్చకుండా gateway వెనుక ఉన్న model ను కూడా మార్చవచ్చు.

Paid API. అత్యుత్తమ quality లభిస్తుంది. అయితే tradeoff ను స్పష్టంగా గుర్తించాలి: conversation content మీ server నుంచి provider వద్దకు వెళ్తుంది. Self-hosting చేయడానికి ప్రధాన కారణాల్లో ఇదొకటి. Key ను docker/.env లో OPENAI_API_KEY గా ఉంచండి. Compose file ఇప్పటికే దాన్ని pass through చేస్తుంది.

మీరు ఏ ఎంపిక చేసినా Compose file లో OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY, LANGFUSE_BASE_URL కూడా ఉంటాయి. అందువల్ల traces ను మీ స్వంత Langfuse instance కు పంపవచ్చు. Chat window ఆధారంగా ఊహించకుండా agents వాస్తవంగా ఏమి చేస్తున్నాయో చూడవచ్చు.

వినియోగదారులు, పాత్రలు మరియు భాగస్వామ్య agent library

మొదటి boot సమయంలో సృష్టించిన admin account ఇతర వినియోగదారుల ఖాతాలను సృష్టించి నిర్వహిస్తుంది. ప్రతి వినియోగదారుకు ప్రత్యేక agents, workspace మరియు credentials ఉంటాయి. ఈ వేర్పాటును browser వద్ద ఉన్న token అమలు చేస్తుంది. దీనితో పాటు అందరూ ఉపయోగించగల shared skills మరియు sub-agents pool ఉంటుంది. కుటుంబం కోసం దీన్ని నడపడం విలువైనదిగా చేసే అంశం ఇదే: ఒకరు మంచి research agent ను ఒక్కసారి రూపొందిస్తే, మిగతావారు దాన్ని మళ్లీ రూపొందించాల్సిన అవసరం ఉండదు.

Tooling విషయంలో జాగ్రత్తగా ఉండాలి. Octop tool approval మరియు shell command guardrails అందిస్తుంది. రెండూ వాస్తవంగా పనిచేస్తాయి. అయితే shell commands నడిపే agent వాటిని data volume mount చేసిన Octop container లోనే నడుపుతుంది. Guardrails నిర్లక్ష్యమైన prompt చేయగల పనులను పరిమితం చేస్తాయి. అవి sandbox boundary కావు. అందువల్ల shell access ఇవ్వని వ్యక్తుల కోసం tool approval ను enabled గా ఉంచండి. దీన్ని ఇతర options తో పోలుస్తుంటే, self-hosted AI agents పై సమీక్ష ప్రతి option ఈ అంశాన్ని ఎలా నిర్వహిస్తుందో పోల్చి చూపుతుంది.

ఈ వేగంతో విడుదలయ్యే ప్రాజెక్ట్‌ను అప్‌గ్రేడ్ చేయడం

చార్ట్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
  }
]

ఇవి repository లోని tag dates. ఇవి 7 August 2026 నాటికి లెక్కించబడ్డాయి. తొమ్మిది రోజుల్లో 4 tagged releases వచ్చాయి. వాటిలో రెండు releases మధ్య వ్యవధి కేవలం 1 day మాత్రమే. అంతకుముందు tag వచ్చిన తర్వాత v0.9.19 విడుదల 3 days కు వచ్చింది. ఈ cadence ప్రాజెక్ట్ చురుకుగా నిర్వహించబడుతోందని సూచిస్తుంది. అయితే latest ను ఆలోచించకుండా run చేయడానికి ఇది సరైన కారణం కాదు. Tags ను వర్తింపజేయడానికి ముందు మార్పులను చదవండి:

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 చేయవద్దు. ఈ ప్రాజెక్ట్ stable releases తో పాటు v1.0.2b9 వంటి betas ను కూడా tag చేస్తుంది. 20 October 2026 నాటికి తాజా tag stable v1.0.2. అది 18 October 2026 న ప్రచురించబడింది. v0.9.19 నుంచి చేసే upgrade 14 September 2026 నాటి v1.0.0 release ను దాటుతుంది. అందువల్ల ఆ log పొడవుగా ఉంటుంది. దాన్ని జాగ్రత్తగా చదవాలి.

ప్రతి సారి ముందుగా backup తీసుకోండి. Startup సమయంలో database migrations run అవుతాయి. ఈ వేగంతో విడుదలయ్యే ప్రాజెక్ట్‌లో 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 ఉంచండి. దాని ఒక copy ను server వెలుపల కూడా భద్రపరచండి. పెద్ద install కోసం ప్రాజెక్ట్ docker/docker-compose.postgres.yml ను కూడా అందిస్తుంది. ఇది SQLite బదులుగా pgvector తో PostgreSQL ను run చేస్తుంది.

విఫల పరిస్థితులు, మీరు చూడబోయే సందేశాలతో

Health check ఎప్పుడూ స్పందించదు. curl http://127.0.0.1:8088/api/health నిలిచిపోతుంది లేదా తిరస్కరిస్తుంది. docker compose -f docker/docker-compose.yml logs -f octop చదవండి. మొదటి init సమయంలోనే container exit అయితే, సాధారణంగా అది data directory లో రాయలేకపోయిందని అర్థం. కాబట్టి OCTOP_DATA కు మీరు సెట్ చేసిన దాని ownership ను పరిశీలించండి.

Dashboard లోడ్ అవుతుంది, కానీ chat నిలిచిపోతుంది. పేజీలో ఎలాంటి error కనిపించదు, reply కూడా రాదు. Browser console తెరిచి wss://octop.example.com/api/agents/.../chat/ws కు విఫలమైన connection కోసం చూడండి. Proxy upgrade ను forward చేయడం లేదు. proxy_http_version 1.1 ను, అలాగే Upgrade మరియు Connection headers ను జోడించండి.

మొత్తం reply అనేక సెకన్ల ఆలస్యంతో ఒకేసారి కనిపిస్తుంది. Streaming పనిచేస్తోంది, కానీ buffering ప్రారంభించబడి ఉంది. proxy_buffering off ను సెట్ చేయండి.

bind: address already in use. 8088 ను ఇప్పటికే మరొక process ఉపయోగిస్తోంది. sudo ss -tlnp | grep 8088 దాని పేరును చూపిస్తుంది. Original entry ను సవరించకుండా override file లో రెండవ ports entry జోడించినా ఇదే సమస్య వస్తుంది.

సరైన password తిరస్కరించబడుతుంది. 5 తప్పు ప్రయత్నాలు చేస్తే 900 seconds lockout ప్రారంభమవుతుంది. మళ్లీ install చేయకుండా lockout ముగిసే వరకు వేచి ఉండండి.

.env లోని కొత్త password ప్రభావం చూపలేదు. ఆ credentials మొదటి init సమయంలో మాత్రమే వర్తిస్తాయి. Dashboard లో password మార్చండి.

Agent reply ఇస్తుంది, కానీ tool ను ఎప్పుడూ అమలు చేయదు. ఇది దాదాపు ఎల్లప్పుడూ local model సమస్యే. Tool definitions కు context window చాలా చిన్నదిగా ఉండవచ్చు లేదా function calling లో model సామర్థ్యం తక్కువగా ఉండవచ్చు. num_ctx ను పెంచి, tool use కోసం రూపొందించిన model ను ప్రయత్నించండి.

FAQ

Octop, Open WebUIకి ప్రత్యామ్నాయమా?

Octop అందించే అదనపు సౌకర్యాలు మీకు అవసరమైతే మాత్రమే. Open WebUI అనేది model ముందు పనిచేసే chat interface. ఒక వ్యక్తికి లేదా పరస్పర విశ్వాసం ఉన్న కుటుంబానికి ఇది ఆ పనిని బాగా చేస్తుంది. Octopలో admin role కలిగిన accounts, ప్రతి userకు ప్రత్యేక workspaces మరియు credentials, అలాగే మార్చుకోగల specialist agents library ఉన్నాయి. అందువల్ల ఒకే historyను పంచుకోకుండా పలువురు ఒకే serverను ఉపయోగించవచ్చు. మీకు ఒకే account సరిపోతే, Open WebUI మరింత సరళమైన మరియు ఇప్పటికే ఎక్కువగా పరిపక్వమైన ఎంపిక.

Octop యొక్క curl install scriptను ఎందుకు ఉపయోగించకూడదు?

ఈ script repository నుంచి కాకుండా Tencent Cloud Object Storage bucket నుంచి అందించబడుతుంది. అందువల్ల ఇది ఏ git tag లేదా commit పరిధిలోనూ ఉండదు. ఇది ఈరోజు చేసే పనిని గత వారం చేసిన పనితో పోల్చలేరు. మీరు దాన్ని చదవకముందే bashకు pipe చేస్తే అది వెంటనే అమలవుతుంది. అదనంగా, ఇది స్వంత Python 3.12 environmentతో hostపై install అవుతుంది. ఈ environment మీ package manager పరిధికి బయట ఉంటుంది. Scriptను download చేసి ముందుగా చదవండి. లేదా checked-out tag నుంచి Docker Composeతో deploy చేయండి.

Paid APIకి బదులుగా Octop local modelను ఉపయోగించగలదా?

అవును. Octop OpenAI-compatible APIsతో పనిచేస్తుంది మరియు Ollama presetను అందిస్తుంది. కాబట్టి containerలో extra_hosts: ["host.docker.internal:host-gateway"]ను జోడించి, hostపై OLLAMA_HOST=0.0.0.0:11434ను set చేసిన తర్వాత దాన్ని http://host.docker.internal:11434/v1 వైపు point చేయవచ్చు. Docker address rangeకు firewall port 11434ను పరిమితం చేయండి, ఎందుకంటే Ollamaకు స్వంత authentication లేదు. Ollama యొక్క num_ctxను 16k లేదా అంతకంటే ఎక్కువకు పెంచాల్సి రావచ్చు. Tool definitions ఉన్న agent prompts default context windowను మించిపోవచ్చు. అప్పుడు model toolsను call చేయడం ఆపేస్తుంది.

నాకు reverse proxy అవసరమా, లేదా port 8088ను తెరవవచ్చా?

మీకు reverse proxy అవసరం. Octopతో అందించే Compose file TLS లేకుండా ప్రతి interfaceపై 8088ను publish చేస్తుంది. అందువల్ల passwords మరియు bearer tokens internet మీద cleartextగా ప్రసారం అవుతాయి. Published portను 127.0.0.1:8088:8088కు మార్చి, certificateతో Caddy లేదా nginxను ముందు ఉంచండి. nginxను ఉపయోగిస్తే WebSocket upgrade headersను forward చేసి proxy_buffering offను set చేయండి. లేకపోతే page load అవుతుంది, కానీ chat ఎలాంటి సందేశం లేకుండా స్పందించదు.

Octop productionకు సిద్ధంగా ఉందా?

August 2026 నాటికి ఇది pre-1.0 దశలో ఉండి, ప్రతి వారం అనేక tagged releasesను విడుదల చేస్తోంది. 14 September 2026న v1.0.0ను tag చేసింది. తరువాత stable v1.0.2ను 18 October 2026న విడుదల చేయడానికి ముందు 1.0.2 beta tags వరుసగా విడుదల చేసింది. ఈ వేగం ఇప్పటికీ ఎక్కువగా ఉంది. కాబట్టి దీన్ని పూర్తిగా స్థిరపడిన softwareగా కాకుండా promising softwareగా పరిగణించండి. Exact tagను pin చేసి, ప్రతి upgradeకు ముందు commit logను చదివి, ప్రతి rebuildకు ముందు data volumeకు backup తీసుకుంటే కుటుంబం లేదా చిన్న internal team కోసం దీన్ని ఉపయోగించవచ్చు. దీన్ని latestపై అమలు చేయవద్దు. Customer dataను ఇంకా ఇందులో ఉంచవద్దు.

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