Cara Host Sendiri Octop AI Assistant di VPS Docker

Apakah Octop, dan mengapa anda perlu menghoskannya sendiri

Octop ialah pembantu AI yang dihoskan sendiri untuk isi rumah atau pasukan kecil. Sebab untuk menghoskan Octop sendiri berbanding sekadar menggunakan antaramuka sembang biasa adalah kerana ia mengasingkan pengguna antara satu sama lain. Open WebUI memberikan anda antaramuka pelayar di hadapan model. Octop menambah akaun dengan peranan admin, ruang kerja peribadi dan set kelayakan untuk setiap pengguna, serta pustaka ejen pakar yang boleh ditukar ganti oleh setiap pengguna mengikut tugasan. Itulah perbezaan yang membolehkan satu VPS melayani lima orang dan bukannya seorang sahaja.

Projek ini terletak di github.com/TencentCloud/Octop. Ia merupakan satu proses yang menyediakan papan pemuka web, antaramuka baris perintah, saluran sembang (Feishu, DingTalk, QQ, Discord, WeCom) dan tugasan berjadual, semuanya disokong oleh satu pangkalan data SQLite di bawah ~/.octop/. Segala maklumat di bawah ditulis berdasarkan tag v0.9.19, yang dikeluarkan pada 5 Ogos 2026. Jika anda masih membuat keputusan antara platform, perbandingan alternatif Open WebUI yang boleh anda jalankan pada VPS merangkumi skop yang lebih luas.

Satu perkara yang perlu jelas sebelum anda meluangkan masa untuknya. Octop ialah perisian pra-1.0 yang diterbitkan daripada organisasi GitHub vendor, dengan sekitar 900 bintang setakat Ogos 2026. Ia berkembang dengan pantas, seperti yang ditunjukkan oleh nombor versinya, dan tiada apa-apa di sini yang menjanjikan laluan naik taraf yang stabil. Tetapkan tag, baca log perubahan, dan sentiasa buat sandaran.

Prasyarat sebelum bermula

• Sebuah VPS yang menjalankan Ubuntu 24.04 dengan Docker Engine dan pemalam Compose. Baru dengan Compose? Mulakan dengan asas Docker Compose untuk VPS.
• git, kerana anda akan menyemak tag keluaran (release tag) dan bukannya menarik (pull) imej.
• Nama domain yang menghala ke VPS, kerana anda memerlukan TLS (transport layer security) di hadapan aplikasi ini.
• Backend model yang menyokong OpenAI API: Ollama tempatan, gateway yang dihoskan sendiri, atau kunci berbayar.

Octop sendiri adalah ringan. Ia merupakan proses Python dan fail SQLite. Beban utama datang daripada backend model, jadi jika anda bercadang untuk menjalankan model pada pelayan yang sama, pastikan saiz pelayan mencukupi untuk model tersebut.

Mengapa kami tidak mengesyorkan pemasang curl

README bermula dengan arahan pemasangan satu baris:

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

Kami tidak mengesyorkannya pada pelayan yang penting bagi anda, atas satu sebab konkrit: skrip tersebut tidak berada dalam repositori. Ia dihoskan daripada baldi Tencent Cloud Object Storage. Tiada apa-apa mengenainya dilindungi oleh tag git atau commit, jadi anda tidak boleh melakukan diff antara skrip hari ini dengan skrip minggu lepas, dan tiada sejarah yang menjelaskan sesuatu perubahan. Baldi tersebut boleh menghantar bait yang berbeza pada hari esok dan tiada apa-apa dalam projek yang akan merekodkannya. Menyalurkan hasil terus ke dalam bash juga bermakna mesin menjalankan skrip tersebut sebelum anda sempat membaca walau sebaris pun daripadanya.

Pemasang itu juga menulis terus ke hos dan bukannya ke dalam container. Ia menggunakan uv untuk mengambil Python 3.12 dan membina persekitaran yang tidak diketahui oleh pengurus pakej anda, jadi membuangnya kemudian menjadi tugas manual.

Terdapat dua pilihan yang lebih baik. Ambil skrip tersebut, baca, kemudian jalankannya, yang hanya mengambil masa tiga puluh saat: curl -fsSL <url> -o install.sh, kemudian less install.sh, dan seterusnya bash install.sh. Atau gunakan Docker, yang merupakan fokus bagi baki panduan ini. Pakej PyPI (pip install octop) sekurang-kurangnya merupakan artifak berversi yang boleh anda tetapkan pada sesuatu release.

Melancarkan Octop dengan Docker Compose, ditetapkan pada v0.9.19

Tiada imej yang diterbitkan untuk ditarik sehingga Ogos 2026. Fail Compose yang dibekalkan membina imej daripada repositori, jadi menetapkan versi bermaksud menyemak keluar (checkout) tag git.

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

Ini adalah servis yang ditakrifkan oleh fail tersebut, diringkaskan kepada bahagian yang penting:

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

Perhatikan blok build:. image: octop:latest ialah nama yang diberikan kepada binaan anda sendiri, bukan rujukan daftar (registry), jadi latest di sini bermaksud apa sahaja yang anda kompilasi paling baru. Tetapkan laluan data ke lokasi yang eksplisit dan bukannya membiarkannya pada laluan lalai, serta berikan akaun admin kata laluan sebenar sebelum but pertama. Letakkan ini dalam docker/.env:

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

Satu perangkap di sini lebih penting daripada bahagian lain dalam fail tersebut. Compose membaca docker/.env hanya untuk melakukan interpolasi pada pemegang tempat ${...} dalam YAML. Kunci yang anda tambah pada fail itu tidak sampai ke dalam kontena melainkan ia juga disenaraikan di bawah environment: dalam fail Compose. Menambah OCTOP_ACCESS_TOKEN_TTL kepada .env sahaja tidak akan memberikan sebarang kesan secara senyap. Alternatifnya ialah menulis kunci yang sama ke dalam ~/.octop/env di dalam direktori data yang dilekapkan (mounted), yang dimuatkan oleh Octop semasa permulaan. panduan mengenai fail env dan rahsia dalam Docker Compose menerangkan sebab kedua-dua mekanisme ini tidak sama.

Bina dan mulakan ia:

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

Instans yang sihat akan menjawab pemeriksaan kesihatan dengan {"status":"ok","version":"..."}. Jika sebaliknya, baca docker compose -f docker/docker-compose.yml logs -f octop sebelum menyentuh pelayar web.

Sekarang, berikan nama yang bermakna kepada imej yang baru anda bina, kerana --build seterusnya akan menulis ganti octop:latest dan anda tidak akan mempunyai cara untuk membezakan kedua-duanya:

docker image tag octop:latest octop:0.9.19

But pertama menjalankan octop init dan menulis kelayakan permulaan ke dalam volum data:

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

Nilai lalai ialah admin / octop, dan ia digunakan hanya pada init pertama. Itu adalah mekanisme di sebalik soalan yang sering ditanya orang: menukar OCTOP_DEFAULT_PASSWORD selepas kontena sudah dimulakan sekali tidak akan mengubah apa-apa, kerana akaun tersebut sudah wujud. Tukar kata laluan dalam papan pemuka (dashboard) sebaliknya.

Jangan dedahkan port 8088

Baris ports: di atas mengikat setiap antara muka pada VPS. Sebaik sahaja kontena bermula, papan pemuka tersebut berada di internet awam dalam teks jelas, dengan kata laluan lalai. Nilai lalai OCTOP_BIND_HOST bagi Octop ialah 127.0.0.1; fail Compose menindihnya kepada 0.0.0.0 kerana proses tersebut mesti menerima trafik dari luar ruang nama rangkaiannya sendiri. Tindihan itu adalah betul. Port yang diterbitkan adalah bahagian yang mendedahkan anda.

Sunting baris ports: dalam docker/docker-compose.yml supaya pemetaan hanya mendengar pada loopback:

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

Jangan cuba membetulkan perkara ini dengan fail tindihan biasa. Compose mencantumkan senarai ports daripada berbilang fail dan bukannya menggantikannya, jadi anda akhirnya menerbitkan kedua-dua pemetaan dan yang kedua gagal untuk diikat. Jika anda ingin mengekalkan fail hulu tanpa disentuh, gunakan tag !override pada jujukan tersebut, yang merupakan cara yang didokumenkan untuk mengganti dan bukannya menambah. Penjelasan tentang cara Compose menggabungkan berbilang fail merangkumi baki peraturan gabungan tersebut.

Mengikat kepada loopback juga menyelesaikan masalah yang akan anda hadapi dengan firewall. Docker menulis peraturan port yang diterbitkan ke dalam jadual nat sebelum rantaian yang diuruskan oleh ufw, jadi ufw deny 8088 tidak menghentikan port kontena yang diterbitkan. Port yang diikat pada 127.0.0.1 tidak akan dapat dicapai dari luar tanpa mengira apa yang difikirkan oleh ufw, itulah sebabnya ia adalah pembetulan yang tepat dan bukannya pilihan kedua terbaik.

Letakkan TLS di hadapan dengan reverse proxy

Caddy ialah laluan paling singkat, kerana ia meminta sijil melalui ACME (automatic certificate management environment) secara automatik dan memproksi WebSocket tanpa perlu dikonfigurasikan secara khusus:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx memerlukan perhatian lebih, kerana Octop menstrim sembang melalui 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;
    }
}

Setiap baris di situ mempunyai fungsi. Sembang berjalan melalui WS /agents/{id}/chat/ws, jadi tanpa proxy_http_version 1.1 dan dua header upgrade, nginx akan menjawab percubaan upgrade dengan 400 Bad Request: papan pemuka dimuatkan seperti biasa tetapi setiap mesej yang anda hantar tergantung selama-lamanya tanpa ralat pada halaman. proxy_buffering off penting kerana endpoint resume human-in-the-loop mengembalikan text/event-stream, dan SSE (server-sent events) yang ditahan dalam penimbal proksi akan tiba sebagai satu kelompok pada akhirnya dan bukannya menstrim. proxy_read_timeout meliputi pelaksanaan alatan yang panjang, memandangkan tetapan lalai 60 saat akan memutuskan sambungan ejen di tengah tugasan dan mencatatkan upstream timed out (110: Connection timed out).

Bagaimana pengesahan JWT berfungsi di sebalik proksi

Octop mengesahkan pengguna menggunakan bearer token, bukan kuki. POST /api/auth/login mengembalikan {access_token, role, user, ...} dan panggilan seterusnya membawa Authorization: Bearer <access_token>. Bagi reverse proxy, ini adalah berita baik: tiada domain kuki, tiada flag Secure dan tiada peraturan SameSite yang boleh tersalah konfigurasi, jadi sesi yang berfungsi pada http://127.0.0.1:8088 akan berkelakuan sama pada https://octop.example.com.

Dua akibat perlu diketahui sebelum anda membenarkan pengguna sebenar menggunakannya.

WebSocket membawa token dalam URL. Endpoint tersebut ialah WS /agents/{id}/chat/ws?token=<jwt>, kerana JavaScript pelayar tidak boleh menetapkan header Authorization semasa jabat tangan WebSocket. TLS melindungi token tersebut semasa transit. Ia tidak melindunginya daripada log anda sendiri: nginx menulis baris permintaan penuh, termasuk query string, ke access_log secara lalai, jadi token yang berfungsi bagi pengguna sebenar akan berakhir dalam fail teks biasa pada pelayan. Log laluan tanpa argumen. $uri ialah laluan ternormal dengan query string yang telah dibuang, jadi letakkan ini dalam blok http dan rujuk ia daripada 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;

Tiada log keluar bagi setiap sesi. OCTOP_ACCESS_TOKEN_TTL ditetapkan secara lalai kepada 86400, jadi token kekal sah selama 24 jam selepas log masuk. Satu-satunya cara yang didokumentasikan untuk membatalkan token adalah octop admin rotate-jwt-secret, yang menukar kunci penandatangan yang disimpan di ~/.octop/secrets/jwt_secret dan membatalkan setiap token yang sedia ada serta-merta, untuk semua orang. Jadi apabila seseorang meninggalkan pasukan, urutannya adalah: padam pengguna, tukar secret, kemudian minta pengguna yang tinggal untuk log masuk semula. Jika ini kedengaran membebankan, pendekkan tempoh hayat, dengan mengingati untuk menambah pemboleh ubah tersebut ke dalam senarai environment: serta .env:

OCTOP_ACCESS_TOKEN_TTL=28800

Serangan brute force dikendalikan: OCTOP_LOGIN_MAX_ATTEMPTS ditetapkan secara lalai kepada 5 kegagalan dan OCTOP_LOGIN_LOCKOUT_SECONDS kepada 900, jadi pengguna yang terkunci hanya perlu menunggu lima belas minit dan bukannya melihat pemasangan yang rosak. Octop mempunyai stor pengguna sendiri dan tiada sokongan OIDC yang didokumentasikan pada v0.9.19, jadi jika anda memerlukan single sign-on yang sebenar, anda perlu meletakkan proksi pengesahan di hadapannya, iaitu tujuan bagi pelayan Authentik yang dihoskan sendiri.

Menghalakan Octop ke backend model

Penyedia dikonfigurasikan bagi setiap ejen dalam papan pemuka, dan octop provider list menunjukkan tetapan yang telah dibuat. Octop menyertakan pratetap untuk API yang serasi dengan OpenAI, DashScope (Qwen), dan Ollama, manakala kelayakan disimpan dalam jadual providers dalam pangkalan data SQLite anda sendiri. Pilihan ini menentukan kos yang perlu dibayar dan data yang keluar dari pelayan.

Model tempatan dengan Ollama. Tiada data yang keluar dari pelayan, dan anda membayar menggunakan RAM dan bukannya token. Perincian sambungan yang sering terlepas pandang: kontena tidak boleh mencapai Ollama pada hos di 127.0.0.1:11434, kerana alamat tersebut adalah loopback bagi kontena itu sendiri. Tambahkan entri host gateway pada servis:

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

Kemudian, tetapkan base URL penyedia kepada http://host.docker.internal:11434/v1, iaitu laluan yang serasi dengan OpenAI bagi Ollama, dan masukkan sebarang rentetan aksara dalam medan API key, kerana Ollama mengabaikannya tetapi klien OpenAI akan menolak jika medan tersebut kosong. Ollama juga mesti mendengar di luar loopback supaya ini berfungsi, yang bermaksud OLLAMA_HOST=0.0.0.0:11434 dalam unit systemd-nya. Ini adalah bahagian yang berisiko: Ollama tidak mempunyai pengesahan, jadi port 11434 yang terbuka pada IP awam akan menjadi pelayan model percuma untuk sesiapa sahaja yang mengimbasnya. Benarkan hanya julat peribadi Docker, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp, dan sekat yang lain. Menjalankan Ollama pada VPS merangkumi saiz model, dan perbandingan Ollama dan vLLM merangkumi situasi apabila Ollama bukan lagi pelayan yang sesuai.

Satu lagi amaran tentang model tempatan, kerana ia kelihatan seperti pepijat dalam Octop sedangkan bukan. Ejen berfungsi dengan memanggil alatan, dan prompt sistem berserta definisi alatan dan sejarah merupakan prompt yang besar. Ollama menyediakan model dengan tetingkap konteks lalai yang sederhana, jadi bahagian hadapan prompt, tempat definisi alatan berada, akan terkeluar daripada tetingkap tersebut. Model kemudiannya berhenti memanggil alatan atau mencipta alatan yang tidak wujud. Tingkatkan num_ctx kepada 16k atau 32k dan pilih model yang benar-benar cekap dalam melakukan panggilan fungsi.

Gateway yang dihoskan sendiri. Letakkan gateway LiteLLM yang dihoskan sendiri di antara Octop dan segala-galanya, dan anda akan mendapat satu base URL, kunci berasingan bagi setiap pengguna, had perbelanjaan, dan satu log tunggal. Anda juga boleh menukar model di belakangnya tanpa perlu menyunting apa-apa dalam Octop.

API berbayar. Kualiti terbaik, dengan pertukaran yang jelas: kandungan perbualan meninggalkan pelayan anda dan sampai kepada penyedia, yang bertentangan dengan tujuan utama self-hosting. Kunci dimasukkan ke dalam docker/.env sebagai OPENAI_API_KEY, yang telah pun dilalui oleh fail Compose.

Walau apa pun pilihan anda, fail Compose juga membawa OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY dan LANGFUSE_BASE_URL, supaya anda boleh menghantar jejak ke instans Langfuse anda sendiri dan melihat perkara yang sebenarnya dilakukan oleh ejen dan bukannya meneka daripada tetingkap sembang.

Pengguna, peranan, dan pustaka ejen kongsi

Akaun pentadbir daripada but pertama mencipta dan mengurus akaun lain. Setiap pengguna mendapat ejen, ruang kerja dan kelayakan mereka sendiri, dan pengasingan tersebut dibawa oleh token yang disimpan oleh pelayar. Di samping itu, terdapat kumpulan kemahiran dan sub-ejen kongsi yang boleh digunakan oleh sesiapa sahaja, iaitu ciri yang menjadikan sistem ini berbaloi untuk dijalankan oleh keluarga: seorang individu membina ejen penyelidikan yang baik sekali sahaja, dan orang lain tidak perlu membinanya semula.

Berhati-hati dengan peralatan yang digunakan. Octop mengiklankan kelulusan alat dan kawalan keselamatan (guardrails) arahan shell, dan kedua-duanya adalah benar, tetapi ejen yang menjalankan arahan shell melaksanakannya di dalam kontena Octop dengan volum data anda dilekapkan. Kawalan keselamatan mengurangkan kesan daripada arahan (prompt) yang cuai. Ia bukanlah sempadan sandbox, jadi kekalkan kelulusan alat dihidupkan untuk sesiapa sahaja yang anda tidak akan berikan akses shell. Jika anda sedang menimbangkan pilihan ini berbanding pilihan lain, ringkasan ejen AI yang dihoskan sendiri membandingkan cara setiap satu mengendalikan perkara tersebut.

Menaik taraf projek yang mengeluarkan versi dengan pantas

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

Berikut adalah tarikh tag daripada repositori, dikira sehingga 7 Ogos 2026. 4 keluaran bertag telah dilancarkan dalam masa sembilan hari, dengan jurang sesingkat 1 hari, dan v0.9.19 tiba 3 hari selepas tag sebelumnya. Kekerapan ini merupakan petanda baik bagi projek tersebut namun menjadi sebab yang kurang baik untuk menjalankan latest. Baca perubahan sebelum anda menerimanya:

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"

Lakukan sandaran terlebih dahulu, setiap kali, kerana migrasi pangkalan data dijalankan semasa permulaan dan migrasi yang gagal pada projek pra-1.0 adalah tanggungjawab anda untuk membaikinya:

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

Kemudian, semak tag baharu dan bina semula dengan docker compose -f docker/docker-compose.yml up -d --build. Jika berlaku kesilapan, menyemak tag lama dan membina semula akan mengembalikan kod tersebut, tetapi hanya fail tarball yang boleh mengembalikan pangkalan data.

Fail tarball tersebut mengandungi octop.db, config.json, kunci penandatangan JWT dan credential.txt, jadi ia adalah sensitif seperti pelayan itu sendiri. Pastikan ia berada pada mod 600 dan simpan satu salinan di luar pelayan. Untuk pemasangan yang lebih besar, projek ini juga menyediakan docker/docker-compose.postgres.yml, yang menjalankan PostgreSQL dengan pgvector sebagai ganti kepada SQLite.

Mod kegagalan, berserta rentetan yang akan anda lihat

Pemeriksaan kesihatan tidak pernah menjawab. curl http://127.0.0.1:8088/api/health tergantung atau menolak sambungan. Baca docker compose -f docker/docker-compose.yml logs -f octop. Kontena yang keluar semasa init pertama biasanya tidak dapat menulis ke direktori data, jadi semak pemilikan bagi apa sahaja yang anda tetapkan pada OCTOP_DATA.

Papan pemuka dimuatkan tetapi sembang tergantung. Tiada ralat pada halaman, tiada balasan diterima. Buka konsol pelayar dan cari sambungan yang gagal ke wss://octop.example.com/agents/.../chat/ws. Proksi tidak memajukan naik taraf (upgrade). Tambahkan proxy_http_version 1.1 serta pengepala Upgrade dan Connection.

Keseluruhan balasan muncul serentak, lewat beberapa saat. Penstriman berfungsi, penimbalan (buffering) dihidupkan. Tetapkan proxy_buffering off.

bind: address already in use. Sesuatu sudah memegang port 8088. sudo ss -tlnp | grep 8088 menamakan proses tersebut. Ini juga ralat yang anda terima jika anda menambah entri ports kedua dalam fail override dan bukannya menyunting fail asal.

Kata laluan yang betul ditolak. Lima percubaan salah akan mencetuskan kunci keluar selama 900 saat. Tunggu sehingga tempoh itu tamat daripada memasang semula.

Kata laluan baharu dalam .env tidak memberi kesan. Kelayakan tersebut hanya terpakai pada init pertama sahaja. Tukarkannya di dalam papan pemuka.

Ejen membalas tetapi tidak pernah menjalankan alat. Hampir selalu merupakan masalah model tempatan: tetingkap konteks terlalu kecil untuk definisi alat, atau model tersebut lemah dalam panggilan fungsi. Tingkatkan num_ctx dan cuba model yang dibina untuk penggunaan alat.

FAQ

Adakah Octop pengganti kepada Open WebUI?

Hanya jika anda memerlukan ciri tambahan yang ditawarkannya. Open WebUI ialah antara muka sembang di hadapan model dan ia menjalankan tugas tersebut dengan baik untuk seorang pengguna atau isi rumah yang saling mempercayai. Octop menambah akaun dengan peranan pentadbir, ruang kerja dan kelayakan bagi setiap pengguna, serta pustaka ejen pakar yang boleh ditukar ganti, supaya beberapa orang boleh berkongsi satu pelayan tanpa berkongsi sejarah sembang yang sama. Jika satu akaun sudah memadai untuk anda, Open WebUI adalah pilihan yang lebih ringkas dan jauh lebih matang.

Mengapa saya tidak patut menggunakan skrip pemasangan curl Octop?

Skrip tersebut dihoskan daripada baldi Tencent Cloud Object Storage dan bukannya daripada repositori, jadi ia tidak dilindungi oleh mana-mana tag atau commit git. Anda tidak boleh membandingkan apa yang dilakukan oleh skrip itu hari ini dengan apa yang dilakukannya minggu lepas, dan menyalurkannya terus ke dalam bash akan menjalankannya sebelum anda sempat membacanya. Ia juga memasang perisian ke dalam hos dengan persekitaran Python 3.12 miliknya sendiri, di luar pengurus pakej anda. Muat turun dan baca skrip tersebut terlebih dahulu, atau gunakan Docker Compose daripada tag yang telah disemak.

Bolehkah Octop menggunakan model tempatan dan bukannya API berbayar?

Ya. Octop menggunakan API yang serasi dengan OpenAI dan menyertakan pratetap Ollama, jadi menghalakannya ke http://host.docker.internal:11434/v1 akan berfungsi sebaik sahaja anda menambah extra_hosts: ["host.docker.internal:host-gateway"] ke dalam kontena dan menetapkan OLLAMA_HOST=0.0.0.0:11434 pada hos. Hadkan port 11434 kepada julat alamat Docker melalui firewall, kerana Ollama tidak mempunyai sistem pengesahan sendiri. Anda mungkin perlu meningkatkan num_ctx Ollama kepada 16k atau lebih tinggi, kerana prompt ejen dengan definisi alatan akan melimpahi tetingkap konteks lalai dan menyebabkan model berhenti memanggil alatan tersebut.

Adakah saya memerlukan reverse proxy, atau bolehkah saya membuka port 8088?

Anda memerlukan proxy. Fail Compose yang disertakan oleh Octop menerbitkan port 8088 pada semua antara muka tanpa TLS, jadi kata laluan dan bearer token akan dihantar melalui internet dalam bentuk teks jelas (cleartext). Tukar port yang diterbitkan kepada 127.0.0.1:8088:8088 dan letakkan Caddy atau nginx di hadapan dengan sijil. Jika menggunakan nginx, halakan header naik taraf WebSocket dan tetapkan proxy_buffering off, jika tidak, halaman akan dimuatkan tetapi sembang tidak akan memberikan respons.

Adakah Octop sedia untuk pengeluaran (production)?

Ia masih di peringkat pra-1.0 dan mengeluarkan beberapa versi bertag setiap minggu setakat Ogos 2026, jadi anggap ia sebagai perisian yang berpotensi dan bukannya stabil. Ia boleh digunakan untuk keluarga atau pasukan dalaman yang kecil jika anda menetapkan tag yang tepat, membaca log commit sebelum setiap naik taraf, dan membuat sandaran volum data sebelum setiap binaan semula. Jangan jalankannya pada latest, dan jangan masukkan data pelanggan ke dalamnya buat masa ini.