सेल्फ़-होस्टेड एनोटेशन टूल: हर एक को चलाने के लिए क्या चाहिए और उसे कहाँ होस्ट करें
सेल्फ़-होस्टेड इंस्टॉल के लिए Label Studio, CVAT, doccano, Argilla, INCEpTION और Potato की सेवाओं, डेटाबेस, साइन-इन और बैकअप पर तुलना, साथ में लागत के अनुसार होस्ट।
सेल्फ़-होस्टेड एनोटेशन टूल को उस सर्वर से चार चीज़ें चाहिए जिस पर वह चलता है: एक डिस्क जो रीस्टार्ट के बाद भी बनी रहे, एक ऐसा डेटाबेस जिसकी सिफ़ारिश टूल के अपने दस्तावेज़ प्रोडक्शन के लिए करते हैं, एनोटेटरों के साइन इन करने का एक तरीका, और एक बैकअप जिसे आप कम से कम एक बार रिस्टोर कर चुके हों। ओपन-सोर्स टूलों में सबसे बड़ा अंतर इस बात का है कि वे अपने साथ कितनी सेवाएँ लाते हैं, एक कंटेनर से लेकर अठारह तक, और होस्टिंग का ज़्यादातर काम जो किसी अध्ययन पर आता है, वह इसी संख्या से तय होता है।
यहाँ सेल्फ़-होस्टिंग का मतलब है एनोटेशन टूल को ऐसी मशीन पर चलाना जो आपके नियंत्रण में हो, चाहे वह लैब का सर्वर हो, विश्वविद्यालय का क्लाउड आवंटन हो या किराए का VM, ताकि डेटा कभी विक्रेता की सेवा से होकर न गुज़रे। जब कोई नैतिकता बोर्ड, डेटा-उपयोग समझौता या अस्पताल डेटा को बाहर जाने नहीं देता, तो सेल्फ़-होस्टिंग ही आम जवाब होता है। नीचे की तुलना बताती है कि छह ओपन-सोर्स टूलों के सेल्फ़-होस्टेड इंस्टॉल को क्या चाहिए, अक्टूबर 2026 तक हर प्रोजेक्ट के दस्तावेज़ के अनुसार, और फिर होस्टों की तुलना लागत से और इस बात से करती है कि रीस्टार्ट के बाद उनमें क्या बचा रहता है।
सेल्फ़-होस्टेड इंस्टॉल की ज़रूरतें
नीचे का हर टूल तीन तरह की स्थिति संग्रहीत करता है: एनोटेट किए जाने वाले आइटम (जैसे टेक्स्ट, इमेज, मीडिया), एनोटेशन, और वे खाते और प्रोजेक्ट जो इन्हें आपस में जोड़ते हैं। सेल्फ़-होस्टेड इंस्टॉल को ये तीनों एक ऐसी डिस्क पर रखने होते हैं जो रीस्टार्ट के बाद बनी रहे, उनका बैकअप कहीं और रखना होता है, और उनके आगे एक साइन-इन लगाना होता है। दो और विकल्प टूल की बनावट से निकलते हैं। जो टूल SQLite के साथ आता है, वह आम तौर पर प्रोडक्शन के लिए डेटाबेस सर्वर की सिफ़ारिश करता है, और जो टूल किसी क्यू, कैश या सर्च इंजन के साथ आता है, उसे इनमें से हर एक चलता हुआ और स्थायी भी चाहिए। होस्टिंग का ज़्यादातर काम इन्हीं अतिरिक्त सेवाओं से आता है। हर एक एक और कंटेनर है जिसे ठीक हालत में रखना है और एक और वॉल्यूम है जिसका बैकअप लेना है, और हर अपग्रेड पर उसका संस्करण बाकियों के साथ संगत रहना चाहिए।
छह टूलों की तुलना
तालिका सारांश देती है कि हर प्रोजेक्ट का दस्तावेज़ सेल्फ़-होस्टेड प्रोडक्शन इंस्टॉल के बारे में क्या कहता है। "सेवाएँ" प्रोजेक्ट की संदर्भ Docker Compose फ़ाइल के कंटेनर गिनता है।
| टूल | समर्थित रूप | सेवाएँ | डेटाबेस | मुफ़्त संस्करण में SSO | सर्वर बैकअप गाइड |
|---|---|---|---|---|---|
| Label Studio | pip, Docker, Compose, Helm | 3 | डिफ़ॉल्ट रूप से SQLite, बड़े पैमाने पर PostgreSQL की सिफ़ारिश | SAML SSO और LDAP केवल Enterprise में | केवल Enterprise दस्तावेज़ में |
| CVAT | Compose, Helm | 18 | PostgreSQL | Community के लिए LDAP दस्तावेज़ित; OIDC और SAML SSO Enterprise में | हाँ |
| doccano | pip, Docker, Compose | 6 | डिफ़ॉल्ट रूप से SQLite, प्रोडक्शन Compose में PostgreSQL | GitHub और Okta OAuth | नहीं मिली |
| Argilla | Hugging Face Spaces, Compose | 5 | डिफ़ॉल्ट रूप से SQLite, PostgreSQL समर्थित, साथ में Elasticsearch या OpenSearch | OAuth2 और Keycloak | केवल डेटासेट निर्यात |
| INCEpTION | JAR, Docker, Compose | 2 | एम्बेडेड HSQLDB, प्रोडक्शन के लिए MariaDB की सिफ़ारिश | SAML2 और OIDC | हाँ |
| Potato | pip, Docker, potato deploy | 1 | फ़ाइलें और SQLite, MySQL वैकल्पिक | OAuth और OIDC प्रदाता | HF या S3 पर बिल्ट-इन बैकअप |
Label Studio एक कंटेनर के रूप में या nginx, ऐप और PostgreSQL के Compose स्टैक के रूप में चलता है। यह डिफ़ॉल्ट रूप से SQLite का उपयोग करता है, और इसकी स्टोरेज गाइड कहती है कि 5 या ज़्यादा समवर्ती उपयोगकर्ताओं के साथ 100,000 से ज़्यादा टास्क होने पर PostgreSQL पर विचार करें। इंस्टॉल गाइड कम से कम 8 GB RAM माँगती है, 16 GB की सिफ़ारिश करती है, और प्रोडक्शन के लिए 50 GB डिस्क की सिफ़ारिश करती है। संस्करण तुलना SAML SSO, LDAP, भूमिका-आधारित पहुँच और गतिविधि लॉग को सशुल्क सुविधाओं में गिनाती है, और Community संस्करण में हर उपयोगकर्ता हर प्रोजेक्ट देख सकता है।
CVAT Docker Compose के रूप में या Kubernetes पर चलता है। इसकी संदर्भ Compose फ़ाइल 18 सेवाएँ परिभाषित करती है, जिनमें PostgreSQL, Redis, कैशिंग के लिए kvrocks, आठ बैकग्राउंड वर्कर, Traefik, ऑथराइज़ेशन के लिए एक Open Policy Agent सेवा, और एक ClickHouse और Grafana एनालिटिक्स स्टैक शामिल हैं। CVAT बैकअप को कदम-दर-कदम दस्तावेज़ित करता है। इसकी गाइड कंटेनरों को रोकती है, डेटाबेस, मीडिया और एनालिटिक्स वॉल्यूम को आर्काइव करती है, और चेतावनी देती है कि रिस्टोर के लिए ठीक वही CVAT संस्करण चाहिए। Community संस्करण के लिए LDAP दस्तावेज़ित है, जबकि OIDC और SAML सिंगल साइन-ऑन Enterprise के रूप में चिह्नित हैं।
doccano SQLite के साथ एक कंटेनर के रूप में शुरू होता है, और इसकी प्रोडक्शन Compose फ़ाइल Celery, RabbitMQ, nginx और PostgreSQL जोड़ती है। इसकी इंस्टॉल गाइड चेतावनी देती है कि पैकेज अपग्रेड करने पर SQLite डेटाबेस खो जाता है। यह GitHub और Okta साइन-इन को दस्तावेज़ित करता है। अक्टूबर 2026 तक PyPI पर इसकी सबसे नई रिलीज़ 1.8.4 है, जुलाई 2023 की, और जनवरी 2026 में GitHub पर प्रकाशित 1.8.5 को PyPI से yank कर दिया गया था।
Argilla Hugging Face Spaces पर या Docker Compose के साथ डिप्लॉय होता है, जहाँ सर्वर, एक वर्कर, PostgreSQL, Elasticsearch और Redis साथ चलते हैं। Elasticsearch 8.5 या OpenSearch 2.4 ज़रूरी है, और डिप्लॉयमेंट गाइड बताती है कि डिप्लॉयमेंट की ज़्यादातर समस्याएँ Elasticsearch से जुड़ी होती हैं। स्थायी स्टोरेज के बिना मुफ़्त Space पर, रीस्टार्ट होने पर डेटासेट, वर्कस्पेस और उपयोगकर्ता खो जाते हैं। इसकी सबसे हाल की रिलीज़ मार्च 2025 की है।
INCEpTION एक Java ऐप्लिकेशन या कंटेनर के रूप में चलता है, और प्रोडक्शन के लिए इसका सुझाया गया डेटाबेस MariaDB है, क्योंकि मशीन क्रैश होने पर इसका एम्बेडेड HSQLDB खराब हो सकता है। एनोटेशन और टेक्स्ट इसके होम फ़ोल्डर के तहत फ़ाइलों में रहते हैं, और एडमिन गाइड सिस्टम-स्तर के बैकअप और रिस्टोर को पूरी तरह समझाती है, जिसका बैकअप खंड इस चेतावनी से शुरू होता है कि "जिस बैकअप को सफलतापूर्वक रिस्टोर नहीं किया जा सकता, वह बेकार है"।
Potato एक प्रोसेस के रूप में चलता है, pip से या एक अकेली Docker इमेज से। हर एनोटेटर का काम आउटपुट डायरेक्टरी के तहत एक फ़ाइल में संग्रहीत होता है, प्रोजेक्ट डेटा उसके बगल में SQLite में होता है, और MySQL एक विकल्प है, ज़रूरत नहीं। प्रोसेस आइटम पूल और असाइनमेंट क्यू को मेमोरी में रखता है, इसलिए यह एक gunicorn वर्कर और ज़्यादा थ्रेड के साथ चलता है, और सर्वर जोड़कर नहीं, बड़ी मशीन पर जाकर बढ़ता है। Google, GitHub, Hugging Face या किसी भी OIDC प्रदाता से साइन-इन ओपन-सोर्स पैकेज का हिस्सा है, जिसे authentication.providers के तहत कॉन्फ़िगर किया जाता है।
हर टूल की सेवाओं की संख्या उन कामों को दर्शाती है जो वह अपने ज़िम्मे लेता है। CVAT की अठारह सेवाओं में इंपोर्ट, एक्सपोर्ट, चंकिंग और क्वालिटी रिपोर्ट के लिए अलग वर्कर, एक एनालिटिक्स स्टैक और पॉलिसी-आधारित ऑथराइज़ेशन हैं, जिनका उपयोग लंबे समय तक चलने वाला इंस्टॉलेशन चलाने वाली बड़ी टीम कर सकती है। Argilla को अपने डेटासेट के लिए एक सर्च इंजन चाहिए। Potato एक कंटेनर तक सीमित रहता है, जो ऐसे अध्ययन के लिए उपयुक्त है जिसे एक लैब सेट करती है, हफ़्तों चलाती है और फिर समेट देती है।
लागत और डिस्क की स्थायित्व के अनुसार होस्ट
इनमें से कोई भी टूल Docker वाले VM पर चलता है, और मुख्य चुनाव यह है कि क्या होस्ट की डिस्क रीस्टार्ट के बाद बनी रहती है। नीचे की लागतें वे अनुमान हैं जो Potato 2.10 अपने potato deploy लक्ष्यों के लिए उनके डिफ़ॉल्ट आकारों पर छापता है, और वही मशीनें बाकी टूलों को भी उसी कीमत पर चलाती हैं, हर टूल की मेमोरी ज़रूरतों के अधीन।
| होस्ट | मासिक लागत | डिस्क रीस्टार्ट के बाद बनी रहती है |
|---|---|---|
| AWS Lightsail, 2 GB | $12 | हाँ |
| Hetzner Cloud, 2 vCPU और 4 GB | लगभग €6 | हाँ |
| 1 GB वॉल्यूम के साथ Fly.io Machine | लगभग $6 | हाँ |
| Jetstream2, ACCESS आवंटन के साथ | मुफ़्त | हाँ |
| Render वेब सेवा | मुफ़्त, या $7 और डिस्क | केवल सशुल्क डिस्क के साथ |
| Heroku Basic dyno | $7 | नहीं |
| Hugging Face Docker Space | PRO या Team प्लान | नहीं |
Jetstream2 NSF से वित्त पोषित एक शोध क्लाउड है, इसलिए ACCESS आवंटन वाला कोई अमेरिकी शोधकर्ता कुछ नहीं चुकाता, और हर इंस्टेंस को एक सामान्य सर्टिफ़िकेट के साथ एक DNS नाम मिलता है। Lightsail की तय कीमत में IPv4 पता और 60 GB डिस्क शामिल है, और इसे केवल lightsail:* और sts:GetCallerIdentity चाहिए, जो विश्वविद्यालय की सीमित IAM भूमिका के लिए उपयुक्त है। 2 GB का Lightsail इंस्टेंस Potato के लिए काफ़ी है, और Label Studio के बताए 8 GB न्यूनतम के लिए बड़ा प्लान चाहिए।
डिस्क मिटाने वाले होस्ट पर बैकअप
Heroku हर दिन डिस्क मिटा देता है, और Render के मुफ़्त टियर और Hugging Face Spaces पर रीस्टार्ट होने पर डिस्क खो जाती है। इनमें से किसी होस्ट पर चलने वाले अध्ययन को ऐसा बैकअप चाहिए जो रिस्टोर भी हो, वरना लौटने वाले एनोटेटर को खाली टास्क मिलता है।
संस्करण 2.10 से, Potato का backup ब्लॉक एनोटेशन आउटपुट और प्रोजेक्ट डेटाबेस के स्नैपशॉट को किसी Hugging Face डेटासेट या S3-संगत बकेट में, डिफ़ॉल्ट रूप से हर पाँच मिनट में, कॉपी करता है, और जब सर्वर खाली डिस्क के साथ शुरू होता है तो उन्हें रिस्टोर करता है। रिस्टोर एनोटेशन के साथ खाते भी वापस लाता है, इसलिए एनोटेटर उन्हीं पासवर्ड से साइन इन करते हैं और जहाँ रुके थे वहीं से जारी रखते हैं, और यह डिस्क पर पहले से मौजूद एनोटेशन को कभी ओवरराइट नहीं करता। सर्वर के एनवायरनमेंट में HF_TOKEN सेट करके और hosting एक्स्ट्रा इंस्टॉल करके, यह ब्लॉक कॉन्फ़िग में जोड़ें:
backup:
schedule_minutes: 5
restore_on_boot: true
sinks:
- type: huggingface
repo_id: lab/pilot-annotationspotato deploy up यही बैकअप --backup hf या --backup s3 के साथ जोड़ता है, और यह बिना बैकअप के Heroku या किसी Hugging Face Space पर डिप्लॉय नहीं करेगा, जब तक कि --demo एनोटेशन को फेंकने लायक घोषित न करे। Render, Railway, Fly और ECS Express को हर हाल में बैकअप चाहिए, क्योंकि प्रोजेक्ट इन होस्टों तक बैकअप के स्टोरेज के ज़रिए ही पहुँचता है। जिन होस्टों की डिस्क बनी रहती है, उन पर भी बैकअप सर्वर से बाहर एक दूसरी कॉपी रखता है, जो रीस्टार्ट के साथ-साथ डिलीट हुए इंस्टेंस से भी बचाती है।
टूल चाहे जो हो, अध्ययन शुरू होने से पहले रिस्टोर परख लें। बैकअप से एक नया इंस्टेंस शुरू करें, एनोटेटर के रूप में साइन इन करें, और जाँचें कि आपका किया आखिरी एनोटेशन वहाँ है। Potato के लिए, potato deploy pull किसी डिप्लॉयमेंट का एकत्र किया सब कुछ आपकी मशीन पर कॉपी करता है, और potato deploy destroy ऐसे डिप्लॉयमेंट को नहीं हटाएगा जिसे कभी पुल नहीं किया गया, इसलिए अध्ययन के अंत में पहले पुल चलाएँ। Potato को लोकल या क्लाउड में चलाना में हर होस्ट के लिए कमांड है।
आगे पढ़ें
- प्रोडक्शन सेटअप, gunicorn, Docker और रिवर्स प्रॉक्सी के लिए
- SSO और OAuth, साइन-इन प्रदाताओं को कॉन्फ़िगर करने के लिए
- एनोटेशन टूलों की तुलना, होस्टिंग के बजाय सुविधाओं के लिए