Cara Self-Host Octop dengan Docker Compose di VPS

Apa itu Octop dan alasan Anda meng-hostingnya sendiri

Octop adalah asisten AI yang di-hosting sendiri untuk rumah tangga atau tim kecil. Alasan meng-hosting Octop sendiri, bukan sekadar menggunakan front end chat, adalah karena Octop memisahkan pengguna satu sama lain. Open WebUI menyediakan antarmuka browser di depan model. Octop menambahkan akun dengan peran admin, workspace privat dan set kredensial untuk setiap pengguna, serta pustaka agent khusus 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, command line interface, channel chat (Feishu, DingTalk, QQ, Discord, WeCom), dan scheduled job. Semuanya menggunakan satu database SQLite di bawah ~/.octop/. Semua langkah di bawah ini ditulis berdasarkan tag v0.9.19, yang dirilis pada 5 August 2026. Jika Anda masih menentukan pilihan 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 mengaturnya. Octop adalah software pra-1.0 yang dipublikasikan dari organisasi GitHub milik vendor, dengan sekitar 900 star per August 2026. Pengembangannya berlangsung cepat, sebagaimana terlihat dari nomor versinya, dan tidak ada jaminan bahwa jalur upgrade akan stabil. Kunci tag yang digunakan, 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

Belum ada image yang diterbitkan untuk ditarik hingga Agustus 2026. File Compose yang disediakan membangun image dari repository, sehingga mematok versi berarti melakukan checkout tag git. Ini memerlukan satu langkah tambahan dibandingkan kebanyakan proyek self-hosted, karena proyek seperti workspace AFFiNE self-hosted mematok tag image yang telah diterbitkan dan tidak pernah melakukan build 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, Anda sudah memahami alurnya.

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

Berikut adalah service yang didefinisikan file tersebut, dengan bagian yang relevan saja:

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 build Anda sendiri, bukan referensi registry, sehingga latest di sini berarti apa pun yang terakhir kali Anda compile. Tetapkan path data secara eksplisit, bukan membiarkannya menggunakan default, dan gunakan password yang benar untuk akun admin sebelum boot pertama. Masukkan ini 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 hanya membaca docker/.env untuk melakukan interpolasi placeholder ${...} di 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 sama sekali tidak berdampak dan tidak menghasilkan pesan 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 merespons health check dengan {"status":"ok","version":"..."}. Jika hasilnya berbeda, baca docker compose -f docker/docker-compose.yml logs -f octop sebelum membuka browser.

Sekarang beri nama yang bermakna pada image yang baru Anda build, karena --build berikutnya akan menimpa octop:latest dan Anda tidak dapat membedakan keduanya:

docker image tag octop:latest octop:0.9.19

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

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

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

Jangan memublikasikan port 8088

Baris ports: di atas mengikat semua interface pada VPS. Begitu container dijalankan, dashboard dapat diakses dari Internet publik melalui koneksi tanpa enkripsi, dengan kata sandi default. Default OCTOP_BIND_HOST milik Octop adalah 127.0.0.1; file Compose menggantinya menjadi 0.0.0.0 karena proses tersebut harus menerima trafik dari luar namespace jaringannya sendiri. Penggantian itu benar. Bagian yang mengekspos sistem 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 binding. Jika Anda ingin mempertahankan file upstream tanpa perubahan, gunakan tag !override pada sequence tersebut. Itulah cara yang didokumentasikan untuk mengganti, bukan menambahkan. Penjelasan tentang cara Compose menggabungkan beberapa file membahas aturan penggabungan lainnya.

Binding ke loopback juga mengatasi masalah yang mungkin Anda hadapi pada firewall. Docker menulis aturan port yang dipublikasikan ke dalam tabel nat sebelum chain yang dikelola ufw, sehingga ufw deny 8088 tidak menghentikan port container yang dipublikasikan. Port yang di-bind ke 127.0.0.1 tidak pernah dapat dijangkau dari luar, terlepas dari konfigurasi ufw. Karena itu, binding ke loopback adalah perbaikan yang tepat, bukan sekadar pilihan cadangan.

Tempatkan TLS di depan dengan reverse proxy

Caddy merupakan jalur paling singkat karena secara mandiri 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 memiliki fungsi. Chat berjalan melalui WS /agents/{id}/chat/ws, sehingga tanpa proxy_http_version 1.1 dan dua header upgrade, nginx menjawab upaya 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 batas waktu 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>. Ini kabar baik untuk reverse proxy: 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 sebenarnya, ada dua konsekuensi yang perlu diketahui.

WebSocket membawa token di dalam URL. Endpoint-nya adalah WS /agents/{id}/chat/ws?token=<jwt> karena JavaScript pada browser tidak dapat mengatur 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 aktif milik pengguna sebenarnya tersimpan dalam file teks biasa di server. Catat path tanpa argumen. $uri adalah path yang sudah dinormalisasi dan query string-nya sudah dihapus. Masukkan konfigurasi berikut ke dalam blok http, lalu referensikan blok tersebut 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 valid selama 24 jam setelah login. Satu-satunya cara yang didokumentasikan untuk membatalkan token 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 lain login kembali. Jika proses ini terasa terlalu berat, persingkat masa berlaku token. Ingat untuk menambahkan variabel tersebut ke daftar environment: dan .env:

OCTOP_ACCESS_TOKEN_TTL=28800

Perlindungan terhadap brute force sudah tersedia: secara default, OCTOP_LOGIN_MAX_ATTEMPTS adalah 5 kegagalan dan OCTOP_LOGIN_LOCKOUT_SECONDS adalah 900. Jadi, pengguna yang terkunci hanya perlu menunggu lima belas menit, bukan mengira instalasi rusak. Octop memiliki penyimpanan pengguna sendiri dan tidak memiliki dukungan OIDC yang terdokumentasi pada v0.9.19. Jika Anda memerlukan single sign-on yang sebenarnya, tempatkan proxy autentikasi di depannya. Itulah fungsi server Authentik yang di-host sendiri.

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.

Memutakhirkan proyek yang merilis versi 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 repository, dihitung per 7 August 2026. 4 rilis bertag dibuat dalam sembilan hari, dengan jeda paling singkat 1 hari, dan v0.9.19 tiba 3 hari setelah tag sebelumnya. Frekuensi ini merupakan pertanda baik bagi proyek tersebut, tetapi alasan yang 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"

Selalu buat cadangan terlebih dahulu, karena migrasi database berjalan saat startup dan migrasi yang gagal pada proyek sebelum versi 1.0 menjadi masalah yang harus Anda pulihkan:

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 checkout tag baru dan lakukan build ulang dengan docker compose -f docker/docker-compose.yml up -d --build. Jika terjadi masalah, checkout tag lama dan lakukan build ulang untuk 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 dengan server itu sendiri. Pertahankan mode 600 dan simpan satu salinan 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 merespons. 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 saat inisialisasi pertama biasanya tidak dapat menulis ke direktori data. Karena itu, periksa ownership dari nilai 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/agents/.../chat/ws. Proxy tidak meneruskan upgrade koneksi. Tambahkan header proxy_http_version 1.1, 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. Hal ini juga terjadi jika Anda menambahkan entri ports kedua dalam file override, bukan mengedit entri asli.

Password yang benar ditolak. Lima percobaan yang salah akan memicu lockout selama 900 detik. Tunggu hingga lockout 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 function calling. Tingkatkan 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 tugas tersebut dengan baik untuk satu orang atau rumah tangga yang saling percaya. Octop menambahkan akun dengan peran admin, workspace dan kredensial untuk setiap pengguna, serta pustaka agent khusus yang dapat diganti. Dengan demikian, beberapa orang dapat berbagi satu server tanpa berbagi satu riwayat. Jika satu akun sudah memadai bagi Anda, Open WebUI adalah pilihan yang lebih sederhana dan jauh lebih matang.

Mengapa saya tidak boleh menggunakan script instalasi curl Octop?

Script tersebut disajikan dari bucket Tencent Cloud Object Storage, bukan dari repository, sehingga tidak tercakup oleh tag atau commit git apa pun. Anda tidak dapat membandingkan perilakunya saat ini dengan perilakunya minggu lalu, dan meneruskannya ke bash membuatnya dijalankan sebelum Anda membacanya. Script tersebut juga menginstal Octop langsung pada host dengan environment Python 3.12 miliknya sendiri, di luar package manager Anda. Download script tersebut dan baca terlebih dahulu, atau deploy dengan Docker Compose dari tag yang sudah di-checkout.

Apakah Octop dapat menggunakan model lokal, bukan API berbayar?

Ya. Octop mendukung 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 port firewall 11434 ke rentang alamat Docker, karena Ollama tidak memiliki autentikasi bawaan. Anda perlu menaikkan num_ctx Ollama menjadi 16k atau lebih, karena prompt agent dengan definisi tool dapat melebihi ukuran context window default dan model kemudian berhenti memanggil tool.

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

Anda memerlukan proxy. File Compose yang disediakan Octop mempublikasikan 8088 pada semua interface tanpa TLS, sehingga password dan bearer token akan melintasi Internet dalam bentuk teks biasa. 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 merespons dan masalahnya tidak terlihat.

Apakah Octop siap digunakan di production?

Octop masih berada sebelum versi 1.0 dan merilis beberapa tagged release setiap minggu hingga August 2026. Karena itu, anggap Octop sebagai software yang menjanjikan, bukan software yang sudah stabil. Octop masih dapat digunakan oleh keluarga atau tim internal kecil jika Anda menetapkan tag yang tepat, membaca commit log sebelum setiap upgrade, dan mencadangkan data volume sebelum setiap rebuild. Jangan jalankan Octop pada latest, dan jangan masukkan data pelanggan ke dalamnya dulu.