Strumenti di annotazione self-hosted: che cosa serve a ciascuno per girare e dove ospitarlo

Uno strumento di annotazione self-hosted chiede quattro cose al server su cui gira: un disco che sopravviva ai riavvii, un database che la documentazione dello strumento stesso raccomandi per la produzione, un modo per far accedere gli annotatori e un backup che hai ripristinato almeno una volta. Gli strumenti open source si differenziano soprattutto per quanti servizi si portano dietro, da un container a diciotto, e quel numero determina gran parte del lavoro di hosting che uno studio si prende in carico.

Self-hosting qui significa eseguire lo strumento di annotazione su una macchina che controlli, che sia un server di laboratorio, un'allocazione sul cloud dell'università o una VM in affitto, così che i dati non passino mai dal servizio del fornitore. Il self-hosting è la risposta abituale quando un comitato etico, un accordo sull'uso dei dati o un ospedale non permette che i dati escano. Il confronto qui sotto copre che cosa richiede un'installazione self-hosted di sei strumenti open source, secondo la documentazione di ciascun progetto a ottobre 2026, e poi confronta gli host in base al costo e a ciò che conservano attraverso un riavvio.

I requisiti di un'installazione self-hosted

Ogni strumento qui sotto conserva tre tipi di stato: gli item da annotare (per esempio testo, immagini, media), le annotazioni, e gli account e i progetti che li tengono insieme. Un'installazione self-hosted deve tenere tutti e tre su un disco che sopravviva a un riavvio, farne il backup altrove e metterci davanti un login. Altre due scelte derivano dall'architettura dello strumento. Uno strumento che viene distribuito con SQLite di solito raccomanda un server di database per la produzione, e uno strumento che viene distribuito con una coda, una cache o un motore di ricerca ha bisogno che anche ciascuno di questi sia in esecuzione e persistente. La maggior parte del lavoro di hosting viene da quei servizi aggiuntivi. Ognuno è un altro container da tenere in salute e un altro volume di cui fare il backup, e la sua versione deve restare compatibile con le altre a ogni aggiornamento.

Sei strumenti a confronto

La tabella riassume che cosa dice la documentazione di ciascun progetto su un'installazione self-hosted di produzione. "Servizi" conta i container nel file Docker Compose di riferimento del progetto.

Label Studio gira come un singolo container o come uno stack Compose con nginx, l'app e PostgreSQL. Usa SQLite per default, e la sua guida allo storage dice di considerare PostgreSQL sopra i 100.000 task con 5 o più utenti contemporanei. La guida all'installazione chiede almeno 8 GB di RAM, ne raccomanda 16 GB e raccomanda 50 GB di disco per la produzione. Il confronto tra le edizioni elenca SSO SAML, LDAP, accesso basato sui ruoli e log delle attività come funzioni a pagamento, e nell'edizione Community ogni utente può vedere ogni progetto.

CVAT gira con Docker Compose o su Kubernetes. Il suo file Compose di riferimento definisce 18 servizi, tra cui PostgreSQL, Redis, kvrocks per la cache, otto worker in background, Traefik, un servizio Open Policy Agent per l'autorizzazione e uno stack di analytics con ClickHouse e Grafana. CVAT documenta il backup passo per passo. La sua guida ferma i container, archivia i volumi del database, dei media e delle analytics, e avverte che un ripristino richiede esattamente la stessa versione di CVAT. LDAP è documentato per l'edizione Community, mentre il single sign-on OIDC e SAML è indicato come Enterprise.

doccano parte come un singolo container con SQLite, e il suo file Compose di produzione aggiunge Celery, RabbitMQ, nginx e PostgreSQL. La sua guida all'installazione avverte che aggiornare il pacchetto fa perdere un database SQLite. Documenta il login con GitHub e Okta. A ottobre 2026 la sua release più recente su PyPI è la 1.8.4, di luglio 2023, e una 1.8.5 pubblicata su GitHub a gennaio 2026 è stata ritirata (yanked) da PyPI.

Argilla si installa su Hugging Face Spaces o con Docker Compose, dove girano insieme il server, un worker, PostgreSQL, Elasticsearch e Redis. È richiesto Elasticsearch 8.5 oppure OpenSearch 2.4, e la guida al deployment nota che la maggior parte dei problemi di deployment riguarda Elasticsearch. Su uno Space gratuito senza storage persistente, un riavvio fa perdere dataset, workspace e utenti. La sua release più recente risale a marzo 2025.

INCEpTION gira come applicazione Java o come container, con MariaDB come database raccomandato per la produzione, perché il suo HSQLDB integrato può corrompersi quando la macchina va in crash. Annotazioni e testi stanno in file sotto la sua cartella home, e la guida per gli amministratori tratta per intero il backup e il ripristino a livello di sistema, con una sezione sul backup che si apre con l'avvertenza che "un backup che non può essere ripristinato con successo non vale nulla".

Potato gira come un singolo processo, da pip o da una sola immagine Docker. Il lavoro di ogni annotatore viene salvato in un file sotto la directory di output, con i dati del progetto in SQLite accanto, e MySQL è un'opzione e non un requisito. Il processo tiene in memoria il pool degli item e la coda di assegnazione, quindi gira con un solo worker gunicorn e più thread, e cresce passando a una macchina più grande invece che aggiungendo server. Il login tramite Google, GitHub, Hugging Face o qualsiasi provider OIDC fa parte del pacchetto open source e si configura sotto authentication.providers.

Il numero di servizi di ogni strumento riflette i compiti che si assume. I diciotto servizi di CVAT comprendono worker separati per importazione, esportazione, chunking e report di qualità, uno stack di analytics e un'autorizzazione basata su policy, che un team grande con un'installazione di lunga durata può sfruttare. Argilla richiede un motore di ricerca per i suoi dataset. Potato si limita a un container, il che si adatta a uno studio che un laboratorio allestisce, fa girare per settimane e poi smonta.

Gli host per costo e persistenza del disco

Ognuno di questi strumenti gira su una VM con Docker, e la scelta principale è se il disco dell'host sopravvive a un riavvio. I costi qui sotto sono le stime che Potato 2.10 stampa per i suoi target di potato deploy alle dimensioni predefinite, e le stesse macchine fanno girare gli altri strumenti allo stesso prezzo, fatte salve le esigenze di memoria di ciascuno strumento.

Jetstream2 è un cloud per la ricerca finanziato dalla NSF, quindi un ricercatore statunitense con un'allocazione ACCESS non paga nulla, e ogni istanza riceve un nome DNS con un certificato ordinario. Il prezzo fisso di Lightsail include l'indirizzo IPv4 e un disco da 60 GB, e richiede solo lightsail:* più sts:GetCallerIdentity, il che si adatta a un ruolo IAM universitario con permessi ristretti. Un'istanza Lightsail da 2 GB basta per Potato, mentre il minimo dichiarato di 8 GB di Label Studio richiede un piano più grande.

I backup sugli host che cancellano il disco

Heroku cancella il disco ogni giorno, e il piano gratuito di Render e gli Spaces di Hugging Face lo perdono al riavvio. Uno studio su uno di questi host ha bisogno di un backup che si possa anche ripristinare, altrimenti un annotatore che ritorna trova un task vuoto.

Dalla versione 2.10, il blocco backup di Potato copia l'output delle annotazioni e degli snapshot dei database del progetto su un dataset Hugging Face o su un bucket compatibile con S3, per default ogni cinque minuti, e li ripristina quando un server parte con il disco vuoto. Il ripristino riporta gli account insieme alle annotazioni, quindi gli annotatori accedono con le stesse password e riprendono da dove si erano fermati, e non sovrascrive mai le annotazioni già presenti sul disco. Aggiungi questo blocco a una configurazione, con HF_TOKEN impostato nell'ambiente del server e l'extra hosting installato:

backup:
  schedule_minutes: 5
  restore_on_boot: true
  sinks:
    - type: huggingface
      repo_id: lab/pilot-annotations

potato deploy up aggiunge lo stesso backup con --backup hf o --backup s3, e non esegue il deploy su Heroku o su uno Space di Hugging Face senza un backup, a meno che --demo non dichiari le annotazioni sacrificabili. Render, Railway, Fly ed ECS Express lo richiedono in ogni caso, perché il progetto raggiunge quegli host attraverso lo storage del backup. Sugli host il cui disco è persistente, il backup tiene comunque una seconda copia fuori dal server, che copre un'istanza cancellata oltre che un riavvio.

Qualunque sia lo strumento, prova il ripristino prima che inizi lo studio. Avvia una nuova istanza dal backup, accedi come annotatore e controlla che l'ultima annotazione che hai fatto ci sia. Per Potato, potato deploy pull copia sulla tua macchina tutto ciò che un deployment ha raccolto, e potato deploy destroy non rimuove un deployment da cui non è mai stato fatto un pull, quindi alla fine di uno studio esegui prima il pull. Eseguire Potato in locale o nel cloud contiene il comando per ogni host.

Approfondimenti

• Configurazione di produzione, per gunicorn, Docker e il reverse proxy
• Autenticazione SSO e OAuth, per configurare i provider di login
• Strumenti di annotazione a confronto, per le funzioni anziché per l'hosting