Herramientas de anotación autoalojadas: qué necesita cada una para funcionar y dónde alojarla

Una herramienta de anotación autoalojada necesita cuatro cosas del servidor en el que se ejecuta: un disco que sobreviva a los reinicios, una base de datos que la propia documentación de la herramienta recomiende para producción, una forma de que los anotadores inicien sesión y una copia de seguridad que hayas restaurado al menos una vez. Las herramientas de código abierto se diferencian sobre todo en cuántos servicios traen consigo, de un contenedor a dieciocho, y ese número determina la mayor parte del trabajo de alojamiento que asume un estudio.

Aquí, autoalojar significa ejecutar la herramienta de anotación en una máquina que controlas, ya sea un servidor del laboratorio, una asignación en la nube de la universidad o una VM alquilada, de modo que los datos nunca pasen por el servicio del proveedor. Autoalojar es la respuesta habitual cuando un comité de ética, un acuerdo de uso de datos o un hospital no permiten que los datos salgan. La comparación de abajo cubre lo que requiere una instalación autoalojada de seis herramientas de código abierto, según la documentación de cada proyecto en octubre de 2026, y después compara alojamientos por coste y por lo que conservan tras un reinicio.

Requisitos de una instalación autoalojada

Todas las herramientas de abajo guardan tres tipos de estado: los ítems que hay que anotar (por ejemplo, texto, imágenes o archivos multimedia), las anotaciones, y las cuentas y los proyectos que los vinculan. Una instalación autoalojada tiene que guardar los tres en un disco que sobreviva a un reinicio, hacer copia de seguridad en otro lugar y poner un inicio de sesión delante. De la arquitectura de la herramienta se derivan dos decisiones más. Una herramienta que viene con SQLite suele recomendar un servidor de base de datos para producción, y una herramienta que viene con una cola, una caché o un motor de búsqueda necesita que cada uno de ellos también esté en marcha y persista. La mayor parte del trabajo de alojamiento viene de esos servicios adicionales. Cada uno es otro contenedor que mantener sano y otro volumen del que hacer copia de seguridad, y su versión tiene que seguir siendo compatible con las demás en cada actualización.

Seis herramientas comparadas

La tabla resume lo que dice la documentación de cada proyecto sobre una instalación autoalojada de producción. «Servicios» cuenta los contenedores del archivo Docker Compose de referencia del proyecto.

Label Studio se ejecuta como un contenedor o como una pila de Compose con nginx, la aplicación y PostgreSQL. Usa SQLite por defecto, y su guía de almacenamiento aconseja plantearse PostgreSQL a partir de 100 000 tareas con 5 o más usuarios simultáneos. La guía de instalación pide al menos 8 GB de RAM, recomienda 16 GB y recomienda 50 GB de disco para producción. La comparación de ediciones recoge SAML SSO, LDAP, el control de acceso por roles y los registros de actividad como funciones de pago, y en la edición Community cada usuario puede ver todos los proyectos.

CVAT se ejecuta con Docker Compose o en Kubernetes. Su archivo Compose de referencia define 18 servicios, entre ellos PostgreSQL, Redis, kvrocks para la caché, ocho procesos de trabajo en segundo plano, Traefik, un servicio Open Policy Agent para la autorización y una pila de analítica con ClickHouse y Grafana. CVAT documenta la copia de seguridad paso a paso. Su guía detiene los contenedores, archiva los volúmenes de la base de datos, de los archivos multimedia y de la analítica, y advierte de que una restauración necesita exactamente la misma versión de CVAT. LDAP está documentado para la edición Community, mientras que el inicio de sesión único con OIDC y SAML aparece marcado como Enterprise.

doccano arranca como un contenedor con SQLite, y su archivo Compose de producción añade Celery, RabbitMQ, nginx y PostgreSQL. Su guía de instalación advierte de que actualizar el paquete hace perder una base de datos SQLite. Documenta el inicio de sesión con GitHub y Okta. En octubre de 2026, su versión más reciente en PyPI es la 1.8.4, de julio de 2023, y una 1.8.5 publicada en GitHub en enero de 2026 se retiró de PyPI.

Argilla se despliega en Hugging Face Spaces o con Docker Compose, donde el servidor, un proceso de trabajo, PostgreSQL, Elasticsearch y Redis se ejecutan juntos. Requiere Elasticsearch 8.5 u OpenSearch 2.4, y la guía de despliegue señala que la mayoría de los problemas de despliegue tienen que ver con Elasticsearch. En un Space gratuito sin almacenamiento persistente, un reinicio hace perder los conjuntos de datos, los espacios de trabajo y los usuarios. Su versión más reciente es de marzo de 2025.

INCEpTION se ejecuta como una aplicación Java o en un contenedor, con MariaDB como base de datos recomendada para producción, porque su HSQLDB integrada puede corromperse cuando la máquina se cae. Las anotaciones y los textos se guardan en archivos dentro de su carpeta de inicio, y la guía de administración trata por completo la copia de seguridad y la restauración a nivel de sistema, con una sección sobre copias de seguridad que empieza con la advertencia de que «una copia de seguridad que no se puede restaurar con éxito no vale nada».

Potato se ejecuta como un único proceso, desde pip o desde una sola imagen Docker. El trabajo de cada anotador se guarda en un archivo dentro del directorio de salida, con los datos del proyecto en SQLite al lado, y MySQL es una opción, no un requisito. El proceso mantiene en memoria la reserva de ítems y la cola de asignación, así que se ejecuta con un solo worker de gunicorn y más hilos, y crece pasando a una máquina más grande, no añadiendo servidores. El inicio de sesión con Google, GitHub, Hugging Face o cualquier proveedor OIDC forma parte del paquete de código abierto y se configura en authentication.providers.

El número de servicios de cada herramienta refleja las tareas que asume. Los dieciocho servicios de CVAT incluyen procesos de trabajo separados para la importación, la exportación, la fragmentación y los informes de calidad, una pila de analítica y una autorización basada en políticas, que puede aprovechar un equipo grande con una instalación de larga duración. Argilla requiere un motor de búsqueda para sus conjuntos de datos. Potato se limita a un contenedor, lo que encaja con un estudio que un laboratorio monta, ejecuta durante semanas y desmonta.

Alojamientos por coste y persistencia del disco

Cualquiera de estas herramientas funciona en una VM con Docker, y la decisión principal es si el disco del alojamiento sobrevive a un reinicio. Los costes de abajo son las estimaciones que Potato 2.10 muestra para sus destinos de potato deploy con sus tamaños por defecto, y las mismas máquinas ejecutan las demás herramientas al mismo precio, según las necesidades de memoria de cada una.

Jetstream2 es una nube de investigación financiada por la NSF, así que un investigador de EE. UU. con una asignación de ACCESS no paga nada, y cada instancia recibe un nombre DNS con un certificado normal. El precio fijo de Lightsail incluye la dirección IPv4 y un disco de 60 GB, y solo necesita lightsail:* más sts:GetCallerIdentity, lo que encaja con un rol de IAM restringido de una universidad. Una instancia de Lightsail de 2 GB es suficiente para Potato, y el mínimo declarado de 8 GB de Label Studio necesita un plan mayor.

Copias de seguridad en alojamientos que borran el disco

Heroku borra el disco cada día, y el nivel gratuito de Render y los Spaces de Hugging Face lo pierden al reiniciar. Un estudio en uno de esos alojamientos necesita una copia de seguridad que además se restaure, o un anotador que vuelve se encuentra una tarea vacía.

Desde la versión 2.10, el bloque backup de Potato copia la salida de anotación e instantáneas de las bases de datos del proyecto a un conjunto de datos de Hugging Face o a un bucket compatible con S3, por defecto cada cinco minutos, y las restaura cuando un servidor arranca con el disco vacío. La restauración recupera las cuentas junto con las anotaciones, así que los anotadores inician sesión con las mismas contraseñas y siguen donde lo dejaron, y nunca sobrescribe anotaciones que ya estén en el disco. Añade este bloque a una configuración, con HF_TOKEN definido en el entorno del servidor y el extra hosting instalado:

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

potato deploy up añade la misma copia de seguridad con --backup hf o --backup s3, y no despliega en Heroku ni en un Space de Hugging Face sin ella, salvo que --demo declare que las anotaciones son desechables. Render, Railway, Fly y ECS Express la exigen en todos los casos, porque el proyecto llega a esos alojamientos a través del almacenamiento de la copia de seguridad. En los alojamientos cuyo disco sí persiste, la copia de seguridad sigue guardando una segunda copia fuera del servidor, lo que cubre tanto una instancia eliminada como un reinicio.

Sea cual sea la herramienta, prueba la restauración antes de que empiece el estudio. Arranca una instancia nueva a partir de la copia de seguridad, inicia sesión como anotador y comprueba que está la última anotación que hiciste. En Potato, potato deploy pull copia a tu máquina todo lo que ha recogido un despliegue, y potato deploy destroy no elimina un despliegue del que nunca se ha hecho pull, así que al final de un estudio ejecuta primero el pull. Ejecutar Potato en local o en la nube tiene el comando para cada alojamiento.

Lecturas adicionales

• Configuración de producción, sobre gunicorn, Docker y el proxy inverso
• Autenticación SSO y OAuth, sobre cómo configurar los proveedores de inicio de sesión
• Herramientas de anotación con IA, comparadas, sobre las funciones y no el alojamiento