Від Matt Connor 2026-10-20

Як розгорнути Octop на VPS для кількох користувачів

Налаштуйте Octop v0.9.19 через Docker Compose з фіксованим tag: ізоляція користувачів, OpenAI-сумісний backend, TLS і причина не використовувати curl installer.

Що таке Octop і навіщо розгортати його самостійно

Octop — це self-hosted AI-асистент для домогосподарства або невеликої команди. Причина розгортати Octop самостійно, а не використовувати звичайний чат-інтерфейс, полягає в ізоляції користувачів один від одного. Open WebUI надає браузерний інтерфейс перед моделлю. Octop додає облікові записи з роллю адміністратора, приватний робочий простір і набір облікових даних для кожного користувача, а також бібліотеку спеціалізованих агентів, між якими користувач може перемикатися залежно від завдання. Саме це дає змогу одному VPS обслуговувати п’ятьох людей, а не лише одного.

Проєкт розміщено на github.com/TencentCloud/Octop. Це один процес, який обслуговує веб-інформаційну панель, інтерфейс командного рядка, канали чатів (Feishu, DingTalk, QQ, Discord, WeCom) і заплановані завдання. Усі вони використовують одну базу даних SQLite у ~/.octop/. Усе нижче описано для tag v0.9.19, випущеного 5 August 2026. Якщо ви ще обираєте платформу, у порівнянні альтернатив Open WebUI, які можна запустити на VPS розглянуто ширший перелік варіантів.

Перед тим як витрачати на це вечір, врахуйте один важливий момент. На момент написання цього посібника Octop був програмним забезпеченням до версії 1.0, опублікованим в організації постачальника на GitHub, і станом на August 2026 мав близько 900 зірок. Згодом для нього було позначено v1.0.0 на 14 September 2026, а станом на 20 October 2026 найновішим tag є v1.0.2 — стабільний випуск, опублікований 18 October 2026 після серії beta tag версії 1.0.2; репозиторій мав близько 10,400 зірок. Наведені нижче кроки написано для v0.9.19 і повторно не перевірено на 1.x. Проєкт швидко розвивається, що видно з номерів версій, тому цей посібник не гарантує стабільний шлях оновлення. Зафіксуйте tag, прочитайте changelog і зберігайте резервні копії.

Що потрібно підготувати перед початком

VPS з Ubuntu 24.04, Docker Engine і Compose plugin. Якщо ви ще не працювали з Compose, почніть із матеріалу Основи Docker Compose для VPS.
git, оскільки ви перевірятимете release tag, а не завантажуватимете image.
Доменне ім’я, що вказує на VPS, оскільки перед сервісом потрібно налаштувати TLS (transport layer security).
Model backend із підтримкою OpenAI API: локальний Ollama, self-hosted gateway або платний ключ.

Сам Octop споживає мало ресурсів. Це Python-процес і файл SQLite. Основне навантаження створює model backend. Тому, якщо ви плануєте запускати model на тому самому сервері, виберіть розмір сервера відповідно до вимог model.

Чому ми не рекомендуємо інсталятор через curl

У README спочатку наведено однорядкову команду встановлення:

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

Ми не рекомендуємо використовувати її на сервері, який для вас важливий, з однієї конкретної причини: цей скрипт не входить до репозиторію. Він розміщується у сховищі Tencent Cloud Object Storage. На нього не поширюється ні git tag, ні commit, тому ви не можете порівняти сьогоднішню версію скрипту з версією минулого тижня. Також немає історії, яка пояснює внесені зміни. Завтра bucket може повернути інший вміст, і в проєкті це ніяк не буде зафіксовано. Передавання результату безпосередньо до bash також означає, що машина запустить скрипт до того, як ви прочитаєте хоча б один його рядок.

Інсталятор також записує файли безпосередньо на хост, а не в контейнер. Він використовує uv, щоб завантажити Python 3.12 і створити середовище, про яке ваш пакетний менеджер нічого не знає. Тому згодом видаляти це середовище доведеться вручну.

Є два кращі варіанти. Завантажте скрипт, прочитайте його, а потім запустіть. Це займе тридцять секунд: curl -fsSL <url> -o install.sh, потім less install.sh, потім bash install.sh. Або використовуйте Docker — саме цьому присвячено решту цього посібника. Пакет PyPI (pip install octop) принаймні є артефактом із версією, який можна прив’язати до певного релізу.

Розгорніть Octop за допомогою Docker Compose із фіксацією на v0.9.19

Файл Compose, що постачається у v0.9.19, збирає image з репозиторію, тому в цьому посібнику фіксація версії означає перемикання на git tag. Опубліковані images також існують. Дерево v0.9.19 уже містить workflow docker-publish.yml, доданий у v0.9.8 15 July 2026, який збирає image і надсилає його до Docker Hub для кожного tag v*. Станом на 20 October 2026 проєкт також публікує images у container registry GitHub (docker pull ghcr.io/tencentcloud/octop:1.0.2). Збірка з перевіреного tag усе одно забезпечує точнішу фіксацію, оскільки ви компілюєте саме той код, який переглянули, а не довіряєте tag у registry. Це на один крок складніше, ніж у більшості self-hosted проєктів: наприклад, self-hosted робочий простір AFFiNE фіксує опублікований tag image і нічого не збирає на вашому VPS. Наведена нижче процедура клонування, перемикання на tag і збірки така сама, як у посібнику з розгортання openGym, тому якщо ви вже один раз це налаштовували, то знаєте загальну структуру.

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

Ось сервіс, який визначає цей файл, із вилученими другорядними частинами:

services:
  octop:
    build:
      context: ..
      dockerfile: docker/Dockerfile
    image: octop:latest
    container_name: octop
    restart: unless-stopped
    ports:
      - "${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"
    volumes:
      - ${OCTOP_DATA:-~/.octop}:/data/.octop
    environment:
      - HOME=/data
      - OCTOP_BIND_HOST=0.0.0.0
      - OCTOP_PORT=${OCTOP_PORT:-8088}
      - OCTOP_DEFAULT_PASSWORD=${OCTOP_DEFAULT_PASSWORD:-octop}
      - OCTOP_ADMIN_USERNAME=${OCTOP_ADMIN_USERNAME:-admin}
      - OPENAI_API_KEY=${OPENAI_API_KEY:-}

Зверніть увагу на блок build:. image: octop:latest — це ім’я вашої власної збірки, а не посилання на registry, тому latest тут означає те, що ви скомпілювали востаннє. Укажіть явний шлях до даних, а не залишайте його значенням за замовчуванням, і задайте справжній пароль для облікового запису адміністратора до першого запуску. Додайте це до docker/.env:

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

Тут є одна важлива особливість. Compose читає docker/.env лише для підстановки заповнювачів ${...} у YAML. Ключ, доданий до цього файлу, не потрапляє до контейнера, якщо його також не вказано в environment: у файлі Compose. Додавання OCTOP_ACCESS_TOKEN_TTL лише до .env взагалі нічого не робить, причому без повідомлення про помилку. Альтернатива — записати ті самі ключі до ~/.octop/env у змонтованому каталозі даних, який Octop завантажує під час запуску. У посібнику з env-файлів і секретів у Docker Compose пояснено, чому ці два механізми не є еквівалентними.

Зберіть image і запустіть його:

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

Працюючий екземпляр відповідає на health check JSON-об’єктом на кшталт {"ok":true,"started_at":...,"db":...,"users_loaded":0,"agents_running":0}. Якщо відповідь інша, перегляньте docker compose -f docker/docker-compose.yml logs -f octop, перш ніж відкривати браузер.

Тепер надайте щойно зібраному image змістовне ім’я, оскільки наступний --build перезапише octop:latest, і ви не зможете відрізнити ці два image:

docker image tag octop:latest octop:0.9.19

Під час першого запуску виконується octop init, а початкові облікові дані записуються до тому даних:

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

Значення за замовчуванням — admin / octop, і вони застосовуються лише під час першої ініціалізації. Саме тому часто запитують: зміна OCTOP_DEFAULT_PASSWORD після першого запуску контейнера нічого не змінює, оскільки обліковий запис уже створено. Змініть пароль у dashboard.

Не публікуйте порт 8088

Рядок ports: вище прив’язує порт до всіх інтерфейсів VPS. Щойно контейнер запускається, dashboard стає доступним з публічного інтернету у відкритому вигляді, ще й зі стандартним паролем. Власне значення OCTOP_BIND_HOST за замовчуванням у Octop — 127.0.0.1; файл Compose перевизначає його значенням 0.0.0.0, оскільки процес має приймати трафік з-поза власного network namespace. Це перевизначення правильне. Небезпеку створює саме опублікований порт.

Змініть рядок ports: у docker/docker-compose.yml, щоб прив’язка прослуховувала лише loopback:

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

Не намагайтеся виправити це звичайним override-файлом. Compose об’єднує списки ports з кількох файлів, а не замінює їх. У результаті будуть опубліковані обидві прив’язки, і друга не зможе прив’язати порт. Якщо потрібно залишити upstream-файл без змін, використайте тег !override для цієї послідовності. Це документований спосіб замінити значення, а не додати його. У поясненні об’єднання кількох файлів Compose описано решту правил такого об’єднання.

Прив’язка до loopback також усуває проблему, яка інакше виникла б із firewall. Docker записує правила опублікованих портів у таблицю nat перед ланцюжками, якими керує ufw, тому ufw deny 8088 не блокує порт контейнера, опублікований Docker. У Docker Engine 28.0.0 або новішої версії порт, прив’язаний до 127.0.0.1, недоступний ззовні незалежно від налаштувань ufw. Саме тому це правильне виправлення, а не компромісний варіант. Старіші версії Engine дозволяють хостам у тому самому L2-сегменті, наприклад іншим машинам у мережі вашого провайдера, підключатися до портів, опублікованих на localhost. Тому виконайте docker version і оновіть Engine, якщо сервер повідомляє про версію нижче 28.

Налаштуйте TLS перед reverse proxy

Caddy — найкоротший шлях, оскільки він самостійно запитує сертифікат через ACME (середовище автоматичного керування сертифікатами) і проксирує WebSockets без додаткових налаштувань:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx потребує ретельнішого налаштування, оскільки Octop передає чат через 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;
    }
}

Кожен рядок у цьому фрагменті виконує певну функцію. Чат працює через WS /api/agents/{id}/chat/ws, тому без proxy_http_version 1.1 і двох заголовків upgrade nginx відповідає на спробу оновлення кодом 400 Bad Request: dashboard завантажується нормально, а кожне надіслане повідомлення зависає назавжди без помилки на сторінці. proxy_buffering off має значення, оскільки endpoint resume у сценарії human-in-the-loop повертає text/event-stream, а SSE (server-sent events), утримувані в буфері reverse proxy, надходять одним блоком наприкінці замість потокової передачі. proxy_read_timeout потрібен для тривалих запусків інструментів, оскільки стандартне значення 60 секунд перериває роботу агента посеред виконання завдання, а в журналах з’являється upstream timed out (110: Connection timed out).

Як працює JWT-автентифікація за reverse proxy

Octop автентифікує користувача за bearer token, а не за cookie. POST /api/auth/login повертає {access_token, role, user, ...}, а наступні запити містять Authorization: Bearer <access_token>. Для reverse proxy це добре: немає домену cookie, прапорця Secure чи правила SameSite, які можна налаштувати неправильно. Тому сеанс, який працював на http://127.0.0.1:8088, так само працює на https://octop.example.com.

Перед підключенням реальних користувачів потрібно врахувати два наслідки.

WebSocket передає токен в URL. Endpoint має вигляд WS /api/agents/{id}/chat/ws?token=<jwt>, оскільки JavaScript у браузері не може встановити заголовок Authorization під час WebSocket handshake. TLS захищає цей токен під час передавання. Але він не захищає токен від ваших власних журналів: nginx за замовчуванням записує повний рядок запиту, зокрема query string, у access_log. Тому робочий токен реального користувача опиняється у відкритому тексті на сервері. Записуйте шлях без аргументів. $uri — це нормалізований шлях, з якого query string уже вилучено. Додайте це до блоку http і підключіть його в 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;

Окремого виходу із сеансу немає. OCTOP_ACCESS_TOKEN_TTL за замовчуванням має значення 86400, тому токен залишається чинним протягом 24 годин після входу. Єдиний задокументований спосіб його інвалідувати — octop admin rotate-jwt-secret. Ця команда змінює ключ підпису, збережений у ~/.octop/secrets/jwt_secret, і негайно інвалідує всі чинні токени для всіх користувачів. Тому після виходу працівника з команди порядок дій такий: видалити користувача, змінити секрет, а потім попросити решту користувачів увійти знову. Якщо це надто жорсткий підхід, зменште час дії токена. Не забудьте додати цю змінну до списку environment: і до .env:

OCTOP_ACCESS_TOKEN_TTL=28800

Захист від brute force уже налаштований: OCTOP_LOGIN_MAX_ATTEMPTS за замовчуванням дорівнює 5 невдалим спробам, а OCTOP_LOGIN_LOCKOUT_SECONDS — 900. Тому заблокований користувач просто чекає п’ятнадцять хвилин, а не вважає інсталяцію несправною. Octop має власне сховище користувачів і не має задокументованої підтримки OIDC у версії v0.9.19. Якщо потрібен повноцінний single sign-on, розмістіть перед ним автентифікаційний proxy. Саме для цього призначений self-hosted сервер Authentik.

Налаштуйте Octop на модельний бекенд

Провайдерів налаштовують для кожного агента в dashboard, а octop provider list показує поточні значення. Octop постачається з готовими налаштуваннями для OpenAI-compatible API, DashScope (Qwen) і Ollama. Облікові дані зберігаються в таблиці providers вашої власної SQLite database. Вибір провайдера визначає витрати та те, які дані залишають сервер.

Локальна модель з Ollama. Дані не залишають сервер, а замість токенів ви витрачаєте RAM. Важлива деталь мережевого підключення: контейнер не може звернутися до Ollama на хості через 127.0.0.1:11434, оскільки ця адреса вказує на loopback самого контейнера. Додайте до сервісу запис про gateway хоста:

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

Потім задайте базову URL провайдера як http://host.docker.internal:11434/v1. Це OpenAI-compatible path для Ollama. У поле API key введіть будь-який непорожній рядок, оскільки Ollama його ігнорує, але OpenAI clients не надсилають порожній ключ. Ollama також має приймати з’єднання не лише з loopback. Для цього в його systemd unit потрібен параметр OLLAMA_HOST=0.0.0.0:11434. Це небезпечна частина: Ollama не має authentication, тому відкритий порт 11434 на публічній IP-адресі перетворює сервер моделей на доступний для будь-кого, хто першим його просканує. Дозвольте доступ лише з приватного діапазону Docker, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp, а решту забороніть. У матеріалі Запуск Ollama на VPS описано вибір розміру моделі, а в матеріалі порівняння Ollama та vLLM пояснено, коли Ollama перестає бути правильним сервером.

Є ще одне застереження щодо локальних моделей. Воно схоже на помилку в Octop, але нею не є. Агенти працюють через виклик tools. System prompt, визначення tools і history разом утворюють великий prompt. Ollama обслуговує моделі з помірним default context window, тому початок prompt, де містяться визначення tools, виходить за межі вікна. Після цього модель перестає викликати tools або вигадує неіснуючі tools. Збільште num_ctx до 16k або 32k і виберіть модель, яка справді добре підтримує function calling. Відповідь, що обривається посеред речення, має іншу причину й пов’язана з іншим параметром — num_predict. Якщо відповіді повертаються обрізаними, варто перевірити, де задано num_predict і що означає done_reason, перш ніж звинувачувати агента. Якщо ви хочете одразу почати з конкретного кандидата, а не зі списку, спробуйте Nemotron 3.5 Lightning. У цьому матеріалі наведено точний tag для завантаження, потрібний обсяг RAM і дані про продуктивність у режимі лише CPU.

Self-hosted gateway. Розмістіть self-hosted LiteLLM gateway між Octop та всіма іншими компонентами. Ви отримаєте одну базову URL, окремий ключ для кожного користувача, ліміти витрат і єдиний журнал. Модель за gateway також можна замінити без змін у Octop.

Платний API. Це найкраща якість, але з очевидним компромісом: вміст розмов залишає ваш сервер і надходить до провайдера. Це суперечить головній меті self-hosting. Ключ потрібно вказати в docker/.env як OPENAI_API_KEY. Compose file вже передає це значення далі.

Незалежно від вибору, Compose file також містить OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY і LANGFUSE_BASE_URL. Тому ви можете надсилати traces до власного екземпляра Langfuse і бачити, що саме роблять агенти, замість того щоб робити висновки лише з chat window.

Користувачі, ролі та спільна бібліотека агентів

Обліковий запис адміністратора, створений під час першого запуску, створює та керує іншими обліковими записами. Кожен користувач має власних агентів, робочий простір і облікові дані. Ізоляцію забезпечує токен, який зберігається в браузері. Окремо є спільний пул навичок і субагентів, доступний усім користувачам. Саме це робить рішення корисним для сім’ї: один користувач один раз створює якісного агента для досліджень, і решті не потрібно створювати його повторно.

Будьте обережні з інструментами. Octop підтримує підтвердження використання інструментів і обмеження для shell-команд, і обидві функції працюють. Проте агент, який виконує shell-команди, виконує їх усередині контейнера Octop, де змонтовано ваш том із даними. Обмеження зменшують шкоду, яку може спричинити необережний prompt. Вони не є межею sandbox, тому залиште підтвердження використання інструментів увімкненим для користувачів, яким ви не надали б доступ до shell. Якщо ви порівнюєте це рішення з іншими варіантами, огляд self-hosted AI-агентів порівнює підхід кожного з них до цього питання.

Оновлення проєкту, який випускає релізи з такою швидкістю

ГрафікDays between Octop releases, v0.9.16 to v0.9.19 (repository tags, 7 August 2026)

version

days_since_previous_release

v0.9.16

v0.9.17

v0.9.18

v0.9.19

Дані, на яких побудовано графік

[
  {
    "version": "v0.9.16",
    "days_since_previous_release": 2
  },
  {
    "version": "v0.9.17",
    "days_since_previous_release": 3
  },
  {
    "version": "v0.9.18",
    "days_since_previous_release": 1
  },
  {
    "version": "v0.9.19",
    "days_since_previous_release": 3
  }
]

Це дати тегів із репозиторію станом на 7 August 2026. За дев’ять днів з’явилося 4 позначених релізів. Проміжок між релізами становив лише 1 день, а v0.9.19 вийшов через 3 днів після попереднього тега. Такий темп свідчить про активний розвиток проєкту, але не дає підстав бездумно запускати latest. Перед оновленням прочитайте зміни:

cd Octop
git fetch --tags
git tag --sort=-creatordate | head
NEW_TAG=$(git tag --sort=-creatordate | head -1)
git log --oneline "v0.9.19..$NEW_TAG"

Перед checkout перевірте, що саме містить $NEW_TAG, оскільки проєкт позначає тегами бета-версії, наприклад v1.0.2b9, поряд зі стабільними релізами. Станом на 20 October 2026 найновішим тегом є стабільна версія v1.0.2, опублікована 18 October 2026. Перехід із v0.9.19 охоплює реліз v1.0.0 від 14 September 2026, тому цей журнал довгий і його варто уважно переглянути.

Щоразу спочатку створюйте резервну копію, оскільки міграції бази даних запускаються під час старту. Якщо міграція не вдасться в проєкті з таким швидким темпом релізів, усувати наслідки доведеться вам:

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

Потім перейдіть на новий тег і перебудуйте проєкт за допомогою docker compose -f docker/docker-compose.yml up -d --build. Якщо щось піде не так, перехід на старий тег і повторна збірка повернуть код. Базу даних можна відновити лише з tarball.

Цей tarball містить octop.db, config.json, секрет підпису JWT і credential.txt, тому він потребує такого самого захисту, як і сам сервер. Встановіть для нього режим 600 і зберігайте копію поза сервером. Для більшої інсталяції проєкт також постачає docker/docker-compose.postgres.yml, який запускає PostgreSQL із pgvector замість SQLite.

Режими відмови та повідомлення, які ви побачите

Перевірка стану ніколи не повертає відповідь. curl http://127.0.0.1:8088/api/health зависає або відмовляє. Перегляньте docker compose -f docker/docker-compose.yml logs -f octop. Контейнер, який завершує роботу під час першої ініціалізації, зазвичай не може записати каталог даних. Перевірте власника каталогу, який ви вказали в OCTOP_DATA.

Панель керування завантажується, але чат зависає. На сторінці немає помилки, але відповідь не надходить. Відкрийте консоль браузера та перевірте, чи не завершилося помилкою підключення до wss://octop.example.com/api/agents/.../chat/ws. Проксі не пересилає upgrade-запит. Додайте заголовки proxy_http_version 1.1 і Upgrade та Connection.

Уся відповідь з’являється одразу із затримкою в кілька секунд. Потокова передача працює, але буферизацію не вимкнено. Установіть proxy_buffering off.

bind: address already in use. Порт 8088 уже зайнятий іншим процесом. sudo ss -tlnp | grep 8088 покаже, який саме процес його використовує. Така сама помилка виникає, якщо додати другий запис ports у файл override замість редагування оригінального запису.

Правильний пароль відхиляється. П’ять невдалих спроб запускають блокування на 900 секунд. Дочекайтеся завершення блокування, а не перевстановлюйте систему.

Новий пароль у .env не набув чинності. Ці облікові дані застосовуються лише під час першої ініціалізації. Змініть пароль на панелі керування.

Агент відповідає, але ніколи не запускає інструмент. Майже завжди проблема пов’язана з локальною моделлю: розмір контекстного вікна недостатній для описів інструментів або модель погано підтримує виклики функцій. Збільште num_ctx і спробуйте модель, призначену для роботи з інструментами.

FAQ

Чи є Octop заміною Open WebUI?

Лише якщо вам потрібні його додаткові можливості. Open WebUI — це інтерфейс чату перед моделлю, і він добре виконує це завдання для однієї людини або сім’ї, де всі довіряють одне одному. Octop додає облікові записи з роллю адміністратора, окремі робочі простори й облікові дані для кожного користувача, а також бібліотеку спеціалізованих агентів, яку можна перемикати. Тому кілька людей можуть спільно використовувати один сервер, не маючи спільної історії. Якщо вам достатньо одного облікового запису, Open WebUI буде простішим і значно зрілішим вибором.

Чому не слід використовувати скрипт встановлення Octop через curl?

Скрипт розміщено у bucket Tencent Cloud Object Storage, а не в репозиторії, тому на нього не поширюється жоден git tag або commit. Ви не можете порівняти його поточну поведінку з поведінкою минулого тижня, а передавання скрипту в bash запускає його ще до того, як ви прочитаєте його вміст. Скрипт також встановлює програму безпосередньо на host у власне середовище Python 3.12, поза межами вашого package manager. Спочатку завантажте скрипт і прочитайте його або розгортайте програму за допомогою Docker Compose з checkout-нутого tag.

Чи може Octop використовувати локальну модель замість платного API?

Так. Octop підтримує OpenAI-compatible API і постачається з preset для Ollama, тому підключення до http://host.docker.internal:11434/v1 працює після додавання extra_hosts: ["host.docker.internal:host-gateway"] до контейнера та налаштування OLLAMA_HOST=0.0.0.0:11434 на host. Обмежте доступ firewall до порту 11434 для діапазону адрес Docker, оскільки Ollama не має власної автентифікації. Збільште значення num_ctx в Ollama до 16k або більше, оскільки prompts агентів із визначеннями інструментів перевищують стандартне context window, після чого модель перестає викликати інструменти.

Чи потрібен reverse proxy, чи можна відкрити порт 8088?

Reverse proxy потрібен. Compose file, який постачається з Octop, публікує порт 8088 на всіх інтерфейсах без TLS, тому паролі та bearer tokens передавалися б через інтернет у відкритому вигляді. Змініть опублікований порт на 127.0.0.1:8088:8088 і розмістіть перед Octop Caddy або nginx із сертифікатом. У разі використання nginx передайте заголовки WebSocket upgrade і встановіть proxy_buffering off, інакше сторінка завантажиться, але чат непомітно не відповідатиме.

Чи готовий Octop до використання у production?

Станом на August 2026 це був продукт до версії 1.0, для якого щотижня випускалося кілька tagged releases. 14 September 2026 для нього було створено tag v1.0.0, після чого вийшла серія beta tags 1.0.2, а 18 October 2026 — стабільна версія v1.0.2. Темп розробки досі високий, тому сприймайте Octop як перспективний, але ще не усталений продукт. Це прийнятний варіант для сім’ї або невеликої внутрішньої команди, якщо ви фіксуєте точний tag, перед кожним оновленням читаєте commit log, а перед кожною повторною збіркою створюєте резервну копію data volume. Не запускайте його на latest і поки що не зберігайте в ньому дані клієнтів.

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