ద్వారా Matt Connor 2026-08-07 · అప్‌డేట్ చేయబడింది 2026-08-30

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 మీకు model ముందు browser interface ను అందిస్తుంది. Octop admin role తో accounts, ప్రతి వినియోగదారుకు private workspace మరియు credential set, అలాగే పనిని బట్టి ప్రతి వినియోగదారు మార్చుకోగల specialist agents library ను అందిస్తుంది. ఈ విభజన వల్ల ఒక VPS ను ఒకరికి బదులుగా ఐదుగురు ఉపయోగించవచ్చు.

ఈ ప్రాజెక్ట్ github.com/TencentCloud/Octop వద్ద ఉంది. ఇది ఒకే process ద్వారా web dashboard, command line interface, chat channels (Feishu, DingTalk, QQ, Discord, WeCom), scheduled jobs ను అందిస్తుంది. వీటన్నింటికీ ~/.octop/ కింద ఉన్న ఒకే SQLite database ఆధారం. దిగువ వివరాలన్నీ 5 August 2026న విడుదలైన v0.9.19 tag ఆధారంగా ఉన్నాయి. మీరు ఇంకా platformల మధ్య నిర్ణయం తీసుకుంటుంటే, VPSపై నడపగల Open WebUI ప్రత్యామ్నాయాల పోలిక విస్తృత అవలోకనాన్ని అందిస్తుంది.

దీనిపై ఒక సాయంత్రం కేటాయించే ముందు ఒక విషయం స్పష్టంగా తెలుసుకోండి. Octop అనేది vendor యొక్క GitHub organisation నుంచి ప్రచురించబడుతున్న pre-1.0 software. August 2026 నాటికి దీనికి సుమారు 900 stars ఉన్నాయి. ఇది వేగంగా మారుతోంది, version numbers కూడా అదే సూచిస్తున్నాయి. స్థిరమైన 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 చేయడం

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 లో చూపిన విధానమే. కాబట్టి దాన్ని ఒకసారి 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 కు వదిలేయకుండా స్పష్టమైన స్థలానికి సెట్ చేయండి. మొదటి 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 లేకుండా జరుగుతుంది. మరో మార్గం, mounted data directory లోని ~/.octop/env లో అదే keys ను రాయడం. Octop startup సమయంలో ఆ file ను 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 కు {"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

Default విలువలు admin / octop. ఇవి మొదటి init సమయంలో మాత్రమే వర్తిస్తాయి. తరచుగా అడిగే ఒక ప్రశ్నకు ఇదే కారణం: container ఒకసారి ప్రారంభమైన తర్వాత OCTOP_DEFAULT_PASSWORD మార్చినా ప్రభావం ఉండదు, ఎందుకంటే account ఇప్పటికే సృష్టించబడింది. Password ను dashboard లో మార్చండి.

8088 port ను public చేయవద్దు

పై ఉన్న ports: line VPS లోని ప్రతి interface కు bind అవుతుంది. Container ప్రారంభమైన వెంటనే dashboard cleartext లో, default password తో public internet లో అందుబాటులోకి వస్తుంది. Octop యొక్క స్వంత OCTOP_BIND_HOST default 127.0.0.1. అయితే process తన network namespace వెలుపలి traffic ను స్వీకరించాలి కాబట్టి Compose file దాన్ని 0.0.0.0 కు override చేస్తుంది. ఆ override సరైనదే. మిమ్మల్ని ప్రమాదంలోకి నెట్టేది published port.

docker/docker-compose.yml లోని ports: line ను మార్చి, 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 ను ఆపదు. 127.0.0.1 కు bind చేసిన port ను ufw configuration ఎలా ఉన్నా బయట నుంచి ఎప్పటికీ చేరుకోలేరు. అందుకే ఇది రెండో స్థాయి ప్రత్యామ్నాయం కాదు, సరైన పరిష్కారం.

Reverse proxy తో TLS ను ముందు అమలు చేయండి

Caddy సులభమైన మార్గం. ఇది స్వయంగా ACME (automatic certificate management environment) ద్వారా certificate ను అభ్యర్థిస్తుంది. అలాగే ప్రత్యేకంగా configuration ఇవ్వకుండానే WebSocket ను 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 /agents/{id}/chat/ws పై నడుస్తుంది. అందువల్ల proxy_http_version 1.1 మరియు రెండు upgrade headers లేకపోతే, nginx upgrade ప్రయత్నానికి 400 Bad Request తో సమాధానం ఇస్తుంది. Dashboard సాధారణంగా load అవుతుంది. కానీ మీరు పంపే ప్రతి message పేజీలో ఎలాంటి error చూపకుండా ఎప్పటికీ నిలిచిపోతుంది. Human-in-the-loop resume endpoint text/event-stream ను తిరిగి ఇస్తుంది కాబట్టి proxy_buffering off ముఖ్యమైనది. Proxy buffer లో నిల్వైన SSE (server-sent events) streaming కాకుండా చివర్లో ఒకేసారి వస్తాయి. Tool runs ఎక్కువసేపు కొనసాగవచ్చు కాబట్టి proxy_read_timeout అవసరం. Default 60 seconds agent ను task మధ్యలోనే ఆపేస్తుంది. Logs లో upstream timed out (110: Connection timed out) కనిపిస్తుంది.

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

Octop bearer token తో authentication చేస్తుంది; cookie తో కాదు. 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 /agents/{id}/chat/ws?token=<jwt>. కారణం, WebSocket handshake సమయంలో browser JavaScript, Authorization header ను సెట్ చేయలేకపోవడం. TLS ఆ token ను మార్గమధ్యంలో రక్షిస్తుంది. కానీ మీ స్వంత logs లో అది కనిపించకుండా రక్షించదు. nginx default గా query string తో సహా పూర్తి request line ను access_log లో రాస్తుంది. అందువల్ల నిజమైన user కోసం పనిచేసే token server లోని plaintext file లో నిల్వ అవుతుంది. Arguments లేకుండా path ను log చేయండి. Query string ఇప్పటికే తొలగించబడిన normalised path ను $uri సూచిస్తుంది. కాబట్టి దీన్ని 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 చేసిన 24 గంటల వరకు token చెల్లుబాటులో ఉంటుంది. Token ను invalidate చేయడానికి documentation లో ఉన్న ఏకైక మార్గం octop admin rotate-jwt-secret. ఇది ~/.octop/secrets/jwt_secret వద్ద నిల్వ చేసిన signing key ను మార్చి, అందరి outstanding tokens ను వెంటనే invalidate చేస్తుంది. కాబట్టి ఎవరైనా team ను విడిచిపెడితే క్రమం ఇలా ఉండాలి: user ను delete చేయండి, secret ను rotate చేయండి, తరువాత మిగిలిన users ను మళ్లీ login చేయమని చెప్పండి. ఇది ఎక్కువ చర్యలుగా అనిపిస్తే lifetime ను తగ్గించండి. అయితే ఆ variable ను environment: list లోనే కాకుండా .env లో కూడా చేర్చాలి:

OCTOP_ACCESS_TOKEN_TTL=28800

Brute-force ప్రయత్నాల నిర్వహణ ఇప్పటికే ఉంది. OCTOP_LOGIN_MAX_ATTEMPTS default గా 5 failures ను, OCTOP_LOGIN_LOCKOUT_SECONDS default గా 900 ను ఉపయోగిస్తాయి. అందువల్ల lock అయిన user, విఫలమైన installation ను పరిశీలించాల్సిన అవసరం లేకుండా 15 నిమిషాలు వేచి ఉండాలి. Octop కు స్వంత user store ఉంది. v0.9.19 లో documented OIDC support లేదు. కాబట్టి నిజమైన 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 ఈ అంశాన్ని ఎలా నిర్వహిస్తుందో పోల్చి చూపుతుంది.

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

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 తేదీలు. లెక్కింపు 7 August 2026 నాటికి జరిగింది. తొమ్మిది రోజుల్లో 4 tagged releases విడుదలయ్యాయి. వాటిలో రెండు releases మధ్య తక్కువ వ్యవధి 1 రోజు. అంతకుముందు tag వచ్చిన 3 రోజుల తర్వాత v0.9.19 విడుదలైంది. ఈ విడుదల వేగం ప్రాజెక్ట్ చురుకుగా అభివృద్ధి అవుతోందని సూచిస్తుంది. అయితే 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 అమలవుతాయి. 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గా ఉంచి, ఒక copyని server వెలుపల కూడా భద్రపరచండి. పెద్ద installation కోసం ప్రాజెక్ట్ docker/docker-compose.postgres.yml ను కూడా అందిస్తుంది. ఇది SQLite బదులుగా pgvectorతో PostgreSQLను నడుపుతుంది.

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

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

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

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

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

సరైన password తిరస్కరించబడుతుంది. 5 తప్పు attempts తర్వాత 900 seconds lockout అమలవుతుంది. Reinstall చేయకుండా 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

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

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

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

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

చెల్లింపు 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 సెట్ చేసిన తర్వాత దాన్ని http://host.docker.internal:11434/v1 వైపు చూపించవచ్చు. Docker address range కు firewall port 11434 ను పరిమితం చేయండి, ఎందుకంటే Ollama కు స్వంత authentication లేదు. Ollama లోని num_ctx ను 16k లేదా అంతకంటే ఎక్కువకు పెంచాల్సి ఉంటుంది. Tool definitions కలిగిన agent prompts default context window పరిమితిని దాటుతాయి. అప్పుడు model tools ను పిలవడం ఆపేస్తుంది.

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

మీకు proxy అవసరం. Octop తో వచ్చే Compose file 8088 ను TLS లేకుండా ప్రతి interface పై 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 సెట్ చేయండి. లేకపోతే page load అవుతుంది, కానీ chat ఎటువంటి స్పందన ఇవ్వదు.

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

ఇది ఇంకా pre-1.0 దశలో ఉంది. August 2026 నాటికి ప్రతి వారం అనేక tagged releases విడుదలవుతున్నాయి. కాబట్టి దీన్ని స్థిరమైనదిగా కాకుండా promising గా పరిగణించండి. Exact tag ను pin చేసి, ప్రతి upgrade ముందు commit log చదివి, ప్రతి rebuild ముందు data volume కు backup తీసుకుంటే కుటుంబం లేదా చిన్న internal team కోసం దీన్ని ఉపయోగించవచ్చు. దీన్ని latest పై అమలు చేయవద్దు. ప్రస్తుతానికి customer data ను ఇందులో ఉంచవద్దు.

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