ஆல் Matt Connor 2026-10-20

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

Octop-ஐ Docker Compose மூலம் v0.9.19 tag-ல் நிறுவுவது எப்படி என்று அறியுங்கள். curl installer-ஐத் தவிர்த்து, பாதுகாப்பான TLS மற்றும் பயனர் தனிமைப்படுத்தலை உறுதி செய்யவும்.

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

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

இந்தத் திட்டம் github.com/TencentCloud/Octop-ல் உள்ளது. இது ஒரு web dashboard, command line interface, chat channels (Feishu, DingTalk, QQ, Discord, WeCom) மற்றும் scheduled jobs ஆகியவற்றை வழங்கும் ஒரே process ஆகும். இவை அனைத்தும் ~/.octop/-ன் கீழ் உள்ள ஒரே ஒரு SQLite database மூலம் இயக்கப்படுகின்றன. கீழே உள்ள அனைத்தும் 5 ஆகஸ்ட் 2026 அன்று வெளியிடப்பட்ட v0.9.19 tag-ஐ அடிப்படையாகக் கொண்டு எழுதப்பட்டுள்ளன. நீங்கள் எந்த platform-ஐத் தேர்வு செய்வது என்று இன்னும் முடிவு செய்யவில்லை என்றால், VPS-ல் இயக்கக்கூடிய Open WebUI மாற்றுகளின் ஒப்பீடு பரந்த அளவிலான தகவல்களை வழங்குகிறது.

இதற்காக ஒரு மாலைப் பொழுதைச் செலவிடும் முன் ஒரு விஷயத்தைத் தெளிவாகப் புரிந்துகொள்ள வேண்டும். இந்த வழிகாட்டி எழுதப்பட்டபோது, Octop என்பது ஒரு vendor-ன் GitHub அமைப்பிலிருந்து வெளியிடப்பட்ட 1.0-க்கு முந்தைய மென்பொருள் ஆகும், ஆகஸ்ட் 2026 நிலவரப்படி இது சுமார் 900 stars பெற்றிருந்தது. அதன் பிறகு, 14 செப்டம்பர் 2026 அன்று v1.0.0 tag வெளியிடப்பட்டது. 20 அக்டோபர் 2026 நிலவரப்படி, புதிய tag v1.0.2 ஆகும்; இது 1.0.2 beta பதிப்புகளுக்குப் பிறகு 18 அக்டோபர் 2026 அன்று வெளியிடப்பட்ட ஒரு stable release ஆகும், மேலும் இந்த repository சுமார் 10,400 stars பெற்றுள்ளது. கீழே உள்ள படிகள் v0.9.19-ஐ அடிப்படையாகக் கொண்டு எழுதப்பட்டவை மற்றும் 1.x பதிப்பில் மீண்டும் சோதிக்கப்படவில்லை. இது வேகமாக மாறக்கூடியது, பதிப்பு எண்களே அதை உணர்த்துகின்றன, மேலும் இங்கே கொடுக்கப்பட்டுள்ள எதுவும் நிலையான 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 கோப்பு மட்டுமே. இதன் சுமை 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 பதிப்பில் நிறுவுதல்

v0.9.19 பதிப்பில் வழங்கப்பட்டுள்ள Compose கோப்பு, களஞ்சியத்திலிருந்து (repository) image-ஐ உருவாக்குகிறது. எனவே, இந்தப் பயிற்சியில் ஒரு குறிப்பிட்ட பதிப்பைப் பயன்படுத்துவது என்பது git tag-ஐ checkout செய்வதைக் குறிக்கும். வெளியிடப்பட்ட images ஏற்கனவே உள்ளன. v0.9.19 கிளையில் docker-publish.yml பணிப்பாய்வு (workflow) உள்ளது. இது 15 ஜூலை 2026 அன்று v0.9.8 பதிப்பில் சேர்க்கப்பட்டது. இது ஒவ்வொரு v* tag-க்கும் ஒரு image-ஐ உருவாக்கி Docker Hub-க்குத் தள்ளுகிறது (push). 20 அக்டோபர் 2026 நிலவரப்படி, இந்தத் திட்டம் GitHub-ன் container registry-யிலும் (docker pull ghcr.io/tencentcloud/octop:1.0.2) வெளியிடுகிறது. Checked-out tag-லிருந்து உருவாக்குவதே மிகவும் பாதுகாப்பான முறையாகும், ஏனெனில் registry tag-ஐ நம்புவதை விட, நீங்கள் வாசிக்கும் குறியீட்டை (code) அப்படியே compile செய்கிறீர்கள். இது பெரும்பாலான self-hosted திட்டங்களை விட ஒரு படி கூடுதல் வேலை. உதாரணமாக, self-hosted AFFiNE workspace போன்ற திட்டங்கள் வெளியிடப்பட்ட image tag-ஐ மட்டுமே பயன்படுத்துகின்றன, உங்கள் VPS-ல் எதையும் compile செய்வதில்லை. கீழே கொடுக்கப்பட்டுள்ள 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-க்கு நீங்கள் வைக்கும் பெயர், இது registry reference அல்ல. எனவே, இங்கே latest என்பது நீங்கள் கடைசியாக compile செய்ததைக் குறிக்கும். தரவுப் பாதையை (data path) இயல்புநிலையாக விடாமல், ஒரு குறிப்பிட்ட இடத்தில் அமைக்கவும். முதல் முறை தொடங்குவதற்கு முன்பே 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 கோப்பை YAML-ல் உள்ள ${...} placeholders-ஐ நிரப்ப மட்டுமே வாசிக்கிறது. நீங்கள் அந்த கோப்பில் சேர்க்கும் ஒரு key, Compose கோப்பில் உள்ள environment: பிரிவில் குறிப்பிடப்படாவிட்டால், அது container-க்குச் செல்லாது. OCTOP_ACCESS_TOKEN_TTL-ஐ .env-ல் மட்டும் சேர்த்தால், அது எந்த மாற்றத்தையும் ஏற்படுத்தாது, அமைதியாகச் செயல்படாமல் இருக்கும். இதற்கு மாற்றாக, அதே key-களை mounted data directory-க்குள் உள்ள ~/.octop/env கோப்பில் எழுதலாம்; 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, {"ok":true,"started_at":...,"db":...,"users_loaded":0,"agents_running":0} போன்ற ஒரு JSON object-ஐ health check-க்கு பதிலாக வழங்கும். வேறு ஏதேனும் பதில் வந்தால், browser-ஐத் திறக்கும் முன் docker compose -f docker/docker-compose.yml logs -f octop-ஐப் படிக்கவும்.

இப்போது நீங்கள் உருவாக்கிய image-க்கு ஒரு அர்த்தமுள்ள பெயரை இடவும். ஏனெனில் அடுத்த --build, octop:latest-ஐ மேலெழுதிவிடும் (overwrite), அப்போது இரண்டிற்கும் உள்ள வித்தியாசத்தைக் கண்டறிய முடியாது:

docker image tag octop:latest octop:0.9.19

முதல் முறை தொடங்கும் போது octop init இயங்கி, தொடக்கக் கணக்கு விவரங்களை data volume-ல் எழுதும்:

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

இயல்புநிலை விவரங்கள் admin / octop ஆகும். இவை முதல் முறை தொடங்கும் போது (first init) மட்டுமே பயன்படுத்தப்படும். மக்கள் அடிக்கடி கேட்கும் ஒரு கேள்விக்கான காரணம் இதுதான்: container ஒருமுறை தொடங்கிய பிறகு OCTOP_DEFAULT_PASSWORD-ஐ மாற்றினால் எந்த மாற்றமும் ஏற்படாது, ஏனெனில் கணக்கு ஏற்கனவே உருவாக்கப்பட்டுவிட்டது. கடவுச்சொல்லை மாற்ற, dashboard-ஐப் பயன்படுத்தவும்.

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

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

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

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

இதை ஒரு சாதாரண override கோப்பைக் கொண்டு சரிசெய்ய முயற்சிக்காதீர்கள். Compose பல கோப்புகளில் உள்ள ports பட்டியல்களை ஒன்றிணைக்குமே தவிர, அவற்றை மாற்றாது. இதனால் நீங்கள் இரண்டு mapping-களையும் வெளியிடும் நிலைக்குத் தள்ளப்படுவீர்கள், மேலும் இரண்டாவது mapping இணைப்பை ஏற்படுத்தத் தவறிவிடும். நீங்கள் upstream கோப்பை மாற்றாமல் வைத்திருக்க விரும்பினால், sequence-ல் !override tag-ஐப் பயன்படுத்தவும்; இது பட்டியலை ஒன்றிணைப்பதற்குப் பதிலாக மாற்றுவதற்கான ஆவணப்படுத்தப்பட்ட வழியாகும். Compose பல கோப்புகளை எவ்வாறு ஒன்றிணைக்கிறது என்பதற்கான விளக்கம் மீதமுள்ள merge விதிகளை விளக்குகிறது.

loopback-ல் bind செய்வது, firewall மூலம் நீங்கள் எதிர்கொள்ளும் ஒரு சிக்கலையும் தீர்க்கிறது. Docker அதன் published-port விதிகளை ufw நிர்வகிக்கும் chains-க்கு முன்பாகவே nat table-ல் எழுதிவிடுகிறது, எனவே ufw deny 8088 ஒரு published container port-ஐத் தடுப்பதில்லை. Docker Engine 28.0.0 அல்லது அதற்குப் பிந்தைய பதிப்புகளில், 127.0.0.1-ல் bind செய்யப்பட்ட port, ufw-ன் நிலையைப் பொருட்படுத்தாமல் வெளியிலிருந்து அணுக முடியாது. இதனால்தான் இது இரண்டாவது சிறந்த தீர்வாக இல்லாமல், சரியான தீர்வாக அமைகிறது. பழைய Engine பதிப்புகள், உங்கள் provider-ன் switch-ல் உள்ள பிற இயந்திரங்கள் போன்ற அதே L2 segment-ல் உள்ள hosts-கள் localhost-க்கு வெளியிடப்பட்ட port-களை அணுக அனுமதிக்கின்றன. எனவே, docker version-ஐ இயக்கி, server 28-க்குக் கீழே ஏதேனும் பதிப்பைக் காட்டினால், அதை upgrade செய்யவும்.

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

Proxy-க்கு பின்னால் JWT அங்கீகாரம் செயல்படும் விதம்

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

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-ஐ மாற்றி, தற்போதுள்ள அனைத்து token-களையும் உடனடியாகச் செல்லாததாக்கிவிடும். எனவே, ஒருவர் குழுவிலிருந்து வெளியேறும்போது, பயனரை நீக்கிவிட்டு, secret-ஐ மாற்றி, மற்ற பயனர்களை மீண்டும் login செய்யச் சொல்ல வேண்டும். இது கடினமாகத் தோன்றினால், token-ன் ஆயுட்காலத்தைக் குறைக்கவும். அப்போது அந்த variable-ஐ environment: மற்றும் .env ஆகிய இரண்டிலும் சேர்க்க மறக்காதீர்கள்:

OCTOP_ACCESS_TOKEN_TTL=28800

Brute force தாக்குதல்கள் கையாளப்படுகின்றன: OCTOP_LOGIN_MAX_ATTEMPTS இயல்பாக 5 தோல்விகளாகவும், OCTOP_LOGIN_LOCKOUT_SECONDS 900 வினாடிகளாகவும் அமைக்கப்பட்டுள்ளது. எனவே, கணக்கு முடக்கப்பட்ட பயனர், ஒரு உடைந்த install-ஐப் பார்ப்பதற்குப் பதிலாக, பதினைந்து நிமிடங்கள் காத்திருக்க வேண்டியிருக்கும். 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 ஏஜென்ட்களின் தொகுப்பு ஒவ்வொன்றும் இதை எவ்வாறு கையாள்கிறது என்பதை ஒப்பிடுகிறது.

வேகமாக releases வெளியிடும் ஒரு project-ஐ upgrade செய்தல்

விளக்கப்படம்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 தேதிகள், 7 August 2026 நிலவரப்படி கணக்கிடப்பட்டவை. ஒன்பது நாட்களில் 4 tagged releases வந்துள்ளன; இதில் குறைந்தபட்ச இடைவெளி 1 நாள் மட்டுமே. மேலும், v0.9.19 ஆனது அதற்கு முந்தைய 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"

$NEW_TAG-ஐ checkout செய்வதற்கு முன்பு அதில் என்ன உள்ளது என்பதைச் சரிபார்க்கவும். ஏனெனில், இந்த project v1.0.2b9 போன்ற betas-ஐ stable releases-உடன் சேர்த்து tag செய்கிறது. 20 October 2026 நிலவரப்படி, புதிய tag என்பது 18 October 2026 அன்று வெளியிடப்பட்ட stable v1.0.2 ஆகும். v0.9.19-லிருந்து v1.0.0-க்கு (14 September 2026) மாறுவது ஒரு பெரிய தாவல் என்பதால், அந்த log நீண்டதாக இருக்கும், அதை கவனமாக வாசிப்பது அவசியம்.

ஒவ்வொரு முறையும் முதலில் backup எடுக்கவும். ஏனெனில், startup-ல் database migrations இயங்கும். வேகமாக releases வெளியிடும் ஒரு project-ல் 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-ஐ checkout செய்து மீண்டும் build செய்வதன் மூலம் code-ஐ மீட்டெடுக்கலாம், ஆனால் database-ஐ மீட்டெடுக்க tarball மட்டுமே உதவும்.

அந்த tarball-ல் octop.db, config.json, JWT signing secret மற்றும் credential.txt ஆகியவை உள்ளன. எனவே, இது server-ஐப் போலவே பாதுகாப்பானது. இதை mode 600-ல் வைத்திருக்கவும், ஒரு நகலை server-க்கு வெளியே சேமிக்கவும். பெரிய அளவிலான install-களுக்கு, இந்த project 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/api/agents/.../chat/ws-க்கான இணைப்பு தோல்வியடைந்துள்ளதா என்று பார்க்கவும். Proxy, upgrade-ஐ forward செய்யவில்லை. 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 தொடர்பான சிக்கல்: tool வரையறைகளுக்கு context window மிகச் சிறியதாக இருக்கலாம் அல்லது model-க்கு function calling திறன் குறைவாக இருக்கலாம். num_ctx-ஐ அதிகரிக்கவும், tool பயன்பாட்டிற்காக உருவாக்கப்பட்ட ஒரு model-ஐ முயற்சிக்கவும்.

FAQ

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

அதன் கூடுதல் வசதிகள் உங்களுக்குத் தேவைப்பட்டால் மட்டுமே இது மாற்றாகும். Open WebUI என்பது ஒரு model-க்கு முன்னால் இருக்கும் chat interface ஆகும்; இது ஒரு தனிநபர் அல்லது நம்பகமான குடும்பத்திற்குச் சிறப்பாகச் செயல்படும். Octop-ல் admin role கொண்ட கணக்குகள், ஒவ்வொரு பயனருக்கும் தனித்தனி workspaces மற்றும் credentials, மற்றும் தேவைக்கேற்ப மாற்றக்கூடிய specialist agents ஆகிய வசதிகள் உள்ளன. இதனால் பல பயனர்கள் ஒரே 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-ல் நிறுவுகிறது. எனவே, முதலில் அதைத் தரவிறக்கம் செய்து படியுங்கள், அல்லது git tag-ஐ checkout செய்து Docker Compose மூலம் deploy செய்யுங்கள்.

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

ஆம். Octop OpenAI-compatible APIs-ஐ ஆதரிக்கிறது மற்றும் Ollama preset-ஐக் கொண்டுள்ளது. எனவே, http://host.docker.internal:11434/v1-ஐக் குறிப்பிட்டு, extra_hosts: ["host.docker.internal:host-gateway"]-ஐ container-ல் சேர்த்து, host-ல் OLLAMA_HOST=0.0.0.0:11434-ஐ அமைத்தால் இது வேலை செய்யும். Ollama-வில் சொந்தமாக authentication இல்லாததால், firewall-ல் 11434 port-ஐ 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-களிலும் வெளியிடுகிறது. இதனால் passwords மற்றும் bearer tokens இணையத்தில் cleartext-ஆகச் செல்லும். எனவே, published port-ஐ 127.0.0.1:8088:8088 என மாற்றி, முன்னால் Caddy அல்லது nginx-ஐ certificate-உடன் அமைக்கவும். Nginx பயன்படுத்தினால், WebSocket upgrade headers-ஐ forward செய்து, proxy_buffering off-ஐ அமைக்கவும். இல்லையெனில், பக்கம் load ஆகும், ஆனால் chat பதில் அளிக்காது.

Octop production பயன்பாட்டிற்குத் தயாரா?

ஆகஸ்ட் 2026 நிலவரப்படி, இது 1.0-க்கு முந்தைய நிலையில் இருந்தது மற்றும் வாரத்திற்குப் பல tagged releases-களை வெளியிட்டது. இது 14 செப்டம்பர் 2026 அன்று v1.0.0-ஐ வெளியிட்டது, பின்னர் 18 அக்டோபர் 2026 அன்று நிலையான v1.0.2-க்கு முன்பு பல 1.0.2 beta tags-களை வெளியிட்டது. அதன் வளர்ச்சி வேகம் இன்னும் அதிகமாக இருப்பதால், இதை முழுமையாக நிலைபெற்றதாகக் கருதாமல், நம்பிக்கைக்குரியதாகக் கருதவும். நீங்கள் ஒரு குறிப்பிட்ட tag-ஐப் பயன்படுத்தினால், ஒவ்வொரு upgrade-க்கு முன்பும் commit log-ஐப் படித்தால், மற்றும் ஒவ்வொரு rebuild-க்கு முன்பும் data volume-ஐ backup எடுத்தால், இது ஒரு குடும்பத்திற்கு அல்லது சிறிய உள்நாட்டுக் குழுவிற்குப் பயன்படுத்த ஏற்றது. இதை latest-ல் இயக்க வேண்டாம், மேலும் வாடிக்கையாளர் தரவுகளை இதில் சேமிக்க வேண்டாம்.

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