Come installare Octop self-hosted con Docker Compose

Che cos'è Octop e perché installarlo in autonomia

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

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

È importante chiarire un aspetto prima di dedicarci un'intera serata. Octop è un software precedente alla versione 1.0, pubblicato dall'organizzazione GitHub di un fornitore, con circa 900 stelle ad agosto 2026. Lo sviluppo è rapido, come confermano i numeri di versione, e queste istruzioni non garantiscono un percorso di aggiornamento stabile. Fissa 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

Ad agosto 2026 non esiste ancora un'immagine pubblicata da scaricare. Il file Compose incluso crea l'immagine dal repository, quindi bloccare una versione significa eseguire il checkout di un tag git. È un passaggio in più rispetto a quanto richiesto dalla maggior parte dei progetti self-hosted: ad esempio, un workspace AFFiNE self-hosted usa un tag di immagine pubblicato e non crea nulla sul VPS. La procedura di clonazione, checkout e build riportata di seguito è la stessa descritta nella guida alla distribuzione di openGym; se hai già configurato quel progetto, 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; quindi latest indica l'ultima versione compilata. Imposta il percorso dei dati in una posizione esplicita invece di affidarti a un valore predefinito e assegna una password reale all'account amministratore 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 errore comune più importante del resto del file. 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, senza mostrare errori. 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.

Esegui la build e avvia il servizio:

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 {"status":"ok","version":"..."}. Qualsiasi altro risultato richiede la lettura di docker compose -f docker/docker-compose.yml logs -f octop prima di intervenire dal browser.

Assegna ora un nome descrittivo all'immagine appena creata, perché il comando --build successivo sovrascriverà octop:latest e non avrai modo di distinguere le due immagini:

docker image tag octop:latest octop:0.9.19

Al primo avvio viene eseguito octop init, che 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 molto frequente: 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: riportata sopra esegue il binding su tutte le interfacce del VPS. Non appena il container si avvia, la dashboard è disponibile su Internet in chiaro e con una password predefinita. Il valore predefinito di OCTOP_BIND_HOST per 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 il mapping sia in ascolto soltanto sull'interfaccia loopback:

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

Non cercare di correggere il problema con un semplice file di override. Compose concatena gli elenchi ports dei diversi file invece di sostituirli. Di conseguenza, finiscono per essere pubblicati entrambi i mapping e il secondo non riesce a eseguire il binding. Se vuoi lasciare invariato il file upstream, usa il tag !override sulla sequenza. È il metodo documentato per sostituire gli elementi invece di aggiungerli. La spiegazione di come Compose unisce più file descrive le altre regole di merge.

Il binding sull'interfaccia loopback risolve anche un problema che altrimenti incontreresti con il firewall. Docker scrive le regole per le porte pubblicate nella tabella nat, prima delle chain gestite da ufw. Per questo ufw deny 8088 non blocca una porta pubblicata da un container. Una porta associata a 127.0.0.1 non è mai raggiungibile dall'esterno, indipendentemente dalla configurazione di ufw. Questa è quindi la correzione appropriata, non una soluzione di ripiego.

Configura TLS davanti all’applicazione con un reverse proxy

Caddy è il percorso più breve, perché richiede autonomamente il certificato tramite ACME (automatic certificate management environment) e inoltra i 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 specifica. La chat usa WS /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 viene caricata normalmente, ma ogni messaggio inviato resta bloccato per sempre senza mostrare errori nella pagina. proxy_buffering off è importante perché l’endpoint di ripresa human-in-the-loop restituisce text/event-stream, mentre gli SSE (server-sent events) trattenuti nel buffer del proxy arrivano tutti insieme al termine invece di essere trasmessi in streaming. proxy_read_timeout gestisce le esecuzioni lunghe degli strumenti, perché il timeout predefinito di 60 secondi interrompe un agente a metà attività e registra upstream timed out (110: Connection timed out).

Comportamento dell'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 ci sono il dominio del cookie, il flag Secure o la regola SameSite da configurare in modo errato, quindi una sessione che funziona su http://127.0.0.1:8088 si comporta allo stesso modo su https://octop.example.com.

Prima di utilizzarlo con utenti reali, è importante conoscere due conseguenze.

Il token viene trasmesso dal WebSocket nell'URL. L'endpoint è WS /agents/{id}/chat/ws?token=<jwt>, perché JavaScript del 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 path senza gli argomenti. $uri è il path 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. OCTOP_ACCESS_TOKEN_TTL ha come valore predefinito 86400, quindi un token resta valido per 24 ore dopo il login. L'unico metodo documentato per invalidarne uno è octop admin rotate-jwt-secret, che ruota la signing key archiviata in ~/.octop/secrets/jwt_secret e invalida immediatamente tutti i token ancora validi, per ogni utente. Quando una persona lascia il team, devi quindi seguire questo ordine: elimina l'utente, ruota il secret e chiedi agli utenti rimanenti di eseguire nuovamente il login. Se questa procedura è troppo gravosa, riduci la durata del token, ricordando di aggiungere la variabile all'elenco environment: oltre che a .env:

OCTOP_ACCESS_TOKEN_TTL=28800

La protezione contro i tentativi di forza bruta è già gestita: OCTOP_LOGIN_MAX_ATTEMPTS ha come valore predefinito 5 tentativi falliti e OCTOP_LOGIN_LOCKOUT_SECONDS 900, quindi un utente bloccato deve semplicemente attendere quindici minuti, invece di pensare che l'installazione non funzioni. Octop dispone di un proprio archivio degli utenti e non offre un supporto OIDC documentato nella versione v0.9.19. Se ti serve un vero single sign-on, devi quindi mettere davanti a Octop un proxy che esegua l'autenticazione, come 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, calcolate al 7 agosto 2026. 4 release contrassegnate da tag sono state pubblicate in nove giorni, con un intervallo minimo di 1 giorno; v0.9.19 è arrivata 3 giorni dopo il tag precedente. Questa frequenza è un buon segnale per il progetto, ma un motivo valido per non eseguire latest alla cieca. Leggi le modifiche prima di applicarle:

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"

Esegui sempre prima un backup, perché le migrazioni del database vengono eseguite all'avvio e, in un progetto precedente alla versione 1.0, una migrazione non riuscita è 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

Quindi passa al nuovo tag e ricompila con docker compose -f docker/docker-compose.yml up -d --build. Se qualcosa non funziona, tornare al tag precedente e ricompilare ripristina il codice, ma solo il tarball ripristina il database.

Il tarball contiene octop.db, config.json, il secret usato per la firma JWT e credential.txt, quindi è sensibile quanto il server stesso. Imposta la modalità 600 e conserva una copia fuori dal server. Per installazioni più grandi, 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 si blocca 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. Controllare quindi il proprietario e il gruppo impostati per OCTOP_DATA.

La dashboard si carica, ma la chat si blocca. 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/agents/.../chat/ws. Il proxy non inoltra l'upgrade della connessione. Aggiungere gli header proxy_http_version 1.1, 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à utilizzata da un altro processo. sudo ss -tlnp | grep 8088 ne identifica il processo. Lo stesso errore si verifica se 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 il sistema.

La nuova password in .env non ha avuto effetto. Queste credenziali vengono applicate soltanto 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 per interagire con un modello e svolge bene questo compito per una persona o per un ambiente domestico fidato. 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 molto più matura.

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

Lo script è pubblicato in un bucket Tencent Cloud Object Storage e non nel repository, quindi non è associato ad alcun tag o commit git. Non puoi confrontare ciò che fa oggi con ciò che faceva la settimana scorsa, e reindirizzarlo a bash lo esegue prima che tu possa leggerlo. Inoltre installa il software sull'host usando un proprio ambiente Python 3.12, al di fuori del 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 un preset per Ollama. Per collegarlo a http://host.docker.internal:11434/v1 è sufficiente aggiungere extra_hosts: ["host.docker.internal:host-gateway"] al container e impostare OLLAMA_HOST=0.0.0.0:11434 sull'host. Limita con il firewall la porta 11434 all'intervallo di indirizzi di Docker, perché Ollama non dispone di autenticazione propria. Imposta il valore di num_ctx di Ollama su 16k o superiore. I prompt degli agenti con 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 incluso con Octop pubblica la porta 8088 su tutte le interfacce e non usa TLS. Di conseguenza, password e bearer token attraverserebbero Internet in chiaro. Modifica la porta pubblicata in 127.0.0.1:8088:8088 e configura Caddy o nginx davanti al servizio con un certificato. Con nginx, inoltra gli header per l'upgrade WebSocket e imposta proxy_buffering off. In caso contrario, la pagina verrà caricata, ma la chat non risponderà mai senza mostrare errori.

Octop è pronto per l'uso in produzione?

È ancora precedente alla versione 1.0 e, ad agosto 2026, vengono pubblicati diversi release tag ogni settimana. Consideralo quindi un progetto promettente, non ancora stabile. Può essere una soluzione praticabile per una famiglia o per un piccolo team interno se blocchi una versione tramite un tag preciso, leggi il log dei commit prima di ogni aggiornamento ed esegui un backup del volume dati prima di ogni rebuild. Non eseguirlo su latest e non inserirvi ancora dati dei clienti.