Paano i-self-host ang Octop gamit ang Docker Compose

Ano ang Octop at bakit mo ito dapat i-self-host

Ang Octop ay isang self-hosted AI assistant para sa household o maliit na team. Ang dahilan para i-self-host ang Octop sa halip na gumamit ng simpleng chat front end ay pinaghihiwalay nito ang mga user. Nagbibigay ang Open WebUI ng browser interface sa harap ng isang model. Nagdadagdag ang Octop ng mga account na may admin role, pribadong workspace at credential set para sa bawat user, at library ng mga specialist agent na maaaring pagpalipat-lipatan ng bawat user ayon sa task. Ito ang pagkakaibang nagbibigay-daan para makapaglingkod ang isang VPS sa limang tao sa halip na sa isa lamang.

Makikita ang project sa github.com/TencentCloud/Octop. Isang process ito na naghahatid ng web dashboard, command line interface, chat channels (Feishu, DingTalk, QQ, Discord, WeCom), at scheduled jobs. Lahat ng ito ay gumagamit ng iisang SQLite database sa ilalim ng ~/.octop/. Ang lahat ng nasa ibaba ay isinulat batay sa tag na v0.9.19, na inilabas noong 5 August 2026. Kung pinagpapasiyahan mo pa kung aling platform ang gagamitin, tinatalakay ng paghahambing ng mga alternatibo sa Open WebUI na maaari mong patakbuhin sa isang VPS ang mas malawak na mga opsyon.

May isang bagay na kailangang malinaw bago ka gumugol ng isang gabi rito. Ang Octop ay pre-1.0 software na inilalabas mula sa GitHub organisation ng isang vendor, at may humigit-kumulang 900 stars noong August 2026. Mabilis itong nagbabago, gaya ng ipinapakita ng mga version number, at walang ipinapangakong stable upgrade path dito. I-pin ang isang tag, basahin ang changelog, at panatilihin ang mga backup.

Mga kailangan bago magsimula

• Isang VPS na nagpapatakbo ng Ubuntu 24.04, kasama ang Docker Engine at Compose plugin. Bago sa Compose? Magsimula sa mga pangunahing kaalaman sa Docker Compose para sa VPS.
• git, dahil magche-check out ka ng release tag sa halip na mag-pull ng image.
• Isang domain name na nakaturo sa VPS, dahil kailangan mong ilagay sa unahan nito ang TLS (transport layer security).
• Isang model backend na gumagamit ng OpenAI API: lokal na Ollama, self-hosted gateway, o bayad na key.

Magaan mismo ang Octop. Isa itong Python process at SQLite file. Ang kumokonsumo ng resources ay ang model backend. Kaya kung plano mong patakbuhin ang model sa parehong box, i-size ang box ayon sa pangangailangan ng model.

Bakit hindi namin inirerekomenda ang curl installer

Nasa unahan ng README ang isang one-line install:

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

Hindi namin ito inirerekomenda sa server na mahalaga sa iyo, dahil sa isang tiyak na dahilan: wala sa repository ang script na iyon. Inihahatid ito mula sa isang Tencent Cloud Object Storage bucket. Walang git tag o commit na sumasaklaw rito, kaya hindi mo maikukumpara ang script ngayon sa script noong nakaraang linggo, at walang history na nagpapaliwanag sa pagbabago. Maaaring ibang bytes ang ihatid ng bucket bukas, at walang anumang bahagi ng project ang magtatala nito. Kapag direkta mong ipinasa ang resulta sa bash, tatakbuhin din ng machine ang script bago mo mabasa ang kahit isang linya nito.

Nagsusulat din ang installer sa host sa halip na sa isang container. Ginagamit nito ang uv upang kunin ang Python 3.12 at gumawa ng environment na hindi alam ng package manager mo, kaya mano-mano ang pag-aalis nito sa hinaharap.

Dalawa ang mas mainam na option. Kunin ang script, basahin ito, at saka patakbuhin; tatagal ito nang tatlumpung segundo: curl -fsSL <url> -o install.sh, pagkatapos ay less install.sh, at saka bash install.sh. O gamitin ang Docker, na siyang paksa ng natitirang bahagi ng guide na ito. Ang PyPI package (pip install octop) ay kahit paano isang versioned artifact na maaari mong i-pin sa isang release.

I-deploy ang Octop gamit ang Docker Compose, naka-pin sa v0.9.19

Walang published image na maaaring i-pull hanggang Agosto 2026. Binubuo ng kasamang Compose file ang image mula sa repository, kaya ang pag-pin ng version ay nangangahulugang pag-checkout ng git tag.

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

Ito ang service na dine-define ng file, pinaikli sa mahahalagang bahagi:

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:-}

Pansinin ang build: block. Ang image: octop:latest ang pangalan ng sarili mong build, hindi registry reference, kaya ang latest dito ay nangangahulugang anumang pinakabagong na-compile mo. Itakda ang data path sa isang malinaw na lokasyon sa halip na iwan ito sa default, at magtakda ng totoong password para sa admin account bago ang unang boot. Ilagay ito sa docker/.env:

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

May isang karaniwang pagkakamali rito na mas mahalaga kaysa sa iba pang bahagi ng file. Binabasa ng Compose ang docker/.env para lamang mag-interpolate ng mga ${...} placeholder sa YAML. Ang key na idinagdag mo sa file na iyon ay hindi mapupunta sa container maliban kung nakalista rin ito sa ilalim ng environment: sa Compose file. Kapag idinagdag lamang ang OCTOP_ACCESS_TOKEN_TTL sa .env, wala itong ginagawa, at walang error na ipinapakita. Ang alternatibo ay ilagay ang parehong key sa ~/.octop/env sa loob ng naka-mount na data directory, na nilo-load ng Octop sa startup. Ipinapaliwanag ng gabay sa env files at secrets sa Docker Compose kung bakit hindi pareho ang dalawang mekanismong ito.

I-build at i-start ito:

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

Ang maayos na instance ay sumasagot sa health check gamit ang {"status":"ok","version":"..."}. Kung iba ang resulta, basahin ang docker compose -f docker/docker-compose.yml logs -f octop bago gumamit ng browser.

Bigyan ngayon ng makabuluhang pangalan ang image na kakabuo mo lang, dahil mao-overwrite ng susunod na --build ang octop:latest at wala ka nang paraan para mapagkaiba ang dalawa:

docker image tag octop:latest octop:0.9.19

Sa unang boot, tatakbuhin ang octop init at isusulat ang panimulang credentials sa data volume:

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

Ang mga default ay admin / octop, at inilalapat lamang ang mga ito sa unang init. Ito ang dahilan sa karaniwang tanong: kapag binago ang OCTOP_DEFAULT_PASSWORD matapos unang ma-start ang container, walang magbabago dahil umiiral na ang account. Palitan ang password sa dashboard.

Huwag i-publish ang port 8088

Binibind ng ports: line sa itaas ang bawat interface sa VPS. Sa sandaling magsimula ang container, available na sa public internet ang dashboard nang walang encryption at may default password. Ang sariling default na OCTOP_BIND_HOST ng Octop ay 127.0.0.1; ino-override ito ng Compose file bilang 0.0.0.0 dahil kailangang tumanggap ang process ng traffic mula sa labas ng sarili nitong network namespace. Tama ang override na iyon. Ang published port ang bahaging naglalantad sa iyo.

I-edit ang ports: line sa docker/docker-compose.yml upang loopback lamang ang pakinggan ng mapping:

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

Huwag subukang ayusin ito gamit ang plain override file. Pinagsasama ng Compose ang mga ports list mula sa maraming file sa halip na palitan ang mga ito, kaya mauuwi ka sa pag-publish ng parehong mapping at mabibigo ang pangalawa na mag-bind. Kung nais mong hindi galawin ang upstream file, gamitin ang !override tag sa sequence. Ito ang dokumentadong paraan upang palitan ang sequence sa halip na idagdag dito. Sinasaklaw ng paliwanag kung paano nagme-merge ang Compose ng maraming file ang iba pang merge rule.

Nilulutas din ng pag-bind sa loopback ang problemang maaaring maranasan mo sa firewall. Isinusulat ng Docker ang mga published-port rule nito sa nat table bago ang mga chain na mina-manage ng ufw, kaya hindi napipigilan ng ufw deny 8088 ang published container port. Ang port na naka-bind sa 127.0.0.1 ay hindi kailanman maaabot mula sa labas, anuman ang tingin ng ufw dito. Kaya ito ang tamang fix, hindi lamang pangalawang opsyon.

Ilagay ang TLS sa harap gamit ang reverse proxy

Pinakamaikling paraan ang Caddy dahil kusa itong humihingi ng certificate sa pamamagitan ng ACME (automatic certificate management environment) at awtomatiko nitong bina-proxy ang WebSockets:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

Mas kailangan ng pag-iingat ang nginx dahil nag-i-stream ang Octop ng chat sa pamamagitan ng WebSocket:

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

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

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

May partikular na gamit ang bawat linya. Tumatakbo ang chat sa WS /agents/{id}/chat/ws, kaya kung wala ang proxy_http_version 1.1 at ang dalawang upgrade header, sinasagot ng nginx ang pagtatangkang mag-upgrade gamit ang 400 Bad Request: normal na naglo-load ang dashboard, pero habang-buhay na nagha-hang ang bawat mensaheng ipinapadala mo at walang error na lumalabas sa page. Mahalaga ang proxy_buffering off dahil nagbabalik ng text/event-stream ang human-in-the-loop resume endpoint, at kung naka-buffer sa proxy ang SSE (server-sent events), darating ang mga ito nang sabay-sabay sa dulo sa halip na tuloy-tuloy na mag-stream. Sinasaklaw ng proxy_read_timeout ang mahahabang tool run, dahil pinuputol ng default na 60 second ang agent sa kalagitnaan ng task at itinatala sa logs ang upstream timed out (110: Connection timed out).

Paano gumagana ang JWT auth sa likod ng proxy

Nag-a-authenticate ang Octop gamit ang bearer token, hindi cookie. Ang POST /api/auth/login ay nagbabalik ng {access_token, role, user, ...}, at kasama sa mga kasunod na request ang Authorization: Bearer <access_token>. Magandang balita ito para sa reverse proxy: walang cookie domain, walang Secure flag, at walang SameSite rule na maaaring maling ma-configure. Kaya ang session na gumana sa http://127.0.0.1:8088 ay gagana rin sa https://octop.example.com.

May dalawang consequence na dapat mong malaman bago mo ito gamitin ng mga aktuwal na user.

Nasa URL ang token ng WebSocket. Ang endpoint ay WS /agents/{id}/chat/ws?token=<jwt> dahil hindi makapagtakda ang browser JavaScript ng Authorization header sa WebSocket handshake. Pinoprotektahan ng TLS ang token habang ipinapadala. Ngunit hindi nito pinoprotektahan ang token mula sa sarili mong logs: bilang default, isinusulat ng nginx sa access_log ang buong request line, kasama ang query string. Dahil dito, napupunta sa plaintext file sa server ang gumaganang token ng isang aktuwal na user. I-log ang path nang walang arguments. Ang $uri ay ang normalized path na natanggalan na ng query string, kaya ilagay ito sa http block at i-reference ito mula sa 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;

Walang per-session logout. Ang default ng OCTOP_ACCESS_TOKEN_TTL ay 86400, kaya nananatiling valid ang token nang 24 oras pagkatapos ng login. Ang tanging documented na paraan para i-invalidate ang isang token ay octop admin rotate-jwt-secret. Niro-rotate nito ang signing key na naka-store sa ~/.octop/secrets/jwt_secret at agad na ini-invalidate ang lahat ng kasalukuyang token para sa lahat ng user. Kaya kapag umalis ang isang tao sa team, ganito ang pagkakasunod-sunod: i-delete ang user, i-rotate ang secret, pagkatapos ay sabihan ang mga natitirang user na mag-login muli. Kung mabigat ito, paikliin ang lifetime. Tandaang idagdag din ang variable sa listahan ng environment:, bukod sa .env:

OCTOP_ACCESS_TOKEN_TTL=28800

Nahaharangan ang brute force: ang default ng OCTOP_LOGIN_MAX_ATTEMPTS ay 5 failures at ang OCTOP_LOGIN_LOCKOUT_SECONDS ay 900. Kaya ang naka-lock na user ay maghihintay lamang ng 15 minuto, sa halip na isipin na sira ang installation. May sarili nitong user store ang Octop at walang documented na OIDC support sa v0.9.19. Kung kailangan mo ng tunay na single sign-on, maglagay ng authenticating proxy sa harap nito. Ito ang gamit ng self-hosted Authentik server.

Point Octop sa model backend

Kino-configure ang mga provider para sa bawat agent sa dashboard, at ipinapakita sa octop provider list kung ano ang naka-set. May mga preset ang Octop para sa OpenAI-compatible APIs, DashScope (Qwen), at Ollama, at naka-store ang credentials sa providers table ng sarili mong SQLite database. Binabago ng pagpili kung magkano ang babayaran mo at kung anong data ang lumalabas sa server.

Isang local model gamit ang Ollama. Walang lumalabas sa server, at RAM ang ginagamit mo sa halip na tokens ang binabayaran. Ito ang wiring detail na madalas nakakalito: hindi maa-access ng container ang Ollama sa host sa 127.0.0.1:11434, dahil ang address na iyon ay loopback ng container mismo. Magdagdag ng host gateway entry sa service:

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

Pagkatapos, itakda ang provider base URL sa http://host.docker.internal:11434/v1, na siyang OpenAI-compatible path ng Ollama, at maglagay ng anumang non-empty string sa API key field, dahil binabalewala ito ng Ollama ngunit tumatangging magpadala ang OpenAI clients kapag walang laman. Kailangan ding makinig ang Ollama sa labas ng loopback para gumana ito, na nangangahulugang OLLAMA_HOST=0.0.0.0:11434 sa systemd unit nito. Ito ang mapanganib na bahagi: walang authentication ang Ollama, kaya ang bukas na 11434 sa public IP ay libreng model server para sa unang makapag-scan nito. Payagan lamang ang private range ng Docker, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp, at i-deny ang iba. Saklaw ng Pagpapatakbo ng Ollama sa VPS ang model sizing, at saklaw ng paghahambing ng Ollama at vLLM kung kailan hindi na angkop na server ang Ollama.

May isa pang babala tungkol sa local model dahil mukha itong bug sa Octop, pero hindi ito bug. Gumagana ang mga agent sa pamamagitan ng pagtawag sa tools, at malaki ang prompt dahil kasama rito ang system prompt, tool definitions, at history. Nagse-serve ang Ollama ng mga model na may maliit na default context window, kaya nawawala sa window ang unahan ng prompt, kung saan naroon ang tool definitions. Pagkatapos, tumitigil ang model sa pagtawag sa tools o gumagawa ng mga tool na hindi naman umiiral. Itaas ang num_ctx sa 16k o 32k at pumili ng model na mahusay talaga sa function calling.

Isang self-hosted gateway. Ilagay ang isang self-hosted LiteLLM gateway sa pagitan ng Octop at ng lahat ng iba pang serbisyo. Magkakaroon ka ng iisang base URL, hiwalay na key para sa bawat user, spend limits, at iisang log. Maaari mo ring palitan ang model sa likod nito nang hindi nag-e-edit ng anuman sa Octop.

Isang paid API. Ito ang may pinakamagandang kalidad, kapalit ng malinaw na tradeoff: lumalabas sa server mo ang laman ng conversation at ipinapadala sa provider, na siyang kabaligtaran ng malaking dahilan kung bakit nagse-self-host. Ilagay ang key sa docker/.env bilang OPENAI_API_KEY; ipinapasa na ito ng Compose file.

Anuman ang piliin mo, dala rin ng Compose file ang OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY at LANGFUSE_BASE_URL, kaya maaari kang magpadala ng traces sa sarili mong Langfuse instance at makita kung ano talaga ang ginagawa ng mga agent sa halip na manghula batay sa chat window.

Mga user, role, at shared agent library

Ang admin account mula sa unang boot ang gumagawa at namamahala sa iba pang account. May sariling agents, workspace, at credentials ang bawat user. Nakapaloob sa token na hawak ng browser ang isolation na ito. Kasabay nito, may shared pool ng skills at sub-agents na maaaring gamitin ng kahit sino. Ito ang feature na nagpapahalaga rito para sa isang pamilya: isang beses lamang bubuo ang isang tao ng mahusay na research agent, at hindi na ito kailangang buuin muli ng iba.

Mag-ingat sa paggamit ng tooling. Nag-aalok ang Octop ng tool approval at mga guardrail para sa shell commands, at tunay na gumagana ang dalawa. Gayunman, ang agent na nagpapatakbo ng shell commands ay nagpapatakbo ng mga ito sa loob ng Octop container na naka-mount ang data volume mo. Nililimitahan ng mga guardrail ang maaaring gawin ng careless prompt. Hindi ang mga ito kapalit ng sandbox boundary, kaya panatilihing naka-on ang tool approval para sa sinumang hindi mo bibigyan ng direktang access sa shell. Kung ikinukumpara mo ito sa ibang option, inihahambing sa roundup ng mga self-hosted AI agent kung paano hinahandle ng bawat isa ang bahaging ito.

Pag-upgrade ng project na ganito kabilis mag-release

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

Iyan ang mga petsa ng tag mula sa repository, batay sa bilang hanggang 7 August 2026. May 4 na tagged release na nailabas sa loob ng siyam na araw, na may pagitan na kasing-ikli ng 1 araw, at dumating ang v0.9.19 makalipas ang 3 araw mula sa naunang tag. Magandang senyales para sa project ang ganitong cadence, pero hindi ito magandang dahilan para awtomatikong patakbuhin ang latest. Basahin muna ang mga pagbabago bago mo ito isagawa:

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"

Mag-back up muna sa bawat pagkakataon, dahil tumatakbo ang database migrations sa startup at ikaw ang kailangang mag-ayos ng failed migration sa isang pre-1.0 project:

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

Pagkatapos, i-check out ang bagong tag at mag-rebuild gamit ang docker compose -f docker/docker-compose.yml up -d --build. Kung magkaroon ng problema, maibabalik ang code sa pamamagitan ng pag-check out sa lumang tag at pag-rebuild, pero ang tarball lamang ang makapagbabalik ng database.

Nasa tarball ang octop.db, config.json, JWT signing secret, at credential.txt, kaya kasing-sensitibo nito ang server mismo. Itakda ito sa mode 600 at magtago ng kopya sa labas ng server. Para sa mas malaking installation, naglalabas din ang project ng docker/docker-compose.postgres.yml, na nagpapatakbo ng PostgreSQL gamit ang pgvector sa halip na SQLite.

Mga failure mode at mga string na makikita mo

Hindi kailanman sumasagot ang health check. Nagha-hang o tumatanggi ang curl http://127.0.0.1:8088/api/health. Basahin ang docker compose -f docker/docker-compose.yml logs -f octop. Ang container na nag-e-exit sa unang init ay karaniwang hindi makapagsulat sa data directory, kaya suriin ang ownership ng anumang itinakda mo sa OCTOP_DATA.

Naglo-load ang dashboard pero nagha-hang ang chat. Walang error sa page at wala ring reply. Buksan ang browser console at hanapin ang failed connection sa wss://octop.example.com/agents/.../chat/ws. Hindi ipinapasa ng proxy ang upgrade. Idagdag ang proxy_http_version 1.1 at ang Upgrade at Connection headers.

Sabay-sabay lumilitaw ang buong reply makalipas ang ilang segundo. Gumagana ang streaming pero naka-on ang buffering. Itakda ang proxy_buffering off.

bind: address already in use. May ibang process nang gumagamit sa 8088. Tinutukoy ito ng sudo ss -tlnp | grep 8088. Ganito rin ang mangyayari kung nagdagdag ka ng pangalawang ports entry sa override file sa halip na i-edit ang orihinal.

Tinatanggihan ang tamang password. Nagti-trigger ang 5 maling attempt ng 900 second lockout. Hintayin itong matapos sa halip na mag-reinstall.

Walang epekto ang bagong password sa .env. Sa unang init lamang ginagamit ang mga credential na iyon. Palitan ito sa dashboard.

Sumasagot ang agent pero hindi kailanman nagpapatakbo ng tool. Halos palaging local model problem ito: masyadong maliit ang context window para sa tool definitions, o mahina ang model sa function calling. Itaas ang num_ctx at subukan ang model na ginawa para sa tool use.

FAQ

Ang Octop ba ay kapalit ng Open WebUI?

Oo, kung kailangan mo ang mga idinaragdag nito. Ang Open WebUI ay chat interface sa harap ng isang model, at mahusay nitong ginagawa ang tungkuling iyon para sa isang tao o isang pamilyang may tiwala sa isa’t isa. Nagdadagdag ang Octop ng mga account na may admin role, mga workspace at credential para sa bawat user, at napapalitang library ng mga specialist agent. Dahil dito, maaaring magbahagi ng isang server ang ilang tao nang hindi nagbabahagi ng iisang history. Kung sapat na sa iyo ang isang account, mas simple at mas mature ang Open WebUI.

Bakit hindi ko dapat gamitin ang Octop curl install script?

Hinahain ang script mula sa Tencent Cloud Object Storage bucket at hindi mula sa repository, kaya hindi ito saklaw ng anumang git tag o commit. Hindi mo maihahambing ang ginagawa nito ngayon sa ginawa nito noong nakaraang linggo. Kapag ipinasa mo ito sa bash, tatakbo ito bago mo pa ito mabasa. Ini-install din nito ang sarili nito sa host gamit ang sarili nitong Python 3.12 environment, sa labas ng iyong package manager. I-download ito at basahin muna, o mag-deploy gamit ang Docker Compose mula sa isang na-checkout na tag.

Magagamit ba ng Octop ang local model sa halip na paid API?

Oo. Gumagamit ang Octop ng OpenAI-compatible API at may kasamang Ollama preset. Gagana ang pag-point dito sa http://host.docker.internal:11434/v1 kapag idinagdag mo ang extra_hosts: ["host.docker.internal:host-gateway"] sa container at itinakda ang OLLAMA_HOST=0.0.0.0:11434 sa host. I-firewall ang port 11434 para sa address range ng Docker, dahil walang sariling authentication ang Ollama. Asahang itaas ang num_ctx ng Ollama sa 16k o mas mataas, dahil lumalagpas sa default context window ang agent prompt na may tool definitions. Dahil dito, tumitigil ang model sa pagtawag sa mga tool.

Kailangan ko ba ng reverse proxy, o maaari kong buksan ang port 8088?

Kailangan mo ng proxy. Inilalabas ng kasamang Compose file ng Octop ang 8088 sa lahat ng interface nang walang TLS, kaya maaaring dumaan sa internet nang cleartext ang mga password at bearer token. Palitan ang published port ng 127.0.0.1:8088:8088 at ilagay ang Caddy o nginx sa harap nito na may certificate. Sa nginx, ipasa ang WebSocket upgrade headers at itakda ang proxy_buffering off. Kung hindi, maglo-load ang page pero tahimik na hindi tutugon ang chat.

Handa na ba ang Octop para sa production?

Nasa pre-1.0 pa ito at naglalabas ng ilang tagged release bawat linggo noong August 2026, kaya ituring itong promising ngunit hindi pa stable. Maaari itong gamitin ng isang pamilya o maliit na internal team kung magpi-pin ka ng eksaktong tag, babasahin ang commit log bago ang bawat upgrade, at magba-backup ng data volume bago ang bawat rebuild. Huwag itong patakbuhin sa latest, at huwag muna maglagay rito ng customer data.