Selbst gehostete Annotationswerkzeuge: Was jedes zum Betrieb braucht und wo man es hostet

Ein selbst gehostetes Annotationswerkzeug braucht vom Server, auf dem es läuft, vier Dinge: einen Datenträger, der Neustarts übersteht, eine Datenbank, die die Dokumentation des Werkzeugs selbst für den Produktivbetrieb empfiehlt, eine Möglichkeit für Annotierende, sich anzumelden, und ein Backup, das Sie mindestens einmal wiederhergestellt haben. Die quelloffenen Werkzeuge unterscheiden sich am stärksten darin, wie viele Dienste sie mitbringen, von einem Container bis zu achtzehn, und diese Zahl bestimmt den größten Teil der Hosting-Arbeit, die eine Studie auf sich nimmt.

Selbsthosten heißt hier, das Annotationswerkzeug auf einem Rechner zu betreiben, den Sie kontrollieren, ob Laborserver, Cloud-Kontingent der Universität oder gemietete VM, sodass die Daten nie über den Dienst eines Anbieters laufen. Selbsthosten ist die übliche Antwort, wenn eine Ethikkommission, eine Datennutzungsvereinbarung oder ein Krankenhaus nicht erlaubt, dass die Daten das Haus verlassen. Der folgende Vergleich behandelt, was eine selbst gehostete Installation von sechs quelloffenen Werkzeugen laut der Dokumentation des jeweiligen Projekts mit Stand Oktober 2026 erfordert, und vergleicht dann Hosts nach Kosten und danach, was sie über einen Neustart hinweg behalten.

Anforderungen einer selbst gehosteten Installation

Jedes der folgenden Werkzeuge speichert drei Arten von Zustand: die zu annotierenden Items (z. B. Text, Bilder, Medien), die Annotationen und die Konten und Projekte, die beides verbinden. Eine selbst gehostete Installation muss alle drei auf einem Datenträger halten, der einen Neustart übersteht, sie an einem anderen Ort sichern und eine Anmeldung davorschalten. Zwei weitere Entscheidungen ergeben sich aus der Architektur des Werkzeugs. Ein Werkzeug, das mit SQLite ausgeliefert wird, empfiehlt für den Produktivbetrieb meist einen Datenbankserver, und ein Werkzeug, das eine Warteschlange, einen Cache oder eine Suchmaschine mitbringt, braucht auch jede dieser Komponenten laufend und persistent. Der größte Teil der Hosting-Arbeit entsteht durch diese zusätzlichen Dienste. Jeder davon ist ein weiterer Container, der gesund bleiben muss, und ein weiteres Volume, das gesichert werden muss, und seine Version muss bei jedem Upgrade mit den anderen kompatibel bleiben.

Sechs Werkzeuge im Vergleich

Die Tabelle fasst zusammen, was die Dokumentation jedes Projekts über eine selbst gehostete Produktivinstallation sagt. „Dienste“ zählt die Container in der Docker-Compose-Referenzdatei des Projekts.

Label Studio läuft als einzelner Container oder als Compose-Stack aus nginx, der App und PostgreSQL. Standardmäßig verwendet es SQLite, und sein Leitfaden zur Speicherung rät, ab 100.000 Tasks mit 5 oder mehr gleichzeitigen Nutzern PostgreSQL in Betracht zu ziehen. Die Installationsanleitung verlangt mindestens 8 GB RAM, empfiehlt 16 GB und empfiehlt für den Produktivbetrieb 50 GB Speicherplatz. Der Vergleich der Editionen führt SAML-SSO, LDAP, rollenbasierte Zugriffskontrolle und Aktivitätsprotokolle als kostenpflichtige Funktionen, und in der Community-Edition kann jeder Nutzer jedes Projekt sehen.

CVAT läuft mit Docker Compose oder auf Kubernetes. Seine Compose-Referenzdatei definiert 18 Dienste, darunter PostgreSQL, Redis, kvrocks als Cache, acht Hintergrund-Worker, Traefik, einen Open-Policy-Agent-Dienst für die Autorisierung sowie einen Analyse-Stack aus ClickHouse und Grafana. CVAT dokumentiert das Backup Schritt für Schritt. Seine Anleitung stoppt die Container, archiviert die Volumes für Datenbank, Medien und Analyse und warnt, dass eine Wiederherstellung genau dieselbe CVAT-Version braucht. LDAP ist für die Community-Edition dokumentiert, während OIDC- und SAML-Single-Sign-on als Enterprise gekennzeichnet sind.

doccano startet als einzelner Container mit SQLite, und seine Compose-Datei für den Produktivbetrieb ergänzt Celery, RabbitMQ, nginx und PostgreSQL. Seine Installationsanleitung warnt, dass ein Upgrade des Pakets eine SQLite-Datenbank verliert. Es dokumentiert die Anmeldung über GitHub und Okta. Mit Stand Oktober 2026 ist seine neueste Version auf PyPI 1.8.4 vom Juli 2023, und eine im Januar 2026 auf GitHub veröffentlichte 1.8.5 wurde auf PyPI zurückgezogen.

Argilla lässt sich auf Hugging Face Spaces oder mit Docker Compose bereitstellen, wo Server, ein Worker, PostgreSQL, Elasticsearch und Redis zusammen laufen. Elasticsearch 8.5 oder OpenSearch 2.4 ist erforderlich, und der Deployment-Leitfaden merkt an, dass die meisten Probleme beim Deployment mit Elasticsearch zu tun haben. Auf einem kostenlosen Space ohne persistenten Speicher gehen bei einem Neustart Datensätze, Workspaces und Nutzer verloren. Die neueste Version stammt vom März 2025.

INCEpTION läuft als Java-Anwendung oder als Container, mit MariaDB als empfohlener Produktivdatenbank, weil die eingebettete HSQLDB beschädigt werden kann, wenn der Rechner abstürzt. Annotationen und Texte liegen in Dateien unter seinem Home-Ordner, und der Admin-Leitfaden behandelt Backup und Wiederherstellung auf Systemebene vollständig, mit einem Backup-Abschnitt, der mit der Warnung beginnt, dass „ein Backup, das sich nicht erfolgreich wiederherstellen lässt, wertlos ist“.

Potato läuft als ein einziger Prozess, aus pip oder aus einem einzelnen Docker-Image. Die Arbeit jeder annotierenden Person wird in einer Datei unter dem Ausgabeverzeichnis gespeichert, die Projektdaten in SQLite daneben, und MySQL ist eine Option, keine Voraussetzung. Der Prozess hält den Item-Pool und die Zuweisungswarteschlange im Speicher, daher läuft er mit einem einzigen gunicorn-Worker und mehr Threads und wächst durch den Umzug auf einen größeren Rechner statt durch zusätzliche Server. Die Anmeldung über Google, GitHub, Hugging Face oder jeden OIDC-Anbieter ist Teil des quelloffenen Pakets und wird unter authentication.providers konfiguriert.

Die Zahl der Dienste spiegelt jeweils die Aufgaben wider, die ein Werkzeug übernimmt. Die achtzehn Dienste von CVAT umfassen eigene Worker für Import, Export, Chunking und Qualitätsberichte, einen Analyse-Stack und richtlinienbasierte Autorisierung, was ein großes Team mit einer langlebigen Installation nutzen kann. Argilla braucht eine Suchmaschine für seine Datensätze. Potato bleibt bei einem Container, was zu einer Studie passt, die ein Labor aufsetzt, wochenlang betreibt und wieder abbaut.

Hosts nach Kosten und Persistenz des Datenträgers

Jedes dieser Werkzeuge läuft auf einer VM mit Docker, und die wichtigste Entscheidung ist, ob der Datenträger des Hosts einen Neustart übersteht. Die folgenden Kosten sind die Schätzungen, die Potato 2.10 für seine potato deploy-Ziele in den Standardgrößen ausgibt, und dieselben Rechner betreiben die anderen Werkzeuge zum selben Preis, vorbehaltlich des Speicherbedarfs des jeweiligen Werkzeugs.

Jetstream2 ist eine von der NSF finanzierte Forschungscloud, daher zahlen Forschende in den USA mit einer ACCESS-Allokation nichts, und jede Instanz erhält einen DNS-Namen mit einem gewöhnlichen Zertifikat. Der Pauschalpreis von Lightsail umfasst die IPv4-Adresse und einen 60-GB-Datenträger, und Lightsail braucht nur lightsail:* sowie sts:GetCallerIdentity, was zu einer eingeschränkten IAM-Rolle einer Universität passt. Eine Lightsail-Instanz mit 2 GB reicht für Potato, während das von Label Studio angegebene Minimum von 8 GB einen größeren Plan erfordert.

Backups auf Hosts, die den Datenträger löschen

Heroku löscht den Datenträger jeden Tag, und die kostenlose Stufe von Render sowie Hugging Face Spaces verlieren ihn beim Neustart. Eine Studie auf einem dieser Hosts braucht ein Backup, das sich auch wiederherstellen lässt, sonst findet eine zurückkehrende annotierende Person eine leere Aufgabe vor.

Ab Version 2.10 kopiert Potatos backup-Block die Annotationsausgabe und Snapshots der Projektdatenbanken standardmäßig alle fünf Minuten in ein Hugging-Face-Dataset oder einen S3-kompatiblen Bucket und stellt sie wieder her, wenn ein Server mit leerem Datenträger startet. Die Wiederherstellung bringt die Konten mit den Annotationen zurück, sodass Annotierende sich mit denselben Passwörtern anmelden und dort weitermachen, wo sie aufgehört haben, und sie überschreibt nie Annotationen, die bereits auf dem Datenträger liegen. Fügen Sie diesen Block in eine Konfiguration ein, mit HF_TOKEN in der Umgebung des Servers und installiertem Extra hosting:

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

potato deploy up richtet dasselbe Backup mit --backup hf oder --backup s3 ein und stellt ohne Backup nicht auf Heroku oder einem Hugging Face Space bereit, es sei denn, --demo erklärt die Annotationen für entbehrlich. Render, Railway, Fly und ECS Express verlangen in jedem Fall ein Backup, weil das Projekt diese Hosts über den Speicher des Backups erreicht. Auf Hosts, deren Datenträger erhalten bleibt, hält das Backup trotzdem eine zweite Kopie außerhalb des Servers vor, die auch eine gelöschte Instanz abdeckt und nicht nur einen Neustart.

Testen Sie, ganz gleich mit welchem Werkzeug, die Wiederherstellung vor Beginn der Studie. Starten Sie eine frische Instanz aus dem Backup, melden Sie sich als annotierende Person an und prüfen Sie, ob Ihre letzte Annotation da ist. Bei Potato kopiert potato deploy pull alles, was ein Deployment gesammelt hat, auf Ihren Rechner, und potato deploy destroy entfernt kein Deployment, das nie gepullt wurde. Führen Sie am Ende einer Studie also zuerst den Pull aus. Potato lokal oder in der Cloud ausführen enthält den Befehl für jeden Host.

Weiterführende Lektüre

• Produktionseinrichtung, zu gunicorn, Docker und dem Reverse Proxy
• SSO und OAuth, zur Konfiguration von Anmeldeanbietern
• Annotationswerkzeuge im Vergleich, zu den Funktionen statt zum Hosting