Cara Self-Host Octop dengan Docker Compose di VPS

Apa itu Octop dan alasan Anda sebaiknya meng-host-nya sendiri

Octop adalah asisten AI yang di-host sendiri untuk rumah tangga atau tim kecil. Alasan meng-host Octop sendiri, bukan sekadar menggunakan frontend chat, adalah karena Octop memisahkan setiap pengguna. Open WebUI menyediakan antarmuka browser di depan model. Octop menambahkan akun dengan peran admin, workspace privat dan kumpulan kredensial untuk setiap pengguna, serta pustaka agen spesialis yang dapat dipilih setiap pengguna sesuai tugas. Perbedaan ini memungkinkan satu VPS melayani lima orang, bukan hanya satu orang.

Proyek ini tersedia di github.com/TencentCloud/Octop. Octop adalah satu proses yang menyediakan dashboard web, antarmuka baris perintah, channel chat (Feishu, DingTalk, QQ, Discord, WeCom), dan tugas terjadwal. Semua fitur tersebut menggunakan satu database SQLite di bawah ~/.octop/. Seluruh uraian di bawah ini ditulis berdasarkan tag v0.9.19, yang dirilis pada 5 August 2026. Jika Anda masih memilih platform, perbandingan alternatif Open WebUI yang dapat dijalankan pada VPS membahas pilihan yang lebih luas.

Ada satu hal yang perlu dipahami sebelum Anda menghabiskan waktu untuk menyiapkannya. Saat panduan ini ditulis, Octop masih merupakan software sebelum versi 1.0 yang dipublikasikan dari organisasi GitHub milik vendor, dengan sekitar 900 stars pada August 2026. Sejak itu, proyek ini menandai v1.0.0 pada 14 September 2026. Per 20 October 2026, tag terbaru adalah v1.0.2, yaitu rilis stabil yang dipublikasikan pada 18 October 2026 setelah serangkaian tag beta 1.0.2. Repository tersebut memiliki sekitar 10,400 stars. Langkah-langkah di bawah ini ditulis berdasarkan v0.9.19 dan belum diuji ulang pada versi 1.x. Perkembangannya cepat, seperti terlihat dari nomor versinya, dan panduan ini tidak menjamin jalur upgrade yang stabil. Kunci tag tertentu, baca changelog, dan simpan backup.

Hal yang diperlukan sebelum memulai

• VPS yang menjalankan Ubuntu 24.04 dengan Docker Engine dan plugin Compose. Belum mengenal Compose? Mulai dari dasar-dasar Docker Compose untuk VPS.
• git, karena Anda akan memeriksa checkout berdasarkan tag rilis, bukan melakukan pull image.
• Nama domain yang mengarah ke VPS, karena Anda akan menempatkan TLS (transport layer security) di depannya.
• Backend model yang mendukung OpenAI API: Ollama lokal, gateway yang di-host sendiri, atau key berbayar.

Octop sendiri ringan. Octop adalah proses Python dan file SQLite. Beban utamanya berasal dari backend model. Jadi, jika Anda berencana menjalankan model pada server yang sama, pilih ukuran server yang sesuai untuk model tersebut.

Mengapa kami tidak merekomendasikan installer curl

README diawali dengan perintah instalasi satu baris:

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

Kami tidak merekomendasikannya pada server yang penting bagi Anda karena satu alasan yang jelas: skrip tersebut tidak berada di repository. Skrip itu disajikan dari bucket Tencent Cloud Object Storage. Tidak ada bagian skrip yang tercakup oleh git tag atau commit, sehingga Anda tidak dapat membandingkan skrip hari ini dengan skrip minggu lalu. Tidak ada riwayat yang menjelaskan perubahan. Bucket tersebut dapat menyajikan byte yang berbeda besok, tanpa ada catatan tentang perubahan itu di project. Mengalirkan hasilnya langsung ke bash juga berarti mesin menjalankan skrip sebelum Anda membaca isinya.

Installer tersebut juga menulis langsung ke host, bukan ke container. Installer menggunakan uv untuk mengambil Python 3.12 dan membuat environment yang tidak diketahui oleh package manager Anda, sehingga penghapusannya nanti harus dilakukan secara manual.

Ada dua opsi yang lebih baik. Ambil skrip, baca isinya, lalu jalankan. Proses ini hanya memerlukan waktu tiga puluh detik: curl -fsSL <url> -o install.sh, lalu less install.sh, kemudian bash install.sh. Atau gunakan Docker, yang dibahas dalam bagian selanjutnya pada panduan ini. Package PyPI (pip install octop) setidaknya merupakan artifact berversi yang dapat Anda pin ke suatu release.

Deploy Octop dengan Docker Compose, dipatok ke v0.9.19

File Compose yang disertakan pada v0.9.19 membangun image dari repository. Karena itu, dalam panduan ini, mematok versi berarti melakukan checkout git tag. Image yang dipublikasikan memang tersedia. Tree v0.9.19 sudah memuat workflow docker-publish.yml, yang ditambahkan pada v0.9.8 pada 15 July 2026. Workflow tersebut membangun image dan mendorongnya ke Docker Hub untuk setiap tag v*. Per 20 October 2026, project ini juga memublikasikan image ke container registry milik GitHub (docker pull ghcr.io/tencentcloud/octop:1.0.2). Membangun dari tag yang sudah di-checkout tetap merupakan pematokan yang lebih ketat. Dengan cara ini, Anda mengompilasi kode yang sama persis dengan kode yang Anda baca, bukan mempercayai tag registry. Ini satu langkah lebih jauh daripada yang diminta sebagian besar project self-hosted. Sebagai perbandingan, workspace AFFiNE self-hosted mematok published image tag dan tidak pernah membangun apa pun di VPS Anda. Prosedur clone, checkout, dan build di bawah ini sama dengan yang dijelaskan dalam panduan deployment openGym. Jadi, jika Anda pernah menyiapkannya sekali, Anda sudah mengetahui strukturnya.

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

Berikut service yang didefinisikan file tersebut, dengan bagian yang tidak relevan dihilangkan:

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 adalah nama untuk build Anda sendiri, bukan referensi registry. Jadi, latest di sini berarti image yang terakhir kali Anda kompilasi. Tetapkan path data ke lokasi yang jelas, bukan membiarkannya menggunakan default. Tetapkan juga password admin yang sebenarnya sebelum boot pertama. Masukkan konfigurasi berikut ke docker/.env:

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

Ada satu jebakan penting di sini. Compose membaca docker/.env hanya untuk menginterpolasi placeholder ${...} dalam YAML. Key yang Anda tambahkan ke file tersebut tidak diteruskan ke container kecuali juga dicantumkan di bawah environment: dalam file Compose. Menambahkan OCTOP_ACCESS_TOKEN_TTL hanya ke .env tidak menghasilkan apa pun dan tidak menampilkan error. Alternatifnya, tulis key yang sama ke ~/.octop/env di dalam direktori data yang di-mount. Octop akan memuatnya saat startup. Panduan tentang file env dan secret di Docker Compose menjelaskan alasan kedua mekanisme ini tidak sama.

Build dan jalankan:

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 yang sehat akan menjawab health check dengan objek JSON seperti {"ok":true,"started_at":...,"db":...,"users_loaded":0,"agents_running":0}. Jika hasilnya berbeda, baca docker compose -f docker/docker-compose.yml logs -f octop sebelum membuka browser.

Sekarang beri image yang baru Anda build nama yang bermakna. --build berikutnya akan menimpa octop:latest sehingga Anda tidak dapat membedakan keduanya:

docker image tag octop:latest octop:0.9.19

Boot pertama menjalankan octop init dan menulis kredensial awal ke data volume:

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

Default-nya adalah admin / octop, dan default tersebut diterapkan hanya saat init pertama. Inilah penyebab pertanyaan yang sering diajukan: mengubah OCTOP_DEFAULT_PASSWORD setelah container pernah dijalankan tidak mengubah apa pun, karena account tersebut sudah dibuat. Ubah password dari dashboard.

Jangan publikasikan port 8088

Baris ports: di atas mengikat semua interface pada VPS. Begitu container dijalankan, dashboard dapat diakses dari Internet publik tanpa enkripsi, dengan kata sandi default. Nilai default OCTOP_BIND_HOST milik Octop adalah 127.0.0.1; file Compose menggantinya menjadi 0.0.0.0 karena proses harus menerima trafik dari luar namespace jaringannya sendiri. Penggantian tersebut sudah benar. Bagian yang mengekspos server adalah port yang dipublikasikan.

Edit baris ports: dalam docker/docker-compose.yml agar pemetaan hanya mendengarkan pada loopback:

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

Jangan mencoba memperbaikinya dengan file override biasa. Compose menggabungkan daftar ports dari beberapa file, bukan menggantinya, sehingga kedua pemetaan tetap dipublikasikan dan pemetaan kedua gagal melakukan bind. Jika Anda ingin membiarkan file upstream tetap utuh, gunakan tag !override pada sequence tersebut. Ini adalah cara yang didokumentasikan untuk mengganti, bukan menambahkan. Penjelasan tentang cara Compose menggabungkan beberapa file membahas aturan penggabungan lainnya.

Binding ke loopback juga menyelesaikan masalah yang akan Anda hadapi pada firewall. Docker menulis aturan port yang dipublikasikan ke tabel nat sebelum chain yang dikelola ufw, sehingga ufw deny 8088 tidak menghentikan port container yang dipublikasikan. Pada Docker Engine 28.0.0 atau yang lebih baru, port yang di-bind ke 127.0.0.1 tidak dapat diakses dari luar, terlepas dari konfigurasi ufw. Karena itu, cara ini merupakan perbaikan yang tepat, bukan pilihan kedua. Rilis Engine yang lebih lama memungkinkan host pada segmen L2 yang sama, seperti mesin lain pada switch milik provider Anda, mengakses port yang dipublikasikan ke localhost. Jalankan docker version dan lakukan upgrade jika server melaporkan versi di bawah 28.

Pasang TLS di depan dengan reverse proxy

Caddy adalah pilihan paling sederhana karena secara otomatis meminta sertifikat melalui ACME (automatic certificate management environment) dan mem-proxy WebSocket tanpa konfigurasi tambahan:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx memerlukan konfigurasi yang lebih cermat karena Octop mengalirkan chat 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 sana memiliki fungsi. Chat berjalan melalui WS /api/agents/{id}/chat/ws, sehingga tanpa proxy_http_version 1.1 dan dua header upgrade, nginx menjawab percobaan upgrade dengan 400 Bad Request: dashboard tetap dimuat secara normal, tetapi setiap pesan yang Anda kirim akan menggantung tanpa batas dan tanpa error pada halaman. proxy_buffering off penting karena endpoint resume human-in-the-loop mengembalikan text/event-stream, sedangkan SSE (server-sent events) yang tertahan dalam buffer proxy tiba sekaligus di akhir, bukan secara streaming. proxy_read_timeout mencakup eksekusi tool yang berlangsung lama karena nilai default 60 detik menghentikan agent di tengah tugas dan mencatat upstream timed out (110: Connection timed out).

Cara kerja autentikasi JWT di balik proxy

Octop melakukan autentikasi dengan bearer token, bukan cookie. POST /api/auth/login mengembalikan {access_token, role, user, ...}, dan permintaan berikutnya membawa Authorization: Bearer <access_token>. Untuk reverse proxy, ini kabar baik: tidak ada domain cookie, flag Secure, atau aturan SameSite yang dapat salah dikonfigurasi. Dengan demikian, sesi yang berfungsi pada http://127.0.0.1:8088 akan berperilaku sama pada https://octop.example.com.

Sebelum Anda menggunakannya untuk pengguna sungguhan, ada 2 konsekuensi yang perlu diketahui.

WebSocket membawa token di URL. Endpoint-nya adalah WS /api/agents/{id}/chat/ws?token=<jwt>, karena JavaScript pada browser tidak dapat menetapkan header Authorization saat handshake WebSocket. TLS melindungi token tersebut selama transmisi. Namun, TLS tidak melindunginya dari log Anda sendiri: secara default, nginx menulis seluruh baris permintaan, termasuk query string, ke access_log. Akibatnya, token yang masih berlaku untuk pengguna sungguhan tersimpan dalam file teks biasa di server. Catat path tanpa argumen. $uri adalah path yang telah dinormalisasi dan query string-nya sudah dihapus. Jadi, masukkan konfigurasi berikut ke blok http dan referensikan dari 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;

Tidak ada logout per sesi. Secara default, OCTOP_ACCESS_TOKEN_TTL bernilai 86400, sehingga token tetap berlaku selama 24 jam setelah login. Satu-satunya cara yang didokumentasikan untuk membatalkannya adalah octop admin rotate-jwt-secret. Perintah ini merotasi signing key yang disimpan di ~/.octop/secrets/jwt_secret dan langsung membatalkan semua token yang masih berlaku untuk semua pengguna. Jadi, ketika seseorang keluar dari tim, urutannya adalah: hapus pengguna, rotasi secret, lalu minta pengguna yang tersisa untuk login kembali. Jika cara ini terlalu berat, persingkat masa berlaku token. Jangan lupa menambahkan variabel tersebut ke daftar environment: selain .env:

OCTOP_ACCESS_TOKEN_TTL=28800

Perlindungan terhadap brute force sudah tersedia: secara default, OCTOP_LOGIN_MAX_ATTEMPTS bernilai 5 kegagalan dan OCTOP_LOGIN_LOCKOUT_SECONDS bernilai 900. Jadi, pengguna yang terkunci hanya perlu menunggu 15 menit, bukan mengira instalasi rusak. Octop memiliki penyimpanan pengguna sendiri dan tidak memiliki dukungan OIDC yang didokumentasikan pada v0.9.19. Jika Anda memerlukan single sign-on yang sebenarnya, tempatkan proxy autentikasi di depannya. Untuk itulah server Authentik self-hosted digunakan.

Konfigurasikan Octop ke backend model

Provider dikonfigurasikan untuk setiap agent di dashboard, dan octop provider list menampilkan konfigurasi yang berlaku. Octop menyediakan preset untuk API yang kompatibel dengan OpenAI, DashScope (Qwen), dan Ollama. Kredensial disimpan dalam tabel providers pada database SQLite milik Anda sendiri. Pilihan ini menentukan biaya yang Anda keluarkan dan data yang keluar dari server.

Model lokal dengan Ollama. Tidak ada data yang keluar dari server, dan biaya yang Anda keluarkan berupa RAM, bukan token. Detail konfigurasi yang sering terlewat: container tidak dapat mengakses Ollama pada host melalui 127.0.0.1:11434, karena alamat tersebut adalah loopback milik container itu sendiri. Tambahkan entri gateway host ke service:

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

Kemudian atur base URL provider ke http://host.docker.internal:11434/v1, yaitu path yang kompatibel dengan OpenAI milik Ollama. Isi kolom API key dengan string apa pun yang tidak kosong, karena Ollama mengabaikannya, tetapi client OpenAI menolak mengirim API key kosong. Ollama juga harus listen pada alamat di luar loopback agar konfigurasi ini berfungsi. Artinya, Anda perlu mengatur OLLAMA_HOST=0.0.0.0:11434 pada unit systemd-nya. Inilah bagian yang berisiko: Ollama tidak memiliki autentikasi, sehingga port 11434 yang terbuka pada IP publik menjadi server model gratis bagi siapa pun yang memindainya terlebih dahulu. Izinkan hanya range privat Docker, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp, dan tolak akses lainnya. Menjalankan Ollama pada VPS membahas penentuan ukuran model, sedangkan perbandingan Ollama dan vLLM membahas kapan Ollama tidak lagi menjadi server yang tepat.

Ada satu peringatan lain tentang model lokal, karena masalah ini tampak seperti bug pada Octop, padahal bukan. Agent bekerja dengan memanggil tool, sedangkan system prompt, definisi tool, dan riwayat percakapan membentuk prompt yang besar. Ollama menyajikan model dengan context window bawaan yang relatif kecil, sehingga bagian awal prompt, tempat definisi tool berada, keluar dari window tersebut. Model kemudian berhenti memanggil tool atau mengarang tool yang tidak ada. Naikkan num_ctx menjadi 16k atau 32k, lalu pilih model yang memang baik dalam function calling. Respons yang berhenti di tengah kalimat merupakan keluhan yang berlawanan dan disebabkan oleh pengaturan lain, yaitu num_predict. Jadi, jika jawaban terpotong, sebaiknya periksa lokasi pengaturan num_predict dan isi done_reason sebelum menyalahkan agent. Jika Anda ingin memulai dari kandidat tertentu, bukan dari daftar pendek, Nemotron 3.5 Lightning layak dicoba. Artikel tersebut mencantumkan tag yang tepat untuk di-pull, kebutuhan RAM, dan kemampuan CPU-only dalam mengimbanginya.

Gateway yang di-host sendiri. Tempatkan gateway LiteLLM yang di-host sendiri di antara Octop dan seluruh layanan lainnya. Dengan begitu, Anda memperoleh satu base URL, key terpisah untuk setiap pengguna, batas pengeluaran, dan satu log. Anda juga dapat mengganti model di balik gateway tersebut tanpa mengubah apa pun di Octop.

API berbayar. Kualitasnya paling baik, dengan kompromi yang perlu dipahami: isi percakapan keluar dari server Anda dan dikirim ke provider. Hal ini bertentangan dengan tujuan utama self-hosting. Masukkan key ke docker/.env sebagai OPENAI_API_KEY. Compose file sudah meneruskannya.

Apa pun pilihan Anda, Compose file juga meneruskan OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY, dan LANGFUSE_BASE_URL. Dengan demikian, Anda dapat mengirim trace ke instance Langfuse milik Anda sendiri dan melihat aktivitas agent yang sebenarnya, alih-alih menebaknya dari jendela chat.

Pengguna, peran, dan pustaka agent bersama

Akun admin dari boot pertama membuat dan mengelola akun lainnya. Setiap pengguna memiliki agent, workspace, dan kredensialnya sendiri. Isolasi ini dibawa oleh token yang disimpan browser. Selain itu, tersedia kumpulan skill dan sub-agent bersama yang dapat digunakan siapa saja. Fitur ini membuat Octop layak dijalankan untuk keluarga: satu orang dapat membuat agent riset yang baik sekali, dan anggota lain tidak perlu membuatnya ulang.

Berhati-hatilah saat menggunakan tooling. Octop menyediakan persetujuan tool dan guardrail untuk perintah shell. Keduanya benar-benar berfungsi. Namun, agent yang menjalankan perintah shell akan menjalankannya di dalam container Octop dengan volume data Anda ter-mount. Guardrail membatasi tindakan yang dapat dilakukan oleh prompt yang ceroboh. Guardrail bukan batas sandbox. Karena itu, tetap aktifkan persetujuan tool untuk siapa pun yang tidak akan Anda beri akses shell. Jika Anda membandingkan Octop dengan opsi lain, ulasan berbagai agent AI self-hosted membandingkan cara masing-masing opsi menanganinya.

Memperbarui proyek dengan rilis secepat ini

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

Itulah tanggal tag dari repositori, dihitung hingga 7 August 2026. 4 rilis bertag dibuat dalam sembilan hari, dengan jeda paling singkat 1 hari, dan v0.9.19 dirilis 3 hari setelah tag sebelumnya. Frekuensi ini merupakan pertanda baik bagi proyek, tetapi alasan buruk untuk menjalankan latest. Baca perubahan sebelum menerapkannya:

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"

Periksa isi $NEW_TAG yang sebenarnya sebelum melakukan checkout, karena proyek ini memberi tag pada beta seperti v1.0.2b9 dan juga pada rilis stabil. Hingga 20 October 2026, tag terbaru adalah v1.0.2 yang dipublikasikan pada 18 October 2026. Peralihan dari v0.9.19 melewati rilis v1.0.0 pada 14 September 2026, sehingga log tersebut panjang dan perlu dibaca dengan saksama.

Selalu buat cadangan terlebih dahulu, karena migrasi database dijalankan saat startup. Jika migrasi gagal pada proyek yang dirilis secepat ini, Anda harus memulihkannya:

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 lakukan checkout pada tag baru dan rebuild dengan docker compose -f docker/docker-compose.yml up -d --build. Jika terjadi masalah, melakukan checkout pada tag lama lalu rebuild akan mengembalikan kode, tetapi hanya tarball yang dapat mengembalikan database.

Tarball tersebut berisi octop.db, config.json, secret penandatanganan JWT, dan credential.txt, sehingga tingkat sensitivitasnya sama seperti server itu sendiri. Atur modenya ke 600 dan simpan salinannya di luar server. Untuk instalasi yang lebih besar, proyek ini juga menyediakan docker/docker-compose.postgres.yml, yang menjalankan PostgreSQL dengan pgvector, bukan SQLite.

Mode kegagalan dan string yang akan Anda lihat

Health check tidak pernah mendapat respons. curl http://127.0.0.1:8088/api/health macet atau menolak koneksi. Baca docker compose -f docker/docker-compose.yml logs -f octop. Container yang berhenti selama inisialisasi pertama biasanya tidak dapat menulis ke direktori data. Karena itu, periksa kepemilikan direktori yang Anda tetapkan pada OCTOP_DATA.

Dashboard dimuat, tetapi chat macet. Tidak ada error pada halaman dan tidak pernah ada balasan. Buka konsol browser, lalu cari koneksi yang gagal ke wss://octop.example.com/api/agents/.../chat/ws. Proxy tidak meneruskan upgrade. Tambahkan header proxy_http_version 1.1 serta header Upgrade dan Connection.

Seluruh balasan muncul sekaligus setelah terlambat beberapa detik. Streaming berfungsi, tetapi buffering aktif. Tetapkan proxy_buffering off.

bind: address already in use. Sesuatu sudah menggunakan port 8088. sudo ss -tlnp | grep 8088 akan menampilkan prosesnya. Masalah yang sama terjadi jika Anda menambahkan entri ports kedua dalam file override, bukan mengedit entri asli.

Password yang benar ditolak. Lima percobaan yang salah memicu penguncian selama 900 detik. Tunggu hingga penguncian berakhir, bukan menginstal ulang.

Password baru dalam .env tidak berpengaruh. Kredensial tersebut hanya berlaku saat inisialisasi pertama. Ubah password melalui dashboard.

Agent membalas, tetapi tidak pernah menjalankan tool. Hampir selalu ini merupakan masalah model lokal: context window terlalu kecil untuk definisi tool, atau model kurang baik dalam pemanggilan fungsi. Naikkan num_ctx dan coba model yang dibuat untuk penggunaan tool.

FAQ

Apakah Octop merupakan pengganti Open WebUI?

Hanya jika Anda memerlukan fitur tambahan yang disediakannya. Open WebUI adalah antarmuka chat di depan model dan menjalankan fungsi tersebut dengan baik untuk satu orang atau rumah tangga yang saling percaya. Octop menambahkan akun dengan peran admin, workspace dan kredensial per pengguna, serta pustaka agen spesialis yang dapat diganti. Dengan demikian, beberapa orang dapat berbagi satu server tanpa berbagi satu riwayat. Jika satu akun sudah cukup bagi Anda, Open WebUI adalah pilihan yang lebih sederhana dan jauh lebih matang.

Mengapa saya tidak boleh menggunakan skrip instalasi curl Octop?

Skrip tersebut disajikan dari bucket Tencent Cloud Object Storage, bukan dari repository. Karena itu, skrip tersebut tidak tercakup oleh tag atau commit git apa pun. Anda tidak dapat membandingkan perilakunya saat ini dengan perilakunya minggu lalu, dan menyalurkannya ke bash akan menjalankannya sebelum Anda membacanya. Skrip tersebut juga menginstal Octop pada host dengan environment Python 3.12 miliknya sendiri, di luar package manager Anda. Unduh dan baca skrip tersebut terlebih dahulu, atau lakukan deployment dengan Docker Compose dari tag yang sudah di-check out.

Apakah Octop dapat menggunakan model lokal sebagai pengganti API berbayar?

Ya. Octop menggunakan API yang kompatibel dengan OpenAI dan menyediakan preset Ollama. Karena itu, mengarahkannya ke http://host.docker.internal:11434/v1 akan berfungsi setelah Anda menambahkan extra_hosts: ["host.docker.internal:host-gateway"] ke container dan menetapkan OLLAMA_HOST=0.0.0.0:11434 pada host. Batasi akses firewall ke port 11434 dari rentang alamat Docker, karena Ollama tidak memiliki autentikasi bawaan. Perkirakan Anda perlu menaikkan num_ctx milik Ollama menjadi 16k atau lebih, karena prompt agen dengan definisi tool melampaui context window default, sehingga model kemudian berhenti memanggil tool.

Apakah saya memerlukan reverse proxy, atau dapat membuka port 8088?

Anda memerlukan reverse proxy. File Compose yang disediakan Octop memublikasikan 8088 pada semua interface tanpa TLS. Akibatnya, password dan bearer token akan melintasi Internet dalam bentuk plaintext. Ubah port yang dipublikasikan menjadi 127.0.0.1:8088:8088, lalu tempatkan Caddy atau nginx di depannya dengan sertifikat. Dengan nginx, teruskan header upgrade WebSocket dan tetapkan proxy_buffering off. Jika tidak, halaman akan dimuat, tetapi chat tidak akan pernah memberikan respons tanpa menampilkan error.

Apakah Octop siap digunakan di production?

Per Agustus 2026, Octop masih berada sebelum versi 1.0 dan merilis beberapa tag release setiap minggu. Octop memberi tag v1.0.0 pada 14 September 2026, kemudian merilis serangkaian tag beta 1.0.2 sebelum stable v1.0.2 pada 18 Oktober 2026. Laju tersebut masih cepat, jadi anggap Octop menjanjikan, bukan sudah mapan. Octop dapat digunakan untuk keluarga atau tim internal kecil jika Anda menetapkan tag yang persis, membaca commit log sebelum setiap upgrade, dan mencadangkan data volume sebelum setiap rebuild. Jangan menjalankannya pada latest, dan jangan menyimpan data pelanggan di dalamnya dulu.