Come installare Octop self-hosted con Docker Compose

Che cos’è Octop e perché eseguirlo in self-hosting

Octop è un assistente AI self-hosted per una famiglia o un piccolo team. Il motivo per eseguire Octop in self-hosting invece di usare un semplice frontend per chat è che mantiene separati gli utenti. Open WebUI offre un’interfaccia browser davanti a un modello. Octop aggiunge account con un ruolo admin, un workspace privato e un set di credenziali per ogni utente, oltre a una raccolta di agenti specializzati tra cui ogni utente può scegliere in base all’attività. Questa è la differenza che consente a un singolo VPS di servire cinque persone invece di una.

Il progetto si trova all’indirizzo github.com/TencentCloud/Octop. È un unico processo che fornisce una dashboard web, un’interfaccia a riga di comando, canali di chat (Feishu, DingTalk, QQ, Discord, WeCom) e attività pianificate, tutti basati su un unico database SQLite in ~/.octop/. Tutto ciò che segue si riferisce al tag v0.9.19, pubblicato il 5 agosto 2026. Se stai ancora valutando le piattaforme, la comparazione delle alternative a Open WebUI eseguibili su un VPS offre una panoramica più ampia.

È importante chiarire un aspetto prima di dedicarci un’intera serata. Al momento della stesura di questa guida, Octop era un software precedente alla versione 1.0, pubblicato dall’organizzazione GitHub di un fornitore, con circa 900 stelle ad agosto 2026. Da allora il progetto ha pubblicato il tag v1.0.0 il 14 settembre 2026 e, al 20 ottobre 2026, il tag più recente è v1.0.2, una release stabile pubblicata il 18 ottobre 2026 dopo una serie di tag beta 1.0.2; il repository conta circa 10.400 stelle. I passaggi riportati di seguito sono stati scritti per v0.9.19 e non sono stati nuovamente testati sulla versione 1.x. Il progetto evolve rapidamente, come mostrano i numeri di versione, e queste istruzioni non garantiscono un percorso di aggiornamento stabile. Blocca un tag, leggi il changelog e conserva i backup.

Cosa serve prima di iniziare

• Una VPS con Ubuntu 24.04, Docker Engine e il plugin Compose. Non hai mai usato Compose? Inizia da Introduzione a Docker Compose per una VPS.
• git, perché devi estrarre un tag di release invece di scaricare un'immagine.
• Un nome di dominio che punti alla VPS, perché vuoi usare TLS (Transport Layer Security) davanti al servizio.
• Un backend per modelli che supporti l'API OpenAI: un'istanza locale di Ollama, un gateway self-hosted oppure una chiave a pagamento.

Octop è leggero. È costituito da un processo Python e da un file SQLite. Il carico deriva dal backend del modello. Se prevedi di eseguire il modello sullo stesso server, dimensiona il server in base ai requisiti del modello.

Perché non consigliamo l'installer tramite curl

Il README inizia con un'installazione su una sola riga:

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

Non lo consigliamo su un server importante per un motivo preciso: lo script non si trova nel repository. Viene fornito da un bucket Tencent Cloud Object Storage. Non è coperto da alcun tag o commit git, quindi non è possibile confrontare lo script attuale con quello della settimana scorsa e non esiste una cronologia che spieghi le modifiche. Domani il bucket potrebbe fornire byte diversi e nulla nel progetto lo registrerebbe. Inviare direttamente il risultato a bash significa inoltre che la macchina esegue lo script prima che sia possibile leggerne anche solo una riga.

L'installer scrive inoltre sull'host invece che in un container. Usa uv per scaricare Python 3.12 e creare un ambiente di cui il gestore dei pacchetti non sa nulla, quindi in seguito la rimozione richiede un intervento manuale.

Esistono due opzioni migliori. Scaricare lo script, leggerlo e poi eseguirlo, dedicando trenta secondi alla procedura: curl -fsSL <url> -o install.sh, quindi less install.sh e infine bash install.sh. In alternativa, usare Docker, che è l'argomento del resto di questa guida. Il pacchetto PyPI (pip install octop) è almeno un artefatto versionato che è possibile vincolare a una release.

Distribuire Octop con Docker Compose, bloccato alla versione v0.9.19

Il file Compose incluso nella versione v0.9.19 crea l'immagine dal repository. In questa guida, quindi, bloccare una versione significa eseguire il checkout di un tag Git. Esistono anche immagini pubblicate. L'albero dei sorgenti v0.9.19 include già un workflow docker-publish.yml, aggiunto nella versione v0.9.8 il 15 July 2026, che crea un'immagine e la pubblica su Docker Hub per ogni tag v*. Dal 20 October 2026 il progetto pubblica anche nel container registry di GitHub (docker pull ghcr.io/tencentcloud/octop:1.0.2). Creare l'immagine dal tag sottoposto a checkout resta il blocco più rigoroso, perché compila esattamente il codice esaminato, senza affidarsi a un tag del registry. È un passaggio in più rispetto a quanto richiesto dalla maggior parte dei progetti self-hosted. Per esempio, un workspace AFFiNE self-hosted usa un tag di immagine pubblicato e non crea nulla sul VPS. La procedura di clone, checkout e build riportata di seguito è la stessa descritta nella guida alla distribuzione di openGym. Se l'hai già eseguita una volta, ne conosci già la struttura.

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

Questo è il servizio definito dal file, ridotto alle parti rilevanti:

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

Nota il blocco build:. image: octop:latest è il nome della build locale, non un riferimento a un registry. Di conseguenza, latest indica qui qualunque sia l'ultima versione compilata. Imposta il percorso dei dati in una posizione esplicita, invece di lasciare che venga usato un valore predefinito, e assegna all'account amministratore una password reale prima del primo avvio. Inserisci questo contenuto in docker/.env:

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

C'è un dettaglio importante da considerare. Compose legge docker/.env soltanto per interpolare i segnaposto ${...} nel file YAML. Una chiave aggiunta a quel file non raggiunge il container se non è elencata anche sotto environment: nel file Compose. Aggiungere OCTOP_ACCESS_TOKEN_TTL soltanto a .env non produce alcun effetto e non genera messaggi. L'alternativa consiste nello scrivere le stesse chiavi in ~/.octop/env, all'interno della directory dei dati montata, che Octop carica all'avvio. La guida ai file env e ai secret in Docker Compose spiega perché questi due meccanismi non sono equivalenti.

Crealo e avvialo:

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

Un'istanza funzionante risponde al controllo di integrità con un oggetto JSON simile a {"ok":true,"started_at":...,"db":...,"users_loaded":0,"agents_running":0}. Qualsiasi altra risposta richiede di leggere docker compose -f docker/docker-compose.yml logs -f octop prima di intervenire dal browser.

Ora assegna all'immagine appena creata un nome significativo. Il prossimo --build sovrascriverà infatti octop:latest e non sarà più possibile distinguere le due immagini:

docker image tag octop:latest octop:0.9.19

Il primo avvio esegue octop init e scrive le credenziali iniziali nel volume dei dati:

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

I valori predefiniti sono admin / octop e vengono applicati solo durante la prima inizializzazione. Questo spiega una domanda ricorrente: modificare OCTOP_DEFAULT_PASSWORD dopo il primo avvio del container non cambia nulla, perché l'account esiste già. Cambia la password dalla dashboard.

Non pubblicare la porta 8088

La riga ports: qui sopra associa la porta a tutte le interfacce del VPS. Non appena il container viene avviato, la dashboard è accessibile da Internet in chiaro e usa una password predefinita. Il valore predefinito di OCTOP_BIND_HOST in Octop è 127.0.0.1; il file Compose lo sovrascrive con 0.0.0.0 perché il processo deve accettare traffico dall'esterno del proprio namespace di rete. Questa sovrascrittura è corretta. È la pubblicazione della porta a esporre il servizio.

Modifica la riga ports: in docker/docker-compose.yml in modo che la mappatura sia in ascolto soltanto sull'interfaccia loopback:

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

Non cercare di risolvere il problema con un semplice file di override. Compose concatena gli elenchi ports dei diversi file invece di sostituirli. In questo modo finisci per pubblicare entrambe le mappature e la seconda non riesce ad associarsi alla porta. Se vuoi lasciare invariato il file upstream, usa il tag !override sulla sequenza. È il metodo documentato per sostituire una sequenza invece di aggiungerla. La spiegazione di come Compose unisce più file descrive le altre regole di unione.

L'associazione all'interfaccia loopback risolve anche un problema che altrimenti incontreresti con il firewall. Docker scrive le regole delle porte pubblicate nella tabella nat, prima delle catene gestite da ufw. Di conseguenza, ufw deny 8088 non blocca una porta pubblicata dal container. In Docker Engine 28.0.0 o versioni successive, una porta associata a 127.0.0.1 non è raggiungibile dall'esterno, indipendentemente dalla configurazione di ufw. Per questo è la correzione appropriata, non un'alternativa di ripiego. Le versioni precedenti di Engine consentono agli host dello stesso segmento L2, ad esempio altre macchine sullo switch del provider, di raggiungere le porte pubblicate su localhost. Esegui docker version e aggiorna Engine se il server segnala una versione precedente a 28.

Configura TLS con un reverse proxy

Caddy è la soluzione più rapida, perché richiede autonomamente il certificato tramite ACME (automatic certificate management environment) e inoltra le connessioni WebSocket senza configurazioni aggiuntive:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx richiede maggiore attenzione, perché Octop trasmette la chat tramite 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;
    }
}

Ogni riga ha una funzione precisa. La chat usa WS /api/agents/{id}/chat/ws, quindi senza proxy_http_version 1.1 e i due header di upgrade nginx risponde al tentativo di upgrade con 400 Bad Request: la dashboard si carica normalmente, ma ogni messaggio inviato resta bloccato indefinitamente senza mostrare errori nella pagina. proxy_buffering off è importante perché l'endpoint di ripresa human-in-the-loop restituisce text/event-stream e gli eventi SSE (server-sent events) trattenuti nel buffer del proxy arrivano tutti insieme al termine, invece di essere trasmessi progressivamente. proxy_read_timeout copre le esecuzioni lunghe degli strumenti, perché il valore predefinito di 60 secondi interrompe un agente durante l'attività e registra upstream timed out (110: Connection timed out).

Come funziona l'autenticazione JWT dietro il proxy

Octop esegue l'autenticazione con un bearer token, non con un cookie. POST /api/auth/login restituisce {access_token, role, user, ...} e le richieste successive includono Authorization: Bearer <access_token>. Per un reverse proxy è una buona notizia: non esistono un dominio del cookie, il flag Secure o la regola SameSite da configurare in modo errato. Di conseguenza, una sessione che funziona su http://127.0.0.1:8088 si comporta allo stesso modo su https://octop.example.com.

Prima di consentire l'accesso a utenti reali, è importante conoscere due conseguenze.

Il WebSocket trasporta il token nell'URL. L'endpoint è WS /api/agents/{id}/chat/ws?token=<jwt>, perché JavaScript eseguito nel browser non può impostare un header Authorization durante l'handshake WebSocket. TLS protegge il token durante il transito. Non lo protegge però dai log del server: per impostazione predefinita nginx scrive la riga di richiesta completa, inclusa la query string, in access_log. Di conseguenza, un token valido di un utente reale finisce in un file di testo in chiaro sul server. Registra il percorso senza gli argomenti. $uri è il percorso normalizzato, con la query string già rimossa. Inseriscilo quindi nel blocco http e richiamalo dal 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;

Non esiste il logout per singola sessione. Per impostazione predefinita, OCTOP_ACCESS_TOKEN_TTL è 86400, quindi un token resta valido per 24 ore dopo l'accesso. L'unico metodo documentato per invalidarlo è octop admin rotate-jwt-secret. Questa operazione ruota la chiave di firma memorizzata in ~/.octop/secrets/jwt_secret e invalida immediatamente tutti i token ancora validi, per tutti gli utenti. Quando una persona lascia il team, procedi quindi in questo ordine: elimina l'utente, ruota il secret, quindi chiedi agli utenti rimanenti di accedere nuovamente. Se questa procedura è troppo onerosa, riduci la durata del token. Ricorda di aggiungere la variabile all'elenco environment: oltre che a .env:

OCTOP_ACCESS_TOKEN_TTL=28800

La protezione contro i tentativi a forza bruta è già gestita: OCTOP_LOGIN_MAX_ATTEMPTS è impostato su 5 tentativi falliti e OCTOP_LOGIN_LOCKOUT_SECONDS su 900. Un utente bloccato deve quindi semplicemente attendere quindici minuti, invece di pensare che l'installazione non funzioni. Octop usa un proprio archivio degli utenti e, nella versione v0.9.19, non offre supporto OIDC documentato. Se ti serve un single sign-on completo, devi collocare davanti a Octop un proxy che esegua l'autenticazione. È questo lo scopo di un server Authentik self-hosted.

Indicare a Octop un backend per i modelli

I provider vengono configurati per ogni agente nella dashboard e octop provider list mostra i valori impostati. Octop include preset per le API compatibili con OpenAI, DashScope (Qwen) e Ollama; le credenziali vengono memorizzate nella tabella providers del proprio database SQLite. La scelta determina i costi e quali dati lasciano il server.

Un modello locale con Ollama. Nessun dato lascia il server e il costo viene sostenuto in RAM anziché in token. Il dettaglio di collegamento che causa più problemi è questo: un container non può raggiungere l'istanza Ollama dell'host tramite 127.0.0.1:11434, perché quell'indirizzo corrisponde al loopback del container stesso. Aggiungere una voce per il gateway dell'host al servizio:

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

Impostare quindi l'URL di base del provider su http://host.docker.internal:11434/v1, che è il percorso compatibile con OpenAI di Ollama, e inserire nel campo della chiave API una stringa non vuota qualsiasi. Ollama ignora questo valore, ma i client OpenAI rifiutano di inviare una chiave vuota. Per funzionare, Ollama deve inoltre accettare connessioni oltre il loopback; nell'unità systemd questo richiede OLLAMA_HOST=0.0.0.0:11434. Questa è la parte rischiosa: Ollama non offre autenticazione, quindi una porta 11434 esposta su un IP pubblico diventa un server di modelli accessibile a chiunque la rilevi per primo. Consentire soltanto l'intervallo privato Docker, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp, e negare tutte le altre origini. Eseguire Ollama su un VPS tratta il dimensionamento del modello, mentre il confronto tra Ollama e vLLM spiega quando Ollama non è più il server adatto.

È necessaria un'ulteriore avvertenza sui modelli locali, perché il comportamento sembra un bug di Octop, ma non lo è. Gli agenti funzionano chiamando strumenti e il prompt di sistema, le definizioni degli strumenti e la cronologia formano un prompt di grandi dimensioni. Ollama serve i modelli con una finestra di contesto predefinita piuttosto ridotta, quindi l'inizio del prompt, dove si trovano le definizioni degli strumenti, esce dalla finestra. Il modello smette quindi di chiamare gli strumenti oppure ne inventa di inesistenti. Aumentare num_ctx a 16k o 32k e scegliere un modello realmente efficace nelle chiamate di funzione. Una risposta che si interrompe a metà frase indica il problema opposto e un'impostazione diversa, num_predict. Se le risposte risultano troncate, conviene controllare dove è impostato num_predict e cosa indica done_reason prima di attribuire il problema all'agente. Se si preferisce partire da un candidato specifico anziché da una lista ristretta, Nemotron 3.5 Lightning merita una prova; la relativa guida indica il tag esatto da scaricare, la RAM richiesta e se le prestazioni con la sola CPU sono sufficienti.

Un gateway self-hosted. Inserire un gateway LiteLLM self-hosted tra Octop e tutto il resto consente di usare un unico URL di base, una chiave separata per ogni utente, limiti di spesa e un unico log. È inoltre possibile sostituire il modello a valle senza modificare la configurazione di Octop.

Un'API a pagamento. Offre la qualità migliore, con un compromesso da considerare: il contenuto delle conversazioni lascia il server e raggiunge il provider, cioè viene meno gran parte del motivo per cui si sceglie il self-hosting. La chiave va inserita in docker/.env come OPENAI_API_KEY; il file Compose la trasferisce già al servizio.

Qualunque sia la scelta, il file Compose include anche OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY e LANGFUSE_BASE_URL. È quindi possibile inviare le tracce a una propria istanza Langfuse e verificare cosa fanno realmente gli agenti, invece di dedurlo dalla finestra della chat.

Utenti, ruoli e libreria condivisa di agent

L'account amministratore creato al primo avvio crea e gestisce gli altri account. Ogni utente dispone dei propri agenti, dello spazio di lavoro e delle credenziali. Questo isolamento è garantito dal token conservato dal browser. È inoltre disponibile un pool condiviso di competenze e sotto-agenti che tutti possono usare. È questa la funzione che rende utile eseguire il servizio in ambito familiare: una persona configura una volta un buon agente per la ricerca e gli altri non devono ricrearlo.

Presta attenzione agli strumenti. Octop pubblicizza l'approvazione degli strumenti e le protezioni per i comandi shell, ed entrambe le funzioni sono effettivamente disponibili. Tuttavia, un agente che esegue comandi shell li esegue all'interno del container Octop, con il volume dei tuoi dati montato. Le protezioni limitano le operazioni che un prompt imprudente può eseguire. Non costituiscono un confine di sandbox. Lascia quindi attiva l'approvazione degli strumenti per chiunque non autorizzeresti a usare una shell. Se stai confrontando questa soluzione con altre opzioni, la panoramica degli agenti AI self-hosted illustra come ciascuna gestisce questo aspetto.

Aggiornare un progetto che rilascia con questa frequenza

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

Queste sono le date dei tag del repository, conteggiate al 7 agosto 2026. 4 release con tag sono state pubblicate in nove giorni, con un intervallo minimo di 1 giorno; inoltre, v0.9.19 è arrivata 3 giorni dopo il tag precedente. Questa frequenza è un buon segnale per il progetto, ma un motivo per non eseguire latest senza prima leggere le modifiche:

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"

Controlla cosa contiene realmente $NEW_TAG prima di eseguire il checkout, perché il progetto assegna tag alle versioni beta, ad esempio v1.0.2b9, oltre che alle release stabili. Al 20 ottobre 2026, il tag più recente è la versione stabile v1.0.2, pubblicata il 18 ottobre 2026. Il passaggio da v0.9.19 include la release v1.0.0 del 14 settembre 2026, quindi il log è lungo e merita una lettura attenta.

Esegui sempre prima un backup, perché le migrazioni del database vengono eseguite all'avvio e una migrazione non riuscita in un progetto che rilascia con questa frequenza è un problema che dovrai risolvere:

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

Esegui quindi il checkout del nuovo tag e ricrea il progetto con docker compose -f docker/docker-compose.yml up -d --build. Se qualcosa non funziona, eseguire il checkout del tag precedente e ricreare il progetto ripristina il codice, ma solo il tarball ripristina il database.

Il tarball contiene octop.db, config.json, il secret di firma JWT e credential.txt, quindi è sensibile quanto il server stesso. Mantienilo con modalità 600 e conserva una copia fuori dal server. Per un'installazione più grande, il progetto fornisce anche docker/docker-compose.postgres.yml, che esegue PostgreSQL con pgvector invece di SQLite.

Modalità di errore e stringhe visualizzate

Il controllo dello stato non riceve mai risposta. curl http://127.0.0.1:8088/api/health resta bloccato o rifiuta la connessione. Leggere docker compose -f docker/docker-compose.yml logs -f octop. Un container che termina durante la prima inizializzazione di solito non riesce a scrivere nella directory dei dati; verificare quindi il proprietario di ciò che è stato impostato in OCTOP_DATA.

La dashboard viene caricata, ma la chat resta bloccata. Nella pagina non compare alcun errore e non arriva mai una risposta. Aprire la console del browser e cercare una connessione non riuscita a wss://octop.example.com/api/agents/.../chat/ws. Il proxy non inoltra l'upgrade. Aggiungere proxy_http_version 1.1 e gli header Upgrade e Connection.

La risposta completa compare tutta insieme, con diversi secondi di ritardo. Lo streaming funziona, ma il buffering è attivo. Impostare proxy_buffering off.

bind: address already in use. La porta 8088 è già occupata. sudo ss -tlnp | grep 8088 identifica il processo che la utilizza. Questo accade anche quando si aggiunge una seconda voce ports in un file di override invece di modificare quella originale.

La password corretta viene rifiutata. Cinque tentativi errati attivano un blocco di 900 secondi. Attendere la scadenza del blocco invece di reinstallare.

La nuova password in .env non ha avuto effetto. Queste credenziali vengono applicate solo durante la prima inizializzazione. Modificarle nella dashboard.

L'agente risponde, ma non esegue mai uno strumento. Quasi sempre il problema riguarda il modello locale: la finestra di contesto è troppo piccola per le definizioni degli strumenti oppure il modello gestisce male le chiamate di funzione. Aumentare num_ctx e provare un modello progettato per l'uso degli strumenti.

FAQ

Octop è un sostituto di Open WebUI?

Solo se ti servono le funzionalità aggiuntive. Open WebUI è un'interfaccia di chat davanti a un modello e svolge bene questo compito per una persona o per un ambiente domestico basato sulla fiducia. Octop aggiunge account con ruolo di amministratore, workspace e credenziali separati per ogni utente e una libreria selezionabile di agenti specializzati. In questo modo più persone possono condividere un server senza condividere la stessa cronologia. Se per te è sufficiente un singolo account, Open WebUI è la scelta più semplice e più matura.

Perché non dovrei usare lo script di installazione curl di Octop?

Lo script viene fornito da un bucket Tencent Cloud Object Storage anziché dal repository. Di conseguenza, non è associato ad alcun tag o commit git. Non puoi confrontare ciò che fa oggi con ciò che faceva la settimana scorsa. Inoltre, se lo inoltri a bash, viene eseguito prima che tu possa leggerlo. Lo script installa anche il software sull'host usando un proprio ambiente Python 3.12, esterno al gestore dei pacchetti. Scaricalo e leggilo prima, oppure esegui il deployment con Docker Compose a partire da un tag estratto dal repository.

Octop può usare un modello locale invece di un'API a pagamento?

Sì. Octop supporta API compatibili con OpenAI e include una configurazione predefinita per Ollama. Dopo aver aggiunto extra_hosts: ["host.docker.internal:host-gateway"] al container e impostato OLLAMA_HOST=0.0.0.0:11434 sull'host, è sufficiente indirizzarlo verso http://host.docker.internal:11434/v1. Limita con il firewall la porta 11434 all'intervallo di indirizzi di Docker, perché Ollama non dispone di autenticazione propria. Prevedi di aumentare num_ctx di Ollama a 16k o più. I prompt degli agenti con le definizioni degli strumenti superano infatti la finestra di contesto predefinita e il modello smette di chiamare gli strumenti.

Mi serve un reverse proxy o posso aprire la porta 8088?

Ti serve il proxy. Il file Compose fornito con Octop pubblica la porta 8088 su tutte le interfacce e non abilita TLS. Le password e i bearer token attraverserebbero quindi Internet in chiaro. Modifica la porta pubblicata in 127.0.0.1:8088:8088 e configura Caddy o nginx davanti all'applicazione, usando un certificato. Con nginx, inoltra gli header di upgrade WebSocket e imposta proxy_buffering off. In caso contrario, la pagina verrà caricata, ma la chat non risponderà senza mostrare errori.

Octop è pronto per l'uso in produzione?

Ad agosto 2026 era precedente alla versione 1.0 e pubblicava diversi release tag alla settimana. Il 14 settembre 2026 ha pubblicato il tag v1.0.0, quindi una serie di tag beta 1.0.2, prima della versione stabile v1.0.2 del 18 ottobre 2026. Il ritmo è ancora elevato, quindi consideralo promettente, ma non ancora consolidato. Può essere una soluzione praticabile per una famiglia o un piccolo team interno se blocchi una versione esatta, leggi il commit log prima di ogni aggiornamento ed esegui un backup del volume dati prima di ogni rebuild. Non eseguirlo su latest e, per ora, non inserirvi dati dei clienti.