Ferramentas de anotação auto-hospedadas: o que cada uma precisa para rodar e onde hospedá-la

Uma ferramenta de anotação auto-hospedada precisa de quatro coisas do servidor em que roda: um disco que sobreviva a reinicializações, um banco de dados que a própria documentação da ferramenta recomende para produção, uma forma de os anotadores fazerem login e um backup que você já tenha restaurado pelo menos uma vez. As ferramentas de código aberto diferem sobretudo em quantos serviços trazem consigo, de um contêiner a dezoito, e esse número determina a maior parte do trabalho de hospedagem que um estudo assume.

Auto-hospedar significa aqui rodar a ferramenta de anotação em uma máquina que você controla, seja um servidor do laboratório, uma cota de nuvem da universidade ou uma VM alugada, para que os dados nunca passem pelo serviço do fornecedor. Auto-hospedar é a resposta habitual quando um comitê de ética, um acordo de uso de dados ou um hospital não deixa os dados saírem. A comparação abaixo cobre o que uma instalação auto-hospedada de seis ferramentas de código aberto exige, segundo a documentação de cada projeto em outubro de 2026, e depois compara hosts por custo e pelo que mantêm depois de uma reinicialização.

Requisitos de uma instalação auto-hospedada

Todas as ferramentas abaixo guardam três tipos de estado: os itens a anotar (por exemplo, texto, imagens, mídia), as anotações e as contas e projetos que ligam tudo isso. Uma instalação auto-hospedada precisa manter os três em um disco que sobreviva a uma reinicialização, fazer backup deles em outro lugar e colocar um login na frente deles. Mais duas escolhas decorrem da arquitetura da ferramenta. Uma ferramenta que vem com SQLite costuma recomendar um servidor de banco de dados para produção, e uma ferramenta que vem com uma fila, um cache ou um motor de busca precisa que cada um deles também esteja rodando e persistido. A maior parte do trabalho de hospedagem vem desses serviços extras. Cada um é mais um contêiner para manter saudável e mais um volume para incluir no backup, e sua versão precisa continuar compatível com as dos outros a cada atualização.

Seis ferramentas comparadas

A tabela resume o que a documentação de cada projeto diz sobre uma instalação auto-hospedada de produção. "Serviços" conta os contêineres no arquivo Docker Compose de referência do projeto.

Label Studio roda como um contêiner ou como uma stack Compose com nginx, o app e PostgreSQL. Usa SQLite por padrão, e seu guia de armazenamento diz para considerar o PostgreSQL acima de 100.000 tarefas com 5 ou mais usuários simultâneos. O guia de instalação pede pelo menos 8 GB de RAM, recomenda 16 GB e recomenda 50 GB de disco para produção. A comparação de edições lista SSO SAML, LDAP, controle de acesso por papéis e logs de atividade como recursos pagos, e na edição Community todo usuário pode ver todos os projetos.

CVAT roda com Docker Compose ou no Kubernetes. Seu arquivo Compose de referência define 18 serviços, entre eles PostgreSQL, Redis, kvrocks para cache, oito workers em segundo plano, Traefik, um serviço Open Policy Agent para autorização e uma stack de análise com ClickHouse e Grafana. O CVAT documenta o backup passo a passo. Seu guia para os contêineres, arquiva os volumes do banco de dados, de mídia e de análise e avisa que uma restauração precisa exatamente da mesma versão do CVAT. O LDAP é documentado para a edição Community, enquanto o login único OIDC e SAML aparece marcado como Enterprise.

doccano começa como um contêiner com SQLite, e seu arquivo Compose de produção acrescenta Celery, RabbitMQ, nginx e PostgreSQL. Seu guia de instalação avisa que atualizar o pacote faz perder um banco de dados SQLite. Ele documenta login pelo GitHub e pelo Okta. Em outubro de 2026, sua versão mais recente no PyPI é a 1.8.4, de julho de 2023, e uma 1.8.5 publicada no GitHub em janeiro de 2026 foi retirada (yanked) do PyPI.

Argilla é implantado no Hugging Face Spaces ou com Docker Compose, em que o servidor, um worker, PostgreSQL, Elasticsearch e Redis rodam juntos. Elasticsearch 8.5 ou OpenSearch 2.4 é obrigatório, e o guia de implantação observa que a maioria dos problemas de implantação envolve o Elasticsearch. Em um Space gratuito sem armazenamento persistente, uma reinicialização faz perder datasets, workspaces e usuários. Sua versão mais recente é de março de 2025.

INCEpTION roda como aplicação Java ou como contêiner, com o MariaDB como banco de dados recomendado para produção, porque seu HSQLDB embutido pode se corromper quando a máquina trava. Anotações e textos ficam em arquivos dentro da pasta home dele, e o guia de administração cobre por completo o backup e a restauração no nível do sistema, com uma seção de backup que abre com o aviso de que "um backup que não pode ser restaurado com sucesso não vale nada".

Potato roda como um único processo, a partir do pip ou de uma única imagem Docker. O trabalho de cada anotador é guardado em um arquivo dentro do diretório de saída, com os dados do projeto em SQLite ao lado, e o MySQL é uma opção, não um requisito. O processo mantém o conjunto de itens e a fila de atribuição na memória, então roda com um worker do gunicorn e mais threads, e cresce passando para uma máquina maior, não acrescentando servidores. O login pelo Google, GitHub, Hugging Face ou qualquer provedor OIDC faz parte do pacote de código aberto e é configurado em authentication.providers.

O número de serviços de cada ferramenta reflete as tarefas que ela assume. Os dezoito serviços do CVAT carregam workers separados para importação, exportação, divisão em blocos e relatórios de qualidade, uma stack de análise e autorização baseada em políticas, o que uma equipe grande com uma instalação de longa duração consegue aproveitar. O Argilla exige um motor de busca para seus datasets. O Potato se limita a um contêiner, o que serve para um estudo que um laboratório monta, roda por semanas e desmonta.

Hosts por custo e persistência do disco

Qualquer uma dessas ferramentas roda em uma VM com Docker, e a principal escolha é se o disco do host sobrevive a uma reinicialização. Os custos abaixo são as estimativas que o Potato 2.10 imprime para seus destinos de potato deploy nos tamanhos padrão, e as mesmas máquinas rodam as outras ferramentas pelo mesmo preço, sujeitas às necessidades de memória de cada ferramenta.

O Jetstream2 é uma nuvem de pesquisa financiada pela NSF, então um pesquisador nos EUA com uma alocação ACCESS não paga nada, e cada instância recebe um nome DNS com um certificado comum. O preço fixo do Lightsail inclui o endereço IPv4 e um disco de 60 GB, e ele só precisa de lightsail:* mais sts:GetCallerIdentity, o que combina com um papel IAM restrito de universidade. Uma instância Lightsail de 2 GB comporta o Potato, e o mínimo declarado de 8 GB do Label Studio precisa de um plano maior.

Backups em hosts que apagam o disco

O Heroku apaga o disco todos os dias, e o plano gratuito do Render e os Hugging Face Spaces o perdem ao reiniciar. Um estudo em um desses hosts precisa de um backup que também restaure, ou um anotador que volta encontra uma tarefa vazia.

A partir da versão 2.10, o bloco backup do Potato copia a saída das anotações e snapshots dos bancos de dados do projeto para um dataset do Hugging Face ou um bucket compatível com S3, por padrão a cada cinco minutos, e os restaura quando um servidor inicia com o disco vazio. A restauração traz de volta as contas junto com as anotações, então os anotadores entram com as mesmas senhas e continuam de onde pararam, e ela nunca sobrescreve anotações que já estão no disco. Acrescente este bloco a uma configuração, com HF_TOKEN definido no ambiente do servidor e o extra hosting instalado:

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

potato deploy up acrescenta o mesmo backup com --backup hf ou --backup s3, e não implanta no Heroku nem em um Hugging Face Space sem um, a menos que --demo declare as anotações descartáveis. Render, Railway, Fly e ECS Express exigem um em todos os casos, porque o projeto chega a esses hosts pelo armazenamento do backup. Em hosts cujo disco persiste, o backup ainda mantém uma segunda cópia fora do servidor, o que cobre uma instância apagada além de uma reinicialização.

Seja qual for a ferramenta, teste a restauração antes de o estudo começar. Inicie uma instância nova a partir do backup, entre como anotador e confira se a última anotação que você fez está lá. No Potato, potato deploy pull copia para a sua máquina tudo o que uma implantação coletou, e potato deploy destroy não remove uma implantação que nunca passou por um pull, então rode o pull primeiro ao final de um estudo. Executar o Potato localmente ou na nuvem tem o comando para cada host.

Leitura adicional

• Configuração de produção, sobre gunicorn, Docker e o proxy reverso
• SSO e OAuth, sobre a configuração de provedores de login
• Ferramentas de anotação comparadas, sobre os recursos, e não a hospedagem