Octop AI assistant-ஐ VPS-ல் self-host செய்வது எப்படி?

Octop என்றால் என்ன, அதை ஏன் நீங்களே host செய்ய வேண்டும்

Octop என்பது ஒரு குடும்பம் அல்லது சிறிய குழுவிற்கான self-hosted AI உதவியாளர் ஆகும். சாதாரண chat front-end-ஐ விட Octop-ஐ நீங்களே host செய்வதன் முக்கிய நோக்கம், பயனர்களைத் தனித்தனியாகப் பிரித்து வைப்பதாகும். Open WebUI ஒரு model-க்கு முன்னால் browser interface-ஐ வழங்குகிறது. Octop, ஒவ்வொரு பயனருக்கும் admin role, தனிப்பட்ட workspace மற்றும் credential தொகுப்பு ஆகியவற்றைச் சேர்க்கிறது. மேலும், ஒவ்வொரு பயனரும் தங்கள் பணிக்கு ஏற்ப மாற்றிக்கொள்ளக்கூடிய specialist agents நூலகத்தையும் இது வழங்குகிறது. இந்த வித்தியாசமே, ஒரு VPS-ஐ ஒருவருக்குப் பதிலாக ஐந்து பேர் பயன்படுத்த அனுமதிக்கிறது.

இந்தத் திட்டம் github.com/TencentCloud/Octop-ல் உள்ளது. இது ஒரு single 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 என்பது 1.0 பதிப்பிற்கு முந்தைய மென்பொருள்; இது ஒரு vendor-ன் GitHub அமைப்பிலிருந்து வெளியிடப்பட்டது. ஆகஸ்ட் 2026 நிலவரப்படி இது சுமார் 900 stars பெற்றுள்ளது. இது வேகமாக மாற்றங்களுக்கு உள்ளாகிறது, அதன் பதிப்பு எண்களே இதை உணர்த்துகின்றன. இங்குள்ள எதுவும் நிலையான upgrade path-க்கான உறுதிமொழி அல்ல. ஒரு குறிப்பிட்ட tag-ஐப் பயன்படுத்துங்கள், changelog-ஐப் படியுங்கள், மற்றும் backups-ஐத் தொடர்ந்து வைத்திருங்கள்.

தொடங்குவதற்கு முன் உங்களுக்குத் தேவையானவை

• Docker Engine மற்றும் Compose plugin நிறுவப்பட்ட Ubuntu 24.04 இயங்கும் ஒரு VPS. Compose உங்களுக்குப் புதியதா? VPS-க்கான Docker Compose அடிப்படைகள் என்பதில் தொடங்கவும்.
• git, ஏனெனில் நீங்கள் ஒரு image-ஐ pull செய்வதற்குப் பதிலாக, ஒரு release tag-ஐ checkout செய்யப் போகிறீர்கள்.
• உங்கள் VPS-ஐச் சுட்டிக்காட்டும் ஒரு domain name, ஏனெனில் இதற்கு முன்னால் TLS (transport layer security) தேவைப்படுகிறது.
• OpenAI API-ல் இயங்கும் ஒரு model backend: உள்ளூர் Ollama, self-hosted gateway, அல்லது கட்டணச் சேவைக்கான key.

Octop மென்பொருள் அளவில் சிறியது. இது ஒரு Python process மற்றும் ஒரு SQLite கோப்பு மட்டுமே. இதன் சுமை model backend-ஐப் பொறுத்தது. எனவே, model-ஐ அதே server-ல் இயக்கத் திட்டமிட்டால், அதற்கேற்ப server-ன் அளவைத் தீர்மானிக்கவும்.

curl installer-ஐ நாங்கள் ஏன் பரிந்துரைப்பதில்லை

README கோப்பில் தொடக்கத்திலேயே ஒரு வரி நிறுவல் முறை கொடுக்கப்பட்டுள்ளது:

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

நீங்கள் முக்கியமாகக் கருதும் ஒரு server-ல் இதை நாங்கள் பரிந்துரைப்பதில்லை. இதற்கு ஒரு தெளிவான காரணம் உள்ளது: அந்த script, repository-ல் இல்லை. அது Tencent Cloud Object Storage bucket-லிருந்து வழங்கப்படுகிறது. இது எந்தவொரு git tag அல்லது commit-ன் கீழும் வராததால், இன்றைய script-ஐ கடந்த வாரத்து script-உடன் உங்களால் diff செய்து பார்க்க முடியாது. மேலும், மாற்றங்களுக்கான எந்தவொரு வரலாறும் அங்கு இல்லை. அந்த bucket நாளை வேறு தரவுகளை வழங்கலாம், அதை இந்த project-ல் எங்கும் பதிவு செய்ய முடியாது. அதன் வெளியீட்டை நேரடியாக bash-க்கு pipe செய்வதன் மூலம், நீங்கள் ஒரு வரியைக் கூட படிப்பதற்கு முன்பே அந்த machine அந்த script-ஐ இயக்கிவிடுகிறது.

இந்த installer, container-க்கு பதிலாக host-லேயே எழுதுகிறது. இது uv-ஐப் பயன்படுத்தி Python 3.12-ஐப் பதிவிறக்கி, உங்கள் package manager-க்குத் தெரியாத ஒரு சூழலை (environment) உருவாக்குகிறது. எனவே, பிற்காலத்தில் அதை நீக்குவது ஒரு கைமுறை வேலையாகிவிடும்.

இதற்கு இரண்டு சிறந்த வழிகள் உள்ளன. script-ஐப் பதிவிறக்கி, படித்துவிட்டு, பின் இயக்கலாம்; இதற்கு முப்பது நொடிகள் மட்டுமே ஆகும்: முதலில் curl -fsSL <url> -o install.sh, பிறகு less install.sh, இறுதியில் bash install.sh. அல்லது இந்த வழிகாட்டியின் பிற பகுதிகளில் கூறப்பட்டுள்ளபடி Docker-ஐப் பயன்படுத்தலாம். PyPI package (pip install octop) என்பது குறைந்தபட்சம் ஒரு version செய்யப்பட்ட artifact ஆகும், அதை நீங்கள் ஒரு குறிப்பிட்ட release-க்கு pin செய்து வைத்துக்கொள்ளலாம்.

Docker Compose மூலம் Octop-ஐ v0.9.19 பதிப்பில் நிறுவுதல்

ஆகஸ்ட் 2026 நிலவரப்படி, பதிவிறக்கம் செய்யக்கூடிய (pull) image எதுவும் வெளியிடப்படவில்லை. வழங்கப்பட்டுள்ள Compose கோப்பு, repository-லிருந்து image-ஐ build செய்கிறது. எனவே, ஒரு குறிப்பிட்ட பதிப்பைப் பயன்படுத்த, git tag-ஐ checkout செய்ய வேண்டும். இது பெரும்பாலான self-hosted திட்டங்களை விட ஒரு கூடுதல் படியாகும். உதாரணமாக, self-hosted AFFiNE workspace போன்ற திட்டங்கள், ஏற்கனவே வெளியிடப்பட்ட image tag-ஐப் பயன்படுத்துவதால், உங்கள் VPS-ல் எதையும் build செய்ய வேண்டியதில்லை. கீழே கொடுக்கப்பட்டுள்ள clone, checkout மற்றும் build முறையானது openGym deployment guide-ல் உள்ளதைப் போன்றதே. எனவே, நீங்கள் ஏற்கனவே அதைச் செய்திருந்தால், இந்த நடைமுறை உங்களுக்குத் தெரிந்திருக்கும்.

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

இந்தக் கோப்பில் வரையறுக்கப்பட்டுள்ள 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: பகுதியை கவனிக்கவும். image: octop:latest என்பது நீங்கள் build செய்யும் image-ன் பெயர், இது registry reference அல்ல. எனவே, latest என்பது நீங்கள் கடைசியாக compile செய்த பதிப்பைக் குறிக்கும். data path-ஐ default-ஆக விடாமல், குறிப்பிட்ட ஒரு பாதையை அமைக்கவும். முதல்முறை boot செய்வதற்கு முன்பே admin கணக்கிற்கு வலுவான கடவுச்சொல்லை (password) வழங்கவும். இதை docker/.env-ல் உள்ளிடவும்:

OCTOP_PORT=8088
OCTOP_ADMIN_USERNAME=admin
OCTOP_DEFAULT_PASSWORD=<a long random password>
OCTOP_DATA=/srv/octop-data

இந்தக் கோப்பில் உள்ள ஒரு முக்கியமான சிக்கல் கவனிக்கத்தக்கது. Compose, docker/.env கோப்பை ${...} placeholders-ஐ நிரப்புவதற்காக மட்டுமே படிக்கிறது. நீங்கள் அந்த கோப்பில் சேர்க்கும் ஒரு key, environment: பிரிவில் குறிப்பிடப்படாவிட்டால், அது container-க்குள் செல்லாது. OCTOP_ACCESS_TOKEN_TTL-ஐ .env-ல் மட்டும் சேர்த்தால் எந்த மாற்றமும் நிகழாது, அது அமைதியாகச் செயல்படும். இதற்கு மாற்றாக, mounted data directory-க்குள் உள்ள ~/.octop/env கோப்பில் அதே key-களை எழுதலாம்; Octop தொடங்கும் போது அவற்றை ஏற்றிக்கொள்ளும். Docker Compose-ல் env கோப்புகள் மற்றும் secrets குறித்த வழிகாட்டி, இந்த இரண்டு முறைகளும் ஏன் வேறுபட்டவை என்பதை விளக்குகிறது.

Build செய்து தொடங்கவும்:

docker compose -f docker/docker-compose.yml up -d --build
docker compose -f docker/docker-compose.yml ps
curl http://127.0.0.1:8088/api/health

சரியாக இயங்கும் instance, 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-ஐ மாற்றினாலும் எந்த மாற்றமும் நிகழாது, ஏனெனில் கணக்கு ஏற்கனவே உருவாக்கப்பட்டுவிட்டது. கடவுச்சொல்லை மாற்ற, dashboard-ஐப் பயன்படுத்தவும்.

port 8088-ஐ வெளியிட வேண்டாம்

மேலே உள்ள ports: வரி VPS-ன் அனைத்து interface-களிலும் இணைப்பை ஏற்படுத்துகிறது. container தொடங்கியவுடன், dashboard இயல்புநிலை கடவுச்சொல்லுடன், cleartext முறையில் பொது இணையத்தில் கிடைத்துவிடும். Octop-ன் சொந்த OCTOP_BIND_HOST இயல்புநிலை 127.0.0.1 ஆகும்; process அதன் சொந்த network namespace-க்கு வெளியே இருந்து வரும் traffic-ஐ ஏற்க வேண்டும் என்பதால், Compose file அதை 0.0.0.0 என மாற்றுகிறது. அந்த மாற்றம் சரியானது. ஆனால், port-ஐ வெளியிடும் (publish) பகுதிதான் உங்களை ஆபத்துக்கு உள்ளாக்குகிறது.

docker/docker-compose.yml-ல் உள்ள ports: வரியைத் திருத்தி, mapping loopback-ல் மட்டும் கேட்கும் (listen) படி மாற்றவும்:

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

இதை ஒரு சாதாரண override file மூலம் சரிசெய்ய முயற்சிக்காதீர்கள். Compose பல கோப்புகளில் உள்ள ports பட்டியல்களை ஒன்றிணைக்கும் (concatenate), மாற்றாது. இதனால் இரண்டு mapping-களும் வெளியிடப்பட்டு, இரண்டாவது mapping bind ஆகத் தவறிவிடும். upstream கோப்பை மாற்றாமல் வைத்திருக்க விரும்பினால், sequence-ல் !override tag-ஐப் பயன்படுத்தவும். இது பட்டியலை இணைப்பதற்குப் பதிலாக மாற்றுவதற்கான ஆவணப்படுத்தப்பட்ட முறையாகும். Compose பல கோப்புகளை எவ்வாறு ஒன்றிணைக்கிறது என்பதற்கான விளக்கம் மற்ற merge விதிகளை விளக்குகிறது.

loopback-ல் bind செய்வது, firewall மூலம் நீங்கள் எதிர்கொள்ளும் ஒரு சிக்கலையும் தீர்க்கிறது. Docker அதன் published-port விதிகளை ufw நிர்வகிக்கும் chains-க்கு முன்னதாகவே nat table-ல் எழுதிவிடும், எனவே ufw deny 8088 ஒரு published 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 வழியாக chat-ஐ stream செய்கிறது:

server {
    listen 443 ssl;
    server_name octop.example.com;

    ssl_certificate     /etc/letsencrypt/live/octop.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/octop.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8088;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

அதில் உள்ள ஒவ்வொரு வரியும் ஒரு பணியைச் செய்கிறது. Chat ஆனது WS /agents/{id}/chat/ws வழியாக இயங்குகிறது, எனவே proxy_http_version 1.1 மற்றும் இரண்டு upgrade headers இல்லையென்றால், nginx அந்த upgrade முயற்சியை 400 Bad Request மூலம் நிராகரிக்கும்: இதனால் dashboard சாதாரணமாகத் திறக்கும், ஆனால் நீங்கள் அனுப்பும் ஒவ்வொரு செய்தியும் எந்தப் பிழையும் காட்டாமல் அப்படியே நின்றுவிடும். text/event-stream-ஐ human-in-the-loop resume endpoint திரும்பத் தருவதால் proxy_buffering off முக்கியமானது, மேலும் proxy buffer-ல் தேக்கப்படும் SSE (server-sent events) ஆனது streaming-க்கு பதிலாக இறுதியில் ஒரே தொகுப்பாக வந்து சேரும். proxy_read_timeout நீண்ட நேரம் இயங்கும் tool-களைக் கையாள்கிறது, ஏனெனில் இயல்பாக உள்ள 60 வினாடி காலாவதி நேரம் agent-ன் பணியை இடையில் துண்டித்து upstream timed out (110: Connection timed out) பிழையைப் பதிவு செய்யும்.

Proxy-க்கு பின்னால் JWT authentication எவ்வாறு செயல்படுகிறது

Octop ஒரு cookie-க்கு பதிலாக bearer token மூலம் authentication செய்கிறது. POST /api/auth/login ஆனது {access_token, role, user, ...}-ஐ வழங்குகிறது, அதன் பிறகு வரும் அழைப்புகள் Authorization: Bearer <access_token>-ஐக் கொண்டு செல்கின்றன. ஒரு reverse proxy-க்கு இது சாதகமான விஷயம்: இதில் cookie domain, Secure flag அல்லது SameSite விதி போன்ற தவறுகள் நடக்க வாய்ப்பில்லை. எனவே, http://127.0.0.1:8088-ல் சரியாகச் செயல்படும் ஒரு session, https://octop.example.com-லும் அதேபோலவே செயல்படும்.

உண்மையான பயனர்களை இதில் இணைக்கும் முன் கவனிக்க வேண்டிய இரண்டு முக்கிய விளைவுகள் உள்ளன.

WebSocket ஆனது token-ஐ URL-ல் கொண்டு செல்கிறது. இதற்கான endpoint WS /agents/{id}/chat/ws?token=<jwt> ஆகும், ஏனெனில் browser JavaScript-ஆல் WebSocket handshake-ன் போது Authorization header-ஐ அமைக்க முடியாது. TLS அந்த token-ஐ போக்குவரத்தின் போது பாதுகாக்கிறது. ஆனால், அது உங்கள் server logs-லிருந்து அதைப் பாதுகாக்காது: Nginx இயல்பாகவே முழு request line-ஐயும், query string-உடன் சேர்த்து access_log-ல் எழுதுகிறது. இதனால், ஒரு பயனரின் செல்லுபடியாகும் token, server-ல் உள்ள plaintext கோப்பில் பதிவாகிவிடும். எனவே, arguments இல்லாத path-ஐ மட்டும் log செய்யவும். $uri என்பது query string நீக்கப்பட்ட normalized 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;

இதில் per-session logout வசதி இல்லை. OCTOP_ACCESS_TOKEN_TTL இயல்பாகவே 86400 என அமைக்கப்பட்டுள்ளது, எனவே login செய்த பிறகு ஒரு token 24 மணிநேரம் வரை செல்லுபடியாகும். இதை ரத்து செய்ய ஆவணப்படுத்தப்பட்ட ஒரே வழி octop admin rotate-jwt-secret ஆகும். இது ~/.octop/secrets/jwt_secret-ல் சேமிக்கப்பட்டுள்ள signing key-ஐ மாற்றி, தற்போதுள்ள அனைத்து token-களையும் உடனடியாகச் செல்லாததாக்கிவிடும். எனவே, ஒருவர் குழுவிலிருந்து வெளியேறும்போது, பயனரை நீக்கிவிட்டு, secret-ஐ மாற்றி, மற்ற பயனர்களை மீண்டும் login செய்யச் சொல்ல வேண்டும். இது கடினமாகத் தோன்றினால், token-ன் ஆயுட்காலத்தைக் குறைக்கவும். அந்த variable-ஐ environment: பட்டியலிலும், .env-லும் சேர்க்க மறக்காதீர்கள்:

OCTOP_ACCESS_TOKEN_TTL=28800

Brute force தாக்குதல்கள் கையாளப்படுகின்றன: OCTOP_LOGIN_MAX_ATTEMPTS இயல்பாக 5 தோல்விகளாகவும், OCTOP_LOGIN_LOCKOUT_SECONDS 900 வினாடிகளாகவும் அமைக்கப்பட்டுள்ளன. எனவே, lock-out ஆன பயனர் 15 நிமிடங்கள் காத்திருக்க வேண்டுமே தவிர, installation பழுதடைந்ததாகக் கருத வேண்டியதில்லை. Octop-க்கு சொந்தமான user store உள்ளது, மேலும் v0.9.19 பதிப்பில் OIDC ஆதரவு ஆவணப்படுத்தப்படவில்லை. எனவே, உங்களுக்கு உண்மையான single sign-on தேவைப்பட்டால், அதற்கு முன்னால் ஒரு authenticating proxy-ஐ அமைக்க வேண்டும். இதற்குத்தான் self-hosted Authentik server பயன்படுகிறது.

Octop-ஐ ஒரு model backend-க்கு சுட்டிக்காட்டுதல்

ஒவ்வொரு agent-க்கும் dashboard-ல் providers கட்டமைக்கப்படுகின்றன, மேலும் octop provider list என்ன அமைக்கப்பட்டுள்ளது என்பதைக் காட்டுகிறது. Octop ஆனது OpenAI-compatible APIs, DashScope (Qwen) மற்றும் Ollama ஆகியவற்றிற்கான presets-ஐ வழங்குகிறது, மேலும் credentials உங்கள் சொந்த SQLite database-ன் providers அட்டவணையில் சேமிக்கப்படுகின்றன. நீங்கள் தேர்ந்தெடுக்கும் முறை உங்கள் கட்டணத்தையும், server-ஐ விட்டு வெளியேறும் தரவுகளையும் தீர்மானிக்கிறது.

Ollama உடனான local model. எந்தத் தரவும் server-ஐ விட்டு வெளியேறாது, நீங்கள் tokens-க்கு பதிலாக RAM-ஐ செலவிடுகிறீர்கள். பலருக்கு ஏற்படும் ஒரு தொழில்நுட்பச் சிக்கல்: ஒரு container-ஆல் 127.0.0.1:11434-ல் உள்ள host-ன் Ollama-வை அணுக முடியாது, ஏனெனில் அந்த முகவரி 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 பாதையாகும். API key புலத்தில் ஏதேனும் ஒரு string-ஐ உள்ளிடவும்; Ollama இதைச் சரிபார்ப்பதில்லை, ஆனால் OpenAI clients காலியான key-ஐ ஏற்காது. இது செயல்பட, Ollama loopback-க்கு அப்பாலும் listening நிலையில் இருக்க வேண்டும், இதற்கு அதன் systemd unit-ல் OLLAMA_HOST=0.0.0.0:11434 தேவை. இது ஆபத்தான பகுதி: Ollama-வில் authentication கிடையாது, எனவே public IP-ல் 11434 port-ஐத் திறந்து வைத்தால், யார் வேண்டுமானாலும் உங்கள் model server-ஐப் பயன்படுத்தலாம். Docker-ன் private range-ஐ, அதாவது sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp, மட்டும் அனுமதித்து மற்றவற்றைத் தடுக்கவும். VPS-ல் Ollama-வை இயக்குதல் பகுதியில் model அளவு பற்றியும், Ollama மற்றும் vLLM ஒப்பீடு பகுதியில் Ollama எப்போது போதுமானதாக இருக்காது என்பது பற்றியும் விளக்கப்பட்டுள்ளது.

local-model தொடர்பான மற்றொரு எச்சரிக்கை, இது Octop-ன் bug போலத் தோன்றலாம், ஆனால் அதுவல்ல. Agents கருவிகளை (tools) அழைப்பதன் மூலம் செயல்படுகின்றன, மேலும் system prompt, tool definitions மற்றும் வரலாறு ஆகியவை ஒரு பெரிய prompt-ஐ உருவாக்குகின்றன. Ollama மாதிரிகள் இயல்பாகவே சிறிய context window-ஐக் கொண்டுள்ளன, எனவே prompt-ன் தொடக்கத்தில் உள்ள tool definitions window-ஐ விட்டு வெளியேறிவிடும். இதனால் model கருவிகளை அழைப்பதை நிறுத்திவிடும் அல்லது இல்லாத கருவிகளை உருவாக்கும். num_ctx-ஐ 16k அல்லது 32k ஆக உயர்த்தவும், function calling-க்குச் சிறந்த ஒரு model-ஐத் தேர்ந்தெடுக்கவும். பதில் பாதியிலேயே நின்றால், அது num_predict அமைப்பைப் பொறுத்தது. பதில்கள் பாதியில் துண்டிக்கப்பட்டால், num_predict எங்கு அமைக்கப்பட்டுள்ளது மற்றும் done_reason என்ன சொல்கிறது என்பதைச் சரிபார்ப்பது நல்லது. நீங்கள் ஒரு குறிப்பிட்ட candidate-ஐத் தேர்ந்தெடுக்க விரும்பினால், Nemotron 3.5 Lightning-ஐ முயற்சி செய்யலாம்; அந்த வழிகாட்டி தேவையான tag, RAM அளவு மற்றும் CPU-மட்டும் போதுமானதா என்பதை விளக்குகிறது.

Self-hosted gateway. Octop-க்கும் பிற சேவைகளுக்கும் இடையில் self-hosted LiteLLM gateway-ஐப் பயன்படுத்தினால், ஒரே base URL, ஒவ்வொரு பயனருக்கும் தனித்தனி key, செலவு வரம்புகள் மற்றும் ஒரே log-ஐப் பெறலாம். Octop-ல் எதையும் மாற்றாமல், அதற்குப் பின்னால் உள்ள model-ஐ மாற்றிக்கொள்ளலாம்.

கட்டண API. இது சிறந்த தரம் கொண்டது, ஆனால் ஒரு சமரசம் உள்ளது: உரையாடல் தரவுகள் உங்கள் server-ஐ விட்டு வெளியேறி provider-க்குச் செல்லும், இதுவே self-hosting-ன் முக்கிய நோக்கத்திற்கு மாறானது. Key-ஐ docker/.env-ல் OPENAI_API_KEY ஆக உள்ளிடவும், இதை Compose file ஏற்கனவே கடத்துகிறது.

நீங்கள் எதைத் தேர்ந்தெடுத்தாலும், Compose file-ல் OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY மற்றும் LANGFUSE_BASE_URL ஆகியவை உள்ளன. எனவே, நீங்கள் உங்கள் சொந்த Langfuse instance-க்கு traces-ஐ அனுப்பி, chat window-ஐ மட்டும் நம்பியிருக்காமல் agents உண்மையில் என்ன செய்கின்றன என்பதைக் கண்காணிக்கலாம்.

பயனர்கள், பொறுப்புகள் மற்றும் பகிரப்பட்ட ஏஜென்ட் நூலகம்

முதல் boot-ன் போது உருவாக்கப்பட்ட admin கணக்கு மற்ற கணக்குகளை நிர்வகிக்கிறது. ஒவ்வொரு பயனருக்கும் தனித்தனி ஏஜென்ட்கள், workspace மற்றும் credentials ஒதுக்கப்படுகின்றன. இந்தத் தனித்தன்மை, browser-ல் உள்ள token மூலம் உறுதி செய்யப்படுகிறது. இதனுடன், அனைவரும் பயன்படுத்தக்கூடிய திறன் மற்றும் துணை-ஏஜென்ட்களின் (sub-agents) பகிரப்பட்ட தொகுப்பு உள்ளது. இதுவே குடும்ப பயன்பாட்டிற்கு இதைச் சிறந்ததாக மாற்றுகிறது: ஒருவர் ஒரு பயனுள்ள ஆராய்ச்சி ஏஜென்ட்டை உருவாக்கினால், மற்றவர்கள் அதை மீண்டும் உருவாக்க வேண்டியதில்லை.

கருவிகளைப் பயன்படுத்தும்போது கவனமாக இருக்கவும். Octop கருவி அங்கீகாரம் (tool approval) மற்றும் shell command பாதுகாப்பு கட்டுப்பாடுகளை (guardrails) வழங்குகிறது. இவை உண்மையானவை என்றாலும், shell command-களை இயக்கும் ஒரு ஏஜென்ட், உங்கள் data volume-ஐ mount செய்துள்ள Octop container-க்குள் தான் அவற்றை இயக்குகிறது. கவனக்குறைவான prompt-களால் ஏற்படும் பாதிப்புகளை இந்தக் கட்டுப்பாடுகள் குறைக்கும். இவை sandbox எல்லைகள் அல்ல என்பதால், நீங்கள் shell அணுகலை வழங்க விரும்பாத எவருக்கும் கருவி அங்கீகாரத்தை (tool approval) எப்போதும் செயல்பாட்டில் வைத்திருக்கவும். நீங்கள் பிற விருப்பங்களுடன் இதை ஒப்பிட்டுப் பார்க்கிறீர்கள் என்றால், self-hosted AI ஏஜென்ட்களின் தொகுப்பு ஒவ்வொன்றும் இதை எவ்வாறு கையாள்கிறது என்பதை ஒப்பிடுகிறது.

மிக வேகமாக வெளியீடுகளை வழங்கும் ஒரு திட்டத்தை மேம்படுத்துதல்

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

இவை 7 August 2026 நிலவரப்படி, repository-ல் உள்ள tag தேதிகள் ஆகும். ஒன்பது நாட்களில் 4 வெளியீடுகள் வந்துள்ளன. இதில் மிகக் குறைந்த இடைவெளி 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"

ஒவ்வொரு முறையும் முதலில் 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 மூலம் மீண்டும் build செய்யவும். ஏதேனும் தவறு நடந்தால், பழைய tag-க்கு மாறி மீண்டும் build செய்வதன் மூலம் குறியீட்டை (code) மீட்டெடுக்கலாம். ஆனால், database-ஐ மீட்டெடுக்க tarball மட்டுமே உதவும்.

அந்த tarball-ல் octop.db, config.json, JWT signing secret மற்றும் credential.txt ஆகியவை உள்ளன. எனவே, இது server-ஐப் போலவே பாதுகாப்பானது. இதை mode 600-ல் வைத்திருக்கவும், ஒரு நகலை server-க்கு வெளியே பாதுகாப்பாகச் சேமிக்கவும். பெரிய அளவிலான நிறுவல்களுக்கு, இந்தத் திட்டம் docker/docker-compose.postgres.yml-ஐயும் வழங்குகிறது. இது SQLite-க்கு பதிலாக PostgreSQL-ஐ pgvector உடன் இயக்குகிறது.

தோல்வி முறைகள் மற்றும் நீங்கள் காணும் செய்திகள்

Health check பதிலளிக்கவில்லை. curl http://127.0.0.1:8088/api/health செயலிழக்கிறது அல்லது மறுக்கிறது. docker compose -f docker/docker-compose.yml logs -f octop-ஐ வாசிக்கவும். முதல்முறை தொடங்கும்போதே வெளியேறும் container-ஆல் தரவு கோப்பகத்தில் (data directory) எழுத முடியாது. எனவே, OCTOP_DATA-க்கு நீங்கள் அமைத்த இடத்தின் உரிமையை (ownership) சரிபார்க்கவும்.

Dashboard ஏற்றப்படுகிறது, ஆனால் chat செயலிழக்கிறது. பக்கத்தில் பிழை இல்லை, ஆனால் பதில் வரவில்லை. Browser console-ஐத் திறந்து wss://octop.example.com/agents/.../chat/ws-க்கான இணைப்பு தோல்வியடைந்துள்ளதா என்று பார்க்கவும். Proxy, upgrade-ஐ முன்னனுப்பவில்லை (forwarding). proxy_http_version 1.1 மற்றும் Upgrade, Connection தலைப்புகளை (headers) சேர்க்கவும்.

முழு பதிலும் ஒரே நேரத்தில், பல நொடிகள் தாமதமாக வருகிறது. Streaming வேலை செய்கிறது, ஆனால் buffering செயல்பாட்டில் உள்ளது. proxy_buffering off-ஐ அமைக்கவும்.

bind: address already in use. ஏதோ ஒன்று ஏற்கனவே 8088-ஐப் பயன்படுத்திக் கொண்டிருக்கிறது. sudo ss -tlnp | grep 8088 அதை அடையாளம் காட்டும். அசல் கோப்பைத் திருத்துவதற்குப் பதிலாக, override கோப்பில் இரண்டாவது ports உள்ளீட்டைச் சேர்த்தாலும் இந்த பிழை வரும்.

சரியான கடவுச்சொல் நிராகரிக்கப்படுகிறது. ஐந்து முறை தவறாக உள்ளிட்டால் 900 நொடிகள் முடக்கப்படும் (lockout). மீண்டும் நிறுவுவதற்குப் பதிலாக காத்திருக்கவும்.

.env-ல் உள்ள புதிய கடவுச்சொல் வேலை செய்யவில்லை. அந்த நற்சான்றிதழ்கள் (credentials) முதல்முறை தொடங்கும் போது மட்டுமே பொருந்தும். Dashboard-ல் அதை மாற்றவும்.

Agent பதிலளிக்கிறது, ஆனால் எந்த கருவியையும் (tool) இயக்கவில்லை. இது பெரும்பாலும் உள்ளூர் மாதிரி (local model) சார்ந்த சிக்கல்: கருவி வரையறைகளுக்கு context window மிகச் சிறியதாக இருக்கலாம் அல்லது அந்த மாதிரிக்கு function calling திறன் குறைவாக இருக்கலாம். num_ctx-ஐ அதிகரிக்கவும், கருவி பயன்பாட்டிற்காக உருவாக்கப்பட்ட மாதிரியைப் பயன்படுத்தவும்.

FAQ

Octop என்பது Open WebUI-க்கு மாற்றா?

அதன் கூடுதல் வசதிகள் உங்களுக்குத் தேவைப்பட்டால் மட்டுமே இது மாற்றாகும். Open WebUI என்பது ஒரு model-க்கு முன்னால் இருக்கும் chat interface ஆகும்; இது ஒரு தனிநபர் அல்லது நம்பகமான குடும்ப உறுப்பினர்களுக்குச் சிறப்பாகச் செயல்படும். Octop, admin role கொண்ட கணக்குகள், ஒவ்வொரு பயனருக்கும் தனித்தனி workspaces மற்றும் credentials, மற்றும் தேவைக்கேற்ப மாற்றக்கூடிய specialist agents-ன் library ஆகியவற்றை வழங்குகிறது. இதனால் பல பயனர்கள் ஒரே server-ஐப் பயன்படுத்தினாலும், அவர்களின் chat history தனித்தனியாக இருக்கும். உங்களுக்கு ஒரு கணக்கே போதுமானது என்றால், Open WebUI மிகவும் எளிமையான மற்றும் முதிர்ச்சியடைந்த தேர்வாகும்.

Octop curl install script-ஐ ஏன் பயன்படுத்தக்கூடாது?

இந்த script repository-லிருந்து வராமல், Tencent Cloud Object Storage bucket-லிருந்து வழங்கப்படுகிறது. எனவே, இது எந்த git tag அல்லது commit-ன் கீழும் வராது. இன்று அது என்ன செய்கிறது என்பதை கடந்த வாரத்துடன் ஒப்பிட முடியாது. மேலும், அதை bash-க்கு pipe செய்வதன் மூலம், நீங்கள் படிப்பதற்கு முன்பே அது இயங்கத் தொடங்கிவிடும். இது உங்கள் package manager-க்கு வெளியே, சொந்தமாக Python 3.12 environment-ஐ உருவாக்கி host-ல் நிறுவுகிறது. எனவே, முதலில் அதைத் தரவிறக்கம் செய்து படியுங்கள் அல்லது ஒரு குறிப்பிட்ட tag-ஐ checkout செய்து Docker Compose மூலம் deploy செய்யுங்கள்.

கட்டண API-க்கு பதிலாக Octop-ல் local model-ஐப் பயன்படுத்த முடியுமா?

ஆம். Octop, OpenAI-compatible APIs-ஐ ஆதரிக்கிறது மற்றும் Ollama preset-ஐக் கொண்டுள்ளது. எனவே, http://host.docker.internal:11434/v1-ஐக் குறிப்பிட்டு, container-ல் extra_hosts: ["host.docker.internal:host-gateway"]-ஐச் சேர்த்து, host-ல் OLLAMA_HOST=0.0.0.0:11434-ஐ அமைத்தால் இது வேலை செய்யும். Ollama-வில் சொந்தமாக authentication இல்லாததால், firewall port 11434-ஐ Docker-ன் address range-க்கு மட்டும் கட்டுப்படுத்துங்கள். Ollama-வின் num_ctx-ஐ 16k அல்லது அதற்கு மேல் அதிகரிக்க வேண்டியிருக்கும், ஏனெனில் tool definitions கொண்ட agent prompts இயல்புநிலை context window-ஐத் தாண்டிவிடும், அப்போது model tool-களை அழைக்கத் தவறிவிடும்.

எனக்கு reverse proxy தேவையா, அல்லது port 8088-ஐ நேரடியாகத் திறக்கலாமா?

நிச்சயமாக proxy தேவை. Octop-ன் Compose file, 8088 port-ஐ TLS இல்லாமல் அனைத்து interface-களிலும் வெளியிடுகிறது. இதனால் கடவுச்சொற்கள் மற்றும் bearer tokens இணையத்தில் plain text-ஆகச் செல்லும். எனவே, published port-ஐ 127.0.0.1:8088:8088 என மாற்றி, முன்னால் Caddy அல்லது nginx-ஐ வைத்து certificate-ஐப் பயன்படுத்துங்கள். Nginx பயன்படுத்தினால், WebSocket upgrade headers-ஐ forward செய்து, proxy_buffering off-ஐ அமைக்கவும்; இல்லையெனில் பக்கம் லோட் ஆகும், ஆனால் chat பதில் அளிக்காது.

Octop production-க்குத் தயாரா?

இது 1.0 பதிப்பிற்கு முந்தைய நிலையில் உள்ளது மற்றும் ஆகஸ்ட் 2026 நிலவரப்படி வாரத்திற்குப் பல tagged releases வெளியிடப்படுகின்றன. எனவே, இதை முழுமையாக நிலைபெற்றதாகக் கருதாமல், நம்பிக்கைக்குரியதாகக் கருதுங்கள். நீங்கள் ஒரு குறிப்பிட்ட tag-ஐப் பூட்டி (pin), ஒவ்வொரு upgrade-க்கு முன்பும் commit log-ஐப் படித்து, ஒவ்வொரு rebuild-க்கு முன்பும் data volume-ஐ backup எடுத்தால், இது ஒரு குடும்பத்திற்கு அல்லது சிறிய உள்நாட்டுக் குழுவிற்குச் சிறப்பாகச் செயல்படும். இதை latest-ல் இயக்க வேண்டாம், மேலும் வாடிக்கையாளர் தரவுகளை இதில் சேமிக்க வேண்டாம்.